Scrum isn't agile and is a waste of time

Image by Stable Diffusion

Warning: This is a highly opinionated post. Here be dragons.

Agile and scrum, two interchangeable terms that have come to dominate how software is built. They are, however, quite different. Agile is a philosophical approach to building software, whilst Scrum is a process that software development teams can use to build software. In my opinion, the agile principles are invaluable whilst Scrum is wasteful. 

The merits of the agile methodology should be obvious from just reading the agile manifesto and its accompanying principles. I won’t go into every one of these points here, but will stress upon a few ones: incrementalism and team empowerment & motivation.

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” 

“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.”

Now onto the more controversial part of this post, or why I find Scrum wasteful. Some context first. I worked at a startup that applied Scrum religiously. We had Scrum Masters who later on rebranded to Agile Coaches, Product Owners, team pods, colorful boards with 3M sticky notes throughout the office. Teams did planning, retrospectives, stand-ups and reviews. Our teams were a minimum of 4 software developers, 1 Agile Coach and 1 Product Owner. Product Owners had a maximum of 2 teams and Agile Coaches were also mapped to no more than 2 teams. Our sprints were two weeks long.

So where is the waste then?

The first wasteful aspect of Scrum is it’s rituals, of which there are many. Below are some of the ones that we applied consistently across all teams.

• A daily 15 minutes standup.

• Every two weeks a 1hr retrospective

• Every two weeks a 1h planning meeting

• Every two weeks a 30 minute Sprint Review meeting

Assuming a 40 hour week spanning a team of 6, then the total productivity (in hours) over a 2 week sprint is 480 hours. Now, if you put in a reasonable estimate for the actual time the above rituals consume over that same two week sprint it amounts to ~7% at the lower end and closer to 10% on the upper end. In other words, anywhere from 7-10% of your bandwidth is allocated to these rituals alone. That in of itself shouldn’t be a problem if you’re actually getting some benefits from them.

In fairness, some were very useful, like the sprint review where the team presented their work to stakeholders. Others, perhaps not so much. A good example is the daily standup. I’ve attended many of them and they are never 15 minutes long. They drag on for much longer with no real use other than just fulfilling a ritual. And that is my gripe with these rituals. They are done for the sake of checking a box, versus achieving an outcome. They are, as the name suggests, rituals.

The second area of waste was in the rigidity of applying this methodology. As a startup, one of the main advantages you have over a larger enterprise is speed. You ought to be able to move faster than a large corporation. Recall that I mentioned our team sizes were a minimum of 4 software engineers + 1 PO + 1 SM. Well, what if we wanted to bootstrap a much smaller team? We couldn’t, because we were shackled in our own implementation of this methodology. We’d rather hold off from creating a small team and wait until we had a large team of 8 and split that. Nor could we build a team without a Scrum Master, since that would violate the Scrum principles that we so rigidly applied. Meanwhile the clock ticks away.

The third has to do with the role of the Scrum Master, or Agile Coach, which to be honest to this day I still find confusing. If you search for the responsibilities of this role you encounter things like: improving how the team operates, streamlining Scrum processes, removing impediments and so on. Other responsibilities include the likes of “teach Scrum practices and principles to the broader organization”, “assist the product owner by incorporating techniques to improve processes”, “coach team members” and on and on.

The fact is, this role is vague, confusing and also impossible to hold accountable to anything. Additionally, because the job is vague, the most obvious manner in which a Scrum Master can show any value is in applying the Scrum rituals. These keep them busy for a small portion of their day - no more than a few hours. What about the rest of the day? The rest of the day, in my experience, is allocated to coaching team members, which implies more meetings and more waste. Those coaching session, between the SM and every team member, are incremental to the 7-10% burden that the Scrum rituals impose.

My empirical observation is that the rituals and ancillary Scrum related meetings amount to 20% of your teams’ time.

---

So if the principles of agile are sound, how then should you organize software development teams? It turns out the agile manifesto offers some insights

“Individuals and interactions over processes and tools”

“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.”

My experience is much aligned with the Agile principles. It shows that the best outcomes occur when you give teams the resources they need to get their job done and empower them to do so. A highly motivated and empowered team who understand what they are tasked to do, why they need to do it, and has all the resources needed to attain these goals trumps a process 100% of the time.

How to organize software development teams?

I have yet to see a team fail because they couldn’t estimate software using Fibonacci numbers or failed because of the lack of a daily stand-up. I have, however, seen many a team fail because they lacked the right resources, were micromanaged or had no clear understanding of what they were tasked to build or why.

I mentioned earlier that this post would be opinionated and entirely based on my own experience. I am sure that there are many counter-examples of organizations that have successfully applied Scrum. I have not, nor have I observed one that has. The reasons I outlined here could be idiosyncratic to me, the teams I worked on or to Scrum as well. I suspect the answer is a mix of all of these factors.

There are for sure elements of waste that were a result of how we applied Scrum versus what the methodology needs. Somehow along our implementation of scrum we prioritized implementing “the book of Scrum”, whilst forgetting the main intent and benefits of agile software development. Maybe that says more about us as an organization versus Scrum. It is a question I pondered on much.