Shu-Ha-Ri

The Three Words Your Team Gets Wrong

A few years back, I was sitting in on a retrospective with a team that had been “doing agile” for about eighteen months. The Scrum Master asked: “Are we following the Scrum Guide?”

A senior developer leaned back, arms crossed, and said - with the confidence of someone who has definitely never read the Scrum Guide - “We’ve moved past that. We’re doing our own thing now. Shu-Ha-Ri, right? We’re in Ri.”

I looked at their board. No sprint goal. No definition of done. A “daily standup” that happened on Tuesdays and Thursdays. The product owner hadn’t attended a sprint review in two months.

This wasn’t Ri. This wasn’t even Ha. This was a team that had never been in Shu - using a Japanese martial arts concept they’d half-read on a blog post to justify skipping the fundamentals entirely.

Shu-Ha-Ri is the most misunderstood concept in the agile coaching world. Not because it’s complicated, but because it’s convenient. It gives teams a sophisticated-sounding reason to stop doing the hard parts.

The concept traces back to the fourteenth century, to Zeami Motokiyo - the father of Noh theater in Japan. Zeami described stages of artistic mastery in his secret treatises, outlining how a performer progresses from rigid imitation to creative expression to a state where technique becomes invisible. The framework later found its fullest expression in Japanese martial arts, particularly through Aikido master Endo Seishiro, who articulated the three stages as a universal path of learning any discipline.

Alistair Cockburn brought Shu-Ha-Ri to the software world in the early 2000s. Martin Fowler’s essay “ShuHaRi” further popularized it in the agile community. And then, as happens with elegant ideas that pass through enough conference talks, it got simplified into a bumper sticker and used to justify all sorts of things it was never meant to justify.

The Three Stages of Actually Learning Something

Shu-Ha-Ri describes a progression of mastery. Not a menu you pick from. Not a maturity assessment where higher is always better. A progression - one that only moves in one direction and only after the previous stage has been genuinely inhabited.

Shu (守) - Protect the Form

The kanji 守 means “protect” or “obey.” In Shu, the student follows the form exactly as taught. No improvisation. No personal interpretation. No shortcuts. You learn the kata precisely the way your teacher shows you, and you practice it until the movements are in your body, not just your head.

In martial arts, this looks like a white belt repeating a basic block three hundred times in a single class. In Noh theater, this meant years of copying the master’s exact movements before the student was permitted a single creative choice. Zeami was explicit: imitation is not the absence of artistry. It is the foundation of artistry.

For agile teams, Shu means following the framework as written. All five events. All three roles. All three artifacts. You don’t skip the sprint review because “nobody finds it valuable.” You don’t merge the daily scrum and the retrospective because “we’re efficient.” You follow the recipe.

This is the stage most teams want to rush through - or skip entirely. And I get it. Shu feels constraining. For experienced engineers who are used to solving problems creatively, being told to follow a process step-by-step can feel almost insulting.

Here’s what I tell those engineers: the constraint is the teacher. You don’t learn why a practice exists by reading about it. You learn why it exists by doing it long enough to feel the edges - the moments where it helps, the moments where it chafes, the moments where you think “this would work better if we just…” That friction is the lesson.

Shu requires patience from the learner and backbone from the teacher. Both are in short supply.

Ha (破) - Break the Form

The kanji 破 means “detach” or “break.” In Ha, the student has internalized the form deeply enough to begin questioning it. Not rejecting it - questioning it. There’s a difference the size of the Grand Canyon between those two things.

Ha emerges from mastery, not impatience. The martial artist who has practiced the basic block thousands of times notices that against certain attacks, a slight angle adjustment works better. This isn’t rebellion. It’s understanding deep enough to see the principle behind the technique.

For agile teams, Ha looks like thoughtful experimentation grounded in understanding. “We’ve been running two-week sprints for a year. We’ve noticed that our stories consistently take longer than two weeks because of the deployment pipeline. Let’s try three-week sprints and see if that changes the completion rate.” That’s Ha - the team understands the purpose of the timebox, they’ve lived inside it long enough to feel its edges, and they’re making a deliberate adjustment.

Compare that to a team that says “two-week sprints feel too short” in their third sprint ever. (Spoiler: they always feel too short at first.) That’s not Ha. That’s Shu-avoidance wearing a Ha costume.

The diagnostic question that separates real Ha from fake Ha is one I use constantly: “Did you learn the rule before you broke it?” If the team can articulate what the practice is for and specifically why their modification serves the purpose better - that’s Ha. If the answer is a shrug and “it just didn’t work for us,” that’s a team that never entered Shu.

Ha is the stage where coaching gets genuinely interesting. The conversations shift from “here’s how the framework works” to “here’s why the framework works, and here’s where the principles might be better served by a different approach.”

