Skip to main content

Comprehensive Documentation Strikes Back

IT community members catechized on the Agile Manifesto will recall that the original signers placed a higher value on "working software" than on "comprehensive documentation." But is working software in isolation our ultimate goal?  I think that as the Agile community has moved in the direction of delivering value, rather than just delivering working software, we are now newly realizing we need more than just rich face-to-face conversations at white boards.  We need accessible archives populated by well-structured documents which have been written in full sentences.  It's time to even the balance.

An early Tech Writer
Scott Ambler has done the Agile community a huge service with frequent and comprehensive surveys to determine what people are actually doing in the field, and how well it's working (see this Ambysoft page for a full list of his surveys and results).  As Ambler reviewed his results in 2008, he was surprised to find that Agile projects are actually more likely, and not less likely, than their traditional counterparts to produce "comprehensive documentation" such as "user manual, operations documentations, support documentation, system overview documentation."  Ambler explains this result by saying:
So, I was thinking about this a bit; and what I think was going on is one of the things that we do know, is that Agilists are actually more likely to deliver than traditionalists. That type of documentation is something that you would write towards the end of the project as things stabilize. So, I think what’s going on is Agilists are more likely to get to the end, therefore, they are more likely to do the type of work that you would do at the end, which is finish up this documentation. That’s my theory at least. I can’t back that up with real numbers but that’s what the trend appears to… (both quotations from Ambler, 2008)
One of the joys of early Agile development was its return to a mode of working which is natural for humans: small groups, close proximity, verbal communication, shared whiteboard drawing, project management through tactile movement of cards or sticky notes around on a big visual chart.  And what about actually being able to sit and talk issues through completely in one sitting rather than futilely exchanging emails in stolen moments between other meetings?  The success and happiness of these early teams is literally hard-wired into our DNA, if you believe in socio-biology, and it is intuitively beguiling to the point that today (again by Ambler's count) over 76% of American corporations are at least dabbling in Agile techniques, despite very few on-the-ground measures of what the return on investment might be.

The importance of wide-band face-to-face communication as part of the software development process is undeniable.  But I believe this heady success has led some people to confuse what is "necessary" with what is "sufficient."  As Agile teams embraced this rich and necessary form of communication, proponents began to assert that immediate, personal, and primarily verbal or visual communcations forms were better than their written alternative in most or all settings and contexts.  See for example this widely distributed chart on the "effectiveness" of communications methods.  It is completely brilliant, and worth reproducing even if I weren't quibbling with it:


Anyone who has done any greenfield software development at all will attest to the validity of this chart in expressing the best way to do "modeling," if that is defined as the creative and iterative process of determining what needs to be done, and how it should be done.

Anyone who has ever done production support of a legacy, or "brownfield" application of any vintage, however, will likely find some fault with the lower curve on the diagram, describing the best way to write lasting documentation.  And in fact, even greenfield developers may disagree that incorporating the visual picture is the sole predictor of either "richness" of communication or overall "effectiveness."
  • If you have a "system down" situation, do you want to bring up a video (if you can find it) and watch it through to figure out what might be going wrong?
  • How many times have you silently mouthed the words "Oh thank goodness!" or the equivalent when someone dug up an old yellowed computer printout for you that had the complete set of metadata translations typed out along with pithy descriptions of what the terms meant in context at the time the application was originally written?
  • And truthfully, how many times have you been grateful that someone took comprehensive minutes during your brainstorming meeting to put context around your architectural diagram, capture intent, and record immediate action items?  How handy was that email to you?  If you were there, do you now want to watch the whole meeting again on video, complete with incomprehensible low-volume discussions you can't hear, nose-blowing, groin-area adjustments, and long-winded tangents from people who aren't usually that annoying (or who are)?  If you weren't able to attend the meeting, how much will you get from the video?
When you introduce a time parameter into the evaluation, the graph looks a little different:
I don't mean to trivialize the achievement of early Agile adopters who have brought people back into the process, nor do I propose to claim that comprehensive written documentation is more important than written code.  Using what Jim Highsmith calls "And" Leadership, I'm saying that we should keep both the baby AND the bath water.

No, wait.

I mean we shouldn't throw out the use of written communication for post-facto documentation just because we want to get rid of big speculative requirements drafting.  For the long term, written communication can do some things that video can't do, and even in-person communication can't.  When you've had that really long, contentious meeting, it's extremely helpful for the consensus you've reached to be neatly summarized in words and whatever pictures are necessary.  Otherwise, you're going to have the argument again tomorrow, in two weeks, and/or next year.

Over time, the delivery of business value depends almost as much on the delivery of comprehensive documentation as it does on the delivery of working software.  Let the light saber wars begin.

Comments

  1. Not sure what the y-axis is supposed to represent in the second graph? If it's similar to the original (i.e., richness of communication), then you'd expect diagrams to be both richer and more effective over time than non-diagrammed text.

    ReplyDelete
  2. Hey Jason! You know, I did think I mis-plotted the final two points on the graphs--written documentation with diagrams would definitely have better longevity than written documentation without them. The y axis is supposed to represent inclusion of text in the document. Thanks for reading this so carefully!

    ReplyDelete
  3. Good way to represent the importance of face to face communication to elicit requirements and importance of documenting for the long term survival of the product

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica