It is precisely because of these dangerous statements, which I call dangerous half-knowledge, that I am now taking the time to go into detail about the Agile Manifesto. Because I want to make it clear that the part of the sentence on the right is important, the part on the left is only considered more important .
Definition of Done helps
The fact is that even in an agile environment, extensive documentation is required.
Especially when using Scrum, the necessary documentation can be defined very well, for example via the Definition of Done (DoD):
- What documentation do we need?
- Where do we put it?
Documentation is not recorded in the DoD as the work package that is still to be done at the end or remains open because there is no more time or it has simply been forgotten in the heat of development. Instead, it is firmly anchored from the outset via the Definition of Done and is therefore included in the estimate of the work in advance. Just like the product itself, the DoD is developed and worked on incrementally.
Background to the statement in the Agile Manifesto
But why was such a sentence included in the Agile Manifesto, which often leads to false statements and plays into the hands of the opponents of agility so well if you don't know the manifesto better?
If we consider a sequential approach, it is characterized on the one hand by the fact that one phase must first be completed in order to start the next phase. This usually means that a lot of time and effort is first invested in creating an all-encompassing requirements specification. The specifications should be "perfect" and cover all the requirements that you want to have later - even if you don't yet know exactly what you want. In response to this "work" - many specifications are heavy and it is often doubtful that anyone really reads these "tomes" in their entirety - a functional specification is then written just as laboriously and intensively in response. Once this new "masterpiece" has been completed, it may (at some point) be ready for implementation. At the end of the realization phase, the product that was previously requested in detail in the specifications will hopefully be available. However, the customer then often realizes that he didn't want it that way and had imagined it differently. Until then, however, a lot of paper or digital data is created, much of which is never looked at again and in the end reworking of the product is still necessary.
In lean, we refer to this as "waste". At the same time, with a sequential approach, it is easy to lose sight of the fact that the customer ultimately wants software that works, but is initially overwhelmed with a huge amount of documentation.
Anyone who can still remember the great days of reference models, such as CMMI (Capability Maturity Model Integration), may also be familiar with the problem that the practices and objectives were often misunderstood and many departments and companies tried to prove to some assessors how far advanced they were by providing too much documentation. Usually this did not lead to the desired success, but the assessors quickly realized that there was just a flood of documentation, but nobody was working with it. However, this wave of documentation also left a bad aftertaste and often led to topics such as CMMI or even SPICE being badly burned in a company, as employees equated the models with unnecessary documentation. And it is precisely the word "unnecessary" that contains the core essence.
Conclusion
Documentation is necessary and is also considered necessary in an agile environment. In an agile environment, documentation is created incrementally and iteratively, just like the product. Always with the focus on as much documentation as necessary. When Scrum is used, the Definition of Done is used, among other things, to define what must be documented for the user story to be considered "done".
And always remember: the right side of the agile manifesto is also important! 🙂
Write a comment