We Should Save Scrum from Scrum
Join the DZone community and get the full member experience.Join For Free
It seems like a paradox but it isn't. I've begun to think that we should save
Scrum from Scrum: from the weight of its popularity that could
transform it into something different.
More and more often I see Scrum not well understood or applied in organizations. This concerns different aspects: Scrum roles, collaboration of people, estimation, etc. We already have a name for such situations: it's the well known "ScrumBut". The real problem is when the "but" part is much bigger than the "Scrum" part and what is kept is just an iterative framework with people playing the Scrum roles and doing some ceremonies with the fundamental agile principles negatively impacted or no longer 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 made to dictate 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 when "Scrum" is no longer "Scrum" and when it's not bringing any of the benefits it was developed for and why we have such common situations.
When a "Pizza" is no longer a "Pizza" ?
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 make but
still consider it a "pizza"?
The success of the Italian pizza is one of the reasons you can see "pizza" all around the world, but the original concept has been interpreted in different ways trying to meet 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 definition of "pizza" is generic enough to make interpretations. What they cannot tell you is that it's an "Italian pizza" because it's now safeguarded as a traditional specialty dish with a more precise description of how to make 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 is not a pizza!... It's clear what Scrum is! 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 or it's 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 their own Scrum, the manager is giving priorities providing the vision on what the team needs to do and people inside the team report hierarchically to him. Is this 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 this is not real Scrum because the PO should be a person from a business background 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."
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 this or other aspects of Scrum trying to agree on what is "correct" and what it's "wrong", saying: "you are doing ScrumBut", others: "it depends on the context". Even if we could consider both scenarios 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 applications 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.
I think that we should save Scrum from its popularity to prevent the risk of using 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 Scrum to several teams is critical and necessary to still have the agile benefits Scrum is supposed to achieve.
In my next article I will focus on scaling Scrum to large companies and on which aspects need more precise guidelines and returns on experience.
Published at DZone with permission of Davide Noaro. See the original article here.
Opinions expressed by DZone contributors are their own.