|An early Tech Writer|
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?
"And" Leadership, I'm saying that we should keep both the baby AND the bath water.
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.