Shu Ha Ri: A Journey Toward Agile Mastery

This article is part of the "Advent of Tech 2024 @ onepoint," a series of tech articles published by onepoint to help pass the time until Christmas. See all the Advent of Tech 2024 articles leading up to Christmas.

How did you first learn about Agile? How do you keep learning to be Agile?

My Agile journey began in the early 2000s, during a time when Agile methodologies were beginning to gain popularity. I read about the Agile Manifesto and Scrum from books and articles in magazines, as the ideas started making their way into the mainstream. At the time, I was in my early 20s, had taught myself programming, and had pursued artistic studies rather than engineering, yet I was determined to find a career in software development.

My artistic studies and early interest in sociology helped me develop an appreciation for human behavior and group dynamics. At the time, I didn’t fully recognize the connection between these interests and my professional journey in software development. But looking back, I can see that my understanding of sociology — how people interact, form groups, and collaborate — has profoundly shaped my Agile journey.

Agile, at its core, isn’t just a set of processes; It’s a mindset — a way of understanding how people work together, how they communicate, and how they adapt in the face of uncertainty. As I started exploring Scrum more deeply, I saw how these principles mirrored what I had been learning about human interaction. Scrum emphasised collaboration, self-organising teams, and adaptability, all of which resonated with my interest in sociology and my desire to understand the dynamics of group behavior.

In my early encounters with Scrum, I began to notice how powerful the group dynamics were. I saw firsthand that teams that understood their own social dynamics — how they interacted with one another and responded to stress, change, and challenges — were more successful. This insight was a key realisation for me: Scrum wasn’t just about following a rigid set of steps; it was about cultivating an environment where teams could thrive through their relationships and their ability to adapt together.

In this article, I’d like to share the insights I’ve gathered over 20 years in the Agile world — as I look back on my experiences — first learning the rules of Scrum, then adapting them to suit the teams I worked with, and eventually transcending those practices to create more sustainable ways of working. I realise that this journey mirrored the stages of Shu Ha Ri: from strict adherence to the rules, to the flexibility of adaptation, and finally to mastery through innovation.

The Gap From Theory to Practice

I was working with a team of structured cabling installers, when I spent more time crawling in ceilings and under floors than in front of a computer! As I learned about Scrum and Agile, I began to reflect on how some of the principles already existed in my work, even in a completely different context.

My team of cabling installers, while not following Agile in any formal sense, had naturally developed some of its key practices without giving them names. We too had a backlog of work orders, task board, daily meetings before heading into work, and end-of-week rituals, when we’d hang out and go over how we can do better next time. No one had to teach us these concepts — they came from our past experiences in other jobs, in school, and from life in general.

I saw these Agile ideas as profound insights, as wisdom from legends who really understood how people really work. I became convinced that it was the only way software should be built, as its simplicity made it easy to grasp, especially for someone like me who was naive to the world of software development.

Agile provided a structure for my learning. It helped me approach my development projects iteratively and incrementally, focusing on small, manageable chunks of work. As I honed my skills, I started building demo projects, and this structured, iterative process led me to my first jobs in early-stage startups. But there, I quickly realized that despite being talented, my fellow programmers and I were, in many ways, just as inexperienced as I was and, most importantly, we didn’t know how to work together effectively.

I tried to organise the team using Scrum, but despite the simplicity of Scrum — all we needed were whiteboards, post-its, and Sharpies — it felt unnatural to the teams who did not seem to understand it, and I went through this cycle a few more times as I drifted from startup team to another startup team. In the end I was discouraged that I could make the Scrum process work at all: although every time I got a little bit better to get a team to “do agile”, I did not feel that I was able to get a team to “be agile”.

This disconnect — between “doing” Agile and “being” Agile — became one of the central challenges of my journey. While Scrum provided a simple framework for teams to follow, I began to see that it wasn’t enough. Simply following the steps didn’t lead to the deep, meaningful transformation I was seeking. I needed to help teams internalise Agile principles, to not just “do” the rituals but to embrace the mindset behind them.

"Being Agile" but not "Doing Agile"

It wasn’t until I joined a large and established creative agency that I had my first real experience with a team that was truly "being agile" — a team that had internalised the principles and mindset of Agile, but didn’t follow it in a formal or rigid way. During my interview for the job, my soon-to-be manager told me that the team had a working Agile culture, one that allowed them to deliver high-quality projects with minimal processes. This was exactly the kind of environment I had been hoping for — a place where I could see what “real” Agile looked like in practice.

