We have been dealing with the values of the Agile Manifesto for several articles now and we are trying to look at them from a different angle. We first wrote about people in relation to processes, and then about cooperation with clients where we do not stick to contracts so tightly, but build mutual trust.
The third value is literally “Software that works in relation to extensive documentation”.
And perhaps this very value is one of the most controversial. Although it seems very logical, clear and concrete, there are many different interpretations of its meaning.
We talk about this from the experience from our Agile leadership training where the discussion of this value is a real treat and an unavoidable topic, not only for IT teams.
If we rename “software” into “product or service”, this value becomes fully usable in every aspect of today’s business.
“Product or service in relation to extensive project documentation”?
The third value suggests to us that we should focus on the software, product or service. Because it is something that brings us a competitive, but also useable, value. Incremental product development allows us to notice the shortcomings of our product in time and influence it on the go. At the moment of “deviating from the path” of development, when the product does not do what we wanted, the extensive documentation that accompanies it becomes not only useless, but also a “burden” of lost time.
On the other hand, there are a lot of proponents of extensive project documentation, because how will we further explain the product to someone if we have not arranged the whole process on “paper”. How will someone who later joins the project team be able to follow what has been done so far and join the team as well as possible and start giving his full contribution. Or when a team member leaves a project, it often happens that his replacement starts from the beginning because he does not want to deal with countless lines of (unexplained) code or project documentation.
And here we are once again at the beginning. It was not our intention to give you the correct answer to the question at the beginning of this text. We just wanted to point out all the advantages but also the disadvantages of both of these approaches. What is perhaps the best? The answer lies in the balance, the feeling for the client, the market but also for your project team. Adapt to the situation, and make some important decisions in an instant.
It may not be easy, but it’s worth a try.