Recent surveys show that over 50% of the companies in IT Industry are undergoing transformation to Agile software development. Over 15% are already pure Agile organizations and about 25% are Hybrid.
Agile software development entered the scene in 2001 as an alternative to traditional approaches to software development. Originally promoted as a movement, many companies adopted it as a new standard. The method was quick to grow and dominate, with most of the growing occurring in the past years.
However, as any new concept that rises, Agile fails exactly because its incapacity to adapt in the most important areas. We will show here how.
I am a Code Developer since 2003, working for the largest IT Corporations, with various Java Enterprise Technologies and (adjacent) Frameworks. In the past years I also have been doing Technical Team Leading and Project Management. I used Traditional Waterfall and Agile Methods like Scrum, a Lean based implementation, DevOps etc. Over the years I learned about the values that code developers price most, about their beliefs and aspirations. And I think they have nothing to do with the Agile development.
IT Businesses base themselves on software programs, i.e. code. It’s as simple as that, nothing else is mandatory for a business in the IT industry. Without code, there is no money. And there is no code without coders. Having nothing to do with the most important link in the business chain, Agile is already showing it’s flaws. Unless it will adapt, it will fall, due to the incapacity of its fundamentals to adapt.
We, as programmers, love the code because it’s cold. It’s true or false, it’s either 0 or 1. It cannot cheat if you’re correct and complete. Though difficult to understand for the exterior world, in it’s essence programming is simple, quiet thus rewording for us. Clearly our first choice over the human interactions, which have nothing of the above.
Programmers value competence. You don’t need very deep psychology skills to see it in the coders’ group interactions. The one that knows most will always be greatly valued and respected by his or her team. Add to this context the clarity and the completeness of the coding universe, and you will understand how deeply wrong it is to use a development method that is not aligned with the coders’ values. The following shows how the Agile Manifesto is in total contradiction with them:
Individuals and interactions over processes and tools
We chose to be programmers so we could code, and not being responsible for doing anything else! Otherwise we would have trained to become Company Representatives or something. We perceive all the talking, the meetings and all the other stuff that is not coding, as being a “waste of time”, “unimportant” and “useless”. Maybe even boring. In any case, one of the reasons for which we chose to be programmers is because we don’t want to do such work.
Various Agile implementations claim they base themselves on extended neuro-linguistic researches. In this case, it is at least odd how such assertion could rise and be implemented. How is it possible that no study shows the method’s misalignment with the coders’ values. Though trivial, I see myself obliged to put down the following rules, maybe they will be understood once and for all:
- programmers don’t like meetings!
- don’t give us that false argument – meetings are not stressful because they are short (15 minutes)!
- the time limit introduces even more stress!
- programmers don’t like digging for the requirements into the twisted, unclear, incorrect, incomplete logic of the client. Just give us the specs and we will work our magic!
- and make up your mind! we hate when you trash our code for the sake of the change friendly environment!
It is hilarious how some Agile implementations pretend they work according to the Agile Manifesto but ask programmers to talk to a wall when they give their status. They move stickers on a board, talking to “the wall”, so the perception is that nobody is listening and judging. It seams these implementations understand why the programmers don’t like individual interactions (in meetings) and the pressure they put on us by asking for daily status report. They try this awkward fix, against the Agile Manifesto, but one thing is for sure, we are not that much of social freaks as you think we are… we understand.
Working software over comprehensive documentation
Sounds great to a programmer, isn’t it? Well, it may seam to you that it does… if you are not a real programmer.
The half part of the truth is that programmers hate documenting the stuff they do, they like to pretend that only God and themselves know what’s in-there. On the other hand they also hate unclear requirements especially when they are combined with unrealistic expectations. Programmers appreciate good documentation when they start working on a project that is already under development for some time. They appreciate good documentation when they work on the same code as other teams, maybe even in different geographies.
Though the programmers don’t really like documenting their work, the lack of good specifications is a big factor of stress for them. Such situations interact directly with the core of their value system: “what the coder knows”. Huge stress is introduced by this context, as the programmers evaluate and rank themselves almost exclusively by “what they know”. Unclear, ever changing requirements may lead to random, uncontrollable outcomes, thus stress. Furthermore, such systematic implementation of a method that fails to align with the coder’s values introduces a heavy feeling of exclusion. You don’t want to work in an environment that does not share the same values with you, as at some point, it will surely exclude you.
Sometimes, in even worse cases, the lack of understanding of the Client’s needs is hidden behind the Agile Development pretext. The management will say they don’t need documentation or code specifications, only working software, because they work in an Agile environment. Many times the truth is that they actually don’t really know what they’re doing, nor what the client wants.
Customer collaboration over contract negotiation
We just don’t really care about such aspects. At all! Programmers do not show interest in unraveling the client’s needs, making requirements out of them, defining the scope of work and delivering the solution. We just want to code cool stuff. To us, the client is a ‘not so bright’ person, having awkward expectations due to a poor understanding of the great things that we do.
The direct interaction and collaboration between the programmer and the customer cannot be done without introducing stress. Most of the times, the programmers never take responsibility for client facing tasks, but they are forced into doing so, and are evaluated for it, under the pretext of the Agile environment. Such approach infringes the very principle of specialization, commonly used for improved work efficiency and productivity.
In short, collaboration over contract is a false problem for a programmer who has the code development as main objective.
Responding to change over following a plan
This does not sound well to a programmer. We use our genius to create solutions… we don’t really enjoy seeing them changed or trashed. We would appreciate more if they were valued by others. In such cases, change may mean wasting precious coding time or even that the client evaluates our code as having poor quality.
The programmers don’t really like plans either, especially as implemented in closed culture environments, where the coders are asked to set deadlines and made responsible for meeting them. However, we prefer plans over disorganized, uncoordinated environments, where the success and evaluations are random or at the discretion of some subjective interpretation.
Furthermore, Self-organized Teams is an utopia. Programmers know how many times they woke up at 6 o’clock in the morning due to the high pressure introduced by the upcoming Demo through the uncertainty relative to the scope of work. – Will it work? I don’t know!… as a programmer I am not allowed to say “I don’t know”, the central value of my evaluation system is: “to know”. I can’t “not know”, it’s the reason of my very existence!… though I don’t know what the client meant by that requirement, I don’t know if the system is stable, with all the changes I don’t know if what I and the others did will work together… I just don’t know! This only is enough for a good… panic.
In a sense it’s also contradictory to say that you do not encourage planning over changes but have planned meetings, planned deadlines for iterations, planned work within iterations etc. And how many times, just before the periodical Demo, the merges crushed due to all kinds of code inconsistencies? The programmers know what I am talking about, and the Project Managers know that such issues can be avoided by accurate planning. Why is it that Agile only accepts some kind of planning but doesn’t call it planning?
Agile is iterative. We are reminded over and over that each time we repeat one process we do it better than the previous time. However, Agile seams to forget that it is also incremental, asking the programmers to do something extra in each iteration, and thus something new, that usually changes everything. In short, the principle does not apply as promoted… we do something different each iteration, something that we have not done before, so we will not improve the performance that much.
Responding to change over following plans may also hide the lack of vision and leadership, all under the Agile umbrella. This, of course, is an extreme interpretation of the Method and its Manifesto, but Agile never ensures that such things would not happen… and they do.
Agile has on the traditional methods the fact that it sells. Clients are more easily convinced to buy if they see something that continuously evolves and adapts to what they need. They will buy in the end and thus Agile will sell. It will sell at the expense of the stress introduced in the development processes. It will sell at the expense of the programmers’ nerves.
But no method could ever succeed if it is not in alignment at least with the most important needs of its stakeholders. Programmers already avoid working in Agile environments foreseeing its fall. In the coming years, the method will need to apply its own principles and change itself in order to adapt and respond to its stakeholders needs, or die because of the flaws within its fundamentals.