I jumped at the opportunity, eager to learn from a team that had achieved what seemed to be the holy grail of Agile: a smooth, effective, self-organising team that delivered without the need for heavy processes. But when I joined, I quickly realized that there was something different about this team. While they excelled at “being Agile,” they weren’t particularly good at “doing Agile” in the formal sense.

The team worked across multiple projects for different clients with competing deadlines. As a shared resource for various teams, my workday was constantly interrupted by urgent meetings, last-minute tasks, and unexpected crises. The pace was fast, and at times, it felt chaotic. Every day seemed unpredictable — one social media post could set off a client crisis, and before we knew it, we were scrambling to fix something we hadn’t even anticipated.

But despite the constant pressure, the team excelled. They had a fanatical drive to deliver high-quality work faster and better than our competitors. There was an infectious sense of positivity, energy, and commitment. The team thrived on collaboration and openness to change. Their culture was one of flexibility, with minimal, lightweight processes that allowed them to quickly adapt to the circumstances of each day.

From the outside, it looked like they were the perfect example of an Agile team. However, as I spent more time with them, I began to see the cracks beneath the surface. The team’s speed and energy were impressive, but the pace was unsustainable. Morale was low, work-life balance was compromised, and personal health was often at risk. It was clear that while we were "doing" Agile, we were not truly following one of its most important principles: sustainable development. The 8th Agile Principle — "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely" — was being ignored.

Though the team was performing well in many ways, it wasn’t enough. We were so focused on delivering quickly and responding to immediate needs that we were ignoring the long-term health of the team. This was when I realised that we needed more than just a good culture — we needed formal guidance on how to "do Agile" in a way that would support our sustainability and well-being.

A Shift to “Being“ and “Doing” Agile

We realised that that none of us at that time had any kind of formal training so we might have known how to “be Agile”, but we didn’t know how to “do Agile”. Determined to improve, we convinced management to send several team members, including myself, to Scrum training with a professional Scrum Master. When we returned, we had a much clearer understanding of how to implement Scrum in our work. We had been living Agile in a certain sense, but now we were ready to truly “do” Agile, not just “be” Agile.

The first major shift came when we held our first “real” retrospective. It was “real” because, for the first time, we were able to make changes that had an actual impact on our team’s way of working. During that retrospective, we applied one of the most important lessons from our training: by collaboratively creating a Team Contract — a simple, yet powerful tool that outlined the rules and commitments we would follow as a team.

One of the first things we realised was how a simple dysfunction had been affecting our work-life balance. A colleague who was always staying late was doing so because he felt obligated to take on additional tasks from others when they would drop by at the end of the day at his desk and ask for “quick ones”. Another colleague stayed late because he didn’t want to leave him alone. This kind of "acceptance" of late work had become normal within our team culture, but it was unsustainable. So, we made a rule: no one on the team would accept any new work after 5pm. It was a small change, but it had a huge impact.

We posted this simple rule on the door of our workspace, and from that day forward, whenever someone tried to add a task late in the day, we would point to the paper and send them away. It wasn’t always easy, but having that clear commitment from the team made a huge difference.

Through this experience, I was encouraged that we were beginning to truly integrate the Agile principles — not just in theory, but in practice. Over time, we continued to refine our processes, holding regular retrospectives to improve how we worked together. We found a rhythm that allowed us to both “do” Agile and “be” Agile in a way that was sustainable and effective.

However, despite our progress, I still felt that something was missing. The Agile process that worked for our team wasn't something that aligned with any formal framework I had come across. We had developed our own way of working that was effective, but it didn't feel like the implementation of Scrum that I had been striving for. It became clear to me that while we had mastered the cultural aspects of Agile, we hadn't fully mastered the structured processes that could sustain our long-term growth.

This gap between "doing" Agile and "being" Agile kept me searching for a deeper understanding. Then, one day, I discovered the concept of Shu Ha Ri. This idea completely transformed my approach to team development, as I began to appreciate how profoundly it resonated with my own Agile journey.

Reflecting on the team's evolution, I realized we had already experienced a cycle of Shu Ha Ri. At first, we had followed the rules and principles that helped us succeed (Shu). Then, we adapted and changed the rules to work more sustainably, without abandoning the core principles (Ha). And ultimately, by transcending those initial rules, we had developed a better way of working that fit our unique needs (Ri).