Ri (離) - Leave the Form

The kanji 離 means “leave” or “separate.” Ri is the stage where technique becomes invisible. The practitioner has internalized the principles so completely that they no longer think about them consciously. They simply act, and the action is appropriate to the moment.

In martial arts, Ri is the master who no longer executes techniques - they flow. The decades of Shu drilling and Ha experimentation have built a repertoire so deep that it operates below conscious thought. In Noh theater, Zeami described this as the stage of “the flower” - a quality of performance so natural and present that it seems effortless, even though it rests on a lifetime of disciplined practice. The audience doesn’t see technique. They see truth.

(If that sounds mystical, it’s because Zeami was writing in fourteenth-century Japan about the nature of artistic transcendence. Cut the man some slack.)

For agile teams, Ri is genuinely rare. A team in Ri doesn’t “do Scrum” or “do Kanban.” They solve problems. The practices emerge naturally from the situation. They don’t think about frameworks. They think about outcomes. The principles of agility - transparency, inspection, adaptation, delivering value - are so deeply embedded that the framework is no longer needed. The framework was the training wheels. The principles are the balance.

Here’s the thing about Ri: very few teams genuinely reach it. It requires stability, autonomy, and mastery of fundamentals that most organizations simply don’t provide. Most teams that claim Ri are actually in one of two places: genuine Ha (they’ve mastered and adapted the practices, which is excellent) or pre-Shu (they never learned the practices and are mistaking ignorance for transcendence). The second category is, unfortunately, the more common one.

What This Changes About Your Coaching

The Pre-Shu Problem

This is the single most valuable coaching application of Shu-Ha-Ri, and it’s the one I reach for most often.

In my classes, I ask a simple question: “How many of you work with teams that have customized their agile process?” Every hand goes up. Then I ask: “How many of those teams learned the standard process first before customizing it?” About a third of the hands stay up.

That gap - between the number of teams doing custom agile and the number of teams who earned the right to customize - is the pre-Shu problem. Teams that skipped Shu and jumped straight to what looks like Ha or Ri, but is actually just making it up as they go.

Pre-Shu is not a stage in the model. It’s the absence of the model. And it’s by far the most common state I encounter in the wild.

The coaching move: don’t argue about whether their current process is good or bad. Instead, ask what they skipped. “Before you decided the daily standup wasn’t valuable, did you run it as designed for at least three months? Did you timebox it? Did the whole team attend?”

Usually the answer reveals that what they tried was a pale imitation of the practice, executed halfheartedly, abandoned quickly, and then cited as evidence that the practice doesn’t work. (That’s like trying to play guitar for two weeks, deciding music isn’t your thing, and telling people you’ve “moved past” musical instruments.)

Diagnosing the Real Stage

When a team tells you they’re “past the basics,” Shu-Ha-Ri gives you a respectful diagnostic framework. You’re not calling them liars. You’re asking them to show their work. Three questions that reveal the real stage:

• “Walk me through why you changed this practice.” (Ha-stage teams can articulate the principle they’re optimizing for. Pre-Shu teams say “it felt wrong.”)
• “What would you lose if you went back to the standard version for one sprint?” (Ha-stage teams can name specific things. Pre-Shu teams aren’t sure what “the standard version” even is.)
• “If a new team member joined tomorrow, could you teach the fundamentals before the adaptations?” (Ri-stage teams can teach any stage. Pre-Shu teams can only teach what they currently do.)

These aren’t gotchas. They’re invitations to self-assess.

The Courage to Enforce Shu

Here’s the hardest coaching move in the whole model: telling a team they need to go back to Shu.

Nobody wants to hear it. A team that’s been “doing agile their way” for two years does not want a coach walking in and saying “actually, I need you to follow the Scrum Guide for the next three months.” It feels patronizing. It feels like regression.

But sometimes it’s exactly what’s needed. The key is framing. Don’t frame Shu as punishment or remediation. Frame it as investment. “You’re smart enough to adapt this framework. But adaptation works better when you know what you’re adapting and why. Let’s build that foundation.”

Shu-Ha-Ri as a Dreyfus Parallel

If you’re familiar with the Dreyfus model of skill acquisition, you’ll notice significant overlap. Shu maps to Novice and Advanced Beginner, where rules provide essential structure. Ha maps to Competent and Proficient, where context informs judgment. Ri maps to Expert, where intuition supersedes conscious analysis.

The parallel reinforces a crucial point: skill acquisition is sequential. You cannot expert your way past the beginner stage. The Dreyfus brothers were studying airline pilots and chess players, not martial artists - but they arrived at the same insight Zeami articulated six hundred years earlier. Mastery is a path, not a destination you can teleport to.

