This is a chapter from Amplio Development: The Path to Effective Lean-Agile Teams

Abstract: Scrum.org makes it sound as if ScrumBut is bad. While it is now promoting ScrumAnd, there are times you should substitute a mandated Scrum practice. Hence, Amplio introduces the term ScrumSub to mean a practice that substitutes for a Scrum practice.

The Scrum Guide tells us that its roles, events, artifacts, and rules are immutable. This is fine if you want to ensure you are doing Scrum. Scrum is based on the belief that following it without change will facilitate Agile. While this is often true when Scrum is used for where it was designed – a cross-functional team building a new product – it is used in many more contexts than this.

Cross-functional teams and being able to plan ahead is not something that can always be accomplished. Just as important, sometimes Scrum’s roles, events, artifacts or rules are not appropriate for a particular situation.

What is ScrumBut?

Scrum.org defines “ScrumBut” as meaning “that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”  For example, a team may say “we do Scrum, but we don’t do sprints.”

Ken Schwaber has since stated he prefers to talk about “Scrum And.” But these two phrases ignore two possibilities. It’s possible to “we do Scrum but we …” where we substitute a Scrum practice that removes the impediment. And Scrum And may include practices that violate the Scrum framework (e.g., abandoning sprints but doing flow while managing work in process).

While it’s true that just abandoning a Scrum practice is likely not good, it is important to be able to substituted a Scrum practice with something that works better for the team.

Why Having Options Or Understanding Some Theory Is So Important

Consider being on a team that is having troubles finishing the stories by the end of a sprint. People aren’t sure what to do. The Scrum model expects people to figure this out but Scrum does not provide the required theory of Flow and Lean to do so. There are several options now. Let’s consider each from different perspectives of the team.

Just stick at it and follow Scrum

Scrum would suggest just to keep trying to get things done by the end of the sprint. It presumes that when an impediment is uncovered, the team needs to figure out how to solve it.  But what if they don’t know how to do this on their own. For example, in this case, understanding Kanban would be a ready solution, or at least give insights on how to solve it. But many teams are mandated to learn Scrum and are not also given Kanban training.

Consider a ScrumMaster who only knows Scrum. They’ll likely propose sticking with Scrum because they don’t have a ready alternative. This is even more likely if they’ve been brought in to do Scrum since that’s their area of expertise.  It also forces them to move out of their comfort zone and may make management question why there are there if Scrum is not being used.  This, by the way, is why it’s best to have Agile coaches know both Scrum and Kanban (Amplio provides the mindset of both).

Any suggestions by the team regarding changing a practice, whether good or bad, is likely to be met with “but then we won’t be doing Scrum.” The challenge with this is, of course, the team’s focus in now on doing Scrum and not solving their own problems.

Falling into ScrumBut

At some point, if the team doesn’t learn how to solve this problem they will eventually come up with something like “let’s not have sprints, let’s do Kanban.” Of course, most of the time, this is really just not having sprints (Kanban is not Scrum without sprints). They are now in uncharted territory without a map for improvement. Things will likely get worse and many people will say “you can’t blame Scrum because they are not dong it.” I would suggest this is an inherent problem with any approach that has preset practices.

Pick from a set of Options

One of the key concepts of Amplio, and other approaches based on first principles, is that there are no one size fits all practices. Instead they should be based on context a team is in. Amplio provides options to choose from, enabling a team to accomplish what’s needed in a way that’s suitable for them. Picking a more appropriate option than one of the immutable aspects of Scrum may have the team not be doing Scrum anymore but getting the job done nonetheless.

Use a Theory to Figure out a Solution

Sometimes a good practice is a good theory. In other words, if it’s not clear what to do then understanding some basics of flow, Lean, and the Theory of Constraints may be all you needed.  Look at your problem, see if there’s another way to solve it, try it and see if you got a good result.

If people just abandon practices without adopting a new one to fulfill the intent of the practice, ScrumBut as a bad thing is likely to ensure. Substituting practices requires understanding the intention of the practice being substituted and a set of alternatives to choose from.

See Know how to Select A More Appropriate Practice to learn how to substitute a better practice for the one you are using.

Introducing “Scrum Sub”

Redefining ScrumBut is too difficult now. The connotation that not doing a Scrum practice is bad is too prevalent. When the situation is “We do Scrum but we substitute this practice for a Scrum practice” makes more sense.

Not doing Scrum is not always bad. Sometimes there’s something more suitable for your team.

 

Go to Amplio Development: The Path to Effective Lean-Agile Teams

Go to Being a Professional Coach

 

Latest Article

Why Leaders Should Focus on Value Streams

Read on Cutter's site >>

Latest Presentation

Intro to BLAST and How To Solve Challenges in the Workflow

Watch Video >>

Upcoming Event

The Amplio Community of Practice (Free)

Learn More >>

New Workshop

The Amplio Development Masterclass

More Info >>

Latest Presentation

Intro to BLAST and How To Solve Challenges in the Workflow