Shu Ha Ri: The Path to Mastery in Agile

The concept of Shu Ha Ri provided the clarity I had been seeking. Up until that point, I had understood Agile as a set of practices — Scrum ceremonies, roles, and artefacts — but I hadn’t fully appreciated the underlying journey of mastery that Shu Ha Ri describes. In a way, Shu Ha Ri served as the missing link, helping me to not only implement Scrum more effectively but to also guide my teams toward a deeper, more sustainable understanding of Agile.

In my previous experiences with Agile, I had realized that simply "doing" Agile wasn’t enough to truly transform a team. I had seen teams go through the motions — following Scrum rituals — but still struggle with the deeper mindset shifts that make Agile work. There was often a tension between the informal, cultural adoption of Agile and the need for structured processes to ensure long-term success. The discovery of Shu Ha Ri illuminated a way forward, offering a framework for navigating this tension and guiding teams through the complexities of Agile mastery.

Shu Ha Ri is a Japanese philosophy rooted in Aikido. While its origins are in martial arts, it has profound relevance for Scrum, Agile frameworks, and even personal growth. Jeff Sutherland, a legend of Scrum and a student of Aikido, described how this concept mirrors the journey of a Scrum Master: from a novice learning the rules, to a journeyman adapting those rules, and finally to a master transcending them.

Following this insight, I was able to map the stages of Shu Ha Ri for every Scrum role and the team itself (see table in appendix). This insight shaped how I guide my teams today.

In Japanese, Shu Ha Ri (守破離) is often translated as “first learn, then detach, and finally transcend.” In practical terms, it’s about learning the basics, breaking them when necessary, and ultimately transcending, or gaining distance from the rules to innovate and evolve.

We can think of it as like learning music. In the Shu stage, when we first learn an instrument, we must strictly follow our teacher’s instructions. We are expected to learn scales and basic techniques repeatedly, often by playing classic songs according to a fixed score. We learn by practice, focusing on the principles of making good music. As we advance, we begin exploring our own interpretations and style. For example, we might start playing a favourite song a little more slowly, adding our personal flourishes, but still maintaining the fundamental techniques that still make it the same song. This is the Ha stage. Repeating the processes of rote practice and improvisation, at some point, we become good enough to create our own music, transcending into the Ri stage from merely repeating songs to composing original works.

This journey is not linear but cyclical. Even virtuoso musicians return to practicing basic scales (Shu), explore new techniques (Ha), and push boundaries (Ri) throughout their careers. Similarly, Agile teams must cycle through these stages as they face new challenges, contexts, and opportunities for growth.

This concept resonates deeply with me because it mirrors my own evolution within Agile. In the beginning, I followed Scrum by the book (Shu), then adapted and experimented with it (Ha), and eventually, I reached a point where I started creating my own methods, innovating within the framework (Ri). But this journey is never truly complete; as new challenges emerge and new contexts arise, I unlearn and relearn. Each new team I work with requires me to revisit the basics, adjust practices, and adapt to new environments, just like a musician returning to scales or a composer reinventing their craft.

Shu Ha Ri has become the lens through which I view both my personal growth and the growth of the teams I guide. It helps me balance the discipline of following the rules with the creativity of transcending them. Mastery, as Shu Ha Ri teaches, is a continuous cycle. Even after reaching a certain level of skill, we return to basics, refine our techniques, and push ourselves to innovate. In the same way, Agile teams must cycle through these stages as they evolve. There will always be new challenges, new opportunities, and new contexts to navigate. The key, as I’ve learned over the years, is not just to “do” Agile, but to truly “be” Agile — embracing its principles as part of an ongoing, dynamic journey toward mastery.

Kickstarting the Shu Ha Ri Journey in Every Sprint

When I took on the role of CTO at a startup that had already gained traction and funding, and was only just hiring their in-house team, I was in a unique position of having both the ability and mandate to set the path of the startup’s team through a Shu Ha Ri journey from the very beginning. Over the five years that I held this role, I iterated on this concept continually, adapting it to the ever-evolving needs of the company.

