Agile Scrum training, as a concept, is as multi-layered as it is effective, having proven successful in the field that is the modern business landscape. For IT managers and more particularly, Agile Scrum managers, it has been the gateway to organizational excellence and has spelled tremendous increases in product and service quality over the years. This Agile revolution represents a fundamental shift away from traditional, rigid project management methodologies, such as Waterfall. Where Waterfall relied on long-term planning, sequential phases, and a late delivery of a single, complete product, Agile embraces uncertainty. It is an iterative and incremental approach, prioritizing flexibility, customer collaboration, and the rapid delivery of functional components. This shift was born from the recognition that the modern business environment is too unpredictable for long-range, detailed plans. Market demands, technology, and customer requirements can change overnight. Agile provides a framework for organizations to not just survive this volatility, but to thrive in it. By building in feedback loops and focusing on adaptive planning, Agile frameworks like Scrum allow teams to inspect their progress and adapt their plan in short cycles. This ability to pivot quickly, without derailing the entire project, is the core value proposition that has driven Agile’s widespread adoption across software development and, increasingly, into other business units like marketing, human resources, and operations.
Understanding the Core of Scrum
Scrum is arguably the most popular and widely adopted framework operating under the Agile umbrella. It is not a full-blown methodology that dictates every step; rather, it is a lightweight framework designed to help teams manage complex work. It is built upon a few key roles, events, and artifacts. The roles are the Product Owner, who is responsible for maximizing the value of the product by managing the product backlog; the Scrum Master, who acts as a servant-leader, ensuring the team adheres to Scrum principles and removing impediments; and the Development Team, a self-organizing group of professionals who deliver a potentially releasable increment of the product each sprint. The events provide the rhythm for the team. The Sprint is a time-boxed period, typically two to four weeks, during which a “Done” product increment is created. Within the Sprint, there is Sprint Planning, where the team decides what work can be accomplished. The Daily Scrum is a 15-minute meeting for the team to synchronize and plan for the next 24 hours. The Sprint Review is held at the end of the Sprint to inspect the increment and adapt the product backlog, while the Sprint Retrospective is an opportunity for the team to inspect itself and create a plan for improvements. Finally, the artifacts—the Product Backlog, Sprint Backlog, and the Increment—provide transparency and opportunities for inspection and adaptation.
The Challenge of Agile Adoption
Despite the proven benefits and relatively simple structure of frameworks like Scrum, successful Agile adoption remains a significant challenge for many organizations. The reason for this difficulty is that Agile is not just a set of processes to be followed; it is a fundamental mindset shift. Organizations steeped in a traditional command-and-control hierarchy find it difficult to embrace the Agile values of trust, transparency, and empowerment. Managers are asked to transition from being task-assigners to being coaches and impediment-removers, a change that can be deeply unsettling to their sense of authority and control. Teams, likewise, are often unused to the level of responsibility and autonomy that Scrum demands. The idea of a truly self-organizing team, where there is no designated “team lead” and all members share accountability, can be foreign and intimidating. Furthermore, the relentless transparency of Scrum can be uncomfortable. The Daily Scrum, burndown charts, and Sprint Reviews make progress, or lack thereof, visible to everyone. This can feel like exposure for teams and individuals accustomed to hiding behind long project timelines and siloed responsibilities. This cultural friction is the single greatest reason why Agile adoptions fail, turning into “cargo cults” where teams perform the ceremonies of Scrum without embracing any of the underlying principles.
Why Traditional Training Fails for Agile
The challenges of adoption are often compounded by a fundamental mismatch in training methods. Many organizations attempt to “install” Agile using the same traditional, top-down training approach they used for new software or compliance policies. They might send their entire staff to a two-day “Scrum certification” workshop, expecting them to return on Monday as a high-performing Agile team. This approach is doomed to failure. Agile and Scrum are not skills that can be passively learned by listening to a lecture or reading a book. They are experiential. One cannot understand the pressure of a Sprint or the value of a Daily Scrum until one has experienced it. This type of training focuses on the “what” (the rules and roles) but fails to instill the “why” (the principles and values). Without a deep understanding of the “why,” the rules seem arbitrary and rigid. Teams will quickly abandon practices like time-boxing or retrospectives when the first real project pressure hits, because they see them as bureaucratic overhead rather than essential tools for success. Effective Agile training must be ongoing, job-embedded, and coached. It must acknowledge that teams and individuals will learn and mature at different rates and will pass through predictable stages of development.
Introducing the Shu Ha Ri Ladder of Learning
This is where the Shu Ha Ri concept, or ladder, becomes integral to the practical implementation of Agile principles. It provides a much-needed mental model for understanding the journey of learning and mastery. It makes for the basis of Agile adoption, from the perspective of the teams that are adopting Agile principles, and the Agile manager who is leading the effort. Shu Ha Ri provides a path, a way to structure the learning journey and set appropriate expectations for each stage. It acknowledges that mastery is not a single event but a gradual progression. Instead of expecting a team to emerge from a training class as Agile experts, the Shu Ha Ri model gives us a framework for patience and for providing the right kind of support at the right time. It helps a Scrum Master or Agile coach diagnose where a team is on their journey and what they need to move to the next level. Are they struggling to follow the basic rules? Or are they following the rules so well that they are ready to start experimenting? Shu Ha Ri provides a language and a philosophy for managing this evolution, making the abstract goal of “becoming Agile” a tangible, staged process.
The Martial Arts Origin of Shu Ha Ri
In essence, Shu Ha Ri is the progression of learning, within which the learner first starts learning and then gradually progresses onwards until they are proficient in their skill. The term is based on a traditional Japanese martial arts concept, used to detail how much of an expert the student is becoming, through several stages of learning. The concept originated in Japanese Aikido and is used to describe the path to mastery, from student to master. It provides a powerful metaphor for skill acquisition in any complex domain, from martial arts to playing a musical instrument, to, as it turns out, practicing Agile Scrum. The term itself, as a Japanese concept, roughly translates into, “learn first, then detach, and lastly, transcend.” Being associated with the martial arts, it is, of course, deeply integrated into the student’s journey from a complete novice, to a master of the chosen art. In the martial arts, a student in the ‘Shu’ stage would meticulously copy the exact form and technique of their master, without deviation. In ‘Ha’, the student, now proficient, begins to understand the principles behind the movements and may experiment with variations. In ‘Ri’, the student has fully internalized the principles and no longer needs to think about the “rules”; their movement is natural, fluid, and effective, and they may even create new techniques.
From Kata to Code: Adapting the Concept
While the concept has existed for many years, it is only recently that it has been related to the general learning cycle, more specifically, for Agile scrum training. The parallels are striking. In martial arts, ‘Shu’ involves practicing kata, which are prescribed sequences of movement. In Scrum, the “kata” are the events, the time-boxes, and the roles. A team in ‘Shu’ practices these kata exactly as prescribed by the Scrum Guide. They hold a Daily Scrum every day, for 15 minutes, standing up, and answering the three questions. They do this not because they fully understand the deep reasons yet, but because the “master” (the Scrum Master or coach) has told them to. This practice builds muscle memory. The team learns the rhythm of the Sprint, the importance of a clear “Definition of Done,” and the pain of letting work spill over. The ‘Ha’ stage begins when the team starts to ask why. “Why 15 minutes? Why these three questions?” They begin to understand the principle of the Daily Scrum, which is daily synchronization and planning, not the ritual of the three questions. They might then “detach” from the specific form and experiment with a different format that achieves the same principle more effectively. This direct translation from a physical discipline to a knowledge-work discipline is what makes Shu Ha Ri so potent as a coaching tool.
The Importance of a Structured Progression
For the organization that is recently adopting Agile principles, there is a lot of learning to be done, and that too in stages, since there are various intrinsic qualities to Agile scrum that need to be integrated into the skill-sets of the teams involved. This ties the concept in to the Shu Ha Ri methodology, within the Agile environment. The danger many organizations face is wanting to jump directly to the ‘Ri’ stage. They hire “expert” developers and expect them to “just be Agile,” without providing the structure or discipline of the ‘Shu’ stage. This often leads to chaos, as everyone is operating on their own interpretation of Agile, and there is no common language or framework. Conversely, other organizations get stuck in the ‘Shu’ stage. They follow the rules of Scrum so rigidly that it becomes a new bureaucracy. They perform the ceremonies without understanding the principles, a state often called “Cargo Cult Agile.” The teams become monotonous, uninspired, and see no real benefit. The Shu Ha Ri ladder shows us that both stages are necessary, and that progression is key. ‘Shu’ builds the foundation, ‘Ha’ builds the understanding, and ‘Ri’ builds the mastery. Skipping a stage, or getting stuck in one, is the primary source of failure in Agile adoption.
Defining the ‘Shu’ Stage: Following the Rules
The ‘Shu’ stage is the foundation of the entire Shu Ha Ri ladder. The word ‘Shu’ translates to “to keep,” “to protect,” or “to obey.” This is the stage of the novice, the apprentice. The primary goal in this stage is to meticulously follow the teachings of the master, or in the case of Agile Scrum, the rules of the framework. The learner is not expected to understand the deep underlying principles at this point. Instead, their focus is on precise imitation and repetition. In the context of martial arts, this is the student learning the basic stances and kata (forms), copying the master’s movements exactly, without deviation or personal interpretation. In this stage, the rules are seen as a protective container. They provide a safe structure within which the team can operate while they build new muscles and unlearn old habits. The ‘Shu’ stage is about building a consistent, shared experience. The team learns the vocabulary, the rhythm, and the basic mechanics of the framework. This stage is characterized by a high degree of prescription. The “how” is dictated, so that the team can focus all their energy on “what” they are building, and on learning the new patterns of interaction. It requires discipline, humility, and a willingness to trust the process, even when it feels awkward or counter-intuitive.
‘Shu’ in Agile Scrum Training
In the ‘Shu’ stage of Agile Scrum adoption, teams practically adopt Agile principles by functioning according to the guidelines set during Agile scrum training. This means the Scrum Guide is treated as the rulebook, and it is followed to the letter. If the Scrum Guide says the Daily Scrum is 15 minutes, the team holds it for 15 minutes, no more, no less. If it says the Sprint Retrospective is a three-hour time-box for a one-month sprint, the team dedicates that time. The focus is on procedural correctness. This allows them to become entwined with Agile concepts at the essential level, so that everything they do reflects the principles as they learned them. This strict adherence serves a critical purpose. It forces the team to confront the dysfunctions that their old ways of working were masking. For example, a team that constantly runs over the 15-minute Daily Scrum time-box is not “bad at Scrum”; rather, the time-box is revealing that their discussions are unfocused, or they are trying to problem-solve instead of synchronize. The ‘Shu’ stage uses the rules of Scrum as a diagnostic tool. By trying to fit their work into the Scrum “kata,” the team immediately discovers their points of friction, their impediments, and their bad habits. This is the first, essential step toward improvement.
The Role of the Scrum Master in the ‘Shu’ Stage
During the ‘Shu’ stage, the Scrum Master plays a critical and highly active role, primarily as a teacher and a guardian of the process. They are the “master” in the martial arts analogy. Their main responsibility is to ensure the team understands and follows the rules of Scrum. This is not about being a “Scrum police” but about being a patient and persistent guide. The Scrum Master must teach the “what” and “how” of every event and artifact. They explain how to write a good user story, how to maintain the product backlog, and how to conduct each of the Scrum events according to the book. This role requires the Scrum Master to be very present. They will often facilitate the Scrum events directly, ensuring they start on time, end on time, and achieve their stated purpose. They protect the team from outside interruptions and prevent stakeholders, or even well-meaning managers, from bypassing the Product Owner or derailing the Sprint. The Scrum Master in the ‘Shu’ stage is a shield, creating a safe bubble for the team to practice the fundamentals without being overwhelmed by the old organizational antibodies that resist change. They are the source of answers, the enforcer of time-boxes, and the primary model of the Agile mindset.
Common Practices for a ‘Shu’ Team
A ‘Shu’ team’s practices are characterized by their adherence to the “basics.” In Sprint Planning, they will diligently calculate their capacity and pull in a corresponding number of story points, focusing on creating a realistic Sprint Backlog. Their Daily Scrums will likely follow the three-question format: “What did I do yesterday? What will I do today? What impediments are in my way?” This structure, while sometimes criticized as rote, is essential for a ‘Shu’ team to learn the habit of daily synchronization and to make impediments visible immediately. In their work, the ‘Shu’ team will focus intensely on their “Definition of Done.” The Scrum Master will coach them to apply this definition rigorously, rejecting work that is “almost done.” This teaches the team the discipline of delivering a truly releasable increment every sprint. Their Sprint Reviews will be a formal demonstration of this “Done” work, gathering feedback from the Product Owner and stakeholders. Their Sprint Retrospectives will be facilitated, perhaps using a simple “what went well, what didn’t, what to try” format, to begin building the muscle of continuous improvement. The emphasis in all these practices is on consistency and repetition.
The Psychology of the ‘Shu’ Stage
The psychological experience of the ‘Shu’ stage is a mixture of excitement, frustration, and discipline. For teams new to Agile, the structure can initially feel liberating. The clear roles, short cycles, and defined events provide a sense of order and purpose that may have been lacking. However, this initial enthusiasm can wane as the team confronts the rigidity of the rules. The 15-minute time-box for a Daily Scrum can feel arbitrary and stressful. The demand to deliver a “Done” increment every sprint can feel like relentless pressure, especially when compared to the long, undefined phases of a Waterfall project. This frustration is a normal and necessary part of the learning process. It is the friction that forces change. The ‘Shu’ stage is about building new “muscle memory.” Just as a martial arts student’s muscles ache as they hold a stance for the first time, a ‘Shu’ team’s brains will ache as they force themselves to conform to new patterns of thinking and collaborating. It requires patience from the team and, critically, from their management. This is where many adoptions fail, as teams abandon the “kata” when it becomes uncomfortable, reverting to old habits before the new ones have had a chance to form.
Overcoming Resistance to ‘Shu’
Resistance to the ‘Shu’ stage is all but guaranteed. Experienced developers may feel that the prescriptive rules are “for beginners” and beneath their skill level. They may resist practices like pair programming or writing unit tests, viewing them as a waste of time. Managers may resist the loss of control, demanding to know “who is working on what” in a way that bypasses the Product Owner and the team’s self-organization. The Scrum Master’s job is to navigate this resistance with empathy and resolve. They must continuously explain the “why” behind the “what,” linking the ‘Shu’ rules to the underlying Agile principles. One of the most effective ways to overcome resistance is to make the benefits visible. When a ‘Shu’ team, by following the rules, successfully delivers a high-quality product increment in their first Sprint, it is a powerful proof point. When the Daily Scrum’s 15-minute rule forces a solution to an impediment that would have otherwise festered for days, the team learns the value of the time-box. The Scrum Master must seize on these small wins, celebrate them, and use them as teaching moments to reinforce the process. Resistance fades not when people are convinced by arguments, but when they experience positive results.
Measuring Progress in the ‘Shu’ Stage
Measuring progress for a ‘Shu’ team should not focus on high-level business outcomes, as it is too early. Instead, metrics in the ‘Shu’ stage should focus on process adherence and consistency. Is the team holding all Scrum events? Are the time-boxes being respected? Does the team produce a “Done” increment at the end of every Sprint? Is the team’s velocity (the amount of work they complete per sprint) starting to become stable? Velocity stability is a key indicator of a ‘Shu’ team’s maturity; it shows they are getting better at estimation and at understanding their own capacity. Other important, though more qualitative, measures include the quality of the artifacts. Is the Product Backlog well-maintained and prioritized? Is the Sprint Backlog visible and updated daily? Is the “Definition of Done” clear and consistently met? The Scrum Master can also track the number and type of impediments raised, and how quickly they are resolved. An increase in reported impediments is often a good sign in a ‘Shu’ team, as it shows they are learning to identify and articulate their blockers, trusting that the process will help resolve them.
The Dangers of Staying in ‘Shu’ Too Long
The ‘Shu’ stage is essential, but it is also temporary. It is a means to an end, not the destination itself. The greatest danger in this stage is getting stuck. This leads to a state known as “Cargo Cult Agile” or “Mechanical Scrum.” This is a team that performs all the ceremonies of Scrum with perfect, rigid precision, but without any of the underlying spirit or understanding. They have daily stand-ups, but they are rote status reports to a manager, not a synchronization meeting for the team. They have retrospectives, but they only identify trivial improvements and never challenge the underlying system. A team stuck in ‘Shu’ will eventually see their performance plateau. They become rigid, uncreative, and resistant to change. They have mastered the form but have completely missed the function. This is often caused by a Scrum Master who is afraid to let go of control, or an organization that rewards procedural compliance over actual outcomes. It is the Scrum Master’s responsibility to recognize when a team has mastered the basics and is ready for the next challenge. They must know when to stop being a teacher and start becoming a mentor, pushing the team to break the rules and enter the ‘Ha’ stage.
Defining the ‘Ha’ Stage: Breaking the Rules
The second stage of the ladder is ‘Ha’, which translates to “to detach” or “to break.” This stage begins when the student has mastered the fundamentals of the ‘Shu’ stage. They no longer need to consciously think about every basic movement or rule; the practices have become second nature, ingrained in their muscle memory. Now, with a solid foundation, the learner is ready to explore the principles behind the rules. In the ‘Ha’ stage, the student begins to understand the “why” of the ‘Shu’ stage’s “what.” They can start to experiment, bend the rules, and adapt the techniques to fit their specific context. In martial arts, this is the student who, understanding the principles of balance and timing, might modify a standard kata to be more effective against a specific opponent. They are “detaching” from the rigid form, not out of ignorance, but from a place of deep understanding. For an Agile team, this is the moment they transition from doing Agile to understanding Agile. They have mastered the “Scrum by the book” and are now ready to start writing their own chapters, always grounded in the principles of the Agile Manifesto.
Transitioning from ‘Shu’ to ‘Ha’
The transition from ‘Shu’ to ‘Ha’ is a critical and often subtle shift. It is not a formal graduation; rather, it is an organic evolution. Signs that a team is ready for ‘Ha’ begin to appear in their behavior and conversations. A team that consistently delivers on its sprint commitments, whose velocity is stable and predictable, and whose adherence to the ‘Shu’ rules is effortless, is a prime candidate. The most telling sign, however, appears in the Sprint Retrospective. A ‘Shu’ team’s retrospective focuses on “how can we follow the rules better?” A team moving into ‘Ha’ starts to ask, “Why do we have this rule?” or “What if we tried…?” They begin to challenge the process, not out of resistance, but out of curiosity and a genuine desire to improve. They might say, “Our Daily Scrum feels like a waste of time with the three questions. We already know what everyone is doing. Can we just talk about blockers?” This is not a ‘Shu’ team complaining; this is a ‘Ha’ team identifying an inefficiency in a rule that was designed for a less mature team. They have absorbed the principle (daily synchronization) and are now ready to find a more effective form. The Scrum Master’s job is to recognize this cue and encourage the experiment.
‘Ha’ in Agile Scrum: Tailoring the Process
During the ‘Ha’ stage, after we have fully absorbed Agile principles, we begin to make innovations, while functioning as we did during the previous stage. It is important to note that teams will perpetually be in the ‘Shu’ stage to some extent, regardless of the learning they have received. However, to an extent, the teams may break the previous modus operandi and work in a more effective and efficient fashion, as Agile dictates. This is the heart of ‘Ha’: intelligent adaptation. The team begins to tailor the Scrum framework to their specific needs, context, and team dynamics. For example, they might decide the three questions of the Daily Scrum are no longer serving them. They might transition to a “walk the board” style, focusing on the flow of work from left to right on their task board. They might experiment with their Sprint length, moving from two weeks to three, or vice versa, to better align with their product’s release cadence. They might combine the Sprint Review and Retrospective into a single, more efficient feedback loop. Or they might introduce practices from other frameworks, like Kanban’s “work in progress” limits, to better manage their flow. Each of these changes is a “detachment” from the ‘Shu’ rules, driven by a ‘Ha’ level understanding of the principles.
The Scrum Master as a Facilitator in ‘Ha’
The role of the Scrum Master undergoes a profound change in the ‘Ha’ stage. They must evolve from being a “teacher” of the rules to a “mentor” and “facilitator” of experiments. This can be a difficult transition. The Scrum Master must have the wisdom to know when to let the team “break” a rule and the courage to let them potentially fail. Their primary tool shifts from prescription to Socratic questioning. When the team suggests a change, the ‘Ha’ stage Scrum Master doesn’t say “no, the Scrum Guide says…” Instead, they ask, “That’s an interesting idea. What problem are we trying to solve with that change? How will we know if it’s working?” Their job is to ensure that the team’s experiments are true experiments. This means helping the team form a clear hypothesis (“We believe that by changing our Daily Scrum format, we will reduce the meeting time and increase focus on blockers”), define a way to measure success, and set a time-box to evaluate the results. The Scrum Master creates the psychological safety for this experimentation, protecting the team from blame if an experiment “fails,” and helping them reframe it as a valuable learning opportunity.
The Role of Retrospectives in ‘Ha’
If the ‘Shu’ stage is built on the foundation of the Daily Scrum, the ‘Ha’ stage is built on the engine of the Sprint Retrospective. The retrospective becomes the most important event for a ‘Ha’ team. It is the formal, sanctioned time for the team to inspect their own process and propose adaptations. The Scrum Master’s facilitation of this event must also mature. Simple “what went well/what didn’t” formats may no longer be sufficient to generate deep insights. A ‘Ha’ level Scrum Master will introduce more advanced retrospective techniques, such as the “5 Whys” to get to root causes, “Sailboat” to identify risks and anchors, or “Start, Stop, Continue” to make concrete decisions. The retrospective becomes the laboratory where the team’s ‘Ha’ level hypotheses are formed. The output is no longer just a vague “we will communicate better,” but a concrete, actionable experiment to be run in the next Sprint, such as “We will dedicate the first 10 minutes of Sprint Planning to a technical design discussion.”
Balancing Innovation with Core Principles
The key challenge of the ‘Ha’ stage is to balance innovation with fidelity to the core principles. This is the difference between “breaking” the rules and “destroying” the system. A ‘Ha’ team is “detaching,” not “derailing.” They are empowered to change the practices of Scrum, but they must never violate the principles of the Agile Manifesto or the values of Scrum (commitment, courage, focus, openness, and respect). For instance, a team might experiment with canceling the Daily Scrum on Fridays. This is a ‘Ha’ level experiment. But a team that decides to stop doing retrospectives altogether is not in ‘Ha’; they are simply regressing. The Scrum Master acts as the guardian of these core principles. When a team proposes a change, the Scrum Master will hold it up against the Agile Manifesto. “Does this change still value individuals and interactions over processes and tools? Does it still prioritize customer collaboration?” If the team wants to skip a retrospective, the Scrum Master will remind them that this violates the core Agile principle of “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” ‘Ha’ is about finding a better way to live the principles, not a way to avoid them.
Case Studies of ‘Ha’ Level Practices
‘Ha’ level practices are diverse and context-dependent, but they share a common theme of moving from rigid prescription to principle-based adaptation. A common example is the evolution of the task board. A ‘Shu’ team uses a simple “To Do, In Progress, Done” board. A ‘Ha’ team, realizing they have a bottleneck in testing, might add “Ready for QA” and “In QA” columns. Then, to further manage this, they might introduce a “Work in Progress” limit of 3 items to the “In QA” column, a practice borrowed from Kanban. They haven’t abandoned Scrum; they have augmented it to solve their specific problem. Another ‘Ha’ level practice is the “Scrum of Scrums,” a meeting not prescribed in the Scrum Guide but invented by teams to solve the problem of coordinating multiple Scrum teams working on the same product. Even the concept of “story points” can evolve. A ‘Shu’ team practices them religiously. A ‘Ha’ team, after mastering them, might find they are no longer necessary and move to a “no-estimates” approach, focusing instead on splitting work into small, similarly-sized items. This is a profound ‘Ha’ level detachment, only possible after the value of estimation has been fully learned in ‘Shu’.
Pitfalls of the ‘Ha’ Stage
The ‘Ha’ stage is powerful, but it is also fraught with peril. The most common pitfall is what can be called the “arrogant ‘Ha’.” This is when a team or individual, believing they are ‘Ha’, starts breaking rules they never fully understood in the ‘Shu’ stage. They might skip Daily Scrums not because they have a better synchronization method, but because they are lazy or undisciplined. This is not ‘Ha’; it is simply ‘Shu’ done badly. It leads to chaos, a decrease in quality, and a loss of transparency, often giving Agile a bad name within the organization. Another pitfall is “analysis paralysis.” The team becomes so enamored with experimenting and talking about the process that they stop delivering value. The retrospectives become two-hour philosophical debates instead of focused planning sessions for improvement. The Scrum Master must guard against this, keeping the team focused on why they are experimenting: to deliver more value, faster, and more sustainably. ‘Ha’ is also a dangerous place for a team with low psychological safety. If management punishes failure, teams will never dare to experiment, and they will remain stuck in ‘Shu’ forever.
Defining the ‘Ri’ Stage: Being the Rules
The final stage of the Shu Ha Ri ladder is ‘Ri’, which translates to “to transcend” or “to leave.” This is the stage of the true master, the expert. In this stage, the learner has so deeply internalized the principles and values that they no longer need to think about the rules or even the underlying principles. The rules and the student have become one. The practice is now effortless, fluid, and intuitive. The master does not “follow” the rules; they are the rules. Their actions naturally and spontaneously embody the principles of the art form without conscious thought. In martial arts, this is the master who can face any opponent and react perfectly without a pre-planned kata. They are “formless,” adapting in real-time to the situation, inventing new techniques on the fly that are perfectly aligned with the core principles of their art. For an Agile team, ‘Ri’ represents a state of high-performance and “flow.” They do not just do Agile or understand Agile; they are Agile. Their every interaction, their way of thinking, and their approach to problem-solving are a living expression of the Agile mindset.
What ‘Ri’ Looks Like in an Agile Team
And lastly, in the ‘Ri’ stage, the teams going through the learning process completely let go of old practices and adopt Agile principles fully. Additionally, they begin to reform the way they function, the way they tackle incoming challenges, the way they collaborate, and how they plan for the future. A ‘Ri’ team is a truly self-organizing, self-managing unit. They do not need a Scrum Master to enforce time-boxes or facilitate retrospectives. They manage their own process, their own internal conflicts, and their own continuous improvement fluidly and automatically. Their “ceremonies” may look nothing like the ‘Shu’ version of Scrum. They might have a “Daily Scrum” that is just a two-minute huddle over coffee, yet it achieves a higher level of synchronization than a ‘Shu’ team’s 15-minute ritual. Their “retrospective” might not be a meeting at all, but a constant, real-time feedback loop. When someone sees a problem, they address it immediately, not waiting for a formal meeting. They plan, execute, and deliver value in a seamless, low-friction flow, adapting to change with an almost unconscious competence.
‘Ri’ Beyond Scrum: Creating New Frameworks
A team in the ‘Ri’ stage has transcended the specific framework they started with. While a ‘Ha’ team experiments within the boundaries of Scrum, a ‘Ri’ team may leave the framework entirely because they no longer need its supportive structure. They will instinctively pick and choose practices from Scrum, Kanban, Extreme Programming (XP), and Lean, blending them into a unique, custom-fit process that works perfectly for their team, their product, and their organizational context. They may even invent entirely new practices that the broader Agile community has never seen. Incidentally, they do all of the above without overstepping the boundaries of Agile, and without affecting the performance of either their teammates or other teams working towards the same goals. This is the key. Their innovations are not random; they are deeply rooted in the 12 principles of the Agile Manifesto. They would never invent a process that sacrifices quality, de-emphasizes customer collaboration, or fails to deliver working software frequently. They are the creators of new knowledge, not just the consumers of it. Many of the practices we now take for granted, like Continuous Integration or DevOps culture, were likely born from ‘Ri’ level teams.
The Scrum Master’s Role in ‘Ri’
The role of the Scrum Master for a ‘Ri’ team changes dramatically. In many ways, the team has “graduated” from the need for a full-time Scrum Master in the traditional sense. A ‘Ri’ team is fully capable of managing their own process, facilitating their own meetings, and removing their own impediments. The Scrum Master’s job is no longer to teach the team or even to mentor them. Instead, the Scrum Master may transition to one of several new roles. They might become an “Agile coach” for the wider organization, taking the lessons from this high-performing team and helping other ‘Shu’ teams begin their journey. Alternatively, the Scrum Master may become a peer on the team, focusing their skills on organizational-level impediments that the team cannot solve on its own. They might work on changing company policy, procurement processes, or HR structures that are hindering not just their team, but all teams. Or, they may simply step away, recognizing that their work is done, and allow the team to operate with full autonomy, moving on to help another team that is still in the ‘Shu’ or ‘Ha’ stage. A truly great Scrum Master’s goal is to make themselves unnecessary.
Continuous Improvement in the ‘Ri’ Stage
It is a common misconception to think of ‘Ri’ as a final destination, a static state of “perfection.” This is incorrect. A ‘Ri’ team does not stop learning or improving. In fact, their rate of learning may even accelerate. The difference is that their improvement is no longer focused inward on their process, which is already fluid and effective. Instead, their continuous improvement focus shifts outward and forward. They focus on improving the product, the technology, and the business itself. They may spend their “retrospective” time (which is now just continuous) learning a new programming language, exploring a new technology that could benefit their users, or analyzing market trends to propose new product features to the Product Owner. They are so efficient at the “how” of delivery that they can dedicate more and more of their collective brainpower to the “what” and “why” of the value they are creating. They seek out new knowledge, attend conferences, read books, and bring that learning back to the team, not as a chore, but as a natural part of their professional identity.
The ‘Ri’ Stage and Organizational Culture
A ‘Ri’ team cannot exist in a vacuum. A team can only achieve and sustain this level of performance if the surrounding organizational culture supports it. A ‘Ri’ team in a ‘Shu’ organization, one that is rigid, bureaucratic, and command-and-control, will be a source of immense friction. The organization will see the team as “rogue” and “non-compliant.” The team will be frustrated by the organizational “sludge” that slows them down. This is the “organizational impediment” that the Scrum Master of a ‘Ri’ team often battles. However, if the organization is open, the ‘Ri’ team can become a powerful change agent. They become a “model team,” an living example of what is possible. Other teams will see their performance, their low-stress environment, and their high morale, and they will want to emulate them. A ‘Ri’ team, through its very existence, can pull the entire organization up the Shu Ha Ri ladder, acting as a beacon and a source of inspiration. They become the internal consultants, the mentors, and the “masters” for the next generation of ‘Shu’ teams.
Is ‘Ri’ a Permanent State?
Another misconception is that once a team or individual achieves ‘Ri’, they stay there forever. This is not true. Shu Ha Ri is contextual. A master martial artist who decides to learn the piano is a ‘Shu’ student once again. The same applies to Agile teams. A ‘Ri’ team, a high-performing unit that has mastered their domain and their process, can be thrown right back into ‘Shu’ by a significant change in context. This could be a new, unfamiliar technology, a new product domain they know nothing about, or a major change in team membership (e.g., losing half the team and gaining new members). In this new context, their old, intuitive ‘Ri’ process may no longer be effective. They must have the humility to recognize this, consciously return to the ‘Shu’ stage, and follow the “rules” of the new domain (e.g., the rules of a new programming language) until they build a new foundation. This ability to “return to Shu” gracefully is, perhaps, the ultimate sign of a ‘Ri’ mindset. It is the recognition that learning is infinite and that mastery is not a title, but a continuous process of adapting to new challenges.
Examples of ‘Ri’ Level Thinking
‘Ri’ level thinking is what moves an entire industry forward. The DevOps movement is a perfect example of ‘Ri’ thinking. It was born from ‘Ri’ level Agile development teams who saw that their fast, iterative process was hitting a wall: the “wall of confusion” between themselves and the ‘Shu’ level, siloed Operations teams. They transcended the boundaries of “Scrum” and “Development” to create a new, holistic culture and set of practices (like CI/CD, and infrastructure as code) that merged development and operations. This was not a pre-defined framework; it was an emergent ‘Ri’ level solution to a systemic problem. On a smaller scale, a ‘Ri’ team’s planning meeting might be a two-minute conversation where the Product Owner says, “We need to solve the cart abandonment problem.” The team, who has a deep understanding of the user, the technology, and the business, can then take that simple, high-level intent and, within a single day, design, build, test, and release a series of small experiments to address it, all without needing a detailed backlog of user stories. This is the “formless” and “transcendent” state of ‘Ri’, where value is delivered in a seamless flow.
The Agile Manager’s Guide to Shu Ha Ri
The Shu Ha Ri ladder is not just a model for teams; it is an essential diagnostic tool for Agile managers, Scrum Masters, and coaches. Its primary value for leadership is to provide a mental model for understanding where a team is in its development journey and, consequently, what kind of support, leadership, and coaching they need. A manager who treats a ‘Shu’ team like a ‘Ri’ team, giving them total autonomy, will be frustrated by their chaos and lack of results. Conversely, a manager who treats a ‘Ri’ team like a ‘Shu’ team, imposing rigid rules and micromanagement, will demotivate them and destroy their high-performance state. The Agile manager’s first job, therefore, is to accurately assess the team’s current stage. This requires a shift from managing tasks to observing behaviors. The manager must ask questions like: “Is the team following the rules consistently? Are they asking why the rules exist? Or are they intuitively and successfully adapting the rules on their own?” Using Shu Ha Ri as a guide, the manager can then tailor their leadership style to match the team’s needs, providing the precise support required to help them mature to the next stage. This is the essence of servant-leadership in an Agile context.
Coaching in the ‘Shu’ Stage: The Teacher
When a team is in the ‘Shu’ stage, their primary need is clarity and direction. The coach or manager must, therefore, adopt the stance of a “Teacher.” This style is highly directive and prescriptive. The coach’s job is to provide the “kata,” the clear, unambiguous rules of practice. They must patiently explain the “what” and “how” of Scrum: “This is a Daily Scrum. It is 15 minutes. We will stand. We will answer these three questions.” The ‘Shu’ stage is not the time for ambiguity or Socratic debate about the merits of time-boxing. The team needs a firm, safe container to practice the fundamentals. The ‘Shu’ coach is also a protector. They defend the team’s time, their process, and their learning. They ensure the organization respects the new rules, such as not interrupting the team during a Sprint. This directive approach can feel unnatural for managers trained in “empowerment,” but it is a necessary phase. It is a temporary scaffolding, erected to support the team as they build their own foundational strength. The coach provides the “training wheels” that allow the team to start pedaling without immediately falling over.
Coaching in the ‘Ha’ Stage: The Mentor
As the team masters the fundamentals and begins to show signs of ‘Ha’—questioning the rules, suggesting experiments—the manager’s stance must shift dramatically. They must transition from “Teacher” to “Mentor.” A mentor does not provide answers; they ask powerful questions. When a ‘Ha’ team says, “We want to stop doing story points,” the ‘Shu’-level coach would say “No, that’s part of the process.” The ‘Ha’-level mentor, by contrast, says, “Interesting. What problem are you trying to solve? How will you know if your new approach is better? What’s the smallest, safest experiment we can run to test your idea?” The ‘Ha’ coach’s primary tools are facilitation and Socratic questioning. They challenge the team’s assumptions and help them think through the consequences of their choices. They encourage experimentation and, most critically, they create psychological safety. They must make it acceptable for an experiment to “fail,” reframing failure as “learning.” This coach’s job is to guide the team in their detachment, ensuring they are breaking the rules from a place of understanding, not ignorance, and that they always remain tethered to the core Agile principles.
Coaching in the ‘Ri’ Stage: The Advisor
When a team finally reaches the ‘Ri’ stage, the manager’s role changes once again. The team is now self-sufficient, high-performing, and may know more about their specific process and domain than the manager does. The “Teacher” and “Mentor” stances are no longer appropriate and would be seen as micromanagement. The manager must now adopt the stance of an “Advisor” or “Consultant.” The relationship becomes one of peers. The manager’s role is to get out of the team’s way and support them at a systemic level. This means focusing on the organizational environment. The ‘Ri’ advisor works to remove high-level organizational impediments that the team cannot solve on its own, such as restrictive HR policies, archaic finance approval processes, or silos between departments. They also act as a connector, linking the ‘Ri’ team’s innovations to the wider organization, helping to scale their good practices. They provide cover, resources, and trust, and then they let the team perform the magic they are capable of.
Creating a Psychological Safety Net for ‘Ha’
The transition from ‘Shu’ to ‘Ha’ is the most critical and most fragile point in the entire journey. This is where most Agile adoptions stall. The reason is simple: the ‘Ha’ stage is defined by experimentation, and experimentation inherently involves the risk of failure. A team will never voluntarily move into the ‘Ha’ stage if the organizational culture punishes failure. Why would a team risk their careers or their bonuses on an experiment to “improve the process” if the result of that experiment “failing” is a bad performance review? Therefore, the single most important job for an Agile manager is to create a robust psychological safety net for their teams. They must explicitly and repeatedly state that experimentation is encouraged. They must celebrate intelligent failures, a term for experiments that were well-conceived but produced a negative result, as valuable learning opportunities. They must publicly praise the courage to experiment, regardless of the outcome. Without this safety net, crafted and defended by management, teams will play it safe, stay in the ‘Shu’ stage forever, and the organization will never unlock the true innovative potential of Agile.
Shu Ha Ri for Individual Development
The Shu Ha Ri model is not just for teams; it is a powerful tool for managing individual development as well. A new junior developer joining a team is in the ‘Shu’ stage. They need clear tasks, pairing with a senior developer, and adherence to the team’s coding standards and “Definition of Done.” A mid-level developer may be in the ‘Ha’ stage, where they understand the codebase and can be given a more ambiguous problem to solve. They might experiment with a new code library or suggest a refinement to the team’s branching strategy. A senior or principal engineer is often in the ‘Ri’ stage. They are not just solving tickets; they are mentoring others, defining technical strategy, and looking at the entire system. A manager can use this model to tailor their one-on-one conversations. For the ‘Shu’ employee, the conversation is about teaching and feedback: “Here is how you can improve your code quality.” For the ‘Ha’ employee, it is about mentoring: “What are your career goals, and what new challenges can we find for you to stretch your skills?” For the ‘Ri’ employee, it is about advising: “What do you see as the biggest technical threat to our business, and how can I help you tackle it?” This individualized approach is far more effective than a one-size-fits-all management style.
Identifying Misaligned Expectations
One of the most common sources of conflict and frustration in the workplace is a misalignment of Shu Ha Ri stages. This often occurs between management and a team. A manager, having heard about the ‘Ri’ level innovations at other companies, might demand that their team, which is still struggling in the ‘Shu’ stage, “be more innovative” and “think outside the box.” This is an impossible and unfair demand. The team has not yet earned the right to break the rules, as they have not even mastered following them. This demand only leads to anxiety for the team and frustration for the manager. Conversely, a manager who is a ‘Shu’ level thinker (a “micromanager”) might be assigned to a ‘Ha’ or ‘Ri’ level team. The manager’s attempts to impose rigid processes and “check the box” compliance will be met with intense resistance and will demotivate the high-performers, likely causing them to leave. The Shu Ha Ri model gives managers a vocabulary to understand these conflicts. It helps them see that the problem is not “a bad team” or “a bad manager,” but a “stage misalignment.” The solution is for the manager to adapt their style to the team’s stage, not the other way around.
Using Shu Ha Ri to Implement Change
The basic idea behind the Shu Ha Ri ladder is that training should be tuned to how the learner understands best, and it needs to follow a pattern which allows the teams receiving the training to naturally let go of old values in favor of Agile principles. This makes the model a powerful framework for managing any organizational change, not just an Agile adoption. Whether implementing a new sales CRM, a new financial process, or a new DevOps culture, the Shu Ha Ri ladder applies. First, the organization must be in ‘Shu’. They must learn the new tool or process exactly as prescribed. This requires clear training, documentation, and non-negotiable adherence. Next, as teams become proficient, they enter ‘Ha’. They will find workarounds, see opportunities for optimization, and start to adapt the tool to their specific needs. Management must encourage this, gathering this feedback to improve the system. Finally, ‘Ri’ is achieved when the new tool or process is so deeply embedded that people no longer “use” it; it is simply part of the natural, fluid way they work. By planning for this three-stage progression, managers can implement change far more effectively.
Common Pitfalls in Applying Shu Ha Ri
While Shu Ha Ri is a powerful mental model, its application is not without pitfalls. The most common mistake is a misdiagnosis of a team’s stage. A manager or Scrum Master, eager to see progress, might prematurely label a ‘Shu’ team as ‘Ha’ and encourage them to experiment. This is disastrous, as the team lacks the foundational discipline and understanding to experiment successfully. They will break the rules not from a place of insight, but from a place of ignorance, leading to chaos, missed commitments, and a breakdown of the process. This often results in the team being blamed, when the fault was with the coach’s poor assessment. Another common pitfall is forcing progression too quickly. Shu Ha Ri is a natural, organic process of learning. It cannot be rushed. A manager who sets a “deadline” for a team to “be in ‘Ha’ by Q3” is fundamentally misunderstanding the concept. Teams mature at different speeds, based on their complexity, their context, and the psychological safety of their environment. Rushing the ‘Shu’ stage is like trying to build a house on a wet concrete foundation. It will inevitably collapse when pressure is applied. Patience is a prerequisite for any leader using this model.
The ‘Cargo Cult’ Agile Trap
Perhaps the most widespread challenge, mentioned earlier, is the ‘Shu’ stagnation, which leads to “Cargo Cult Agile.” This term comes from post-World War II Pacific islanders who, having seen “cargo” (supplies) dropped from planes, built straw airplanes and runways in the hopes of attracting more. They were mimicking the form of the activity without understanding the function. In the Agile world, this is the team that is stuck in ‘Shu’ forever. They follow the Scrum ceremonies with rigid precision but have no understanding of the “why.” Their Daily Scrums are dull status reports. Their retrospectives are repetitive and yield no real change. This state is worse than not doing Agile at all, as it gives the illusion of agility while providing none of the benefits. It becomes a new, more expensive bureaucracy. This trap is often set by an organization that rewards compliance over outcomes, or by a Scrum Master who sees their job as a “process police” rather than a coach. Breaking out of a cargo cult requires a ‘Ha’ level intervention, often from an outside coach, who can challenge the team’s assumptions and force them to reconnect with the “why” behind their “what.”
The ‘Arrogant ‘Ha” Problem
While getting stuck in ‘Shu’ is a problem of stagnation, the ‘Ha’ stage has its own corresponding dysfunction: the “arrogant ‘Ha’.” This occurs when a team has some success, learns some of the principles, and then incorrectly assumes they are masters. They begin to break rules with abandon, not as a carefully considered experiment, but from a place of ego. They decide they are “too good” for retrospectives, or that “estimation is a waste of time,” but they do so without a deep understanding of the problems those practices were designed to solve. This is not a ‘Ri’ team’s transcendence; it is a ‘Ha’ team’s hubris. This chaotic, undisciplined state is often what critics of Agile point to when they decry its lack of rigor. It leads to unpredictable delivery, declining quality, and conflicts with other teams. A good coach or manager must identify this behavior, challenge it, and pull the team back. They must force the team to articulate their “why” and hold them accountable to the core Agile principles, reminding them that ‘Ha’ is about improving the system, not just blowing it up.
Criticisms of the Shu Ha Ri Model
Shu Ha Ri is not a perfect, scientific model, and it has valid criticisms. One of the main critiques is that it presents learning as an overly linear and simplistic progression. It suggests a neat, three-step ladder, when in reality, learning is a messy, cyclical, and iterative process. A team may be in ‘Ha’ with their testing practices but still in ‘Shu’ with their stakeholder communication. The model can struggle to account for this kindof uneven development. It is not a single ladder for the team, but a collection of different ladders for different skills. Another criticism is that it is a “model,” not a “reality.” It is a descriptive metaphor, not a prescriptive plan. An organization that tries to “implement Shu Ha Ri” by creating formal gates, checklists, and promotions for each stage has missed the point entirely. It is a lens for understanding, not a process to be managed. Overly-rigid application of the model can lead to the very same “cargo cult” behavior it is trying to prevent. It must be held lightly, as one of many tools in a coach’s toolbox.
Shu Ha Ri and Distributed Teams
The rise of remote and hybrid work presents new challenges for applying the Shu Ha Ri model. When a team is co-located, a coach can “manage by walking around.” They can observe the ‘Shu’ team’s body language in a Daily Scrum, overhear a ‘Ha’ team’s spontaneous problem-solving at a whiteboard, or feel the “flow” of a ‘Ri’ team. This observation, or “gemba,” is much harder in a distributed environment. It is more difficult to distinguish between a ‘Shu’ team quietly following the rules and a ‘Shu’ team that is quietly disengaged and lost. Coaches and managers must adapt. They need to be more explicit in their communication and more deliberate in their observation. They might need to rely more on the digital artifacts: is the board being updated? Are the virtual collaboration tools being used effectively? They must also work harder to create the psychological safety required for ‘Ha’, as it is much more difficult to build trust through a screen. Virtual retrospectives and planning sessions need to be more skillfully facilitated to encourage the vulnerability and experimentation that ‘Ha’ requires.
Shu Ha Ri in DevOps and Beyond
The earliest stages of Agile training need to focus on repeating a series of practical steps until they are engrained in the teams’ work ethic itself. This does not mean that processes need to become monotonous; it only requires the principles to be followed at all times. This principle, as embodied by Shu Ha Ri, extends far beyond Scrum. The DevOps movement, for example, follows a clear Shu Ha Ri progression. A team in ‘Shu’ learns to follow the “kata” of Continuous Integration: check in code frequently, run automated tests. As they move to ‘Ha’, they begin to understand the principle of a fast feedback loop and start experimenting with Continuous Delivery, automating their release pipeline. In ‘Ri’, they achieve a state of “Continuous Deployment,” where code flows to production safely and automatically multiple times a day, guided by principles of “infrastructure as code” and “site reliability engineering.” They have transcended the old, siloed thinking entirely. The model can be applied to any complex skill domain, from cybersecurity to data science to product management.
The Learning Organization: Shu Ha Ri at Scale
The ultimate goal of using Shu Ha Ri is not just to create a few high-performing ‘Ri’ teams. The true goal is to create a “learning organization.” This is a company where the entire system operates on the principles of Shu Ha Ri. It is an organization that knows how to bring in new employees and put them through a ‘Shu’ stage of effective onboarding. It is an organization that provides the psychological safety and management support for ‘Ha’ stage experimentation and innovation at all levels. And it is an organization that identifies its ‘Ri’ level masters and empowers them to teach, mentor, and drive the company’s next evolution. This kind of organization is not afraid of change; it thrives on it. It sees every new market, technology, or competitor as a new opportunity to “return to Shu” and begin a new learning cycle. This creates a culture of profound resilience, antifragility, and continuous improvement. Shu Ha Ri, in this sense, is not just a training methodology; it is a blueprint for organizational excellence in the 21st century.
Conclusion:
Shu Ha Ri is just one of the methodologies that make up Agile Scrum training, and it can be used as a basis for Agile and DevOps managers to coach their teams and implement change. It is a powerful lens, a compass for the long and challenging journey of mastery. Once all the steps are followed to the letter—once the discipline of ‘Shu’ is mastered, the innovation of ‘Ha’ is explored, and the principles of ‘Ri’ are internalized—teams can truly begin to adopt and innovate in tune with their learning. When managers use this model to guide their efforts, they can be sure that their Agile training is more than just a fleeting initiative. It becomes a fruitful, sustainable investment in their people and their culture. The final lesson of Shu Ha Ri is that mastery is not a destination you arrive at, but a journey you commit to. The ‘Ri’ master is simply a ‘Shu’ student of a new, more advanced topic. This mindset of humble, continuous learning is the true bottom line, and companies that foster it are the ones that are bound to improve and thrive.