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

Active woman in front of sunset

Values I Value

- Psychology

How aligned are you with me? This is my top 5 list of human values, both present in myself and that I'm attracted to in friends, coworkers and lovers. I also included my interpretation of each one to avoid any confusion…

Assembled cog wheels

Validating and Viewing OpenAPI Definitions with Docker

- Quality Assurance, Programming

Here are a few commands I crafted to validate and easily read API definitions in the OpenAPI format, using Docker and open source tools provided by Swagger. I have yet to convert them into proper shell scripts, but I hope these will be helpful nonetheless. The commands are designed to be run in a…

Radiating business woman

Essential International Standards and Registries for Web Developers

- Programming, Quality Assurance, Security

The following is a collection of free international standards, registries and references that I collected throughout the years while developing websites and web services. These references, while very precise and technical by their nature, are extremely useful in order to ensure that a specific…

Spaceship flying over active volcanoes

A Universe and World Creation Script for Mongoose Traveller 2nd Edition

- Tabletop RPGs, Programming

The following is a Python script developed by yours truly to generate a sector according to the core rulebook of the Mongoose Traveller 2nd Edition tabletop RPG, exactly as described in the Universe and World Creation chapter. It is designed to describe worlds in human-readable format as much as…

Medusa in fiery scenery

Deep Learning in Python with PyTorch - Tutorial and Demo

- Programming, Mathematics

As I am continuing my personal journey into deep learning research and development, I wanted to try out PyTorch, a machine learning framework with GPU acceleration primarily designed for the Python programming language. However, I couldn't find any good introductory resource online for it. So I read…

See all of my articles