Managing Transition from Waterfall to Agile: Leaving Documentation Behind
All previous notions of documentation have to be discarded while transitioning to agile. This is not as simple as it looks. Organizations are deeply entrenched in a waterfall model to the point where stakeholders view documentation artifacts as indicators of project health and progress. I have seen some projects put milestones based on document delivery dates.
Documentation provides a sense of security to the team members allowing them to fall back to the typical response- “Not my problem, this was not mentioned in the document”. In an agile world, responsibility is shared, decisions are made as a project team and as stated in the agile manifesto — Working product is preferred over Comprehensive Documentation.
Mike Cohn rightly said — Written documents imply a precision that they can’t back.Through years of my own experience in projects as a tester, developer , analyst and as a project manager in waterfall projects I can say with surety that no level of documentation can capture the complete information set within the constraints (time/cost) that are imposed on the project.
One of the advantages of the old processes was that everything was “known”, development knew the requirements and so did the testers , management knew the exact schedule and customers kind of knew what was coming their way . Information was explicit.
While the agile philosophy inherently overcomes the flaw in a documentation focused engineering process, it makes information tacit i.e. available on-demand for e.g. during scrums and through conversations, or the product code itself.
To the project team undergoing this transition from explicit to tacit is scary because it deals with the unknown. And thus questions arise — “how can i estimate when i don’t know the details”.
I believe that to successfully make this transformation requires more planning than usually done. In this post I explain my initial thoughts on managing this transformation
As a project team, take a blank white board and write down the documentation artifacts that have been delivered in the past. Write down the purpose of each document, the information it conveys and the consumers of the document up and down the organizational hierarchy and outside the organization.
Now as the team goes through the list of documents ask how much information presented in that document is covered by the user stories.Understanding that all information will not be available at the time of user story creation, what additional documents will be required to supplement the user stories? Based on the team/organization’s unique processes and need Is it still necessary to provide the same level of information and at what stage should that information be provided.
It is critical to recognize that not all information is required upfront and will be delivered later, but it is equally critical to sketch out templates of the documents or the information artifacts that will be developed as the team progresses through the execution of the project. By doing this you are promising the team members who are still afraid of the unknown that the information will be made available as and when required. Remember these templates/sketches are just that — it it not mandatory to provide that documentation for each user story. The team demands and justifies the development of every document and remembers that in the end the proof is in the pudding (product).
Originally Published as a Linkedin Article: https://www.linkedin.com/pulse/managing-transition-from-waterfall-agile-leaving-vinayak/
