While skimming the book, Lean Software Development: An Agile Toolkit
, I came across a passage that has been on my mind for a few days that I’d like to share.
Many software development processes require paperwork for customer sign-off, or to provide traceability, or to get approval for a change. Does your customer really find this makes the product more valuable to them? Just because paperwork is a required deliverable does not mean that it adds value. A good test of the value of paperwork is to see if there is someone waiting for what is being produced. If an analyst fills out templates, makes tables, or writes use cases that others are eager to use—for coding, testing, and writing training manuals—then these probably add value. Even so, there should be a constant search for the most efficient, effective means to transmit the information. Lean Software Development: An Agile Toolkit
, Mary Poppendieck & Tom Poppendieck, Addison Wesley, 2003
While the book was written in advocacy of agile methods of software development (one of the tenets of the Agile Manifesto is the emphasis on “working software over comprehensive documentation”), I think these ideas also ring true – and perhaps especially so – for “heavier” methodologies.
Now, I’m not knocking documentation in general. There is great value in a spec that represents meaningful, collaborative dialog through which key decisions are made and that expresses stakeholder need in a way that is intuitive to designers, developers and testers. Depending on the company or the industry, there may also be compelling reasons (level of criticality, government regulation, etc.) to produce detailed documentation that, in order to not get too far off-topic, I may address in a later post.
My point is that sometimes we (and I’m talking about myself first and foremost) get so caught up in doing things just because they’re part of “the process” that we neglect to seriously question whether our time might not be better spent on activities that are more likely to hasten the delivery of good software.
The bottom line is that regardless of the process for getting software done, there is no value in paperwork that no one needs and no one cares to read.
Here’s a challenge: Take a look your current delivery model. Does it include documents or regularly performed activities upon which no one is really dependent? Would eliminating them free up resources for value-add activities that might potentially shorten the delivery cycle? If so, how do you go about amending your model?
As always, I’ll be interested to hear your thoughts.
Comments