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 content I wrote

Floating mathematical formulas

A Technical Introducition to MathML Core for Writing Mathematics on the Web

- Programming, Mathematics

Thanks to recent efforts, all major web browsers currently support MathML Core, a subset of MathML focused on important presentation markup, to support mathematics on the web. As of this writing, the MathML Core specifications are still not finalized, but given its strong origins and support, it can…
Fireworks

The New Open Source Video Game Randomizer List Is Now Live

- Video Games, Programming

Time to update your bookmarks! After a few months of work behind the scenes, the new open source version of The BIG List of Video Game Randomizer is now live for your enjoyment, with dark mode support and a brand new UI for better readability! The new URL is: https://randomizers.debigare.com/ (The…
Open treasure chest with a question mark in it

The Future of the Video Game Randomizer List

- Video Games, Programming, Anecdotes

It's hard to believe that it's been almost 8 years since I first posted on the ROMhacking.net forums a list of video game randomizers that I found online, and that it would evolve into the massive project it has become today, with almost 900 entries currently being listed. It's always a strange…
Woman being blindfolded by someone hidden behind her

A Corrupt Judge's Prayer

- Fiction, Psychology

That's not what the law says. And if it does, that's not what the constitution says. And if it does, that's not what their authors meant. And if they did, the case has no merit due to a technicality. And if there isn't, I will delay my decision. And if I can't... It's not my responsibility.

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…

See all of my articles