Scrum Is Not Agile

- Programming, Business, Psychology

Slippery road signs scattered everywhere

While there is no denying that Scrum revolutionized the software industry for the better, it may seem a little strange to read about someone that dislikes it despite strongly agreeing with the Agile Manifesto, considering the creator of Scrum was one of its signers.

However, after having experienced multiple Scrum teams throughout my professional career, I can only arrive at one conclusion: while Scrum is generally much better than the traditional Waterfall model, it also generally doesn't work as expected, and even violates all of the Agile Manifesto values.

To make my point, I will focus on the Scrum ceremonies and their consequences on the software development life cycle.

Backlog refinement

While it does allow Product Owners to prioritize work better by having some idea of how complex some potential work is going to take, and developers to better understand the scope of this potential work before starting the work in the wrong direction, story estimation within this ceremony is a huge time sink with questionable benefits.

The first big issue is the concept of story points at the core of this activity. Simply put, a lot of developers mistakenly try to convert between them and time estimates regardless of how many times this mistake is pointed out to them. I highly suspect that because both use integers and because their values are partially correlated, many people are not able to properly differentiate the concepts.

Even after having passed this hurdle with everybody on the team, more often than not, developers will be involved even if they are redundant for this activity, constantly argue about how much a story point really is, and end up missing important details that are important to the scope of the estimated story anyway.

There are better ways to achieve the benefits described earlier with a much lesser time investment. Personally, I would privilege having regular high-level estimates of complexity with Product Owner validation of the related requirements before, during and after the design process.

Agile values violated:

Sprint planning

There is literally no benefit to this ceremony whatsoever. Instead of focusing on what's the most important for the Product Owner, more debates will occur about how to fill the sprint's capacity without leaving a gap, and whether the capacity itself needs to change due to known or probable events outside of it.

Not only does this encourage prioritizing stories with lower estimates even if their net value is lower overall, but sticking to a plan will cause missed opportunities, and the plan is likely to change anyway due to unforeseen factors, rendering any independent plans from the Product Owner or outside parties as potential liabilities.

The worst part however isn't even any if that. The worst part is that because the team committed for some sort of deadline, they will be encouraged to cut corners in order to meet said deadline against all reason. Of course, this kind of technical debt will not be part of a follow-up sprint to hide the evidence, at least until it has inflated and can no longer be ignored. Even when the cut corners is for the documentation, it's only a matter of time before nobody knows if the software is working as per the original requirements or not anymore.

For those considering a substitute, I suggest looking at Kanban as a base for inspiration.

Agile values violated:

Daily Scrum

Whenever someone in the team completes a task, needs help with something or notice some new impediment, they should communicate with the rest of the team then, not wait until the next meeting about it!

The only people that really care about daily status updates are supervisors that do not trust their subordinates, or that care more about following a plan over anything else. The end result is a lot of wasted time and the removal of work hours flexibility for team members.

The team should be able to self-manage, and if not it will quickly become apparent even to outside parties anyway. This ceremony looks good, but that's pretty much all it accomplishes.

Agile values violated:

Sprint review

This can definitely be a great and useful meeting as-is, but alternatives may also be better depending on context. For example, it may be a good idea to partially shield the developers from some negative influences from stakeholders about their needs which may have different priorities from the Product Owner, or focus on better documentation that achieves the same goal and can be referred to in the future.

The point is, there is no obvious issue with this particular ceremony, but sticking to that particular format may be sub-optimal compared to other solutions.

Agile values violated:

Sprint retrospective

Last but not least, regular evaluation by ourselves and by peers can be really useful. The problem is that it's easy to point at pain points, but not at finding their root causes, solutions, and ensuring said solutions are followed.

While this is an issue in general with team evaluations, the way Scrum implements this makes it even worse by time-boxing the activity and focusing exclusively on the last sprint by default. This prevents in-depth analysis of issues when needed, and not leave time for follow-ups on previously-reported issues unless the pain had been felt again. Anything more will affect the sprint and must be planned accordingly, affecting its capacity and causing even more issues with the sprint planning ceremony.

While a recurring retrospective meeting like that can be a good start, it should generally not be the whole process. Whatever method you use for team improvement, make sure there are actionable items and that they are properly followed through and not forgotten.

Agile values violated:

Related articles I wrote

Dice stacked in a triangle shape, with their face numbers matching their row position

I Designed the Perfect Gambling Game, But...

- Mathematics, Business, Game Design

Back in 2006-07-08, during the 13th Canadian Undergraduate Mathematics Conference at McGill University, I presented a gambling game I designed with the novel property of being both advantageous to players and the house, and that despite this proprety, that pretty much nobody in their right mind…
Stream of zeros and ones in space

Minifying JSON Text Beyond Whitespace

- Programming, Mathematics

JSON is a common data serialization format to transmit information over the Internet. However, as I mentioned in a previous article, it's far from optimal. Nevertheless, due to business requirements, producing data in this format may be necessary. I won't go into the details as to how one could…
Field of CG-rendered disembodied arms pointing at a dark sky at sunrise

Current Generative AIs Have Critical Quality Issues

- Business, Quality Assurance, Security

The hype for generative AI is real. It is now possible for anybody to dynamically generate various types of media that are good enough to be mistaken as real, at least at first glance, either for free or at a low cost. In addition, the seemingly-creative solutions they come up with, and the…
Stream of concatenated JSON objects

Current Data Serialization Formats May Be a Waste of Money

- Programming, Business

Storing data. Transmitting data. Processing data. These fundamental topics of computer science are often overlooked nowadays thanks to the historical exponential growth of processing power, storage availability and bandwidth capabilities, along with a myriad of existing solutions to tackle them. So…
Cowboy riding a horse in the sunset

Upgrading Your Cybersecurity from Cowboys to Sheriffs

- Security, Business, Anecdotes

Roaming throughout the countryside, dangerous desperados are awaiting in their hideout for the perfect opportunity to rob their victims in silence. Powerless, the authorities have posted wanted posters on public boards with cash bounties for any information that could lead to their arrest or death…

See all of my articles