The Dreyfus parallel also gives you a Western vocabulary for teams that might resist the martial arts framing. Some teams respond better to “you’re at the Advanced Beginner stage of this skill” than “you’re in Shu.” Same insight, different language. Use whatever gets through.

What It Looks Like in the Room

I’d been coaching at a regional logistics company for about six weeks when the request came in. The VP of Operations wanted me to work with the warehouse management software team - seven developers and a product owner who’d been, her words, “doing agile for three years.”

I’ve heard that sentence more times than I can count. I heard it when I was running eight Scrum Masters across seven departments at a clinical diagnostics manufacturer. I heard it at the in-flight entertainment company where I was a Technical Program Manager. I heard it at the email delivery startup where I was the first agile coach they’d ever hired, back when the company was twenty-five people and I watched it grow to two hundred and twenty. “We’ve been doing agile for X years” is one of the most dangerous sentences in organizational life, because time served is not the same thing as learning earned.

The VP’s exact framing was: “They’re mature. They’ve figured out their own process. But delivery keeps slipping and we can’t figure out why.” That’s almost always the tell. When leadership describes a team as mature but can’t explain the delivery gap, what they’re really saying is: the team looks confident and the results don’t match the confidence.

I sat in on sprint planning my first day. The team moved with the loose rhythm of people who’ve been doing something a long time. They had a backlog. They had a board. They pulled stories and estimated them with fist-of-five - quick flashes, no discussion, move on. It had the shape of a ceremony. It did not have the substance of one.

No sprint goal. The tech lead - a sharp developer named Tasha, the kind of engineer who remembers every architectural decision from three years ago and can tell you exactly why it was made - said they’d stopped setting sprint goals about a year ago. “We found them artificial. We know what we need to build.” No definition of done. “We know what done means. We don’t need to write it down.” Retrospectives happened once a month instead of every sprint. “We ran out of things to talk about,” the product owner, Carl, explained with a shrug that suggested he hadn’t thought too hard about why that might be a problem.

The daily standup was a ten-minute status report. Nobody mentioned blockers. Nobody asked questions. Two developers checked their phones while others were talking. I’ve taught over seventy A-CSM classes at this point, and I always tell my students: the daily scrum is the canary in the coal mine. When it becomes a status meeting that people endure rather than a coordination session they need, something upstream is broken. This canary wasn’t just dead. It had been dead long enough that nobody remembered it was supposed to sing.

On paper, this team looked like Ri. They certainly thought so. Tasha used the word “evolved” at one point. Carl described their process as “post-Scrum.” I wrote that down, because I wanted to come back to it later. (I have a collection of phrases teams use to describe processes they’ve never actually followed. “Post-Scrum” is one of my favorites, right up there with “Scrum-ish” and “agile-adjacent.”)

I spent the second week doing something boring and essential: I pulled the data. Sprint completion rates over the last six months averaged 54 percent. Stories carried over sprint after sprint like luggage nobody claimed at baggage carousel three. The team hadn’t released to production in eleven weeks. There was no impediment log, no metrics dashboard, no velocity tracking. Nothing. Just vibes and a Jira board.

Here’s the thing about 54 percent. That’s not a struggling team. That’s a coin flip. You could literally flip a coin at sprint planning to decide whether a story gets done, and you’d hit the same rate. When I show teams that comparison, it tends to land.

At the end of that second week, I asked Tasha to grab coffee. I’d figured out pretty quickly that direct worked better with her than diplomatic. Some tech leads want you to walk them gently toward an insight. Tasha wanted you to say the thing and let her chew on it.

“Your team isn’t in Ri,” I said. “You’re not even in Shu. You’re in pre-Shu.”

Her eyebrows went up. “We’ve been doing this for three years.”

“You’ve been doing something for three years. But you started with a loose interpretation of Scrum, discovered the uncomfortable parts, removed them one by one, and now you’re running a process that has agile vocabulary and waterfall results. Three years of practice only counts if you were practicing the right things.”

I pulled up the completion rates on my laptop. 54 percent. Tasha stared at the number for a long time.

She didn’t argue. That’s how I knew she was the real deal. Bad tech leads argue with data. Good ones go quiet and start recalculating.

The next conversation was harder - the one with the full team. I drew the Shu-Ha-Ri model on the whiteboard. Three stages, left to right, with the kanji above each one. Then I asked the question that changed the engagement: “For each practice you’ve modified or dropped, can you tell me what it was designed to do - and why your modification serves that purpose better?”

Silence. Not angry silence. Thoughtful silence. The honest kind, where people are actually checking their assumptions instead of loading their next rebuttal.

Carl spoke first. “I dropped per-sprint retros because they felt repetitive. But honestly, I couldn’t tell you what a retrospective is actually supposed to produce.”

