Agile for Information Development

By Laura Clymer

Software development methods seem to change more often than the seasons, and just when information development professionals are familiar with one approach a new one comes along.  One method that has received wide acceptance and seems to have some staying power, however, is the Agile software development method.  As described by the Agile Manifesto (2001), Agile software development is:

  • A group of software development methodologies
  • Based on iterative and incremental development
  • Solutions evolve through collaboration of cross-functional teams

(Wikimedia, 2012)

Cross-functional teams comprised of members from all disciplines—including information development—use short, iterative cycles called “sprints” to prioritize and make decisions quickly while delivering fully fleshed-out features that can ship at any time.  This new emphasis on small group interaction and iterative development requires new writing, content review, and front-end engagement approaches for information developers.

The first new approach required involves content creation.  The traditional method of writing content once features are complete, then compiling that content into a book does not work in an Agile environment as it does not allow for short cycles and deliverable by feature.  Iterative development requires iterative writing, something that traditional tools and methods cannot handle; however, iterative writing can be accomplished easily using DITA XML.  DITA XML uses a topic-based schema for technical information creation, and these topics work very well in an Agile environment.  Instead of writing chapters or lengthy paragraphs, information developers focus on concepts, references, or task topics.  The content is delivered as the feature develops, allowing the information developer to react to changes quickly.  These small, self-contained pieces of content are reused through the product as needed, for example as a context-sensitive help system or as part of a marketing brief.  The emphasis is on creation of the needed topics, not an end-to-end deliverable.

One of the hallmarks of the Agile method is the idea of the sprint, a brief stretch of development time that is typically two to four weeks in length depending on the project.  These sprints govern how the product develops, and the goal is to have features that can ship to customers at the end of each sprint; in other words fully tested and documented functionality.  This is entirely different from the more familiar waterfall development method in which all features were developed, tested, documented, and then shipped together.  The Agile method allows a product owner to decide mid-stream to remove or add features, so the product is evolving until the development cycle is complete.

This idea of evolution influences how information developers schedule their work, and directly impacts content reviews.  Given the iterative nature of the product, how can someone schedule a first or second review?  The answer is you cannot, as such things are a waterfall-based approach.  Instead, the Agile information developer manages the review of and sign-off on discrete chunks of content that pertain only to the feature developed as part of each particular sprint,  ensuring that all information associated with that feature is ready to ship at the end of the cycle. The Agile method uses “acceptance criteria”—a set of required criteria that must be met before a feature can be declared complete—to ensure timely review. The team cannot close on a feature unless the information developers’ content is reviewed and signed off by the stakeholders by the end of the sprint.

The front-end engagement process is a final hallmark of the Agile method. In a traditional waterfall method, an information developer creates a documentation plan once the set of features is finalized by engineering and marketing.  Again, given the iterative and ever-changing nature of developing software within the Agile method, this type of final agreement does not happen.  Therefore, an information developer must learn a new planning approach that involves the initial sizing of features for amount of content, and then building out a delivery schedule based on that information.  Agile teams usually employ some type of measurement to determine how much functionality fits into a sprint; this measure applies to information development tasks as well.  By using the same measurement system, all stakeholders understand how much content fits into a sprint and everyone operates at the same pace.

Agile software development is dynamic and fast-paced aimed at providing value to customers at a rapid rate.  Information development is an integral part of the software development team, and as such has a responsibility to embrace the tenets of Agile and apply them to information deliverables for the benefit of the end user.


About the Author:

Laura Clymer is a creative and imaginative information development solutions architect and writer, who helped to lead the transition from unstructured content to DITA XML. She has over 16 years of IT industry experience, a BA degree from UCLA, a master’s degree from Stanford University, and is pursuing an MBA at St. Edwards University. She is currently a Senior Information Development Manager with Dell Inc.

Be Sociable, Share!

One Comment

Comments are closed.