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”?

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.”

but…

“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 ?