The key insight I had was that Shu Ha Ri is not a simple, linear path from beginner to master. Rather, it is an iterative and continuous learning process. Shu is about learning and sticking to the basics. Ha is when we start to experiment, adapt, and evolve the processes. Ri is when we transcend the framework, making it our own and innovating to better meet our needs. These stages are not fixed — they evolve and overlap, and the team’s progress isn’t bound by a straight line but rather a dynamic loop of growth.

This mirrors the very essence of Agile itself. At its core, Agile is about iterative development and continuous improvement. Just like teams don’t “arrive” at a final, perfect process, the Shu Ha Ri model reflects how both teams and individuals are always evolving. Whether it’s refining practices in Shu, experimenting with new ways of working in Ha, or pushing boundaries in Ri, the key is the ongoing cycle of reflection, adaptation, and innovation. This cycle is the foundation of Agile — constantly improving how we work, learning from each sprint, and adapting our methods to better meet the challenges we face.

In the same way that Agile encourages teams to inspect and adapt each sprint, Shu Ha Ri provides a framework for individuals and teams to reflect on their growth and adjust their approach, ensuring they are always progressing and never stagnating.

As teams mature, they cycle back through Shu and Ha. They learn new techniques, challenge assumptions, and experiment with new practices until they reach Ri again, transcending previous limitations and continuing their growth. This iterative process of self-improvement and evolution lies at the heart of Agile, providing Scrum teams with the framework to continually adapt, innovate, and reach new heights of mastery.

A Dream Needs a Team, and a Team Needs a Dream

It became clear to me that this journey needed to be part of the DNA of the team from day one. It was important to set our shared vision and expectations as early as possible. So, as I gathered the first members of the team, we began by envisioning what a high-performance team would look like. In one of our early retrospectives, I posed a simple but powerful question to the team: What does a high-performance team look like to you?

The answers were as diverse as the people in the room. Some referenced their favourite sports teams, like football or Formula 1, where strategy, precision, and teamwork are paramount. Others drew from iconic groups like Metallica or the Avengers, emphasising a sense of unity and purpose. We discussed what made these teams successful: trust, communication, shared goals, and a commitment to continuous improvement. More importantly, we asked ourselves what characteristics we could adopt in our own work to become a high-performing team.

This conversation was critical — it was the foundation for building our ikigai, our sense of shared purpose. In Japanese, ikigai refers to a sense of meaning and fulfilment — a reason to wake up in the morning and do what you do. We worked together to define our collective purpose, ensuring that it wasn’t just about delivering features or hitting metrics. It was about creating an environment where each of us could thrive, contribute, and be part of something greater than ourselves.

From this shared sense of purpose, we created a Team Contract. This was a document that outlined our team’s values, commitments, and expectations. It became a living agreement, not just a set of rules to follow but a set of guiding principles that kept us accountable to one another. We defined how we would communicate, how we would handle conflicts, how we would celebrate wins, and how we would support each other through challenges.

Having this contract allowed us to stay aligned, even when we faced difficult decisions or changing circumstances. It gave us a sense of ownership and agency over our work, reinforcing that each of us had a responsibility to help the team succeed. Over time, as we moved through the stages of Shu Ha Ri, the contract evolved with us. What started as a foundational tool in Shu became a dynamic, adaptable document that reflected our growth into Ha and eventually Ri.

By iterating on the Shu Ha Ri model, we were able to build a team that wasn’t just capable of doing Agile, but that could transcend it. We could adapt the principles to our context, experiment with new ways of working, and innovate to solve challenges in ways that were unique to our team and the business.

This iterative, evolving approach allowed us to stay true to the core principles of Agile while constantly improving how we worked together. Every sprint, every retrospective, and every new challenge was an opportunity to revisit our practices, evolve them, and transcend the framework to meet our evolving needs.

Mastering the Daily Scrum with Shu Ha Ri

As we explored in the previous section, Shu Ha Ri provides a framework for continuous improvement. This iterative process of learning, adapting, and innovating applies not just to the overall Scrum methodology but to each individual practice within it — such as the Daily Scrum.

One of the most fundamental rules of Scrum that many teams struggle with is the 15-minute timebox for the Daily Scrum. Just like any other Scrum ceremony, the Daily Scrum has a fixed structure and purpose that, when followed correctly, drives collaboration and focus.

In the early stages of a team’s Shu Ha Ri journey, the Daily Scrum can serve as a litmus test for how well the team is internalising the basic principles of Scrum. Timeboxing, for example, is one of the most sacred elements of Scrum — it's non-negotiable.

