Why I Hate Agile
Thomas Pfau
<tfpfau at protonmail.com>
I have yet to hear a good explanation for why everything needs to come to a stop and restart every two weeks.
Lack of up-front design causes major reworks of sections of code due to later discovered requirements not being achievable with earlier work.
Lack of documentation makes it difficult for developers coming in later to understand what's been done. Although Agile is not supposed to be an excuse to forego the documentation, in my experience it either doesn't get done or it doesn't get done well.
Frequently, one section of code becomes a focus and several developers are tasked with implementing different but overlapping changes. This leads to massive complex merges that create new problems. This is exacerbated by scrum masters who know scrum but don't understand the code or the development process.
Lack of up-front design causes different developers to have different ideas about what is being developed and work towards incompatible solutions. This can create chaos if one developer has the design in his head but is unable or unwilling to write it down in an understandable format. No one else understands where the project is going. A variation of this is when a developer completes his story but no one likes the way he did it. The code gets scrapped and rewritten. Only after development of an unacceptable implementation is there any thought or discussion within the group of how it should have been done.
Although Agile gives managers a lot of data to assess how much work is getting done and by whom I am still required to write my own performance review.
There is a rush to estimate a task without a deep analysis of exactly what will be required, then anguish over not finishing within the allotted time.
The rush to get stories done leaves little space to refactor code that is improperly structured. This grows over time until it becomes extremely difficult to do much of anything with the code. If a developer does take the time to do necessary refactoring it probably wasn't figured into the time estimate so we end up in the situation of the previous paragraph. A refactoring task will probably be scheduled with other work within the affected areas of code resulting in another massive error-prone merge.
Giving stakeholders the ability to change goals and requirements continuously means that they will. This leads to confusion as the goalposts keep moving.
When someone complains that they worked in an Agile environment and it didn't work, the standard retort is "that wasn't Agile" or "you weren't doing it right". This is the same argument used with people who complain that socialism or communism has never worked - "it's never been done right".
I have the mental picture of programming in a maze - we go off in some direction, then find it's a dead end and have to backtrack before going off in a new direction of unknown merit. I'm also reminded of the concept of "throw the first one away" where the first iteration of development becomes an exploration of a design and is thrown away when it's shortcomings are discovered. Imagine this occurring repeatedly to many segments of code over the course of a project and you have Agile.
Agile has so little going for it that to make it look good it is always compared to the most strict implementation of a Waterfall methodology. I’ve done plenty of projects using Waterfall and I have only seen one that was run that strictly – it was for a government agency.
"Individuals and interactions over processes and tools"
Yet Agile itself is a process and its god is Jira. What do the individuals get out of it? What interactions are improved?
"Working software over comprehensive documentation"
I had an argument with a manager over Agile. His argument was that the Agile process creates usable software that can be incrementally supplied to the customer putting it in his hands sooner. I shot him down with one remark - What happens late in the process when an early assumption is invalidated? All of that software the customer has been working with becomes a waste of time for both him and us since it all has to be rewritten for the new reality. A little more high-level design up front could have avoided this.
"Customer collaboration over contract negotiation"
As stated above, if the customer is allowed to change requirements mid-project, then he will continuously be changing the requirements and the project will never finish.
"Responding to change over following a plan"
Without planning you don't know where you're going or how you will get there or even know when you have arrived. And there's no reason to believe that Agile is the only process capable of changing mid-stream.
I am still of the opinion that Agile may be good for things like web sites that are developed in small increments and have no published interfaces for other components. However, in any system that needs to communicate with other systems those communications need to be spelled out so that development of both systems proceeds to the same goal with well defined data elements, messages, and interactions. There is no substitute for proper planning and design at least at a mid to high level.
Go ahead and have your stand-up meetings, planning meetings, retrospectives, whatever. Divide the work up into small chunks achievable in a short time frame. But the sprint concept is useless and don't eliminate proper design and documentation. Design should address the major components, processes within them, external interfaces, and interactions between parts of the system. It does not need to be done at a deep level - the developer should be given leeway on how to implement provided it meets design criteria, but he, too, should first take time to write a design document covering what he intends to code and its impact on the rest of the system. All of these components and interactions should be documented so that anyone coming into the project knows what was done and why. Developers should document what they wrote, including documentation of tests that includes what requirements were being tested (you do use requirements to write your tests, right?).
https://www.objectstyle.com/agile/why-developers-hate-agile
https://hygger.io/blog/6-things-developers-hate-about-agile/ -- especially #6