Why scrum is passé?
For some time now, I’ve been observing that Scrum is in decline. It’s not about its decreasing popularity. On the contrary, it has become a buzzword. It appears in almost every job advertisement (alongside a young dynamic team), losing its original meaning. In my surroundings, people show less enthusiasm to implement it - they often want to modify it and see it as chains imposed on the team. It looks like ScrumBut. To some extent, this is related to the fact that agility has become a somewhat insignificant slogan. Just by using Jira and having daily stand-up meetings, I can say that I work in Scrum. However, I’ll leave this level of ignorance without further comment. Dave Thomas presented some interesting observations a few years ago in his talk “Agile is dead”. He notes that “the value was lost behind the implementation”. Has anything changed since then? Is there any improvement?
Scrum According to Google
If you ask an average programmer what Scrum is, they will likely talk about sprints, retrospectives, and other meetings. Some certified Scrum developers will tell you how long the meetings should last and will present the roles of team members.
This aligns with what Google teaches us about Scrum. Today, I searched Google for the term “Scrum”, and here’s what I got:
Almost all the images look the same, showing screws, circles, arrows. We see sprints, daily meetings, etc. In other words - we see how the process looks. However, we learn little about the principles.
If we turn to the Scrum Guide, we find the following statement:
When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.
In my opinion, this quote is the most important excerpt from the official guide. It clearly indicates what is most important. Unfortunately, none of the graphics show anything about trust, the three pillars, and only one image depicts the values. Why isn’t there any picture in the style below?
Unorthodox Scrum
Usually, when I ask someone what methodology they work in, if the answer is Scrum, it’s “light Scrum”, “unorthodox Scrum”, or another term suggesting a deviation from the original process, e.g., “Yes, we have Scrum but…”. In other words, it’s the aforementioned ScrumBut. Interestingly, Scrum itself, according to its definition, is lightweight, so here we have something lighter than light.
What does such a lighter process look like? I’ve encountered situations where a team gave up retrospectives. Is there anything wrong with that? Let’s take another look at the Scrum pillars and the process itself. It turns out that all process elements reinforce our pillars. The product backlog enhances transparency, retrospectives provide inspection and adaptation. Similarly, daily meetings contribute to inspection, adaptation, and transparency. If we consider all the process elements that appear in Scrum, all the artifacts that are created, it all adds up to a coherent whole, promoting transparency, inspection, and adaptation.
Let’s go back to the situation where the team got rid of retrospectives. It makes sense only in two situations. When they don’t care about the three pillars or when they introduced something else in return. Unfortunately, in the described case, they didn’t introduce anything in return. Short-sighted laziness won.
Another example I observed was not hiring Scrum Masters due to the need to pay them a salary. In this case, short-sighted savings won.
Message for Today
If you decide to work in Scrum, remember what principles and pillars are the heart of the process, and importantly, don’t fight against them, but accept them. I’m not saying that modifying Scrum is wrong. On the contrary, Scrum encourages experimentation. However, it must be done in a systematic way to determine its impact on the process, team, and product. Ensure that values are not lost behind the implementation.