The timebox is not just about managing time; it’s about preserving the focus and ensuring that the team’s time is respected. Adhering to the timebox signals that the team is still in the Shu phase: they’re practicing the fundamentals, staying focused on coordination and collaboration, and honouring the fixed nature of the ceremony.

A team that truly respects the 15-minute timebox is demonstrating its understanding of Focus and Respect — two Scrum values that are essential to success. In the Shu stage, these values are practiced faithfully, often in a more structured and rigid manner. The team is still learning how to prioritise communication and collaboration effectively, and the timebox helps them do that.

Value	How it applies to the Daily Scrum
Focus	The timebox forces the team to focus on the most important topics, helping them avoid unnecessary distractions.
Respect	We show respect for each other’s time by keeping the meeting efficient and relevant.
Courage	Within a short period, team members need the courage to speak up and share updates without hesitation or delay.
Openness	Having fixed times for meetings and fixed timeframes allows us to have discussions and maintain transparent communication.
Commitment	The team commits to staying within the timebox, ensuring the meeting is productive and efficient.

If the Daily Scrum consistently runs over the 15-minute limit — or conversely, feels rushed and unfocused — it’s a sign that the team is still working on mastering the basics. This is where the Shu stage plays a crucial role: following the rules and ensuring that the process runs smoothly. If the team struggles to keep the Daily Scrum within the timebox, it’s often an indication that they haven't fully internalised the purpose of the ceremony, or there may be underlying issues like unclear goals or poor sprint planning.

As the team moves into the Ha stage, they begin to experiment with different ways to improve the effectiveness of their Daily Scrum while still adhering to the timebox. They may try new tactics to enhance engagement — such as standing in a circle to keep the energy up — or use a timer to stay mindful of the time. These are examples of how the team adapts the basic structure of the ceremony to fit their needs while still respecting the core elements. This experimentation in Ha is all about refining the process to better serve the team, while still following the fundamental principles.

By the time the team reaches Ri, the Daily Scrum feels second nature. The team has mastered the ability to stay within the timebox while also knowing when to dig deeper into specific issues that need attention. At this stage, the Daily Scrum is no longer just a ritual to be followed but a dynamic, flexible meeting that adapts to the team’s needs. Teams in Ri have the ability to innovate within the rules—finding new ways to optimise the meeting without ever compromising the core principles of Scrum. It’s a clear sign of mastery: not only can they follow the rules, but they can also create new ways to improve them, reflecting the essence of continuous improvement that lies at the heart of Agile.

This progression — from Shu through Ha and Ri — reflects the maturation of the team as they grow in their understanding of Scrum. What starts as rigid adherence to the rules eventually evolves into a flexible, innovative approach that allows the team to continuously refine their practices, improve collaboration, and achieve greater effectiveness in their work.

In a similar way, Agile itself is an iterative process, where the team’s growth — whether in mastering ceremonies, refining their communication, or adapting their practices — is always evolving to better meet the needs of the team and the organisation.

Guiding Team Evolution Through Shu Ha Ri

One of the most important aspects of guiding a team through Shu Ha Ri is regular reflection. Agile Retrospectives are the perfect opportunity for teams to inspect their processes, measure their progress, and adapt their practices. But the key is not just to look at the most recent sprint — it’s about taking the opportunity to reflect on the team’s journey and how far they’ve come over time.

In my experience, retrospectives often focus on immediate issues that arise during the sprint, resulting in minor adjustments rather than strategic, foundational improvements. This “in the trenches” mentality can sometimes prevent the team from stepping back and considering how their practices are evolving over time and how those practices contribute to their broader growth in the Shu Ha Ri framework. However, these issues may be symptoms of larger, systemic challenges that only become clear over time.

A more impactful approach is to introduce a Shu Ha Ri retrospective at the end of every quarter of a year (every three months), as the final retrospective of the quarter. Looking at a broader timeframe (e.g., all the sprints in the quarter) gives teams the chance to reflect on patterns, challenges, and opportunities that might not be apparent in the individual sprints. For example, if the Daily Scrum exceeds its timebox once every other week, it might not seem like a big deal in a single sprint, but over the course of a quarter, it could have occurred at least once for nearly 50% of the team’s sprints, which is a much bigger issue.

