Documentation – a detailed one at that – has been the backbone of all project managers’ work. We all have been through the drills where we created detailed documents with each business case and each requirement in excruciating detail.
Once the documents were created, those documents stood still. So many times we have seen that those documents, often created in the beginning of the project, were often irrelevant by the end of the project. Most probably because the goal posts had changed. The terms and the requirements or even the objectives changed.
Paraphrasing a quote I had read in childhood – “if in the last few months you have not acquired or rejected a major opinion, check your pulse you may be dead!” Organizations are living organisms. Simply because they are a composite whole comprising living and breathing human beings. As humans change, the world changes – so do the organizations.
And, most of what we thought was the basis of every work we were supposed to do, becomes redundant.
In came Agile. Agile project management practices have a completely different viewpoint when it comes to documentation. For them, a document is part of the delivery. Not a deliverable. Something that the waterfall traditionalist will find tough to understand or even appreciate.
For the waterfall traditionalists, documents are deliverables. They are detailed and often overlapping. Probably because there is some kind of security in knowing that even when you couldn’t deliver the result of the project, at least you delivered the documents which detailed how it could have been done! Had it been done right, of course!
This chart brings out the difference between the two approaches – Waterfall/Traditional and Agile – pretty clearly.
The timing for the documentation shifts down the project timelines, when the facts documented have reached a level of maturity. Until then, documentation is mostly high level.
While waterfall produces too much of documentation, sometimes Agile fanatics produce too little. There needs to be a balance between the two.
The reason why documentation needs reduce within Agile as opposed to Waterfall is how the teams are structured. In Agile, the team including the business, the SMEs, the developers and the decision makers are part of the scrum. The stories, the backlog, the decisions, the planning and delivery demos are done together.
In waterfall, however, the work is compartmentalized.
Developers very rarely interact with the business folks directly. That is the purview of the Business Analysts. BAs act as interpreters and communication agents between the two. Unlike in Agile, where even when BAs may do that liaison, they do so more based on their experience of being the bridge as opposed to the only go-between. Both, business and IT, interact along with BAs. Not just through them.
This means that over documentation to compensate for the “error in translation” is lesser. All three – IT developers, business users, and BAs – are on the same page for every backlog and its requirement.
These are the documents that teams regularly create in a Waterfall project.
- Business Requirement Document
- Functional Design Document – Current State and Future State
- Technical Design Document – Current State and Future State
- Configuration Document
- Test Strategy
- Test Cases – Integration testing and User Acceptance Testing
- Communication Plan
- RACI Chart
- System Design and Architectural documentation
