We should save Scrum from Scrum

It seems a paradox but it isn’t. I start to think that we should save Scrum from Scrum: from the weight of his popularity that could transform it in something different.

More and more often I see Scrum not well understood and applied in organizations. This concerns different aspects: Scrum roles, collaboration of people, estimation, etc. We have already a name for such situations: it’s the well known “ScrumBut”. The real problem is when the “But” part is much more bigger than the “Scrum” part and what is kept it’s just an iterative framework with people playing the Scrum roles and doing some ceremonies with the fundamental agile principles negatively impacted or no more present. You can see development managers playing the Product Owner role instead of someone with business knowledge, ScrumMaster with a subordinate hierarchical link with the PO, Scrum Masters who assign the tasks to people, estimation done by the team with in reality a Gantt Chart already done to tell how things should go… I’m sure you have already seen such situations and many others.

I think it’s time for reflection to understand where “Scrum” is no more “Scrum” and when it’s not bringing anymore the benefits it was developed for and why we have such common situations.

When a “Pizza” is no more a “Pizza” ?

If you look at the pictures below, do you consider they are both “pizza”? Or do you think the one on the right went too far from the original concept? But what does it mean “pizza”? What are the changes I can do still considering I’m eating a “pizza”?

Pizza examples

Two different pizza

The success of the Italian “pizza” it’s one of the reason you can see today “pizza” all around the world, but the original concept has been  interpreted in different ways trying to meet the different cultural tastes… the result can be something different. However you will find people who will tell you that the one on the right is still a pizza, and probably they are right because the “pizza” definition is generic enough to make interpretations. What they cannot tell you is that it’s an “Italian pizza” because it’s now safeguarded as traditional specialty guaranteed dish with a more precise description on how to do it. “Pizza” (Italian) has been saved from… the popularity of “pizza”!

This little story brings us to think why we should save Scrum from Scrum…

Scrum can lead to different interpretations on some important aspects

You may think: “Hey what are you saying? Scrum it’s not a pizza!… It’s clear what is Scrum! You have Sprints, Retrospectives,  Daily Meetings, the PO and SM roles, etc..”.

Well… Yes we have all these things but the problem is that often people understand and apply Scrum in different ways so: either it’s a problem of understanding either is a problem in the way it’s defined. I would say that at least one part of the responsibility is in the way it’s defined.

Imagine the scenario where there is a Scrum team with a Product Owner role played by a development manager. In this scenario the development team is running his own Scrum, the manager is giving priorities providing the vision on what the team need to do and people inside the team report hierarchical to him.  Is it respecting the definition of Scrum?

People arguing that it’s still Scrum can use this:

“The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals” – From the Scrum Guide

“The Product Owner is the single individual who is responsible for drawing out the most valuable possible product by the desired date. This is done by managing the flow of work into the team, selecting and refining items from the Product Backlog”From Agile Atlas

People who think that is not real Scrum because the PO should be a person from business side could focus on this:

“The Product Owner is typically the individual closest to the “business side” of the project.” – From CSPO ScrumAlliance

or from Mike’s Cohn blog:

“The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed.”


“This, of course, varies tremendously based on whether the team is developing commercial software, software for internal use, hardware or some other type of product. The key is that the person in the product owner role needs to have a vision for what is to be built.”

You could have seen people discussing on this or other aspects of Scrum trying to agree on what it’s “correct” and what it’s “wrong”,  telling: “you are doing Scrumbut”, others: “it depends on the context”. Even if we could consider the scenarios both correct from a (lack of) definition point of view we miss a clear list of negative impacts on the expected benefits of when we apply Scrum in one way or the other.

I think a consequence of this point is that in organizations we have different types of Scrum and potentially not the expected benefits as they were thought by people who “defined” Scrum.

Details are provided on less important aspects of Scrum

It’s strange for me to see how the Scrum definition could lead to different application of the Product Owner role but instead it’s really clear about the minutes of the daily stand-up:

“The Daily Scrum is a 15 minute time boxed event for the Development Team”From the ScrumGuide

I think a consequence of providing details on less important aspects is that people might consider such details as fundamental aspects of the framework, focusing more on practices than principles.

In conclusion

I think that we should save Scrum from his popularity to prevent the risk to use it, more and more often, without having the expected benefits. I don’t think it’s only a problem of correct understanding of Scrum itself but also of the way it’s defined. The existing literature leaves too many assumptions unspoken, we need more returns on experience on correct and wrong Scrum application together with the negative impact on the benefits.  This problem with existing literature is even more important and true when we speak of using Scrum in large companies where scaling well Scrum to several teams is critical and necessary to still have the agile benefits Scrum is supposed to achieve.

On my next article I will focus on scaling Scrum to large companies and on which aspects with need more precise guidelines and returns on experience.

Do you also think we should save Scrum ? From What ?


3 Responses to We should save Scrum from Scrum

  1. Davide

    From what should we save Scrum ?

    My answer will be short and direct:
    The worm was in the apple
    When Jeff Sutherland oversells hyperproductivity to Top Managers, and defined “Sprint” as the word for the Scrum iterations…

    As well, hard to expect a complete framework from 15 pages guide

    Scrum Lifesaver already exists : it is the Agile Manifesto

    By the way Davide, I would like to invite to animate a next Agile Lunch on this subject, end Jan
    We could bring each one a Pizza, and discuss if they are still pizza or .. if they are good or delicious to eat 🙂

    Kind Regards

  2. Roles
    At Ericsson we had a similar situation, command-and-control managers were mapped to product owner roles and subordinates left to defend the team as scrum masters.

    As expected, the POs gently forced the teams to consistently overcommit or cut quality corners while the scrum master was just a ceremonial role.. From that we felt that there really were too many managers – you don’t really need a manager per team when you have all the operational decision making done by PO and team. And the team manager really shouldn’t be the PO. So, what happened was that the previous team manager (they each had 2 teams) had to apply for new jobs: supporting 4-6 teams as agile coach without authority, become developers, become scrum masters of 2 teams, become POs of 1-2 teams, become pure manager for a competence group. Just never to keep a scrum role and be in a position of power over the team.

    Lately I have seen scumbut’s in a new flavor – the potentially shippable increment vs DevOps.
    In the scrum guide it says the team shall deliver a potentially shippable increment. This has led to teams saying its enough if the code is checked in and not fully tested in each increment, because it has the potential of being shippable if the QA passes. Which leads to costly QA and releases.

    The DevOps community then goes on to claim they are fixing the broken parts of scrum, but empasizing the delivery pipeline and collaboration with QA and OPS. Personally I feel it is embarrasing that Scrum fails to be clear enough on this point. Most of us coaches already practice lean SW delivery and as such are pushing for bringing done to production done.

    So despite all of us already working towards production, DevOps can rightly claim to have the solution…

  3. Davide Noaro says:

    Hi Johannes
    thanks for your valuable feedback!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: