.svg){kind=icon}
.svg){kind=icon}
.svg){kind=icon}
Get your free ebook
One popular criticism is that Scrum has too many meetings, more than is necessary to ensure a team’s effectiveness. Let me ask you this, however: what ratio of planning to action do you think is necessary to deliver a high-quality complex project?
If you answered “about 15% planning to 85% action” - congratulations! That’s exactly how much time an average Scrum Team spends on meetings. The rest is work: well-planned, focused work with a clear sense of vision.
It’s true that there’s quite a few types of meetings in the Scrum process, though, as you can see in our Scrum introduction. But each of these meetings serves an important and clearly defined purpose.
There’s no room for distraction; the Scrum Master makes sure that each meeting stays on-topic and is completed within the designated timebox, precisely to avoid the team getting bogged down with unnecessary talk.
There are companies and organizations that have given Scrum a try and decided it is not a solution for them. And that is okay.
But before you decide that Scrum is definitely not the way to go, ask yourself another question: Is my company ready for Scrum?
If your company does not encourage frequent and open communication, you may not be quite ready to implement the framework. The direct cooperation that Scrum offers takes some getting used to, and requires the right company values.
Perhaps your company is not ready for any framework at all. If your daily work involves chaos and disorganization, some criticism and resistance is to be expected in implementing not only Scrum, but any system at all.
Only once you have given real, by-the-book Scrum a fair shot for a reasonable amount of time can you say that it “doesn’t work”.
This criticism is often presented by the developers themselves. Developers new to Scrum might see Scrum meetings and the work of the Scrum Master and Product Owner as unnecessary fluff, interrupting their workflow.
However, you should keep in mind that Scrum is meant for teamwork. Emphasis on the ‘team’.
A lone wolf mentality is fine in some cases, but when working on a complex project, you need to be aware of the product vision and goals at all times. You lose that awareness if you don’t plan your work and compare it to the client’s actual needs.
It may be true that a developer free of Scrum meetings could do more programming in the same time. But it is also true that without the ‘non-programming work’, some of the code will turn out to be useless. It may turn out that the client’s vision was completely different, or that another developer on the team already covered that feature.
In the end, the developers are paid for solving the client’s problems, not for supplying as many lines of code as they can. So it pays dividends to keep those problems in mind and talk about them often.
I’m sure it’s no surprise that this post caused a tiny spot of controversy among our followers. One of them commented another Scrum criticism to add to the list:
The argument seems to be that the Scrum Master is not necessary for the functioning of a team. If the team can self-organize and follow the rules of Scrum by themselves, the Scrum Master has nothing to do.
Actually, you might hear some Scrum Masters themselves saying the same thing. Some of them take the approach that “the Scrum Master strives to become unnecessary”. But that’s not entirely true.
First of all, the framework cannot exist without the people implementing it. Sometimes people lose motivation. Suddenly, they can’t be bothered to follow the elements of Scrum - even if they were self-organized before. In those cases, the Scrum Master is there to help them follow the framework. All of its elements exist for a reason.
And even if we do assume that a team can ‘self-organize’ under Scrum, they still need:
The Scrum Master fulfills all of these roles. Babysitters, usually, don’t go to such lengths.
Implementing Scrum takes some doing. As you can see above (and in our Scrum introduction), between the Scrum roles, meetings and rules, there’s a lot of ground to cover. It’s no surprise, then, that some people make mistakes in implementing Scrum, sometimes leading them to abandon the framework altogether.
I asked Dominika what the Number One Scrum Mistake was. Her answer was almost instantaneous:
“People do things without asking why.”
All too often, Scrum adepts focus too hard on the actual steps of the process without seeing the greater reasoning behind them. They say that they have to do a Planning meeting, or a Backlog Refinement meeting, or a Daily Stand-up.
But they don’t really have to do the meetings.
What they actually need is to have their work planned, their backlog refined and their daily efforts synchronized. The exact way they do it is their business.
In the end, Scrum is just a tool. A well-defined, widely used and exceedingly effective tool in the right hands, but a tool nonetheless. It won’t fix your problems by itself if you don’t put in the effort. But if you do, Scrum will make sure your effort is not wasted.
If you want to learn more about the importance of 'why?' in Scrum, here's a video of her presentation from the latest STX Next Tech Power Summit:
We firmly believe that in the end, truth and beauty will prevail.
If you’ve ever encountered a Scrum nay-sayer who used one of the criticisms above, make sure to share this article with them - they just might see the light. The share buttons are right below this text.
Perhaps your experiences with Scrum and Agile are a bit different and you have unique Scrum problems that you seek to resolve. Have no fear! We’d be happy to help. You can always contact Dominika and the rest of our crew to have a chat about Scrum at business@stxnext.pl.
(And if you’re looking to learn more about the business side of software development with Scrum, why not check out our C-Level Guide to Software Development Nearshoring?)
