Shared publicly  - 
Scrumbut isn't always a bad thing
by +James O'Sullivan

There have been discussions for many years about the need to always do Scrum by the book. I think this statement might be true for some teams, but not all. I'm not talking about having a half-arsed Scrum adoption, but allowing your teams to evolve beyond it when they are ready. The last four words of that last sentence are critical. There's a dichotomy within the framework, we are expected to inspect and adapt, but not in ways that adapt set parts of the framework.

The mantra of, do it by the book, seems to have grown out of problems with teams that only adopt parts of the framework and then wonder why it's not working. Hence the name scrumbut, we do Scrum but.... Agile and/or Scrum are often the obvious scapegoats rather than looking into internal problems.

For your initial scrum adoption I do recommend that you do everything by the book. Also hire some seasoned ScrumMasters to help you out. Though Scrum is a simple framework, sending someone on a 3 day course and expecting them to be an expert is naive at best. Another option is to hire an agile coach to work with your newly minted ScrumMasters. I can't stress this more. Don't go it alone. If you're serious about agile, then take it seriously and hire the right people to teach others.

Anyway getting back to the point of the post. I'm a great believer in the martial art concept of Shu, Ha, Ri (which I was introduced to by Lyssa Adkins in her Coaching Agile Teams book).

Shu - learn the rule.

Ha - break the rule.

Ri - be the rule.

Teams start in Shu, i.e. do Scrum by rote. This is essential so that teams build up the discipline needed for a successful adoption. It doesn't mean that you can't ask questions as to why something is done a specific way. In fact that is encouraged, but you aren't ready to adapt away from the constraints of Scrum. This is where a seasoned ScrumMaster or coach is essential. They'll be able to give knowledgeable answers to any questions that arise and know when a team is ready to move to the next state. Ha.

Note: teams might be at different levels for different practices.

When teams have achieved Ha, the ScrumMaster will start letting them break existing rules. This will allow the team to learn, but without the discipline that has been built up they won't have a frame of reference.

Lots of teams want to skip directly to Ha or Ri stages without going through Shu.

Finally as the team learns through breaking the rules they'll achieve Ri. This is the state of high performance. Teams will be able to inspect and adapt how ever they want. At this stage, they may have evolved their Scrum practices in a way that would be considered Scrumbut, but they now have the experience to understand why they've done it.

Finally, I believe there's a conflict of interest here with certifying organizations. If teams keep on changing their process, they may no longer fit the model of strict Scrum and have no need for certifications.

Remember that Scrum is a starting place on your agile journey, not the final destination and not the only way to get there.

Are you doing Scrum by the book, in ways that would be considered Scrumbut? Do you think Scrum by the book should be the only way to do it?
James O'Sullivan's profile photoJarek C's profile photoDave Rooney's profile photoTodd Charron's profile photo
Hi James!

First of all, I totally agree with "starting off with scrum by the book". Getting some training will not replace any self-made experience and coaching lessons can be a great help.

The problem I met over and over again, is some kind of misunderstanding when organisations and/or people talk about scrum. Mostly I hear "we have a scrum process now" or "we have to adapt to the scrum process" and imho this is not clarified in most books: scrum is a method and will/can/should NOT replace a release- or deployment process totally! Most books and trainers do focus on scrum and miss to tell the human being on the other side about the constrains and context of scrum.

It makes live so much easier, if you start off with a tested and well introduced release process, define the entry point of adding requirements to a backlog and the exit point of hand over to operations/live system/what ever.

The danger to do scrum by book only (attention: I am talking about the method) and do not care about integration into any IT delivery process will cause lot of troubles and pains.

I can see the benefit to following the rules up to a point, so you know why the rules exist. Scrum lays out a framework, but the details and evolution is managed by the team.

