The Agile Way II
This is part two of my thoughts on the agile process of software development.
There is one value in the Agile Manifesto, which is probably the programmer’s most favourite one:
"Working software over comprehensive documentation" Agile manifesto
We can abstain from lengthy documentation as long as the software works. We assume the best – namely that the code is self-explanatory. If it’s not, we have comments. That’s it.
Where I have a problem with this agile value is that while it very well applies to technical decisions in the code, it fails to reliably document the functional requirements and business cases.
The value is further strengthened by the following principle:
"The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation." Agile manifesto
Let’s say you have a business case for a monolith software system that is already in its maintenance phase. The software is however viable and valuable for the company. The implementation of a business case is spread throughout the code in numerous domain objects, services, etc. Where exactly does one document it? Basically we have two options – either not document the business case or write a code comment in some entry point class/service, or ideally a controller (if it’s an MVC). If we decide not to document, we rely on the fact that every developer that needs to make a change to the business code will conscientiously go through the code, understand exactly how it works, and after that implement the change. If we choose to document in the code, we need to update the comment every time the business case changes. Of course, there is also a third option, which is – document the case along with the change externally in a task management system. Both the second and third options would somewhat contradict the agile value and the principle, as they state that the working software is more important and the face-to-face conversation should take precedence over documenting.
In my real-life example, there is a mixed state between the three above-mentioned scenarios, with the result that no business case is sufficiently documented, and the whole business knowledge is kept safe by maybe 2 developers and one project/product manager, both long-time employees.
This leads to the following problems - every change that needs to be made to this system (and changes are rare because the system is in its maintenance phase) is accompanied by the risk of breaking multiple business cases. (monolith system!). With missing regression tests or generally very few tests, the stability of the system is in danger every time a change is made. If the persons who have the knowledge about the business cases are not available (not in the office or worse – no more in the company), no change can be implemented reliably.
Fortunately there is one agile principle that works as a safety net for all other principles:
"At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly." Agile manifesto
If the self-organizing team is really motivated to get the job done, they will make good use of the safety net. The question of what happens if they are not leads me to the next problems I have with the agile development process. Who will keep the team motivated? Who should make the decision about which person belongs to a team, and who has the responsibility for not choosing the right person? How is the effectiveness measured?
The agile principles and values are part of a manifesto. As such, they are positively formulated, and they assume the best about the people involved. They assume that every developer will act in the name of his team’s best interest. And he/she probably will. According to his/her understanding, which is most probably subjective. As long as we don’t measure the team effectiveness objectively, we can’t tell if it has become more effective. What the agile process lacks, in my opinion, is time and cost management as a way to measure effectiveness. This would imply some sort of project management, and this is something that the agile manifesto doesn’t mention at all.