In these retrospectives, I suggest to periodically review the basic principles of Agile and Scrum, as well as your team's Contract (if you have one). Ask questions that help evaluate where the team is in terms of applying the rules or principles from the perspective of Shu Ha Ri. These questions allow the team to reflect not only on the tactical aspects of their process but also on their broader evolution:

• Shu: How well did we follow the Scrum rules in this sprint?
• Ha: What did we do differently? Was this sprint better, worse, or the same as before?
• Ri: What could we do better without changing the rules? If we innovate, are we doing it while respecting the Agile principles?

These questions not only helped us identify areas of improvement but also encouraged deeper reflection on where we were struggling. The idea is to inspect and adapt in every retrospective — not just tactically but also strategically. This mirrors the iterative nature of Agile itself, where every sprint offers an opportunity to learn, grow, and refine processes.

By stepping back and looking at the bigger picture, teams can identify deeper issues and make more strategic decisions that guide their long-term development. This approach turns the retrospective into a tool for ongoing evolution, rooted in Shu Ha Ri. Instead of simply addressing immediate tactical concerns, teams are encouraged to reflect on their broader journey, just as Agile encourages teams to continuously reflect and adapt at a high level.

The quarterly Shu Ha Ri retrospective doesn’t add new ceremonies to Scrum but adapts the existing process to better suit the needs of the team. Over time, this becomes a way to transcend the framework, making it more relevant and impactful for the team’s unique context. As teams evolve, so too does their approach to reflection. In this way, the retrospective itself follows the Shu Ha Ri pattern: it starts with structured, rule-based reflection (Shu), evolves into a more flexible and experimental form (Ha), and eventually becomes a powerful tool for team-driven innovation and mastery (Ri).

Scrum and Shu Ha Ri, redux

Sociology provided me with a deeper understanding of Agile’s emphasis on human-centred design. Agile frameworks like Scrum advocate for collaboration, transparency, and respect for individuals — values that align perfectly with sociological principles such as group cohesion, collective action, and social trust. As I moved forward in my career, I began to recognise the importance of "group norms" (like those promoted by Scrum ceremonies) and their impact on productivity and morale.

In many ways, working with Agile principles was like studying sociology in real-time. Each team was a microcosm of human society, where norms, roles, power dynamics, and relationships shaped outcomes. Whether it was a small group during a retrospective or the collective effort during a sprint, understanding the sociology of these teams helped me guide them toward higher performance.

As you guide your team through the process, always remember that Shu Ha Ri is not a one-way journey from novice to expert, but rather a cyclical process of learning and growth. Just as Scrum encourages continuous improvement through regular inspection and adaptation, teams cycle through Shu, Ha, and Ri as they deepen their understanding and refine their practices.

In practice, Shu Ha Ri helped me guide the team through each phase of their development, ensuring we built a solid foundation, adapted when necessary, and eventually innovated beyond what was initially prescribed. This dynamic process helped foster the kind of sustainable growth and mastery that makes Agile truly effective.

As you implement Shu Ha Ri, consider the implications of lacking any of its components:

• Shu ensures that your team has a solid foundation in Scrum. Without a strong grasp of the fundamentals — like timeboxing, backlog refinement, and the roles within Scrum — your team won't be able to fully appreciate or realise the benefits of Agile. Skipping this stage or rushing through it often leads to confusion, lack of clarity, and poor adoption of the process.
• Ha is where your team begins to adapt. At this stage, experimentation becomes vital. The team should begin to take ownership of their own processes, tweaking and evolving them to meet their specific needs. Scrum, at its core, is a flexible framework, and to unlock its full potential, a team must adapt it to their context. This stage is where true growth begins, but it's also where teams can become too comfortable and stop challenging their assumptions.
• Ri is when a team internalises the Scrum process so deeply that following the rules feels like a second nature. But even within the confines of Scrum, there’s room for innovation. Teams at this stage can transcend traditional methods, adding their own creative spins on Agile practices. However, without Ri, a team risks falling into the trap of “cargo cult Scrum” — performing the rituals without achieving meaningful outcomes. Without the underlying mindset of continuous improvement, a team will not evolve and will remain stagnant.