Look at the US Constitution vs the laws of the nation. The constitution is a terse document (relative to other countries and our body of laws) which outlines how the government should work, domains and limitations of the government. The actual implementation of day to day lives are done through the laws passed by congress and the president. And upon contest they are considered against the constitution whether they fit the intent of it (and there is even provisions for amendment). Now, to further the analogy, there is a higher law than the constitution (of which the parts of bill of rights implicitly acknowledges) natural law, which includes freedom of speech, religion, self defense, property rights, due process, and others.

Arguably the Agile Manifesto would be our natural law. These are the things we hold highest. Scrum is but a constitution. And the implementation is derived by the team, following the precepts of scrum and amending their processes as they go. The team answers first to the principles of the manifesto, then checks against scrum, and finally, if necessary, changes from scrum to scrumbut where it allows them to better follow the agile goals (of course this is for folks living in scrumbia, not those who live in kanbania).
What I believe is really dangerous is to start out with a "ScrumBut" approach and just calling it Scrum. If you fail with your half-hearted implementation, you'll have a very hard time trying to sell the real thing. Adjusting your processes after having gone through a succesful implementation is an entirely different thing. Either way I would argue against calling it "Scrum" if it's not reasonably close to the book.
+Holger Schauer I completely agree with you. I've seen instances where doing scrum by the book meant always doing it that way and not letting teams evolve it. That is a bad thing. Like I said Scrum is just one starting point, you'll eventually adapt to the point where you have your own tailored agile process which will continue to evolve
I think, there's one important point: The Scrum master and his team must be able, to distinguish between Scrum Adoption/Evolution and Scrum Erosion. Scrum from the book isn't agile at all, because it's just slavish following a plan (!). On the other hand, I've seen a couple of projects, doing Scrum just as long as it is "convenient" and dropping it, if it starts to hurt. Therefore I think, the art of finding the "right" Scrum is to to as much "Scrum from the book" as neccessary to avoid erosion and do as few as possible to stay truely agile.
+James O'Sullivan I use the term erosion as a methaphor to "landscape erosion": Essential parts of Scrum are omitted, because they seem cumbersome or boring (=erosion) and not to make it more efficient and appropriate (=elaboration/improvement).
Jarek C
My thoughts:
- no rule of scrum should be applied just because it is scrum. People need to understand what is reason behind.
Scrum helps to focus on product, and focus should stay on product.
-Good retrospection is a base of scrum, and learning on own mistakes is the most convincing way of learning.
-Scrum guide is very limited (just 16 pages) to foster creativity, and allow people to find solutions that are working best for them, limiting scrum rules to really absolute baseline/minimum
+Jarek Cichon I agree that no rule be applied without being told why, which is different from understanding. True understanding only comes with experience.
Well said, James. In the "Agile world", we've been using the shu-ha-ri approach for many years to describe the learning process, and your post nails exactly what we've been saying.

When I start working with a team new to Agile, I tell them that I'm going to show them some practices that are a starting point (shu). They should use reflection through retrospectives to figure out over time how to tweak or even swap out practices to best suit their context (ha). Finally, if I came back to observe them after a year or two, they should have evolved into a smooth-running process that really works for them and could conceivably look very little like Scrum (ri).

Unfortunately, many teams don't progress beyond 'shu', and even then cherry pick the practices that they think are easy. Without the deeper understanding of why the practices exist and an overarching goal or vision of why they're changing their process, they never get to 'ha' let alone 'ri'.

So, to sum up what we're both saying, teams that are really, truly being agile may look a lot like they're doing Scrum-but! The difference is that they evolved to that place naturally and with their eyes wide open.
Someone is telling them they have to change their process, but the teams haven't bought into the reason behind the change. Essentially, they're doing it 'cus they were told to.
People often seem to forget that if they aren't doing "Scrum by the book," they aren't "failing to do scrum properly," but rather they are simply implementing another form of agile.  Scrum happens to be the most popular form of agile at this time, but teams aren't doing anything wrong if they choose to experiment with other methods.
+John Peltier that depends on what "aren't doing Scrum by the book" means.  I've seen far too many teams be "pragmatic" about the practices they choose to implement, only picking the easy ones.  They might do standups for a while and work in 3 week cycles.  However, they never get the benefits of introspection, truly cross-functional teams, or a business-facing prioritized backlog.  After a while, they pretty well abandon all that because they aren't seeing any of the promised benefits of Agile.  Well, duh!!

