Scrum has become absurdly popular, and a good part of this popularity is due to its simplicity. But, as the Scrum Guide stated in its first lines of the 2017 version:
Scrum is simple to understand, but difficult to master
- Scrum Guide, 2017 version
In other words, there’s a universe of distance between understanding Scrum and truly mastering it. And that’s where the danger lies: this distance is the perfect habitat for victims of the Dunning-Kruger effect.
Image created by www.investificar.com.br
From Wikipedia: The Dunning–Kruger effect is a cognitive bias in which people with limited competence in a particular domain overestimate their abilities. Some researchers also include the opposite effect for high performers: their tendency to underestimate their skills.
That said, let’s get to the three fake news!
1 — The problem with Scrum is that it’s too simple
Scrum is a framework, but it’s common to hear people refer to Scrum as a methodology. It may seem like nitpicking, but this simple word swap says a lot about the understanding of Scrum.
After all, what is a framework? Well, according to the Cambridge dictionary:
A supporting structure around which something can be built
- Cambridge Dictionary
Scrum is a structure upon which you should build your way of working. It’s like Ruby on Rails, ExpressJS or Hibernate: they don’t work alone, but they help you work in a more structured and productive way.
Frameworks are incomplete by default and on purpose. They are created so you can think and expand them in the way that makes the most sense in your work context. And that’s where agile practices like Story Points, User Story Mapping, Risk x Value Prioritization, User Stories, etc. come from.
As Scrum implements the PDCA cycle, it’s possible to adopt a certain agile practice, validate its effects and decide whether it’s worth continuing with that practice. And of course, it’s necessary to experiment with new ideas and repeat this reflection at the end of each Sprint.
In summary:
Scrum is simple and incomplete on purpose to make you think of ways to complement it.
If someone tells you that the problem with Scrum is being too simple, this person hasn’t understood anything about the framework yet.
2 — Management 3.0 and DevOps came to replace Scrum
In Minas Gerais (a state in Brazil) we have a commonly used expression when someone says something like this:
WHAT??? — Translation: excuse me, what did you just say?
This statement makes no sense if you’ve already understood the concept of a framework: Management 3.0 and DevOps come to complement, not to replace.
After all, the Scrum Guide says:
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.
- Scrum Guide
Yes, Scrum doesn’t talk about automating deploys, for example. It doesn’t talk about feedback wraps, delegation boards or intrinsic motivators.
Because Scrum is a… framework!
I believe that this visual representation used by Alexandre Magno in his training sessions illustrates this idea very well.
Representation of the Scrum framework completed by emerging techniques, created by Alexandre Magno
3 — We don’t have Scrum teams anymore. We have Squads.
This one is quite interesting, and I added it here because I increasingly see organizations using terms from the famous Spotify model. And often the justification is that the teams are multidisciplinary and not segmented by areas of knowledge.
But, what does the Scrum Guide say about its Scrum Team?
-
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.
-
Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
The concept of Squads was born collaboratively at Spotify and was partially documented in 2012 in this pdf by Henrik Kniberg and Anders Ivarsson. In the document, available at this link, they say:
A Squad is similar to a Scrum team, and is designed to feel like a mini-startup. They sit together, and they have all the skills and tools needed to design, develop, test, and release to production. They are a self-organizing team and decide their own way of working.
It’s always worth reflecting on the model adopted by the organization:
-
Does your Scrum Team have the characteristics mentioned in the Scrum Guide?
-
Does your organization provide the necessary environment for the existence of Squads/Scrum Teams?
-
What problem is being addressed with the adoption of Squads?
-
What differentiates your Squad from a Scrum Team?
Squads made sense in Spotify’s scaling context, and they might even be compatible with your organization. But it’s essential to understand which problems Scrum and the “Spotify Model” try to solve before doing a CTRL+C / CTRL+V.
At the end of the day, misinformation will always exist and eventually people can spread it even with the best of intentions. The only way I know to avoid these traps is to follow the advice of the wise philosopher E.T. Bilu:
E.T. Bilu would read the Scrum Guide before starting to use Scrum
So, shall we take some time to reread the 16 pages of the Scrum Guide?
