ShuHaRi for the real world

Unless you’re already well versed in Agile, you might roll your eyes when I say that a Japanese martial arts concept can really help Scrum teams deliver. It’s even a polarising topic among practitioners.

But if you’re of the view that Far Eastern philosophy is an Agile Theatre fig leaf for ever-more-demanding targets, I have three words for you: ShuHaRi.

Now I’m not a Ted-Talking global thought leader. My job — supporting software Scrum teams for the global online platform for used photography and videography kit, MPB — is as grounded and hands-on as project management gets. We build software to manage the entire process, from warehousing to eCommerce applications.

So if I tell you I routinely use ShuHaRi, it isn’t because I have something to sell. But I’m getting ahead, especially if the term means nothing to you. Let’s start at the very beginning … with an aikido lesson.

Shu … what, now?

In traditional Japanese martial arts schools, students are taught that mastery comes about in three stages:

• Shu (守): Apprenticeship. The master models a new skill and students imitate exactly, practising until it becomes an unconscious process;
• Ha (破): Practice. The student develops, experiments and adapts, learning from peers and seeing what works for him/her;
• Ri (離): Mastery. The student acquires the skill well enough to make it his/her own.

Three words. I don’t suggest looking them up in a Japanese dictionary — the precise translation is ambiguous but the process it describes is useful.

Not that you’d always know that from discussions among Agile evangelists. For every “coding dojo” there’s a critic to call “cargo cult” or question the “worrying” concept of mastery. And for many of us, one thing the modern workplace clearly lacks is an all-knowing Jedi master.

But let’s quietly sidestep the bar fight. To me, ShuHaRi is a useful tool that serves the original, worthwhile principles of Agile. It’s a path not to enlightenment, but simply to learning and improvement.

Let me explain how and why that works in our business.

What are we measuring, exactly?

It’s perfectly possible to use ShuHaRi as a glorified appraisal system but for me there’s a much more valuable goal here.

The best teams keep getting better. After any one sprint you might not notice much difference from what went before in product terms. But small changes under the hood add up to big differences over time. It’s a kaizen thing.

We can use ShuHaRi to focus on what we can improve now, building on those skills and competencies over the longer term. Team performance or overall business performance is what we’re measuring, not individual contributions.

But the really big point is this: continuous improvement is the goal, not achieving all-around Zen-like levels of Ri in every discipline. Choosing what we improve, and where we’re happy to remain at Shu for now, is the essence of it all.

There are those who view Agile, with its obscure-sounding concepts and ceremonies, as a quasi-religious belief set. They’re missing some real value.

Our aim is always to move towards greater self-reliance, better communication, adapting to change and keeping our skills up to date. But it’s no more about hitting Ri in all areas than daily stand-ups are about box-ticking.

Team members change. Technology changes. Organisations’ priorities change. Keeping track of team effectiveness needs to cope with constant change and ShuHaRi is a simple but effective way to do it.

How it works

At MPB the process for building team competence looks like this:

1. Create a ‘maturity model’ describing the required tasks and performance levels (see below)
2. For each item, assess the current competence level
3. Define the desired competence level
4. Define a target competence level for the next quarter
5. Define the strategy for doing that
6. Periodically monitor current state v expectation across sprints
7. Adjust actions and/or strategy as required
8. Rinse and repeat.

The maturity model we use takes our overall business goals, breaks out the essential tasks required to achieve them, and describes what each level looks like.

To use a practical example, we might break the “make our delivery more predictable” goal down into facets. That could include, say, “Refinement”, “Planning” or “Flow”. The key results are measured now on how much we improve those facets and the common objective is to consistently improve them.

Then for each of those headings, we can list typical approaches and the level they equate to. We might say that a key part of sprint planning is refining descriptions of functionality. We could define ‘Shu’ level as holding regular refinement sessions, while ‘Ha’ might mean completing refinement two sprints ahead with tasks that can be delivered within 1–2 days.

Using this approach we can arrive at a target timetable for improving each chosen competence. Then every month we review progress; we can then redefine the target or introduce new ones.

Of course, there’s no point in doing this unless we enable our people to improve. If we want to increase our competence in an area, we can organise Agile training, team workshops, formal training or 1:1 coaching as appropriate.

Getting better all the time

For me, the whole point of Agile software development is that cycle of continuous improvement. It’s an empirical approach — experiment, keep what works, make changes based on that and see what works. It isn’t about the jargon or using every tool in the kit all the time.

What I hope we’re creating at MPB is a template to help us manage that improvement. ShuHaRi is a really effective first step towards getting everyone on the same page and speaking the same language.

Take Design Authority, the creation of design documents to guide developers coding new features. A lot of companies might have just a few technical leads working on that and making all the decisions. At MPB we’ve opened it up so that everyone on the team has a say and the final details are agreed as a team. It’s a much more inclusive approach, and the resulting robust documentation makes everything easier and more efficient down the line — refinement, planning, coding, the lot.

There are some people who see maturity models as the destination rather than the journey. But it’s not about aiming to be uniformly Ri in a few years’ time. By then we might have more teams working on different areas, each with their own levels of expertise or experimentation. There will never be a moment when we say, “We’re 100% Agile, we’re done here.”

And there are many solid teams who perform at a high level yet may never achieve ‘Ri’ because there’s no business need for them to do that. That’s fine. What worked in Spotify’s culture may not work for everyone.

If you take an approach too seriously it’s always going to be a failure. You find a baseline, iterate and continually improve. Not so fast that people feel overwhelmed, not so slow that they feel we aren’t improving quickly enough. That’s the key to the journey.

Alexis Uzcategui is Scrum Master at MPB, the UK’s leading reseller of photographic equipment with operations in Britain, Europe and North America. https://www.mpb.com