While skimming the book, Lean Software Development: An Agile Toolkit
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
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.
I am in complete agreement. All activities you are doing for a project should add value. Don’t document for document sake. If it adds value do it. This concept should hold true regardless of development methodology.
I agree too.
Where documentation is required I think we need to ask ourselves how much of the document is enough to get the point across. Very often I see people getting bogged down trying to fill out each section of a templated document, wondering what goes into a section. Just forget that section and move on is my usual response, since there should be a feedback loop in place which will identify if that section was truly required or not.
I used to see people immediately jump in to a charting tool like Visio to document a flow or process, but now I see them more and more draw on a whiteboard and then paste the image, which is much quicker. I’m a big fan of the whiteboard and camera approach.