Tag Archives: change

Why Best Practice lives in a Shu Box

Shu-Ha-Ri is a popular metaphor in Agile Circles. 

It’s borrowed from Martial Arts (where it works well) and one way to explain it might be:

  1. Shu – Follow the rules
  2. Ha – Break the rules (adapting them to your context)
  3. Ri – Become the rules

It is most often used as a justification for why beginners should not question their ScrumMaster™ (or process) and simply follow the rules laid down for them by the methodology. 

Much like jazz, any given student1 is only permitted to rise to the next level of the process once they’ve conquered the preceding steps.  i.e. you don’t earn the right to break the rules until you’ve proved that you can follow the rules.2

What’s this got to do with Best Practice?

The term “Best Practice” tends to mean “Industry Best Practice” – people want to adopt Best Practice because it’s considered as something that has been proven to work elsewhere.  i.e. it’s a way to short-cut learning.3

If we say for the moment that we’re talking about authentic Best Practice here, then any deviation from the rules therefore means some kind of sub-optimal performance on the part of the implementers (and should obviously be avoided).

It’s a Good Idea, it’s how Humananity has managed to continue to make technological and societal progress that extends well beyond the confines of the average human lifespan.

The Democratisation of Excellence

There is only one problem. For something to be widely regarded as Best Practice, then it has to be somewhat democratised.  By which I mean it needs to be able to be widely implemented.

If something is widely implementable however, it means that it does not, by definition, take advantage of any organisational or personal strengths.

Thus if we return to the martial arts roots of Shu-Ha-Ri – your Kyū level training will teach you how to punch effectively and without breaking your wrists, but it won’t help you take full advantage of the fact that you’ve got shoulders that would put Schwarzenegger to shame.

By Definition, Ha means Abandoning Best Practice

“Ha” means to break the rules.4  This “right” accrues to the martial arts student upon the event that they are able to prove that they can follow the rules without deviation.

(Thus, we can safely assume that the rules are not being broken due to an insufficiency in ability)5

Once so gifted, students will then begin to break (some of) the rules in order to better adapt the techniques to their individual contexts – always in an endevour to produce superior results.6

For these students, Best Practice ceased to be enabling and had become limiting.

Best Practice is a step along the journey, it’s not the destination

There is actually a lot to discuss around Shu-Ha-Ri7, and I know that some people (Adam Yuret comes to mind)  dislike the concept simply because it creates an apparent hierachy, encouraging people to self identify as “Ha” or even “Ri” simply because that’s a higher grade.

But the simple point I want to make here – is the surprising position that Best Practice finds itself in.

It’s nothing more than the lid of the Shu-Box.

  1. Side thought – wouldn’t it be nice if we all regarded ourselves as students of Agile rather than practitioners, masters or gurus? I doubt you could find many Black Belts in Karate who actually regarded themselves as no longer being a student of the art. 
  2. Skipping this step in music is all that separates jazz from punk. 
  3. Afterall, who wants to be learning when they could be doing 
  4. Yes, the ones you just spent at least 5 years learning. 
  5. There is also the presumption that at least some level of understanding has occured. At the very least, once the student is able to revert to “best practice” at any time, they can now judge for themselves as to whether their adaptations are providing superior outcomes or not.  Also from my personal experience, truly studying a martial art instils a strong degree of humility. (Contrary to what much of Hollywood might portray) 
  6. As opposed simply for the purposes of saying “Hey look I invented my own Martial Art!  It has a different name, an extra few belts and I’m the GrandMaster!” 
  7. I think I have enough Blog Drafts on the topic to fill a book. 


Back in, I think it was 2009, at the Lean Software Systems Conference in Long Beach California, I had the opportunity to have a brief conversation in the hallway with Barry Boehm. For those of you who don’t know the name, you may still be familiar with his most widely spread idea The Cost of Change Curve.

It looks something like this:


It’s most commonly used (in my experience) as a justification for Why We Must Use Waterfall.[1]

I mean, if you look at it, it’s obvious right? You want to get those requirements right! No good finding out that you’ve build the wrong thing once it gets into production! Waaay too expensive.

I gently called Barry on this; kind of / sort of blaming him for arming legions of Waterfall Enthusiasts with a deadly weapon of science and reason. After all you can talk Value until you’re blue in the face, but nobody wants their costs to go up – at least not by that much.

A strange sad expression passed briefly across Barry’s face as he asked me “What else could it mean?”

If you open you mind and look carefully at the chart again- it might just switch from being a mandate to becoming a warning.

A warning, that if you use a Waterfall Style Method, your cost of change WILL go up exponentially towards the end of the project. As it turns out, Waterfall is the cause (and for many people the cure)[2] of and for the Cost of Change Curve.

What had happened was that people (lots of people) had misunderstood the message.