There are other things you can do that will bring some of those benefits.  I believe that you an take the Agile Values and Principles and implement them any number of practices.  It does, however, mean you have to be deliberate about what you're doing... which is a good idea anyway! :)
I find this issue comes up more and more as Agile crosses the chasm and becomes more mainstream. I wrote about this a couple of years ago (see ).

There seems to be a lot more momentum these days behind pure pragmatism in software development. So much so that I think it may completely water down both Agile and Scrum to the point that the terms become meaningless.

Someone recently posted "If it works for them then they're doing 'Agile' perfectly.".

Umm no. Agile isn't just whatever works for you, otherwise Agile is anything. Working 80-100 hours a week might "work" for your company, but it's not sustainable and certainly isn't Agile. What Agile is, to me, is what's clearly stated in the manifesto and principles.

Agile teams evolve, and they should. This includes Scrum teams as well. However, they need to do so aligned with the values and principles of the manifesto, not simply by doing whatever is less painful or more convenient.

It seems like we're moving from grand notions of "Transforming the world of work" to "hoping to perhaps improve things a little bit for some people without offending anyone, if you don't mind? Oh you do? Never mind then... go back to what you were doing"
+Todd Charron I completely agree. My point wasn't about pragmatism. If your going to start out with Scrum then do it by the book. As you said, they must evolve and sometimes that means evolving the way some of the Scrum practices are done, but only when they understand why it works. You make a good point about evolving in ways that are detrimental to the team.

I completely agree that we need to keep "transforming the world of work". Let's go big or go home.
Jarek C
Pragmatism is when you change something that you tried and you want to change for some reasons. But, if you change something without trying to implement - then it is not pragmatism. I.e. mixing roles seems silly - we will not do it because it will not work. - then we will do not even try to see it it might work, or not.
+Todd Charron it depends on whose definition of pragmatism you're using. Did I mention that it changes from person to person? :)

I blogged about "Pragmatic Agile" a while back at 

As I mention in the post, I have no problems with "pragmatic" as Dave Thomas and Andy Hunt use it.  I do have problem with much of the pragmatism I've encountered as an excuse to avoid good software development practices.

On the bright side, I'm currently working at a place where they embrace the former definition, shipping high quality code constantly.  Not surprisingly, this company is doing very well.
+Dave Rooney and I'm waiting for you to submit your article to InfoQ on your new place and how they're embracing the former definition :)

You are correct that there are many definitions of pragmatism. What I'm referring to are things like this:

1) Cherry picking - Here's an actual quote from the HN article on the original post, "Agile is a toolbox of best practices and tricks. You need to use the ones that make sense.". Yup, that's what a large number of people promoting Agile seem to think Agile is. sigh.

2) Good enough - Meaning, it's hard to adopt something like say Scrum, so we'll just do daily stand-ups and call ourselves Agile. I'm actually ok with people gradually adopting Agile practices, but only if you recognize where you're at and understand that you have more work to do. Most organizations don't do this. They start with what's easy and stay there. If you're not continuously improving, you're not Agile.

3) Stopping practices without understand why they work. "We don't need retrospectives anymore, we're doing fine." Really? Is there no way you could improve? You're the best software development team in the world and all your code and delivery is flawless? No? Then I'm pretty sure there's still a lot of value you could get out of a retrospective. If you choose to not have it, how are you going to ensure that you still adhere to "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.".

If you can still satisfy that principle, then go for it, but that's not really what most teams end up doing.
btw +James O'Sullivan I completely agree with everything you said, I'm just pointing out the trend of articles promoting watered down Agile these days.
Add a comment...