Shu ha ri—three stages towards agile maturity

“Scrum has its roots in Japanese thought and practice”, Jeff Sutherland, the co-creator of Scrum, tells us in his book Scrum: the art of doing twice the work in half the time (Random House, 2014), p.38.

One of the ideas that Scrum has drawn on is the Japanese martial art concept of shu ha ri (or shuhari) which outlines three stages of learning towards mastery.

Over the last few years, I have found this a really useful model to bear in mind when working with teams as they embrace and grow towards agility.


The first stage of mastering something is shu (守), which roughly translates into English as ‘protect’, ‘obey’, ‘observe’.

In this state, the student learns the rules, forms and patterns of the discipline. The rules are followed and not deviated from. They are repeated and absorbed.

In the film, The Karate Kid (1984), Mr Miyagi sets Daniel to do menial tasks like painting the fence and waxing the car (“wax on, wax off”). Daniel feels frustrated, he wants to get on and learn karate not do chores; he feels that Mr Miyagi is simply using him as a slave. But this is the shu state: learning the basic patterns, feeling the rhythm, learning muscle memory.

For teams learning Scrum and agility the shu state can be experienced when teams learn the rhythm of the events (sprints, daily scrums, backlog refinement meetings, sprint review and retrospective), learning to use the backlog and writing user stories.


The next state is ha (破), which roughly translates as ‘detatch’, ‘digress’, ‘broken’. Once you have mastered the forms, you can begin to break them and make innovations.

When I was learning Hebrew at university, I would first write the Hebrew characters exactly as I had been taught, almost printing them. In my second year, the characters were familiar. I could write them without thinking and having read more Hebrew and looked at more font faces, I began to adapt a few of the characters to make them my own.

For teams learning Scrum and agility this state of ha can be found in perhaps adapting the daily stand-up meeting to not slavishly follow the three question format (What did I do yesterday? What will I do today? Are there any impediments?), or exploring news ways to run a retrospective to ge the best out of the team.


The final state in the road to mastery is ri (離), which roughly translates as ‘leave’, ‘separate’, ‘depart’.

In this state you now embody the discipline. It is so embedded within you, you can stop clinging to the initial forms and be creative in an unhindered way doing everything in the spirit of your discipline without awkwardly trying to recreate the exact patterns and forms.

Consider the guitarist who has so mastered their instrument they are longer constrained to playing fixed mode and scale patterns; they now traverse the fretboard fluidly, playing the full length of the instrument, switching scales at will and sometimes going outwith the scales to express themselves.

For Scrum teams being in a state of ri might mean that they stop estimating stories because they now instinctively create small-enough stories that will be delivered to production within a day or two. Or their daily scrums become gatherings that adapt to the needs of the team, with on-the-spot analysis towards shippability and where corrective action is taken.

A familiar model

This model is probably familiar to many. Learning anything takes discipline. At the start you ‘obey’ (shu) your coach’s instructions. Once you understand why you are doing it you begin to ‘detatch’ (ha) and adapt. And finally, after further practice you can ‘leave’ (ri) those early practices behind, fully make the discipline your own and coach others.

“Scrum is a lot like that,” writes Jeff Sutherland. “It requires practice and attention, but also a continuous effort to reach a new state—a state where things just flow and happen.”

What I really like about this model is that it encourages teams to slow down and focus on the basics. In such a fast-paced world, it’s refreshing to be encouraged to slow down and go deep. It’s okay to be where you are in terms of your agile maturity. Embrace it and strive to be better.

No shortcuts

Why are the New Zealand All Blacks rugby team so good? Because they have focused on the basics, have embodied the fundamentals, and they understand why these disciplines are important.

My friend Steve teaches bass guitar. When new pupils tell him that they want to be able to play fast, he simply replies, “Playing fast is just playing slow speeded-up.” Learn the basics, get your technique right, learn the positions, learn the scales. Then take it to the next stage.

You can’t take shortcuts. I’ve seen teams new to agile decide early on that they’d like to abandon user story estimates because “that’s what some of the best agile teams do”. But they’ve only done that because of their experience. They understand why they are not using estimates because they have embodied the disciplines that now make estimates unnecessary. That only comes through discipline, practice and experience.

Situational leadership

The kind of input a team needs from their scrum master will to some extent depend on where a team is on this shu ha ri spectrum.

