Shu Ha Ri

There are various ways to think about people gaining and improving skills. One such way is called Shu Ha Ri. It comes from martial arts, but the underlying idea can be applied to other domains as well. Many other much smarter people than I (such as Martin Fowler and Alistair Cockburn) have already given their take on Shu Ha Ri. I would encourage you to read their words as well. In this blog post I’ll give my own interpretation of Shu Ha Ri as well as some observations I’ve had about it.

Introduction

So what is Shu Ha Ri? It is a way to describe skill acquisition using three levels, named shu, ha, and ri. There are different ways to describe these three levels. I like to describe them like this:

• Shu - Follow the rule. At this stage learners are focused on what the rules of the skill are. Learners at this level often want a list of rules about what they should do and how they should do it. A lack of rules or excessive exceptions to the rules will cause confusion and frustration.
• Ha - Bend the rule. At this stage the learner has learned the basic rules of the skill and is now learning what the exceptions to the rules are. This stage can also start to include context specific rules. e.g. Rule X applies in situation Y but not in situation Z.
• Ri - Be the rule. At this stage the specific rules are less important than the principles behind the rules. In fact, the specific rules originally learned may now seem overly burdensome.

An Agile Example

While the idea of Shu Ha Ri can be used in lots of contexts, it is often used in the context of various practices from agile software development. For this example I want to use an idealized adoption of the Scrum software development methodology.

When a team or organization first starts investigating agile methodologies they are often coming from a completely different methodology. Therefore any agile methodology will be foreign to them. They want to know exactly what they should do to “be agile.” Scrum has a lot of specific practices around specific ceremonies, such as a daily standup meetings, sprint planning meetings, or retrospectives. This looks a lot like a list of rules to a new learner. Newcomers to Scrum will tend to worry about things like exactly how many weeks their sprint should be, what exactly people should and shouldn’t say during the daily standup, or what questions should be discussed during a retrospective. The rules are completely foreign so they want to know exactly what those rules are. This is the essence of shu: learn the rules.

One of the beauties of Scrum (and most other agile and lean methodologies) is that it won’t necessarily solve your problems, but it will make them painfully obvious to you. As learners become more familiar with the rules around specific meetings and practices, they will start to run into problems. They may notice that daily stand up meetings tend to be boring. Constantly having work spill over from one sprint to the next may cause them problems. They may discover other pain points. Some of these pain points may suggest areas where they should modify their behavior to fit the methodology, but others may suggest areas where they should modify the methodology to fit their unique needs. This is the essence of ha: learn when to modify the rules and adjust them in different contexts.

Assuming that the team or organization continues to improve their development practices using retrospectives and other feedback mechanisms they will likely reach a point where they feel frustration despite following all the Scrum practices. Scrum has a lot of specific practices around sprints and the related meetings, but it says very little about technical practices. Realizing that the specific rules of Scrum might be insufficient for their context could be a source of frustration for learners. The team might have moved to pair programming or mob programming, reducing the need for a daily standup meeting. The team may have developed sufficient discipline and automation that they can release whenever they want, not just at the end of a sprint. Suddenly they start feeling constrained by the rules of Scrum. Rather than helping, the rules are hindering the performance of the team. This is the essence of ri: the underlying principles behind the rules have been learned and the specifics of the rules are no longer important.

Some Observations

I’d like to share a few observations I’ve had about Shu Ha Ri and how it can be applied to some common situations.

Different people, different skills, different levels

The first observation is pretty straight forward. It is that there are different skill levels. Different people have different levels of skill. And different people are at different levels in different skills. For example, I might be at a ri level at test driven development while you are at a shu level. But at the same time you might be at a ri level at database design while I am at a shu level in that same skill. There might be other skills at which I am at a ha level. Most importantly, just because a person is at a given level in a given skill it does not mean they are that level of person! Just because I am at a shu level in a particular skill it doesn’t mean I’m a shu person. Nor does it mean that I can’t improve in that or any other skill.

Expert beginner

There is an interesting point when learners are approaching the end of the shu phase or entering the ha phase for a given skill. Shu and ha are all about learning the rules and finding exceptions to the rule. It can be easy for learners to conflate mastering the rules of a skill with mastering the skill itself. This pitfall is so common that it even has a special name: expert beginner. The expert beginner trap is an important one for any learner to keep in mind as they are acquiring a new skill. It’s always worth asking a self-reflective question about whether you have truly mastered a skill or if you have only mastered the beginning rules of that skill.

Different perspectives

Differences in perspective can be challenging in all kinds of contexts. Shu Ha Ri is no different. The most extreme case is between shu learners and ri learners.

A shu learner looking at a ri learner will see someone who doesn’t follow any of the rules. The ri learner often won’t be able to explain why they do what they do in a way that makes sense to a shu learner, instead giving reasons like “That’s just the way you should do it” or “It just feels right”. To a shu learner a ri learner may do things that don’t make sense or that look like chaos and anarchy.

On the other hand, a ri learner looking at a shu learner will see someone longing for constraints, for lists of things they should and shouldn’t do, for explanations of every step of every process. The way a shu learner wants to work will often feel byzantine and cumbersome to a ri learner.

Because of these different perspectives it can be challenging for a shu learner and a ri learner to relate to each other. It can be hard for the ri learner to remember what it was like to be the shu learner. And it can be hard for the shu learner to imagine the things the ri learner is talking about. Sometimes a ha learner can help bridge the gap between a shu learner and a ri learner.

Conclusion

As you are working to acquire new skills, think about how you will need to progress through that learning. Keep in mind that you’ll probably need to learn a lot of rules before you can start bending them.

Next time you’re having a debate with someone on a given topic, stop and think about what level each of you are at on that topic. Are you both at the same level? Are you at different levels? Is one of you at shu while the other is at ri? Are either of you falling prey to the expert beginner trap?

If you’re a shu learner in a given skill, try to accept the advice a ri learner provides, even if it sounds crazy. If you’re a ri learner, try to remember what it was like to be the shu learner and help them through that part of their journey as best you can. And if you’re a ha learner, try to keep the shu learners and ri learners around you from killing each other.