“A Person's Feet Caught in a Net,” courtesy Pexels (cottonbro studio)

Disclaimer: We don’t actively think or concern ourselves with shu-ha-ri. One critic of this posting said that shu-ha-ri is a “terrible” metaphor and apparently not even a good idea in the context of martial arts. They may be right, but it misses the point, which is that far too many agile practitioners have ended up stuck in the beginner’s phase–where they treat agile solely as a set of practices. You need only understand the metaphor of shu-ha-ri to the point that it helps reinforce the notion that you must advance beyond rote practice.

Thanks to guest co-author Nick Goede!

Students of martial arts learn various movements as part of their fundamental training, such as the Kokyunage (“breath throw”) movement in Aikido. Initially, students seek to precisely mimic the challenging movements made by their instructor. They also seek to ingrain these movements to the point where they are made near-instinctively (think “wax on, wax off” from Karate Kid).

Being able to perfectly replicate the body of movements isn’t the end goal, however–it only represents the first stage toward becoming an expert. To master a martial art, you must have also learned when to break the rules and how to transcend them.

The martial art of Aikido establishes three stages of learning, referred to as shu ha ri:

• shu: “obey.” Adhere to, ingrain, and accept the fundamental movements as taught.

• ha: “detach.” Break from the fundamental movements and experiment.

• ri: “separate.” Act on your own accord, as long as you continue to align with core principles. “Open the door to creative technique”¹

Applying Shu-Ha-Ri to Agile Software Development

Agile represents a set of values and principles used to help teams succeed at the very complicated challenge of delivering quality software. Some folks have applied the shu ha ri stages to teams learning agile software development.

For many, unfortunately, the first exposure to agile is through first ingraining a body of practices, typically derived from an applied framework like Scrum:

• Regular communication via daily stand-up meetings

• Estimation via story points

• User story creation using a rigid story format (“given / when / then”)

• Sprints / iterations as cadence mechanisms and commitment periods

• Inspection & adaptation via retrospectives (“what did we do well, what did we not do well, what do we need to change”)

• Planning and tracking of stories in Jira

Each of these techniques is easily mimicked by individuals and teams.

As a result of being introduced to agile in this manner, many people perceive agile to be a collection of practices.

In reality, none of these practices–which can all provide value–are required in order for a team to be agile. Conversely, a team can employ all of these practices and not at all be agile. Agile software development is a set of values and principles, not a collection of practices.

Agile Shu

The most typical agile dysfunction we see is the team stuck in what we’ll call agile shu. They’ve ingrained a set of practices, such as the daily standup, but have not evolved an increment further.

Nick relates a story about a team kicked back to shu:

At a company I worked at, which we shall call FrozenAssets, they decided to bring in trainers in order to bring about an “Agile Transformation.” (By Agile, they of course meant Scrum™.)

The Scrum™ trainers explained shu ha ri, then said that all the teams at FrozenAssets would need to return to shu. For some teams this meant a sudden forced adoption of agile values and Scrum™ practices. For others that had already adopted the agile values, this meant a sudden change of practices from the ones they had refined.

Worse, now management believed the team had adopted the Process for All Time–completely missing the point of shu ha ri.

Additionally, since agile was presented as a process, the only real training was on how to execute the process–what practices must we do and when? The developers and product managers were otherwise given little to no training on how to actually survive, adapt, and thrive in a Scrum-like process.

FrozenAssets teams performed retrospectives in an effort to improve things. But because Management allowed nothing to change, the retrospectives were both useless and infuriating for the people on the teams. The best outcome that the retrospectives provided was the action item of “talk to management”–which management met with either confusion or anger.

Left in shu, the teams at FrozenAssets burned out. The codebase got even worse, since no one knew how to refactor or write tests in a rapidly moving codebase. Eventually the original trainers returned (for a different engagement). They were somewhat horrified to find out FrozenAssets was still following the same process.

Shu Stuck in the Muck

Daily stand-up meetings (aka “the daily Scrum™”) in many teams are 15-minute exercises where participants must answer three questions: “What did you do yesterday,” “what are you doing today?,” and “what are any blockers?”

For most involved, the stand-up seems a protracted, tedious waste of time. At any given point, it’s often only valuable to the person speaking and a project- manager-sort in the room. The remainder of the team crosses their arms and thinks more about what they’ll say when it’s their turn. As such, the typical stand-up is a glorified status meeting.

And yet, six months or two years later, the stand-ups for these teams still look the same and are still painful.

a-Ha!

Heeding shu ha ri means that we must begin to mature. Moving out of shu and into ha means recognizing that, while our practices represent a good starting point, we must look at and understand the bigger picture. We do that through the core agile principle of continuous reflection and adaptation.

The three-question stand-up meeting does not represent an end goal. It is instead a starting point toward an end goal. Our end goal, again per the agile manifesto principles, is for business folk and developers to work together daily in order to continue delivering high-quality software.

Five minutes of reflection would reveal that the typical stand-up is dysfunctional–it seems to provide only minimal value, and almost no one enjoys them. We can explore ways of improving them, as have countless other people who’ve written countless other blogs on fixing your stand-up.²

We might, for example, discard the beginner’s rule of every person answering three questions. We explore alternatives, and instead choose to center the stand-up around features. For each feature, we discuss as a group what it will take to deliver it. This aligns our stand-ups with the notion of focusing on continually delivering high quality software.

Our adaptation results in a changed practice. We’ve broken away from the original constraints of our stand-up, and moved onto something better.

Practices exist solely to help us adhere to core principles and values, which in turn are what truly lead us to better solutions. As such, they are but implementation details that should evolve over time.

Ri, a Stage We Call Ourselves

As we evolve practices, we will discover that we create other (hopefully lesser) problems as a result. Centering the stand-up around discussing features can highlight the fact that we’re working on too many things at once. Or it might point out that, while our WIP limit is low, we are working too disjointedly and things are getting missed.

The ri stage tells us to transcend the rote practices–to move out of “prescriptive learning via practices” and into experimentation and learning based on principles.

It is this ri mentality, echoed in the agile manifesto, that has advanced and honed our techniques for successfully delivering quality software for over two decades. As one example, Scrum and original XP heavily promoted fixed-duration iterations (“sprints” in Scrum). But many teams discovered that ideas from lean manufacturing could be tremendously valuable when adapted to software development. Some of these teams found they were more successful when they adopted a purely kanban approach, eschewing iterations completely.

Remember, the concept of shu ha ri doesn’t say “do whatever you want.” In fact, you must first put on the shu and completely ingrain the basic practices before you say “ha!, I’m not doing that any more.” You must fully understand the reason for rules–how they help you meet the underlying principles–and how to apply them before knowing when it’s appropriate to break them.

Breaking Out of the Shu Box

The practices and rules established by frameworks like Scrum and XP can seem like OK starting points. They are cookie cutters, however, designed so that every team’s practice will look the same at the outset. Yet every team’s composition, context, and challenges are unique, implying that each should evolve past these starting points.

If your team has mastered Scrum or another framework, to continue letting it box you in would be ri-diculous. Otherwise, consider something aligned more closely with agile principles from day one. (Secrets to be revealed in our forthcoming post!)

Share your comment