Why Agile Will Continue to Fail
I’ve talked about Agile before, but I think it’s time to talk about it again. I’ve worked in so many different Agile environments and have talked to other developers about their company’s Agile approach. Time and time again I see the same issues crop up and I wanted to talk about them.
Meetings, meetings, meetings
It seems the core of the modern agile approach revolves around synchronous meetings. What do I mean by that? Think about your average day in an agile environment. The first meeting you have is a stand-up meeting. If you’re working from home you’re likely joining via Zoom, Slack, Teams, whatever. If you’re in the office you’re likely using a meeting room. Depending on the number of people involved in stand-up it can take anywhere from 15 to 30 minutes. This meeting is usually led by the Scrum Master, which we’ll talk about a bit later, and is supposed to be for the developers. Each developer will say what they did yesterday, what they’re doing today, and if they have any blockers and what those might be (if they exist).
This meeting is ultra repetitive and I’ve been personally involved in a lot of very quiet stand-up meetings. Let me be clear, I’m not saying that you shouldn’t communicate with your team or that stand-up is necessarily a bad thing to do. However, if there’s no standup update, why have a meeting? Why disrupt your team's workflow if nothing important is going to be said or done.
There are plenty of other Agile meetings, but I wanted to use the stand-up meeting to demonstrate some common sense regarding Agile meetings. They can provide benefits to you if you tailor them to your needs. Too many times I’ve seen the Scrum Master act as a dictator over the team and the processes are seen as not being flexible. If you say it’s not working the Agile people say “oh well it’s not the process, you’re just not doing it right.” This is a particularly common, and particularly dangerous thing to get into. The primary reason this is so bothersome is that the Scrum Master is almost never anyone with any kind of technical background.
Agile Leadership
Agile is supposed to be for developers by developers right? A bunch of developers came up with Agile to replace waterfall and it was supposed to be the next big thing to supercharge software development processes. Despite best intentions, modern Agile is not for developers nor is it by developers. How many developers are Scrum Masters? How many Scrum Masters have never touched a piece of code in their lives? The answers (respectively) are very few and too many.
The main issue with that is that these people have no idea how software development works in the real world. They only know what they’re told in their 2-day Agile crash course. This becomes apparent when they insist on things that simply don’t make sense. One of those things is having themselves involved in technical discussions. Often times I’ve spent at least 10 to 15 minutes of meetings trying to explain technical details to someone non-technical. I also end up having to repeat myself constantly because they have no technical foundation they require me to reiterate my points. This is something that makes absolutely no sense, and something I’ve seen too often.
Going along the same thought as the meetings section, Agile leadership also tries to insert far too many people into a meeting. What I’ve often seen is that the Scrum Masters will try to insert as many people into a meeting as possible. Let’s give an example. The business has decided to introduce a new feature into the main product. All the requirements have been given and now the technical teams need to come up with a way to introduce the feature. It stands to reason that there needs to be some technical discussion around how we best fit this piece into the puzzle. This is an example of a meeting that should ONLY happen between technical leadership to get technical requirements ready for their teams.
However, what often happens is that the Scrum Masters think this should all be done by democracy. So they get the Scrum Masters, Product Owners, Developers, and everyone’s grandmother in the meeting. This ties into what I was talking about earlier, I have to spend time explaining technical things to people who don’t need to know the technical details. Then I spend a bunch of time reiterating these technical details and wasting more time. This just wastes time and doesn’t provide any benefit for the time spent.
What I’ve found is far more efficient and keeps my blood pressure down, is taking control of those kinds of meetings myself. As a team lead, I try to make sure I have all the technical details ironed out before the work gets to my team. I make sure that I’m the one scheduling the meetings and only including the people I need to be there. This, oftentimes, results in a quicker and smoother release of a product. We often outline the requirements in a shared document (i.e. Confluence) with links to the tickets. I have noticed that when we stray from this working process we often get a lot of confusing requirements, a lot of waffling back and forth, and we often end up with no one knowing what is going on. Confusion is the enemy of productivity and there seems to be no shortage of confusion in the Agile way. When you have non-technical people dictating technical things it rarely works out well.
Fixing the Issues
So there are issues and there has to be a solution, right? Well, that’s a more complicated answer than it may seem at first. I talked about a few specific issues that I’ve seen so I’ll only talk about how I went about solving those issues. Whether you’ve faced these specific issues before or not, you may still find some of my suggestions useful in your day-to-day life.
Solving the Meetings
One solution that I’ve found particularly useful is doing asynchronous stand-up meetings. Slack has a lot of really nice tools, one of which is an automated poll feature. One of the primary benefits of stand-up is the last thing that is talked about, the blockers. If there are blockers then it is certainly beneficial to figure those out before your day moves on. Otherwise, I’ve found stand-up to generally be a waste of time.
We send a poll out to the team before stand-up to ask if we should have a stand-up meeting. This question was agreed upon to mean if there are any blockers or outstanding items that require conversation. If not, then we post our normal updates in the team slack channel and acknowledge them there. I have found that this process takes a lot less time, gets in just as much benefit, and isn’t highly disruptive to the workflow. This is one suggestion that I have found incredibly beneficial to my team that goes against the standard Agile way.
Solving the Leadership
Ultimately, technical people need to be in charge of technical things. There needs to be more control put in the hands of technical leadership. The way I see it if there is a non-technical Scrum Master on the team they should be a tool in the belt of the technical leadership, not the technical leadership itself. Scrum Masters should not be dictating the processes around the code is written or deployed, nor do they need to understand that. These things are simply outside the scope of their responsibilities. If you’re going to have a non-technical Scrum Master I think they should have limited responsibility. If you’ve ever worked in a kitchen or seen an episode of Kitchen Nightmares there is a person who expedites the orders in the kitchen. This person is not a chef/cook but they take in the orders, organize them, and then feeds them to the kitchen. The expedited doesn’t know, nor do they need to know, how the food is being made but they help get the ball rolling quicker.
The other issue is that of having too many people in each meeting. Often times Scrum Masters like to pull everyone into meetings that really should only have a few people. This seems like a relatively straightforward solution, have more focused meetings. When you have more focused meetings with a more focused audience and one person in control of it. That way the meeting is more productive and less time is wasted.
Final Thoughts
At the end of the day, what works for every team is going to be a little different. I find that the way Agile is implemented today is very rigid and tries to implement the same thing everywhere, which just doesn’t work. I would encourage technical teams to push back against this paradigm and do things that make sense.
If you’ve enjoyed this article I’d love for you to join my mailing list where I send out additional tips & tricks!
If you found this article helpful, interesting, or entertaining buy me a coffee to help me continue to put out content!
