OK, back again for part four of the Scrum Myth-Buster series and this time we are entering into agile taboo territory… documentation…
So this is a major myth that I’m sure you’ve all heard before many times over, the perception being that Scrum is anti-documentation (especially detailed documentation and this is why we utilize the ole’ User Story format). Doesn’t the Agile Manifesto back up this assertion? i.e. “We prefer working software over comprehensive documentation”. Well this myth has led to one of the most common catch-cries of the infamous Agile Cowboy – we don’t document, we’re agile! Well the problem with these cowboys is the fact that they are either unaware of, or choose to ignore the important footnote inherent within the manifesto: “That is, while there is value in the items on the right, we value the items on the left more”.
What this message is telling us is that there is in fact still value in the items on the right. The point is that they instead need to be treated as a means to an end rather than as the end unto themselves. In other words, these items need to be fit for purpose to support us in the context that we’re working within.
For example, if we’re a startup with three employees working in a garage, do we really need to communicate via 200 page spec documents and complicated collaboration tools? Of course not.
On the other hand lets say we’re a multinational finance organization, working with distributed teams all over the world and needing to adhere to various audit standards, then guess what? We’re going to need much more formalized documentation. In fact we’re going to need more of everything on the right hand side and that is not a bad thing or ‘anti-agile’ if it is necessary and supporting our end goal of creating working and relevant products.
The reality is that documentation could well form a vital part of your product. A software application is not just code and its working tests either. In many cases, there is documentation that is required for a number of potential reasons – audit requirements, support documentation and end-user documentation to name a few.
If documentation is required then we don’t shy away from it. Instead, we ascertain nice and early what is actually required for our collective team memory and ensure that it is treated just as seriously as any other element in our Definition of Done for each requirement we build.
There is a big difference between generating documentation for memory rather than using it to create an artificial perception of upfront control. Scrum in conjunction with the User Story format is not about eliminating detail and documentation. It is about getting the right level of detail at the right time.
Once again, I thank you my fellow mythbusters for joining me on the fourth leg of our truth-revealing journey. See you next time when we tackle the next Scrum myth!
If you liked this article, you can:
Subscribe to this RSS feed!
Find out more about documentation in Scrum by taking one of our CSPO training courses.