How Shu Ha Ri could make you better than 96%

*** This is a 7 minute read. If in a hurry just read Intro, Shu Ha Ri and Summary. ***

Intro

2018 only 4% report that their agile practices are enabling greater adaptability to market conditions.

Key word here (according to my analysis): practices

It is difficult (impossible?) to benefit from agile’s greatness through practices only! Yet, the community is constantly debating which technique is the better one when it could be argued that a discussion about the purpose of these techniques would add more value right there.

The Shu Ha Ri concept is a good visualizer of this, and can maybe explain a few of the behaviors we see out there. So I thought I’d spread some light on that and how it can help us adding value faster and not get stuck in a technique discussions like:

“SCRUM says that you should…”

“In the book about KanBan it says that…”

“Sprint boards should be digital…”

I am as guilty as anyone. Years ago I spent a long time convincing (not coaching) a former organization how we could solve almost any problem with some context of ITIL, that I had newly understood to the level where I could read “The Matrix”. I would do that so differently today…

Practices today

We are flooded in new way-of-working philosophies, methodologies, frameworks, models, and techniques. New ones keeps popping up. Heard of the “new TDD” for example? A bit mind boggling, but genius, if you want to drive a certain behavior.

This flooding scales the focus on techniques and we tend to be more lost in HOW-discussions and forget the Why and What.

My suggestion

So if we, like Simon Sinek suggests, start with Why and try that around the agile transformation topic. As an experiment:

  • Why: adapt to changes faster and therefore be better at what we’re doing
  • How: apply Agile & Lean principles (note: not techniques)
  • What: It depends on where the individuals are today. Let’s have someone who understands it all coach the different individuals.

This is where Shu Ha Ri comes in.

Shu Ha Ri

Shu Ha Ri comes from the world of martial arts and describes the process of learning, and it can often be seen in an agile context.

Think of it as a learning ladder. I usually use the movie Karate Kid as a metaphor for this but I realize many are too young to know the reference 🙂

Shu.

In the beginning when we try to learn something new we just do as the teacher says. We do it to learn how things work, to make it a habit. Only then can we start to evaluate things. This stage of the learning is called Shu.

Here’s an example from Karate Kid when Daniel protests about the meaningless practices (typical Shu reasoning).

Ha.

At this level we are now comfortable with all the basic techniques and can start evaluate what works best for a given situation.

Some basics stuff we learned when in Shu, can be discarded if we see it fit. We are now having discussions how we can evolve and do even better. (If the teams lead this discussion, Agile is really starting to happen.)

Ri.

This is the phase when we can create our own approaches and adapt what we’ve learned to our own particular circumstances.

How to use Shu Ha Ri

Everyone will go through all these stages when learning something new. One effective way of moving faster through the phases is to have someone teach you. Or rather coach you. A commander style will teach the techniques&practices but then people won’t learn the habit of evaluating the techniques.

Another effective way is to start with why or the value, this will increase your journey past Shu. You may even skip the Shu phase sometimes when doing this. Ask yourself in the beginning: “so we do this to achieve…”.

So, in essence, what I propose is that in any journey you take on that includes learning, make sure you try to start with why, and have access to someone who’s at one level above you on the Shu Ha Ri. This will dramatically increase your learning curve.

And make sure that person is guided by your Why, so you don’t get lost on the way.

If you don’t have one within your organization, get one. Either by training one, employing one, or hiring a consultant.

This way you won’t end up trying technique after technique only to be disappointed when they don’t give the result you hoped for. 4%… remember?

Possible thresholds

However, there might be some thresholds to hiring a coach, that you have to pass:

  1. The insight that you are actually “only” at the Shu level when you feel full of newly won insights is a hard one. This phenomenon of over estimating your ability even has a name: The Dunning Kruger Effect. (Not meant as a diss to anyone, but this is important, and may have a direct connection to the imposter syndrome we all may suffer from at times later on when actually in Ha or Ri). But try this to avoid falling into that insight trap: When you are guided by your Why, ask yourself “Who knows more than me about this”. If you come up with a name, chances are that person would be good to involve, even if just as a mentor.
  2. The insight that help would be useful, and the humbleness to ask for it, can be a threshold. No easy ways to overcome this one if it’s not natural to you. Look at it as a sign. If you feel that you can manage anything on your own, your agile journey will be long and frustrating anyway.
  3. The feeling of being conned by consultants hungry for earnings. What can I say. There are gold diggers out there but if you listen carefully, you will probably be able so separate them from the ones asking more questions about the Why and about the spirit amongst the teams, than talking about the latest techniques and practices.

Shu Ha Ri is out there

Shu Ha Ri is not mine. I am not linking this martial arts analogy to agile (or any other way of working). This has already been done several times, and the debate today indicates that this piece is missing all too often.

For example, I came across this 2016 article by Jason Novack with some good examples on how Shu Ha Ri can be used in agile teams. It’s a good read.

This one from Matt LeMay is also pointing to the same conclusion and has a visualized “agile trap”.

