45% of large organisations have less detailed documentation since moving to Agile
The now legendary Agile Manifesto, published in 2001, outlines the fundamental principles of Agile software development. It values “working software over comprehensive documentation”. This core value asks us to think about how much and which kinds of documents are needed and when they need to be written.
Agile seeks to minimise waste, so there is a common misconception that Agile means no documentation at all.
It means we prioritise working software over documentation. Documentation should be concise and essential.
43% of the organisations we spoke to in our recent research have over promised clients based on a lack of understanding around Agile. If you don’t get the documentation down, and don’t have the design, then you will spend time (guaranteed) doing re-work. If there is no adequate planning to distribute the work amongst teams and make sure they each know what they’re responsible for, then you will spend more time in the middle of the project and at the end re-factoring the code to get to the solution that was originally intended.
Let’s use the analogy of building a house – if you started without the blueprint and went straight to throwing up the walls and then added the roof and built out from there. There is a chance the house will come falling down because the foundation was overlooked. On top of that, what’s to say you used bricks and forgot to cement each brick in place. You’d need to start again, which costs time and money and results in running late. It’s an example that would more than likely never happen, but that is because the method in place is tried and tested, and a design is followed. No one ever deviated from waterfall’s documented processes because it was tried and tested, so why do it for agile? It was designed to improve the time to delivery, not take short-cuts, but when people insist on creating short-cuts it falls flat on its face. 59% of organisations we spoke to for our recent research say agile processes are not always properly followed in their organisation.
Our approach is to make sure we document what our customers want. This becomes our guide. The scoping phase is the most important part of the project. It ensures we can deliver to expectations, on time and on budget. Communication is absolutely essential. Where are we with the project? What’s next? What are we learning, what changes can we make to improve things etc. Documentation (which can be lightweight initially) serves as a blueprint on which to build upon.
Our blog in the coming weeks will focus on more results from the report so stay tuned for more updates.