Disciplined Agile

Re-thinking ScrumBut and ScrumAnd

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 its roles, events, artifacts, and rules will facilitate Agile. While this is often true, doing so sometimes either cannot be done economically or at all. 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.”

“ScrumBut” defined this way ignores the possibility that maybe there’s a better solution to one of its immutable roles, rules, artifacts and events and that the reason you’re doing “ScrumBut” is because it’s better.

Scrum does allow you to add things to it  – called “ScrumAnd.” But sometimes the best way to remove a dysfunction is to change a practice that is mandated by Scrum and substituting one that is more applicable to the team.

While it’s true that just abandoning a Scrum practice is likely not good, having a set of practices that must be followed has its own set of problems.

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 (or Disciplined Agile which includes 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.

Fall 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 Disciplined Agile is that there are no one size fits all practices. Instead they should be based on context a team is in. DA 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 (or if you haven’t anyone on the team who knows DA Scrum), then understanding some basics of flow, Lean and ToC 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.

Making a change can be accomplished with this four step process:

  1. Are you having challenges with the practice because it is being done poorly? If Yes, then inspect and adapt and see if you can do it better. If No, continue.
  2. Is there something else in the organization that is causing us this problem? If Yes, then see how to fix that or at least influence the fixing of it. If No, then continue.
  3. Is the ecosystem that the team finds itself in causing the problem? That is, are people not co-located when they need to be or are required skills missing? Can you improve on this? If yes, do so. If No, continue to see if another practice that works within this ecosystem will work better (see next step).
  4. What else can we do that meets the same objective of the practice? If there is something else you can do, then try that. If not stick with the practice until you learn more.

There is no definitive set of alternative practices to Scrum. That is the entire point. But it is worth investigating a few of them to illustrate how Scrum as Example can be used.

How to tell if a change is better

There is a set of underlying principles that can provide an indication if a change will improve things.  This is always in theory to some extent, because even if a change will improve things if made, there are often side effects caused by people not adopting the change that work against it. We must always be diligent and validate any change we make.

The measure to use is the value stream impedance scorecard. In a nutshell, the VSIS indicates how much resistance the system will impose on work being attempted. It is based on what improves total value manifested. Lowering this resistance usually results in more value manifested.

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


Doing ScrumBut Properly

  1. We do Scrum, but we don’t have fully cross-functional teams.
  2. We do Scrum but we can’t stop management from interrupting us.
  3. We do Scrum but we don’t have hard iterations, we follow more of a flow model.
  4. We do Scrum, but tests are not complete by the end of the sprint.
  5. We don’t do retrospections
  6. We don’t have a product owner
  7. We don’t estimate because it takes too long or management beats us up.