When Agile Seems to be Broken
I am old enough to remember the move from a waterfall process to an agile methodology. It was all the rage. Funny thing is, agile had become so popular, I was part of the transitioning process from a waterfall to an agile process 3 times in 3 different companies. Each time it was different, but of course each time the leaders explained that this is agile “pure”, whatever that means :-).
Many years have passed. We, or rather I, have been using the Agile development process for the past 15 years now. Somehow begs to ask the question, what comes next right? I am not aware of any company in the software industry which is still implementing the waterfall process. Or maybe, at least knowingly not implementing. Some remnants of that process still remain.
After such a long time working with the Agile development process, I think I can state the following unpopular opinion:
The Agile development process is being misused too many times.
There, I said it!
Back to Basics
The agile manifesto, or part of it, as it reads to this day:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Having re-read this, looking at the process now, would it surprise you to know that some of the founders of the agile process themselves are saying “Agile is Dead”?
Here is a short list of what you might never have heard:
- Dave Thomas: Agile is Dead (Long Live Agility) (2015)
- Martin Fowler: “our challenge now is dealing with faux Agile.” (2018)
- Robert C. Martin —” The tragedy is that the Agile movement was supposed to promote the ideals of Craftsmanship, and it failed. Horribly.” (2018)
- Kent Beck: “There’s still a tendency for some people to look for a list of commandments to use for a project, which is not what agile is about” (2010)
- Andrew Hunt — “…recently label the movement a failure.” (2015)
I am not going to say “Agile is Dead”, rather, it’s being misused.
The road to hell is paved with good intentions
This is not happening in all companies. Thank God for that. But from my observation, I think the trend is the following:
A small startup company is developing using the agile process and the process is working for the startup and all people involved. The startup gets bigger and slowly but surely adds more people and the agile process is being impacted, as more and more practices are being standardized in the company, but it is still recognizable as an agile process. Then you get even bigger, and the need for oversight and control grows, and that’s when you start perverting the agile process to something it is not.
I guess what I’m saying is that the misuse of the agile development process is in bigger companies and is usually managerial-driven. At least that is my observation.
Signs of a broken Agile process
I’ll try to explain in a couple of paragraphs what I mean when I say the agile process is being misused.
You are not in control of your tickets
At some companies, I am actively discouraged or even prohibited from opening tickets myself. Sometimes I have to write a mail to someone who has the permissions and is allowed to open tickets, sometimes I can’t even do that, as someone else entirely is managing what and when goes into a ticket.
Strange isn’t it? Shouldn’t the tickets help me in my development process? Usually, with this type of process the Individuals and interactions are being sacrificed for processes and tools which is the exact opposite of what should have been. It seems the tickets are being used as a monitoring and control mechanism more than anything else.
Personally, I do not like to work in such an environment as the tool does not serve my needs at all.
Document before with endless meetings
Don’t get me wrong. In my opinion, documentation is key for maintainable software, but this is different. When you have to start with a document describing all you need to do for this software to work you are doing something wrong.
Working software is the primary measure of progress. (Principles behind the Agile Manifesto)
The tickets you open yourself are the actual document you might be demanded to write. Be dynamic and have meetings at all stages of your progress to be aligned with different teams and requirements throughout the development process.
Documenting before is just a waterfall process disguised as faux-agile.
All requirements before starting to code
Nothing screams more waterfall than this. Didn’t we learn some 15 years ago that this does not really work?
We know that you cannot know all requirements to begin with, rather you start small and lean, knowing the requirements will change and you will need to readjust. That’s the whole point.
It sounds like the following statement: “We understand that the waterfall process is outdated and does not work too well in more modern times of software engineering. What we need now is a new process, we shall call it Agile! And we shall implement this agile process by practicing waterfall methodologies”. Savvy?
Plan multiple months ahead
I do not have more to add than what I’ve said in the previous paragraph. I only wonder why there are still companies implementing this process and then complain about the lack of velocity. Each change has a huge impact on the software which has already been written based on outdated requirements.
Intricate ways to deal with the process
At this one company, I observed an odd planning routine. Members of the team were being handed cards, playing cards, with numbers on them. When it was time to suggest how many days it would take to develop a task, people devised the number using the cards, laid them upside down on the table, and only after the last one had done so, were we allowed to show the cards.
Now you ask, why is that? I didn’t know either, so I asked. The answer is this: In order for anyone’s answer not to be influenced by anyone, this is the best way.
WUT?????
Can you please stop this BS and put the Individuals and interactions back into the agile process?
Agile Ceremonies over Valuable Interactions
Sometimes the process is just that. A process. In this context, nobody even questions whether the process is adding value or not.
For instance, you have a daily meeting and each one of the members has a different task, on different issues, and each one just rambles about his/her problems and updates but no one really listens because it doesn’t matter to anyone.
Or, you have a retrospective meeting and the issues raised are not being noted. Or even worse: they are being recorded, but nobody does anything with it. That’s even a bit degrading in my opinion.
Why continue with those ceremonies? Other than wasting valuable time, what is the intent of such a meeting? It seems the processes and tools have once again pushed the Individuals and interactions to the side.
Final Thoughts
Don’t get me wrong. I love the agile development process. I remember the days when planning was done half a year ahead, and halfway through the process we knew already 2 things for certain:
- We would miss the deadline.
- We would work overtime for 2 months straight to make the twice-delayed deadline.
I do not miss those times and for the most part, I do not experience issues like these in today’s agile development process. At least not with the same intensity and certainty.
So what am I saying? Get back to the basics. Let people communicate with one another without the restraints of over-complicated processes and process tools. Let people start coding without hindering them from having all requirements and dependencies, to begin with. And the most important:
Set a Goal, not a path!