Mike Cohn has a really helpful (and free) 15-page paper called Situational Scrum Mastering that explores this and offers a helpful model. If you are interested, it’s well worth a read.

Where is your team?

If you’re working with an agile team, where is your team on this journey, shu, ha or ri?

Do you need to take more time to focus on the foundations, replay the patterns and rehearse the basics? Or is it time to innovate and push the boundaries of what you’ve learned to find more agile ways of working.

Originally published on my work’s internal blog.

Photo by Thao Le Hoang on Unsplash

Team meeting via Google Hangouts

Daily meeting via Google Hangouts
Daily meeting via Google Hangouts

Last week I had to work from home one morning. Our team meets at 09:30 every morning to catch-up. Years ago I suppose I would have had to either phone in or miss it.

We used Google Hangouts to allow my colleague Lewis and I to take part, connecting remotely.

Isn’t the world wide web an amazing thing!

Agile planning poker

For a few months we’ve been starting to use Agile, and specifically Scrum, methods in planning and managing our Web projects at work.

This week we adopted a new practice: planning poker.

Agile / Scrum iteration planning board
Agile / Scrum iteration planning board

Like many teams starting out with Agile practices we didn’t just jump in feet first and adopt every Agile method going; that would have been too much to take in. So we began with a few methods:

The photograph above, taken a couple of months ago, shows the planning board in our office — an information radiator — that shows us at a glance how many tasks are left to do, what’s currently being worked on, what’s in testing, what’s done and (unlike, I would guess, most other Agile boards) what we’re waiting for.

Multiple projects

By definition Agile really should be used by teams working on one project at a time. It’s simply not efficient working on more than one because as soon as you start switching between different projects you lose time. One reason is that it takes time to get back up to speed with project B after working on project A.

However, some of us have no option but to work on more than one project at a time, as well as juggle support emails, telephone calls and the like. In which case you simply have to adapt the principles of Agile to accommodate more than one project, and essentially run them all in tandem as though you were working on multiple threads of a single project.

Karl Scotland, formerly Development Team Leader with BBC Interactive wrote a really useful paper back in 2002 entitled “Agile planning with a multi-customer, multi-project, multi-discipline team” (DOC, 225 KB) in which he explained how he ran things at the BBC where they would regularly work on three projects simultaneously.

We currently have 19 projects on the go at the moment. Which is far, far too many and we need to do something about it. So this week we revisited our project backlog and introduce a new Agile method to the mix: planning poker.

Planning poker

Planning poker cards
Planning poker cards

The idea behind planning poker is very simple: “planning poker is a consensus-based estimation technique for estimating, mostly used to estimate effort or relative size of tasks in software development” (Wikipedia).

Each member of the team had a pack of cards (I made our cards using Microsoft Publisher 2007 and a handful of skills) which have a sequence of numbers printed on them. They are quite often close to a Fibonacci sequence to reflect the uncertainty in estimating larger items. Our pack uses the sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, a ? (unsure) and a coffee cup (I need a break).

We then took each item in our project backlog and after an explanation of what was required we all took a vote on how difficult we thought it would be as a project, placing the cards down on the table at the same time so as not to influence another player’s estimation by laying your card earlier than them.

Once voted, unless the group has a consensus the person who laid the lowest-value card and the person who laid the highest-value card explains why they thought it was easier (they’ve done this before, for example) or harder (what did the others miss?).

Votes are taken again until a consensus has been reached and then the team passes to the next task or project on the list.

We found it a really useful exercise because it actively encourages everyone to speak and gives everyone an equal say in the decision-making processes associated with managing projects. We really quickly got to the core issues related to each project and at times an interesting spectrum of scores (13, 20, 40 and 100 for one project).

Planning poker cards (PDF)

Our conclusion

Our next stage is to complete the scoring on the remaining <cough> 60+ projects, and work with our boss to prioritise projects. That should give us an overall score (estimate x priority) which will enable us to more accurately plan when we should schedule these projects and in which order. For example, you don’t really want to be tackling three really taxing projects at once.

Oh, and it makes the task of planning much more fun.

If anyone wants a copy of the cards I made (in PDF format) drop me a note in the comments and I’ll upload them for you.

More resources

Luis Goncalves, co-author of the excellent book Getting value out of Agile Retrospectives has written a really useful article about planning poker:

Planning poker and scrum poker: everything you need to know