What’s the difference between software and content? None. At least in my view. Both require creative juices to produce and both improve people’s life or productivity. If that’s the case then proven and working practices for creating great software could and should be applied to creating great content. Very few would argue that Agile Development is one of the most successful methods today to create great software. Let me share how I applied some of Agile Development practices in Content Publishing.

What Is Agile Development Anyway?

According to Wikipedia Agile software development (emphasis is mine):

… is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change.

Agile Methods

There are quite a few methods, values, and artifacts to Agile Development but let me focus on vital few in my opinion:

Backlog. This is the simple list of topics needed to be produced.

Sprint. This is the cadence for delivering Working Content.

Stories. This is list of relevant stories from those who would use the content to be successful. For example, “As a developer I need to build secure web site in the cloud.”

TDD. Test Driven Development is about testing everything throughout the whole lifecycle vs. waiting until the end. Best way to test content is involving those who would use the content from the beginning of the project as outlined in Create Effective Technical Content Using Social Networking.

Vision. This is essential. This is the north star for the whole effort. The key part is making sure the vision is super simple and it is a one-liner. For example, Developers Rely On Our Guidance To Effectively Secure Their Cloud Applications.

Working content. This is one of the trickiest parts. In software development working increment is some sort of scenario that end user can accomplish. In content publishing working content is something that one can rely on to create a working increment of software.

Working Increment Of Content

Working increment of content is driven by Information Architecture (IA) that lays out the body of knowledge for specific technology. Key elements of the IA are:

Getting Started. This is collection of very few topics that help you create Hello World app. Usually prerequisites and very basic simple instructions to make it work. The mindset should be “if the user cannot get started in 10 minutes or less (you will have your own threshold) he will walk away.” And if he walks the Getting Started is not working.

Components/Features. This is set of content that describes in details “what’s in the bag.”

Functionality. This is set of very brief topics that describe what you can do with what’s in the bag. Usually it serves to just funnel to other topics. The idea is to provide a common sense vocabulary that funnel into specifics that are not well known.

Scenarios/Solutions. This is list of recipes. The mindset is “if this is your situation and you want to make it work this is what you need to do and this is how.” It is collection of pointer to relevant prescriptive topics to solve specific scenario.

Guidelines/Quality. This is set of topics that help keep it working. It is about non-functional qualities such as security, performance, etc.

T-shooting. When things break and go wrong this is where you go.

How-to’s. These are super key ingredients for Scenarios/Solutions. Prescriptive step-by-step procedures that walk you from zero to something working.

Samples. This is where you go when you don’t want to start from scratch.

Reference. This is key ingredient for the How-To’s and Samples.

To create working increment of content consider picking one Scenario and derive related topics that help cre

Test Driven Content Engineering

Everything related to content is being tested, from initial assumptions during inception to actual topics. Consider the following when testing technical content:

Test content ideas and assumptions against product group’s scenarios. I am sure they had some scenarios in mind when started the development, eh?

Test scenarios to be documented against customer advocates – professional services reps or other front line customer facing individuals.

Test early versions of content on un-SLA’ed online outlets such as blogs and wiki.

Test production grade content against reactive support representatives or other front line customer facing individuals.

Backlog, Velocity, Burndown

Creating backlog is essential. The hard part is to identify what would be the workitem in content publishing space. To solve this look at the IA above and try generative tipics as a workitems for each category. Here are few examples that work well:

How-To (prescriptive content)

Explained (conceptual topic)

API reference

While How-To’s and Explained topics can be easily managed as workitems API reference is not. If the technology has hundreds or more types, classes, members then managing it separately would be a nightmare. The way that worked well is defining a namespace of API’s as a workitem.
Once workitems identified it’s relatively easy to put a “price” tag on it – its velocity. As the content team becomes more mature the topic delivery velocity estimates get more and more precise. Having clear backlog and workitems velocities estimates it’s simple math to project what burndown the team should have to hit the deadline

2 Comments on "Agile Development Applied In Content Publishing"

There is a key different between software and code — software compiles.

That’s the thing our team struggled with the most, while producing content. It was very tough to keep a good working build with conceptual integrity, and make sure that any changes to the content, didn’t “break” the intents.

That’s why I very much focused on a test-driven approach. While we called it “test-driven”, James Newkirk and a few others made a strong case for calling it “test-first” and I think it’s a great choice of words, since we are starting with the tests, but not quite driven by them.

A metaphor that helped our team treat our content (well, knowledge) with more respect, is we would say, “Our content is our code.”

Building great guidance is tough … but the beauty is there are a lot of ways to really reinforce deep insight, and make content more actionable.

JD
That’s the mindset “My code is my content.” And yes, code compile while if the content has a typo it’s still found by Google, and it’s still can be useful. But biggest bugs are usually caused by flawed design vs. code, and this is where the similarity gets even closer.