How Scrum creates ScrumBut and what to do about it

 

What is ScrumBut?

Scrum org defines “ScrumBut” as “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.”

I believe that the prevalence of Scrum-but is a direct result of the way Scrum is defined. I will explain why I believe this is so as well as what you can do about it.

Getting into ScrumBut

Let’s first see how Scrum-but often occurs. It starts when a team has an impediment such as they don’t finish the work they put on their sprint backlog that they targeted to do. They often come up with several reasons including:

  1. They get interrupted
  2. Testing can’t keep up with development
  3. Requirements changed on them

They know they are supposed to remove these impediments. Getting interrupted is something that is sometimes out of their control. Not being able to do this has Scrum coaches sometimes lament that Scrum isn’t working because management doesn’t get it.

Testing can’t keep up with development often results from the team following a cycle of analyzing the requirement with the product owner, the person with developer skills (there is no coder role in Scrum) and the person with testing skills (there is no testing role in Scrum) talking with each other and getting clarity on the requirements. They know that they are supposed to remove this impediment but they don’t know how. The same is true for requirements changing on them. They see the problem – they don’t see a solution.

This is an important point. People usually understand the thinking behind Scrum – even before they take a course. They have seen the effect of stories getting drawn out. They understand that the longer it is between the time from writing code until it is tested the longer it will take to fix any error found. This is because they’ve spent their entire career working with or against the nature of software development.

The Underlying Cause of ScrumBut – Improper Mindset Leading to Unprepared Teams

Although teams may understand principles of Flow and Lean when pointed out correctly, they don’t know practices to address these challenges Flow and Lean thinking can solve. Scrum intentionally doesn’t include them and relatively few teach them. Scrum was designed for a team to figure out what’s needed to solve their problems. To me, this is silly. First of all, it doesn’t require 2 days to teach the basics of Scrum (it’s based on a 19-page guide). There are ways to teach Scrum in 4 hours with the dot game. What people need are the few common practices that will help them solve most of the problems most teams face. In the examples above ATDD will go a long way towards that. But I’ll get to that later. For now, let’s see what they do when scrum is taught as it is advocated – provide just the framework and let folks fill in the practices they need.

So let’s go back to our team that is having troubles completing their sprint on time. They see two main reasons being coding and testing is not keeping up and requirements are changing on them. They’ve been told that “Scrum’s roles, events, artifacts, and rules” are immutable. They don’t see how they can get Scrum to work. But many teams have been told that they need to do Scrum by their management. So they do “Scrum but we do …”

If they aren’t required to do Scrum they may figure that the best solution is to go to Kanban. Kanban would also see these are impediments but these folks don’t know that. What they know is that Kanban would also suggest removing these impediments. So their lack of understanding how to solve their problem leads them to do both “ScrumBut” and “not Kanban” (Kanban is not Scrum without iterations). What’s needed?

What’s Needed to Get Out of ScrumBut

Two things are needed. First of all, when teams get trained, the instructor needs to be aware of what challenges most teams are going to hit. But this flies in the face of the empirical process control theory on which Scrum is based. Empirical process control theory would tell us each place is different and although there are patterns, it’s not a good idea to assume things are going to happen. And, there’s truth to that – you can never be sure. But systems thinking tells us that the system is the cause of most of the problems. And Lean tells us to look at delays, their cause and is quality being built in. in most situations it is easy to correctly predict they will have the problems they have – both because of theories of Flow and Lean and because of the patterns systems provide us.

So in a case where developer and testing skills are in different people it’s almost certain that Acceptance Test Drive Development (ATDD)  is going to be needed. Instead of spending two days on Scrum, it’s better to do a 1/2 to 1 day on Scrum and 2 days on ATDD. With modern training methods this can be done at the same cost of certified Scrum classes. Now, when the team hits the challenges that can be reasonably predicted prior to training, they’ll be prepared for them.

In this case we were able to still use Scrum by just adding a practice to the framework. But this is not always the case. Take the situation where three teams have a shortage of subject matter expertise. That there is only one person who has this deep enough and she is required for all of the teams. In this case, having this person not be assigned to a team, but rather available to all the teams is a good practice. We can manage their availability based on need and Kanban methods. We’re no longer doing Scrum but we’re getting our job done.

How to Avoid ScrumBut by moving from Scrum to Scrum as Example

Let’s reflect on what happened. Scrum teams often run into impediments where they don’t know how to solve them. Sometimes, the solution for these impediments are outside of the Scrum Framework as well. So our intention is to equip Scrum teams with both the knowledge of how to remove impediments and we should be clear, it shouldn’t matter whether these solutions are within the Scrum framework or not. The goal is being Agile, not doing Scrum.

We can equip teams with what they need to do by looking at seeing what key practices most teams need to know. I would suggest ATDD is one of these. The other thing to arm them with is a process they can follow that will help them determine if a change in practice is going to help. We have found these three concepts will help most teams remove most of their impediments.

A Postscript

I came to the conclusions based on observing and talking to hundreds of Scrum teams over the last 2 decades. I did not predict this would happen. However, as a person who has studied both human psychology and organizational development and is very familiar with the pressures software development teams face, I think this behavior could be predicted. It is at least consistent with those theories. I find that when evidence supports a theory, it is likely to be valuable to attend to it.

Practice

Process

  • A Simple Guide to See if a Change Will Be an Improvement enables you to make changes to Scrum while ensuring you are making improvements and not merely ignoring a problem.
  • Scrum as Example is a way to start with Scrum, but then go beyond it as better solutions are available.
  • How to improve or change your practices. Varying a specified practice should not be done capriciously. But you should be able to take another practice that has the intent of the one not working and see if it’s applicable or not.
  • A simple guide to see if a change will be an improvement. Empirical process control, on which Scrum is based, suggests we have to try something to see if it’d be an impediment. While `100% predictability is not achievable, you can pretty well tell if something will be an improvement when you understand Flow and Lean. This guide tells you how.

Further reading

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.