Table of Contents

Introduction

This article calls out practices adopted and adapted from agile programming and scrum project management to technical content publishing.
In this context agile development and scrum project management used as a set of tools vs. complete solution. 

Agility is...

Following are few practices, values, and approaches that were successfully adopted and adapted in technical content publishing. The practices were applied to produce successful technical content. 
  • Adaptability 
  • Backlog
  • Burndown
  • Simplicity
  • Iteration
  • Sprint
  • Stories 
  • TDD 
  • Transparency
  • Vision
  • Working content 

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
  • Components/Features
  • Functionality
  • Scenarios/Solutions
  • Guidelines/Quality
  • T-shooting
  • How-to’s
  • Samples
  • Reference
One simple and easy example for delivering working increment of content is producing one of the elements of the IA above. For example, "Getting Started" iteration may include several sprints that produce Getting Started content. By the end of the "Getting Started" iteration end user, the reader, is able to use the technical content to get started with particular technology.

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.
  • 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 reps 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. 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 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.

References