Reflecting on my journey, I guided a team to consistently perform exceptionally well over five years, even during the global COVID-19 pandemic, when we had to rethink how we collaborated remotely, by building on our habits without losing sight of how we should behave as a high-performing team together. By embracing the iterative nature of Shu Ha Ri, we were able to continue improving and refining our processes even in the face of uncertainty.

For me, the real power of Shu Ha Ri lies in its simplicity and flexibility. Whether you’re just beginning with Scrum or you’re a seasoned practitioner, it gives you a framework to understand your current state, identify areas for improvement, and create your own path toward mastery.

If you’re new to Shu Ha Ri, start by discussing it with your team. Identify where you are in the process. Are you in Shu, strictly following the rules? Are you in Ha, adapting Scrum or some other Agile framework to better fit your needs? Or are you in Ri, innovating and experimenting?

Use this framework as a starting point for your next retrospective, and continuously evolve your understanding. By embracing Shu Ha Ri, you can unlock the full potential of Scrum and foster a culture of sustainable growth that adds lasting value to your team and your organisation.

This article is part of the "Advent of Tech 2024 @ onepoint," a series of tech articles published by onepoint to help pass the time until Christmas. See all the Advent of Tech 2024 articles leading up to Christmas.

Appendix

Shu Ha Ri applied to Scrum team roles

Role	Shu (Follow)	Ha (Detach)	Ri (Transcend)
Scrum Master	- Learn the Scrum framework and strictly facilitate ceremonies (Daily Scrum, Sprint Review, etc.). - Rely on guides and best practices. Example: Facilitate daily scrums without deviation from the Scrum Guide.	- Understand the principles behind Scrum. - Experiment with facilitation styles and team dynamics. Example: Adapt facilitation techniques to suit the team’s culture and needs.	- Master servant-leadership. - Innovate new techniques to foster high-performing teams and organisational agility. Example: Introduce advanced Agile practices like Lean or Systems Thinking to optimise workflows.
Product Owner (PO)	- Learn backlog management and prioritisation techniques (e.g., MoSCoW, Eisenhower Matrix, INVEST). - Follow stakeholder instructions closely. Example: Use the Scrum backlog template and prioritise based on stakeholder demands.	- Deeply understand the principles of value delivery. - Experiment with new techniques for backlog refinement and stakeholder engagement. Example: Use customer feedback loops or create a more dynamic backlog refinement process.	- Shape strategic product visions. - Anticipate market trends and innovate new ways to maximise product value. Example: Proactively explore new product opportunities or market shifts, and adjust the product vision accordingly.
Developers	- Learn Scrum basics, roles, and ceremonies. - Follow Definition of Done and adhere to team commitments. Example: Participate in daily scrums and commit to sprint goals.	- Understand the "why" behind Scrum principles. - Suggest improvements to processes and adopt technical best practices. Example: Introduce new coding practices or collaborate on cross-functional tasks to improve team efficiency.	- Innovate workflows and delivery methods. - Mentor others and contribute to team-wide technical excellence. Example: Lead in introducing new tools or automation, and help the team implement them effectively.
Team as a Whole	- Adhere strictly to Scrum events and roles. - Depend on the Scrum Master for guidance. Example: Follow the Scrum Guide and let the Scrum Master lead ceremonies.	- Explore process improvements collaboratively. - Take ownership of delivering value while adapting practices. Example: Experiment with Kanban boards or tweak sprint planning to make the process more efficient.	- Self-organising and fully autonomous. - Seamlessly blend Agile principles into custom workflows. Example: Develop a hybrid approach, incorporating Scrum and Lean elements, to continuously improve the team's output and adapt to changing business needs.

Resources

• Shu Ha Ri on Wikipedia https://en.wikipedia.org/wiki/Shuhari
• Shu Ha Ri: What makes a great Scrum Master? https://www.scruminc.com/shu-ha-ri-what-makes-great-scrummaster-2/
• The 12 Principles behind the Agile Manifesto https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/
• The Scrum Guide https://www.scrum.org/resources/scrum-guide
• How to Facilitate Powerful Working Agreements (Team Contracts) https://resources.scrumalliance.org/Article/facilitate-powerful-working-agreements
• Some related and complementary ideas:
  • Tuckman’s stages of group development https://en.wikipedia.org/wiki/Tuckman's_stages_of_group_development
  • Dreyfus model of skills acquisition https://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition
  • Four stages of competence https://en.wikipedia.org/wiki/Four_stages_of_competence