“That’s because nothing changed between retros,” I said. “You generated action items and then didn’t track them. So the next retro surfaced the same problems. Of course it felt repetitive. The retro didn’t fail you - you made it fail by treating the output as optional.”

I could feel the room shifting. Not defensiveness, but the specific discomfort of smart people realizing they’d been coasting on assumptions.

I proposed a deal. Eight sprints of Shu. Full Scrum by the book. Sprint goals. Definition of done. Retros every sprint with tracked action items. Sprint reviews with actual stakeholders in the room. No modifications, no shortcuts, no “well, we tried that and it didn’t work” exemptions.

“Eight sprints,” I said. “That’s it. After that, you’ll have earned the right to change anything you want. But right now, you’re editing a document you haven’t read.”

Tasha crossed her arms. But she didn’t say no.

The first two sprints were rough. Tasha told me the daily scrum format was “kindergarten.” One developer complained that the definition of done felt like “bureaucratic overhead designed by people who don’t write code.” (I wrote that one down too. My collection is extensive.)

By sprint four, something shifted. The sprint goal - the same practice Tasha had dismissed as artificial - turned out to be the thing that finally gave the team focus. Instead of pulling twelve unrelated stories, they pulled eight that pointed at the same outcome. When you know what you’re trying to accomplish as a team, it changes how you plan, how you swarm, how you trade off. Completion rate hit 78 percent. Not because the team got faster. Because they got more focused.

By sprint six, the definition of done had caught three bugs that would have shipped under the old process. One of them was a data integrity issue that would have been ugly in production. Carl said something in the retro that I’ve quoted in classes ever since: “I didn’t know what I was missing because I’d never had it.”

That’s the whole pre-Shu problem in a single sentence. You can’t miss what you never experienced.

By sprint eight, the team shipped their first release to production in nearly five months. Not because the code was suddenly ready - the code had probably been close for weeks. But the definition of done now included a deployment checklist, and having that checklist meant nobody was afraid of what they might have forgotten. Fear of the unknown was what had been blocking releases. The DoD made the unknown known.

At the sprint eight retro, I kept it simple: “Ready to start modifying?”

Tasha had a list. Of course she had a list. She’d been keeping it since sprint three, cataloging every place where the by-the-book process created friction she thought could be resolved. Most of her proposed changes were small - tweaks to the review format, adjustments to backlog grooming cadence. But one was significant: she wanted to drop story points entirely and move to flow metrics, tracking cycle time and throughput instead of velocity.

When I asked why, she gave me a detailed answer. Story points weren’t capturing deployment pipeline variability. Cycle time would give better signal about where work actually got stuck. Throughput would tell them whether process changes were improving output or just shuffling it around. And the Scrum Guide itself says teams should choose whatever metrics help them inspect and adapt.

I smiled. “That’s Ha.”

Tasha rolled her eyes. But she was grinning.

Six months later, the team’s completion rate was hovering around 85 percent. They’d shipped to production nine times. They were running a process that looked nothing like textbook Scrum - they’d replaced sprint reviews with demo-on-demand sessions, moved to continuous backlog refinement, and yes, adopted Tasha’s flow metrics. It looked nothing like the book and everything like a team that had learned the book deeply enough to write their own.

That’s the whole point of Shu-Ha-Ri. Not that the rules are sacred. Not that the rules are optional. That the rules are a necessary passage on the way to something the rules alone can never teach you.

Go Deeper

• Cockburn, A. (2007). Agile Software Development: The Cooperative Game. 2nd edition, Addison-Wesley. Cockburn’s foundational work on agile as a human endeavor, including his influential application of Shu-Ha-Ri to software methodology adoption. This is where the concept entered the agile lexicon.

• Fowler, M. (2014). “ShuHaRi.” martinfowler.com. A concise essay connecting the three stages to software practice adoption. Fowler’s framing of why teams must resist the urge to jump to Ha is particularly useful for coaching conversations.

• Zeami Motokiyo (c. 1418). Fushikaden (The Flowering Spirit). Translated by William Scott Wilson. Zeami’s secret treatises on Noh theater - the original source. The progression from imitation to internalization to transcendence holds up across six centuries.

• Dreyfus, H.L. & Dreyfus, S.E. (1986). Mind Over Machine: The Power of Human Intuition and Expertise in the Era of the Computer. Free Press. The five-stage skill acquisition model that parallels Shu-Ha-Ri from a Western cognitive science perspective. Essential for understanding why sequential mastery isn’t optional.

• Endo, S. (2003). Writings on Shu-Ha-Ri in Aikido practice. Endo Seishiro’s articulation of the three stages is the most direct martial arts lineage for the model as used in agile coaching. His emphasis on the teacher-student relationship in Shu is particularly relevant for coaches.