I have been part of several discussions about agile, and how agile teams should (or should not) use documentation during the project.
It is interesting to see that many people see that documentation is a big no-no in Agile.
But, is that true?
Agile manifesto and different agile methodologies (ie SCRUM, Kanban, etc…) brought to software development a different way to approach things, more collaborative and with gains on both product development and team satisfaction to name a few.
Developers that are working on Agile always mention their appreciation to be part of the solution, and not only mere code builders. On top of that, they like Agile because ideally it should have less paperwork or documentation.
It is one of the items at the Manifesto: to give priority to code and working software over documentation. We all heard that every time we talk about documents and governance in Agile projects: “to produce documentation is not the Agile way to do things”, or “we don’t really do documentation in Agile”.
Let’s check the Agile Manifesto. This is what it is written:
“Working software over comprehensive documentation”
It also says:
“That is, while there is value in the items on the right, we value the items on the left more.”
Now, reading these words, it is clear that working software is one of the things that the Agile framework values more than documentation. It does not say “no documentation”. It does say spend more time delivering software and value than on documentation.
There is a fundamental difference here.
This in my view is in part a misconception and a mislead of real world interpretation of the manifesto.
I think it is worth to understand that the Manifesto was written back in 2001. Do you have any idea how software development was back then? Let me tell you, as I was fresh out of college at that time: the company I was working on was very strict on the process, as many of the big tech companies at the time. To change a couple of lines of code, you would need to update between 3-6 documents. Yes, to change a If statement you could impact this amount of documents. That means create some, update others and review all with the team. Now, how many people really read those documents after it is implemented? Not many, and if you compare the value of the software you just changed versus the amount of documentation the process was requiring you to change, it seems obvious the reason why the Manifesto (and most developers) would say less documentation. It does make sense.
Agile as a framework focus on delivery value often and in short periods of time. On highly regulated fields, delivering value also means good documentation in compliance with internal processes. This is what they need. There is no point for an organization to have great software but fail on compliance and pay penalties and fees due to lack of documentation as required by regulations.
Let’s take for example highly regulated areas like financial or healthcare institutions. These type of organizations needs a well structured project governance, thus documentation, due to it’s regulatory and audit requirements. If that is the case, can they use agile? Absolutely yes.
Governance documentation needs to be understood as part of bringing value to the organization. Only in that way the organization can fully take advantage of the benefits of agile.
And just to be sure: eliminate all the unnecessary documentation. Keep what do bring value to the organization.
Next time when starting an Agile project, think not only on the team and software, but also all the ways the team can bring value to the organization.