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.


  1. Hi,
    could not agree more with your post, was really a good read.
    I just got my SCRUM master Certification.
    in our organization some Teams do follow SCRUM and some don't, my team does not.
    we tried and at some level it did work for us, but eventually Team mates found SCRUM meetings sheer waste of time.
    I do not want to force my Team to follow something they do not want to, and just for the fact that I have a certification.
    anyway, I personally not of the opinion that SCRUM is THE ANSWER for all.
    here, I just want to gather some information about example of SCRUM failure and its reason, rather then always chanting about SCRUM success stories.
    I will really appreciate if you can share some of your personal experience about the same.

  2. Scrum is not an Agile Software Development process. It's an Agile project management process. That may account for some of the frustrations people have with it's ascent. It's actually got stuff-all to do with delivering working software. Most Agile adoptions I've seen have focused almost completely on Scrum and on the managers, not on the "hard skills" like TDD, refactoring, OO design and so on. So we get a lot of "Agile" teams who are good at writing user stories and "grooming" their backlogs etc, but suck at delivering software that works and that can accomodate change. To use a music analogy, Scrum is about conducting the orchestra. But we seem to have forgotten about the musicians and the music. Not much point in having a great conductor if your orchestra can't play.

  3. I mostly agree with you, although I often experienced it the other way around. Probably depends on who started Scrum in that particular environment: top down (management) or bottom up (frustrated developers) on what gets the main focus. If Scrum is introduced bottom up the focus often is on TDD, XP etc. but working with customers, filling and prioritizing backlogs lacks behind.
    It highly depends on the environment. Teams that do some parts of the whole process very well can be found often; but 99 % would need some help in a lot of areas (which are never the same). I don't think Scrum or any other Agile process itself is to blame.