There is one value in the Agile Manifesto which is probably the programmer’s most favourite one:
Working software over comprehensive documentationAgile 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 problem with this agile value is while it very good 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 ofAgile manifesto
conveying information to and within a development
team is face-to-face conversation.
Let’s say you have a business case in a monolith software system which is already in its maintenance phase. The software is however viable and valuable for the company. The implementation a business case is spread throughout the code in a 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 a MVC). If we decide not to document, we rely on the fact that every developer that needs to make change to the business code will conscientiously go through the code, understands exactlty how it works and after that implements 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 externaly in a task management system. Both the second and the third option 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 with 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 busieness cases are not available (not in the office or worse – no more in the company), no change can be implemented relialbly.
Fortunately there is one agile principle that works as a safety net for all other principles:
At regular intervals, the team reflects on howAgile manifesto
to become more effective, then tunes and adjusts
its behavior accordingly.
If the self-organizing team is really motivated to get the job done they will make good use of the safety net. The question 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 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 lack 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 agile manifesto doesn’t mention at all.
To be continued…