Agile Content Development Framework

“Agile content development is not about producing content quickly, but about delivering the right content at the right time to meet the needs of the user.” — Robert Mills

As someone who has worked on building and managing content at Microsoft for more almost two decades, I know firsthand the importance of an effective content development process.

Over the years, I have developed and refined an Agile approach to content development that has proven to be successful in delivering high-quality content while maintaining flexibility and adaptability.

This approach emphasizes collaboration, iteration, and continuous improvement, allowing teams to respond to changing needs and feedback from stakeholders. In this guide, I will share my insights and strategies for implementing Agile content development in your organization.

Agile Content Life Cycle

Here’s a rough picture of the process

Phase	Development
Exploration	Backlog Architecture Spikes Stories / Scenarios Minimum Credible Release Project Planning Vision / Scope
Iteration 0	Team Setup Process Setup Infrastructure Setup
Iteration N (2 weeks)	Backlog Prioritization Incremental Delivery Deliver Working Software Stories / Scenarios Retrospective
Release Prep	Final Acceptance Test Release Work Completed Documentation Finalized
Release	Publish

Examples

I’ve used the Agile Content Development Framework for content efforts small and large.   Some of the larger efforts involved leading virtual teams of 40+ experts around the world.

Here are some of the “Blue Books” at Microsoft I created using the Agile Content Development Framework:

• Building Secure ASP.NET Applications Guide
• Improving .NET Application Performance and Scalability Guide
• Improving Web Application Security Guide
• Performance Testing Guidance
• Team Development with Visual Studio Team Foundation Server Guide
• Windows Communication Foundation Security Guide

Each body of work was several hundred pages of content, as well as a deep knowledge base, and in many cases, videos and multi-media, too.

Here ios a brief explanation of what happens along the way:

Design

The dominant focus here is identifying candidate problems, candidate solutions, and figuring out key risks, as well as testing paths to explore.

The best outcome is a set of scenarios we can execute against.

• Research – finding the right people, the right problems, and the right solutions.
• Prototypes – experiment and test areas of high risk to prove the path.  This can include innovating on how we build prescriptive guidance.  We also use these to test with customers and get feedback on the approach.
• Question Lists – building organized lists of one-liner user questions.
• Task Lists – building organized lists of one-liner user tasks.
• Scenario Frames – organizing scenarios into meaningful buckets.
• Information Models – framing out the problem space and creating useful ways to organize, share, and act on the information.
• Content Types  – testing which guidance types to use (how tos, checklists, guidelines, patterns, … etc.)

Execution

The dominant focus here is product results.  It’s scenario-driven.  Each week we pick scenarios to execute against.

• Development – building prescriptive guidance, including coding, testing, and writing.
• Backlog – our backlog is a prioritized set of scenarios and guidance modules.
• Iterations – picking sets of scenarios to focus development on and test against.
• Refactoring – tuning and pruning the guidance to improve effectiveness.  This includes breaking the content up and rewriting it.  For example, a common refactoring is factoring reference information from action.  We try to keep reference information in our Explained modules and action information in our How Tos.
• Testing –  step through the guidance against the scenario.  The first pass is about making sure it works.  It should be executable by a human.  Next, it’s about reducing friction and making sure the guidance really hits the what, why and how.  We test the guidance against objectives and scenarios with acceptance criteria so we know when we’re done.
• Problem Repros – creating step by step examples that reproduce a given problem.
• Solution Repros – creating step by step examples that reproduce a given solution.

Release

We produce a Knowledge Base (KB) of guidance modules and a guide.

The guidance modules are modular and can be reused.

The guide includes chapters in addition to the guidance modules.

Agile Publishing

We release our content modules along the way to test reactions, get feedback and reshape the approach as needed.

• Web site – we publish our guidance modules to a public Website so we can share early versions of the guidance and get customer feedback, as well as to test the structure of the guidance, and experiment with user experience.
• Desktop tool (Guidance Explorer) – we publish guidance modules to Guidance Explorer so users can do their own guidance mash ups and build their own personalized guides.  Our field also uses this to build customized sets of guidance for customers.

Stable Reference

Once we’ve tested and vetted the guidance and have made it through a few rounds of customer feedback, we push the guidance to an online Website as part of the library — in this case, the Microsoft Developer Network (MSDN).

• MSDN – this is the trusted site that users expect to see our prescriptive guidance in final form.
• Visual Studio/ Visual Studio Team System – once we’re a part of the MSDN distribution, we can automatically take advantage of the tools documentation integration.

You Might Also Like

Agile Architecture Method
Agile Methodology in Microsoft patterns & practices
Extreme Programming at a Glance
How Agile and Lean Help Business
Roles on Agile Teams
Scrum at a Glance
Software Methodologies at a Glance
Waterfall to Agile
What is Agile?