Scott is the Chief Methodologist for Agile & Lean for IBM Rational.
In This Issue:
- Agile Documentation and Specification Strategies
- Take the "State of the IT Union" Survey and potentially win a copy of Glitch by Jeff Papows.
- Hot Links
Agile Documentation and Specification Strategies
Over the past few months, I’ve had the opportunity to work closely with several organizations across the world to help them to understand how to apply Disciplined Agile Delivery (DAD) strategies at scale. A common issue that they all asked me about was how agile teams approach documentation; but digging deeper, I found that they were struggling with both specification as well as documentation strategies. So here’s my advice on the subject.
My experience is that there’s an important difference between specifications and deliverable documentation, particularly when it comes to how much effort you should invest in their creation. Specifications, as their name implies, define the particulars of something, such as the requirements of a solution or the architecture of that solution. Specifications may be static, captured on paper or electronically using a word processor or even a software-based modeling tool (SBMT). The term "static" refers to the idea that you can’t run the specification, not that the specifications aren’t updated over time. In fact, some “static specifications” prove to be quite dynamic over time, but I’m cruelly playing with the English language when I say such things.
Specifications may also be executable, captured as tests via tools such as Fitnesse or the xUnit framework, or captured as executable models (which may include tests) using tools such as IBM Rational Rhapsody. Executable specifications run, or in the case of some models, have code generated from them that can then be run, and as such will also be dynamic over time as well. Agile practices such as test-driven development (TDD) and agile model driven development (AMDD) with sophisticated SBMTs produce executable specifications as a matter of course.
So why distinguish between static specifications and executable specifications? First, because of the significant value provided to the development team by executable specifications, it is far more likely that the team will keep the specification in sync with the code. In the case of executable tests, they enable the development team to proceed safely with changes. And with executable models, they are in actuality the code itself. Also, executable specifications require greater skill to create and maintain than static specifications. A team taking an executable specification approach will be staffed differently than one taking a static approach, and will likely require more training and mentoring, too. Additionally, executable specifications can reduce your overall cost to produce a solution and reduce time to delivery compared to static specifications. Finally, particularly in the case when you take a TDD-based approach, executable specifications lead to greater quality because you find and fix defects earlier.
But enough about specifications.
Deliverable documentation, on the other hand, is the documentation that you need to provide to your stakeholders as part of your overall solution. This will of course vary between projects, but deliverable documentation typically includes user manuals, training materials, operations manuals, support manuals, and system overviews. It typically does not include static specifications, except of course in regulatory situations where such documentation is required or in contract negotiations where it's mandated as part of the contract. However, because executable specifications are of significant value to the people who will need to maintain and enhance the system over time, they should automatically be included in your deliverable “documentation.” With the exception of executable specifications, deliverable documents are typically static as discussed previously.
Dr. Dobb’s Journal (DDJ)’s 2008 Modeling and Documentation Practices on IT Projects Survey found that agilists were just as likely as traditionalists to produce deliverable documentation. Then, a little over a year later September 2009 DDJ State of the IT Union Survey found that the quality of the documentation being produced by agile teams was of equal quality to that being produced by traditional teams. Unfortunately, both agilists and traditionalists were doing a relatively poor job of it, but at least they were equally crappy. Regardless of paradigm, we can and should be doing better when it comes to deliverable documentation.
When writing deliverable documentation, or any documentation for that matter, the best advice that I can give is to first try to find better ways to capture the information to begin with. Can you write better quality code and thereby reduce the explanatory documentation required (yes, code comments count as documentation)? Can you improve the usability of the user interface and thereby reduce the need for detailed help information? Can you increase the automation of operations activities and thereby reduce the need for detailed operations procedures?
You should also wait for the information to stabilize before you write it down. If you document information that isn't yet stable, you run the risk of having to rework your documentation. You should write any documentation after you've done the majority of the development work, in other words towards the end of an iteration or towards the end of the project itself. Agile Modeling (AM) offers two documentation practices — document continuously and document late — which reflect this concept. Both practices can be applied separately or in combination.
Agile Modeling’s Document Continuously practice advises you to write and maintain deliverable documentation throughout the project lifecycle. Interestingly, based on iteration/sprint length, there proves to be two flavors of this practice. When iterations are long, say four weeks or more, the documentation is written during the actual iteration. With long iterations you have sufficient time for information to stabilize and thereby capture it during that iteration. However, with short iterations, say two weeks or less, you write the documentation during the following iteration (perhaps this should be referred to as Document a Bit Behind). With short iterations it's unlikely that the information will stabilize in time for you to complete the documentation. To remain efficient as possible you should consider writing the deliverable documentation for iteration N during iteration N+1. With medium length iterations (two to four weeks) you will need to experiment to identify which approach works better for you. Interestingly, Ambysoft’s November 2010 Agile State of the Art Survey found that experienced agile teams had an iteration length of 2.3 weeks on average.
By writing deliverable documentation continuously throughout the project, you address both delivery and accuracy risk. By writing the documentation in sync with the rest of the solution, you know you have sufficient documentation to support what you've built to date. The implication is that your solution will in fact be potentially shippable at the end of each iteration. Furthermore, when your team actually follows this practice the documentation is more likely to be accurate because of the short feedback cycle between doing the work and documenting it.
Unfortunately, adoption of a continuous approach to documentation potentially increases three project risks: Financial risk, schedule risk, and accuracy risk. First, financial risk is increased due to the impact of evolving requirements, which require you to evolve existing documentation in pace with changes to the rest of your solution. You are in effect "travelling heavy" from an agile point of view by documenting continuously. Second, schedule risk is increased because it takes time and effort to write and maintain this documentation, and any rework of the documentation resulting from evolving requirements in effect impacts your schedule due to the required rework. Third, in practice accuracy risk is also increased due to human behavior. Sadly, it's easier to claim that you’re documenting continuously than it is to do it, and many teams will unfortunately let their documentation efforts slip and get out of sync with the rest of their work.