Scrum and Shu Ha Ri

I hear many people describe teams leveraging Scrum in terms of Shu Ha Ri. How that Scrum executed well, teams delivering high value, is a Ri state.

While I understand that perspective, and have coached to that perspective, I see things differently. I see Shu Har Ri being more representative of a higher level.

What is Shu Ha Ri?

Shu ha ri comes from Japanese martial arts. It’s a phrase used to describe becoming a martial arts master. The stages a student passes through on their journey to mastery.

“It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebears created. We remain faithful to these forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.”

Aikido master Endō Seishirō shihan

How I describe Shu Ha Ri to others:

• Shu — Follow the Rules
• Ha — Break the Rules
• Ri — Define the Rules

A subtitle of the Scrum Guide reads: The Rules of the Game.

Aha — a team using Scrum at Shu level follows the rules as defined in the Scrum Guide.

Scrum is a Teaching Framework

Scrum is a teaching framework. It introduces the concept of a timebox, called a Sprint, which helps teams learn to limit scope. It introduces several feedback cadences, the Sprint Review and the Sprint Retrospective. These teach the team to inspect and adapt both the product and their ways of working.

A phrase I’ve heard from several PSTs (Professional Scrum Trainers) is that “as the team evolves, Scrum dissolves”.

I like that phrase, and completely agree. Teams can outgrow Scrum. It’s like the scaffolding used to build a house. Once the house is far enough along in its construction the scaffolding is no longer needed. It can even get in the way.

Frameworks are not the Goal

All frameworks add overhead to the system, some more than others. I’m looking at you SAFe.

While Scrum is lightweight it is not free. It takes time for the team, stakeholders and others to attend the events and perform additional Scrum related activities.

Following frameworks alone will not make a team, or an organization, Agile. Without understanding how the various aspects of Scrum teach Agile it becomes a process to follow. Learning will not happen. Adaptation to context will not occur. Blindly following Scrum leads to Zombie Scrum, Dark Scrum, Cargo Cult, it has many names.

Being the best team ever at performing Scrum is not the goal. If framework adherence is the wrong target, Ri level isn’t flawless Scrum.

Agility is the Goal

I define agility as the ability to hold loosely to plans and to adapt when necessary. This means at all levels, not only teams.

Not all companies will benefit from, or even need, high levels of agility. Some industries do not have high levels of uncertainty or high levels of unknowns across the board. For example, in the highly regulated banking industry, a lot of the work has well known solution spaces.

An example is incorporating Identity Management into the systems. This is a well defined problem and solution space. Not a lot of uncertainty so adding the overhead of a framework such as Scrum, to reduce risk in highly uncertain domains, isn’t necessary.

If you are in such a domain, and teams are using Scrum, it’s likely time to begin breaking the rules.

Breaking the Rules (Ha)

There are at least 2 indicators that teams should begin breaking the (Scrum) rules:

• The domain doesn’t require high agility (see above).
• Teams have incorporated the learning from Scrum and would benefit from adapting their ways of working to context.

In such environments begin to examine the Scrum events, accountabilities and artifacts. Ask questions:

• Are there better ways to inspect and adapt the teams way of working other than a scheduled Retrospective every Sprint? Could they implement an andon cord concept and stop and retrospect in the moment when they encounter an issue?
• Does the team need the formality of the Sprint? Would they benefit by experimenting with a continuous flow approach and gathering feedback in smaller batches or single items?
• Does the team need a full-time Scrum Master? Can several team members adopt parts of the accountability?
• Would the team benefit by adding Kanban practices into their processes?

Form these answers into hypothesis and then perform experiments. Use data such as cycle time or throughput to measure the effectiveness of the changes. If delivery is improving, keep the change. If no, ditch that change immediately and adapt. Be agile about increasing agility. Don’t let egos hold you to bad change.

Ask the team members. I’m certain they will have suggestions that better fit their context than I can describe in a more generic sense in an article. I’m not there, I can’t define specific suggestions without knowing your space.

The Correct Level of Agility is Mastery (Ri)

A former colleague wrote:

An agile enterprise is one that has achieved a level of operational excellence that enables it to make changes at the same pace that it discovers a need for them.

Tim Snyder

There is no way I can improve on that. And years after first reading it I still refer to it often and draw inspiration from it.

Each team and organization must seek the optimal level of agility for them. There can be no one-size-fits-all. No framework can deliver those results.

Teams and organizations must experiment and use data to gauge the effectiveness of change. At a team level I rely on Lean metrics such as Lead Time and Throughput. At the organizational level DORA metrics can be quite useful.

Teams that are crushing it, continually delivering high value with high quality, may have started with Scrum. But now you would likely see few or no aspects of Scrum. The team has evolved, the framework has dissolved.

You know it when you see teams like this. You feel their effectiveness, customers are happy and the team is happy. They adapt at speed as the need arises.

This is Mastery, this is Ri.

For more on adding Kanban practices to Scrum check out my article on that topic:

Enhance Scrum With Kanban Practices

If you found this article helpful, please click on 👏 and follow me for more valuable information on Agile, Lean and Book Reviews.

Until next time!