I started to think about what else people had misunderstood (and as a result typically misused) in the world of methods and processes – and came up with what I called “The Misunderstandability Index”. Reflecting on the fact that (for example) Scrum rated very highly on the Misunderstandability Index, whilst the Kanban Method (again for example) ranked a great deal lower.[3]

I largely kept this idea to myself and a few colleagues until a few years later, when I was having lively conversation with Yuval Yeret at the Speakers Dinner after LKNA in Chicago.

We had been having a discussion around whether teams that had utterly failed to grasp Scrum could in fact do Kanban well, or at all. And additionally that it seemed often to be the case that Teams working in environments that were the least suited to Scrum, wanted to to do it the most.

In order to illustrate a point I brought up my story about Barry and my Misunderstandability Index. Yuval was excited, and asked me to publish something on Misunderstanability.

It’s about ease, not difficulty, in cognition

One key factor I’ve come to understand about misunderstanabilability over the last few years is that it’s about ease in cognition. Not difficulty.

Another example may help. At the same conference, Donald Reinertsen was also speaking. And he was speaking on dense economic models. Lots of maths, lots of big words. The stuff he’s famous for. Good stuff, but hard going.

In that room there was very little misunderstanding going on; largely because there was not a great deal of understanding going on. For many people it was all just too hard – but they knew it was too hard.

Misunderstanding occurs when you think you grasp something, but in fact you haven’t.[4]

It brings to mind the Twain quote:

It ain't what you don't know that gets you into trouble.
It's what you know for sure that just ain't so.

Misunderstanabilability is therefore the natural pre-disposition that an idea has towards being misunderstood.[5]

Ideas are not sufficient. If we’re constantly having to tell clients that “it’s not working because they’re doing it wrong” then maybe it’s time we stopped lecturing and started examining the level of misunderstandabilability in our messages.

  1. I personally first encountered the curve, in Project Management classes at University  ↩

  2. This is of course a cure in the same sense of the word that staying drunk is a “cure” for a hangover.  ↩

  3. The lower the score, the more the intent behind your idea is understood by others.  ↩

  4. In psychological terms, you’ve made a substitution in the first instance and are subject to confirmation bias in the second instance. It’s the second part that gets us into trouble, because once we have misunderstood, it’s very hard to suddenly start understanding.  ↩

  5. And in this way I would like to make a clear distinction between “misleading” which implies an intent to deceive and something that’s simply high in “misunderstandabilability” meaning that it’s highly susceptable to misinterpretation.  ↩

Have you Mastered the Basics?

So I’ve noticed a trend in recent years. Whereby a lot of people are hungry for “advanced” Agile and Lean techniques (whether it be at a conference, in the classroom or in a coaching engagement)

So far so good, both Agile and Lean have been around for decades – and so it should not be a surprise that people are passed the basics and ready for some more advanced stuff.

But a conundrum often arises in these situations whereby the organisations and people most eager to learn the more advanced techniques are the very same ones that are yet come to grips with (let alone having mastered) the basics of Agile or Lean.1 (This is obviously a generalisation and not true in every case, but it’s sufficiently widespread for me to consider it a trend)

As I tweeted back in January:

And talking to other established consultants, trainers and practitioners it seems that I’m not alone in this observation.

So what’s going on?

There seem to be two fundamentally different views on what “the basics” are actually comprised of.2

And these two views may be an attribute that is unique to (or at the very least exacerbated by) the very nature of Lean, Agile & Systems Thinking.

(So again making a gross generalisation here)

Many people tend to class the basics as things that you do.3

Whereas “we in community” tend to class the basics as concepts you understand.

And thus many feel that they have mastered the basics when they can go through the motions – they write things on post-it’s or enter them into a tool – perhaps they set WIP limits, and they almost certainly know which three magic questions lead to hyperproductivity

But because they’ve not mastered the basics by the community’s definition – they often fail to yield any benefits from these changes (sometimes they do however, but that’s a topic for another time) – and thus they feel the hunger for something more advanced. Something more to do.

So this explains the phenomena – at least to my satisfaction – but it does not necessarily provide an answer 😉

Except perhaps that we should more carefully consider how we use our language and how we label things; because Basic Practices != Fundamental Concepts.4

  1. This does however put me in mind of an episode of House (“House vs God”) – where Wilson convinces a child who believes that he is a saint and thus does not need surgery to have surgery through the argument that an actual saint would have the humility to believe that they were in fact just sick and not in fact special. 
  2. This being an entirely different question to “what the basics actually are” – I’m arguing ontology here. 
  3. As soon as you do that, it’s also easy to apply models like Dreyfus 
  4. Ease of measurement and evaluation plays a big part here too. It’s much quicker and easier to determine whether or not somebody is having a 15 minute Daily Scrum than it is to determine whether or not everybody has internalised the value of (say) slack.