Why is Scrum getting an anti-word?

For quite some years Scrum has been THE agile development process. Scrum got mainstream. But let’s have a look what got mainstream here. Scrum, Agility, Buzzwords, Scrum Master got mainstream as words, in business talk, in dev talk, in trainings.

But what did it really achive for better communication, better relations and collaboration between developers, managers, customers etc. Has Scrum fundamentally improved the way software is delivered in our industry?

I probably couldn’t find many people who’d respond with an unconditional “YES!” to this question.

But why? Why is Scrum getting an anti-word for many?

There are various different reasons:

• Scrum’s transparency creats angst for people living in and from intransparency
• Scrum’s need for change is uncomfortable for people’s need for stability
• Wrong implementation of Scrum
• Scrum Master who don’t take people with them and run ahead in their own speed
• Unbalanced power division between roles
• Scrum Master who have THE solution instead of enabling teams to find differing ways for different problems
• The Scrum hype and overwhelming/missleading marketing
• Could go on with lots more

Let’s focus on a few and look at them a little bit more in-depth.

Speedy Scrum Master

A person who just got his Scrum Master Certificate and gets all enthusiastic about it returns to his company from training and wants to start. His textbook knowledge tells him how to technically implement Scrum, but without years of experience it’s applied in a step-by-step way. Without soft-skills and knowing what’s appropriate when it’s allmost impossible to be successful right away without watering down Scrum to non-Scrum. Picking people up where they are is one of the key things. You can’t just tell them where they ought to be without telling why and what for.

Once this poor Scrum Master introduced Scrum to team for a few sprints he and his team will hit walls without knowing how to climb over them. At this point the lack of experience of the Scrum Master leads to the first internal critics to surface. The longer a Scrum Master only has his Scrum process goal in mind without providing real solutions the more Scrum will be the scapegoat.

The more this happens (and I guess it does a lot), the more people will say “Oh no, not another of these Scrum guys”.

Unbalanced power division between roles

Unbalanced power division between roles causes wrong implementation and frustration.

For example Scrum Masters who don’t have the support of upper management to make things happen.

Teams without the power to stop a sprint, without the needed skills and not cross-functional are handicapped teams.

Product Owner who are not directly responsible for the profit and loss or ROI of the product. I often wonder how a Product Owner is supposed to prioritize without? I still often hear something along the lines “we need everything!”.

One of the things that’s done wrong in projects that use Scrum is that Scrum should help a project to fail early instead of staying for a long time and dying a long slow death over years. Why’s that? Because often all people involved have conflicting interests regarding their job safety and early project death. The only one that could have an interest in that is a Product Owner with budget responsibility who knows that a project shouldn’t be continued if the value of to be implemented stories is lower than its costs.

The Scrum hype and overwhelming/missleading marketing

Scrum is often advertised as solution for everything. Scrum has been hyped for years. The result is lots of so called ‘experts’ promote and implement Scrum without ensuring it’s done right or often even without the experience on how to do it right. Again Scrum gets the blame for failing projects that might or might not have failed anyway.

So is Scrum at fault? Or is it the way Scrum is used today? Can Scrum be rescued or do we need something new just because Scrum is done wrong instead of because it is wrong?

As with so many things I think we should focus more on quality instead of quantity. Don’t look for cookbook receipts, let your team tailor their process inside the Scrum skeleton and share (don’t force it) your experience with them. I might follow up on this in a future article.