A lot of organizations I come across has a lot of frameworks and models in place (or partially) but when asked what they are meant to do, their purpose, many fail to have a clear answer. This looks a lot like Shu level thinking where you focus on the technique rather than the purpose. How well can such a framework perform value?

Ola Berg, a Swedish “agilist” wrote a post on this topic where he serves a three step process which is going to be tough for a Shu person to handle alone. Also a good 1min read.

Summary

Finally, let’s get back to the fact that only 4% report that their agile efforts are actually enabling greater adaptability.

  • Is it because agile doesn’t really work?
  • Is it because many are adapting scaled agile and are in the beginning of their journey?
  • Is it because many try to handle their journey from Shu levels?

I can’t know for a fact but my guess is that a lot of those 96% are not doing it the way it’s supposed to, yet.

And I Believe that having a Shu Ha Ri perspective when learning something new, such as agile, will immensely increase the speed towards real value.

Let’s all try together to do better than 4% – with a little help of someone who has even more skills and understanding.

*** Commercial warning***

I love to remove obstacles that keeps you from effectively delivering value so if you feel you might benefit from a discussion, let’s have a “swedish fika“. My first humble question will probably be what you’re aiming to achieve and we could have a wonderful interaction from there…

If you feel you can mentor me to achieve a higher understanding in agile priciples, let’s have a swedish fika!

*** End of warning, and of article as well ***

No trust – No Agile

New assignment, new client. The mission is to help an IT organization cooperating together in a better, common flow.

I suggest (again) that we approach the project iteratively instead of making a detailed plan assuming that the proposed medicine is right.
All management agree.

Out of experience I choose to double check a few things with management to avoid future misunderstandings:

  • That means that we will work with the things the organization experience needs improving. That way we create value faster and commitment with less effort.
  • We only do what we have to, to achieve our epics/goals. No more. No less.
  • We continually adjust the projects focus to where it benefits the most.
  • We can’t say exactly when we will be finished, it can be both sooner and later than expected, but we will always be able to give a forecast/assumption based on what we have done and learned so far.
  • Iterations in the near future will be more detailed than the more remote ones.
  • And, agile does not mean we don’t plan – in fact we plan more than in traditional projects…

Management still agrees.

Then it comes to doing it IRL with the appointed team. This is when it starts to hurt:

  • “Well, you guys can’t work agile with my people since they work in the line organization…”
  • “Can you specify all the activities in all the sprint now, so we now what will be done?”
  • “You can run the project agile but I need a detailed plan…”
  • “But, if we don’t control the team they can hide behind their sprint and do whatever…”
  • And more of the same…

I think all of this comes from trust. Lack of trust.

  • Trust that agile actually works (although all companies today aim to be more agile and innovative)
  • Trust that staff can take responsibility to solve tasks themselves, in the best possible ways (although serious money are spent on competent people)
  • Trust that others can decide what is the right, or wrong, thing to do
  • Trust that the priority will be done right (although we ask the business to be active product owners and handle the backlog)
  • There are more examples…

What happens then is that we start doing lots of compromises to please management which, in turn, doesn’t always help achieves the outcomes faster. It normally does t help the teams either

I think that truly successful agile isn’t so much about the tools and methods in itself, but more about management and leaders (I have to write about the difference some day) starting to let go of their habitual ways of acting, thinking and leading.

Management and leaders must start to really trust that their colleagues can do what is the best thing.
Trust that motivation actually increases with increased autonomy.

Without this true trust, agile can never really blossom, or scale beyond some departments or groups.

Maybe, as Erik and Dick suggested in agilpodden (Swedish only), managers should be sent to Scrum Master courses. Not to become Scrum Masters but to understand how agile can be done in reality and how much the teams rely on a business oriented Product Owner to prioritize the backlog.

Trust.

What do you think?

Agile or ITIL (incident edition)

Mattias had a client where the agile way of working had gone a bit too far on the chaos end so a bit more structure was needed, or bureaucracy as Henrik Kniberg says in the classic animation (below).

The solutions was mainly found in the ITIL framework, which was of course frowned upon as old school.

– processes? We work agile…, they said.

So how do we sneak in structure to a team that shrugged at the bare word process?

Well, three of us got together and took some structure from an ITIL process, and shaped it so it would fit the agile teams – never mentioning the word “process”.

We then realized others could use this, so we decided to try to make it an animation.

So here we have it. It’s how to handle incoming bugs or tickets for a agile team that takes care of their product/service in production. Or, in the language of ITIL, incident management.

We strongly believe you don’t have to choose between ITIL or Agile. Or any other framework or model. You get the best benefit if you can cherrypick stuff from all of them in a way that suits you.

We have an ambition to make another one about how to we work with change  (ITIL definition) in a smooth flow without unnecessary stops or thresholds. Would that be interesting? Let us know.

Oh yes, three of us made the film. The fantastic Johanna Bach Wallentin was the third enthusiastic creator!