Shu-Ha-Ri Considered Harmful?

Back in 2002, Alistair Cockburn wrote about three levels  of practice: learn, detach, transcend that we can apply to our listening, reading and coaching. He used Shu-Ha-Ri from Aikido to illustrate that these three levels of practice are found in other skill areas.

• Shu, the student copies techniques without adapting them.
• Ha, the student reflects on what has been learned and breaks free from traditions.
• Ri, the student is now a practitioner extending the art.

In the 2nd edition of Agile Software Development, Alistair adds "You can apply Shu-Ha-Ri to designing courses and writing technique materials."

Although he takes care to say "Organize your material to reassure the advanced people in your course that it is not being presented as a cure-all, but simply as another technique in the toolbox of the professional. .. But before you finish, put the technique into a larger context so that the beginners can start to see where they will expand to and so that the advanced people can see how this technique bridges to others they might already know or want to learn."

I've seen Agile rollout programs styled around Shu-Ha-Ri for years. In the early days of both XP and SCRUM, it was stressed that you should first do all the practices by the book. Only then would you be in a position to adapt them. You would avoid the travesty of Pretty Adventuresome Programming  where the team avoids any difficult new practices and also drops stuff not mandated like documentation!

Jeff Sutherland relies on the same Shu-Ha-Ri philosophy when he expounds "You enter the dojo and do what the Sensei (teacher) says. You repeat exercises over and over until it is part of muscle memory. Only when you have mastered the basic practices are you allowed to improvise. And the last and most important – Before you have gained discipline, centering, and flexibility, you are a hazard to yourself and others."

I'm uncomfortable with approaches that force students to follow agile practices without questioning. These approaches seem to violate the first value of the Agile Manifesto "Individuals and interactions over processes and tools." I question whether introducing agile software development techniques to people is anything like martial arts training. Software development is knowledge work and our aim is to build a team of reflective practitioners. To do this we need to engage with how people think about their work. Are techniques from physical arts that build muscle-memory really applicable here?

For me, agile Boot Camps and Shock Therapy approaches lack basic respect for the team's unique context and the experience of people on the team. Agile software development is a much looser discipline than a martial art like Aikido. Organizational culture and nature of the product being built are major factors in what agile techniques the team will benefit from most. If we establish a sensei-novice model, we're not fostering the independent thinking and reflection that will take the team beyond the Shu level.

A different approach that draws from martial arts is the Coding Dojo . Dojos are becoming a popular way to encourage learning in groups without this emphasis on a sensei.

Installing a basic set of agile practices by force can be done quickly so the organization starts getting benefits from new ways of working faster. Teams are superficially at the Shu level in the space of a few weeks. Often, the management team considers the agile rollout is now complete. It's assumed that teams will continue to apply what they've learned. But without any experts around to enforce agile practice, pretty soon a team falls back to their old ways or sometimes worse carries on with agile practices that don't make sense for their project.

I was pleased to see "cargo-cult agile" called out in the new book "Practices for Scaling Lean & Agile Development" by Craig Larman and Bas Vodde. They say "Avoid forcing--When coaching we encourage: volunteering; do not force any agile or lean approach onto people; people should be left the choice to think and experiment...with concentrated long-term, high quality support. The best, the most sticky adoptions we have seen had this approach."

Learning new ways of working takes time.  As Ron Jeffries once said "They're called practices for a reason".."You have to have done them. Practice makes perfect." If you base an agile adoption on Shu-Ha-Ri model, the trick is to remember the goal is beyond the first-level. Your teams need more than training. Allow plenty of time and on-going coaching support for teams to get them into the Ha phase and beyond.

Comments

[Christian Edward Gruber]

I understand the concern, especially the respect for context and unique character of the teams... but this betrays a misunderstanding, or mis-application of Shu-Ha-Ri. Shu doesn't imply that the students are fungible. Technique is still taught in the context of the student (team.

In Aikido, especially, students practice the techniques in multiple contexts, so they can get a sense of the suppleness. What isn't asked, is that the student innovate, or combine before they've at least mastered the basic technique - so they're not thinking through each step of a move while they're doing it - they "get" it. They they can move closer to innovation.

Your post, while understandably compassionate, confuses two separate things... models of instruction, training, and practice with notions of respect, oppression, and dominance. Telling a student to try the basic move and get it better before expanding isn't disrespectful, it's understanding the learning models of the student. However, it is quite possible for a student to "grok" the technique more quickly, and if Sensei observes this, he will show the student something slightly more advanced, and have him practice this. The point of Shu-Ha-Ri is, as you point out, to ensure that one doesn't miss the basics while playing with the innovative and the expansive. If it's being used to hold a student back, or somehow contains a disrespect for the student - that's a failing of the teacher (coach).

I feel you are mischaracterizing Aikido, which is taught in many forms, but Agile is not looser, nor is Aikido tighter. Aikido is, in any good Dojo, taught with great sensitivity to the needs of the student, the capacities and readiness of the student. It is taught to groups, individually - that is, it is demonstrated to the group, then practiced in pairs, with Sensei observing, correcting... coaching. If anything, rolling Agile out in a large organization, and taking large groups through paces is UNLIKE Aikido training.

Bootcamps fail to do Shu-Ha-Ri if they insist that all steps of Shu are learned at equal pace by all learners. This is not Shu-Ha-Ri being harmful - this is Shu-Ha-Ri being ignored.

warmest regards,
Christian.

[Rachel Davies]

Christian,

Thanks for your comment. I did not mean to sound critical of Shu-Ha-Ri as a sensitive way to teach Aikido. I also appreciate that there are different learning levels.

My concern is that the Shu-Ha-Ri model is being (mis)used to justify teach software development teams to adopt practices without question. I agree with what you say, this is UNLIKE Aikido training.

Aikido is much older than software development and has moves that have evolved over many years. In Aikido there are physical skills to learn. Whereas, what is taught as agile involves a wide range of thinking and communication skills.

I would say that many techniques within agile software development have not yet reached the maturity for Shu-Ha-Ri to be applied in the same way as to Aikido. So talking about Shu-Ha-Ri for agile software development is potentially misleading.

[Matthew Barcomb]

I really like the Shu-Ha-Ri model when teaching/training technical skills (software craftsmanship). While I feel this does align with agile philosophy, I too am unsure if it is wise to use the same learning concept to teach an agile method. There is a balance that must be struck. The new agile learners must understand the "whys" behind the basics before moving forward otherwise a poor or misunderstood adoption of agile may occur. However being forced, either from a coach/consultant or organizationally from "on high" to simply follow a method by-the-book without considering the situational context of the team and the environment is just a path to folly.

[Rachel Davies]

Matthew,
You make a good distinction in your comment. Software development practices, like refactoring and writing code test-first, are an individual skills that can be honed. Other parts of an agile method like understanding what product to build, refining user stories, and creating a release plan are team activities that can be highly dependent on the situation the team is facing.

[Ilja Preuß]

I'm concerned about forcing Agile practices on a team, too. That would obviously totally counter to the teams selforganization. Fortunately, it's not at all how I understand Shu (and I don't think it would work well in martial arts, either).

What it is about is to me asking the student to suspend disbelief. The student follows the sensei out of his respect for his experience. And doing that is valuable *exactly because* often the most effective way to have the student understand the why is not to explain, but to let him experience the effects of doing it a certain way.

[Account Deleted]

Great post Rachel.

At the first AgileCoachCamp, we had a lot of discussion around Shu-Ha-Ri. Some coaches claimed that it's the coach's responsibility to take people they are coaching from Shu to Ha to Ri level.

I think this notion is completely flawed. Its not the coaches responsibility. Its the individual's responsibility to move from shu-level to Ha-level to Ri-Level.

Having independently applied some of the Agile thinking to software development projects, I think, it took me first few years (almost 5 projects) to really understand Agile. In other words, it took me at least 5 projects to move beyond the shu level on certain aspects. (BTW I'm still at the shu level on certain other aspects). How could a single coach give me this breath of experience?

Also a lot of times we miss the fact that one might be at different levels on different topics. I consider myself at a Ha-level when it comes to applying TDD to OO Langs. But I'm at a Shu-level when it comes to applying TDD to Func Langs. There is so much context and variation that we seem to dumb it down and loose the essence.

[Rick van der Arend]

I agree with Christian on the "two separate things... models of instruction, training, and practice with notions of respect, oppression, and dominance".

It should be so that students at the Shu level WANT to be teached by a teacher at a higher level. The problem is, for this to be realised, it should be possible for the student to recognize that he is at a lower level of competence. This can be both in software practices as well as in 'outward' knowledge of the context.

There you see the main difference between Akido and Agile: the link between practices and succesful outcome is fuzzy and hard to determine. Maybe not so much for the (wannebe) teacher, but surely for the (would-be) student.

In Akido, the teacher will just do a match with the student to show he has more skill. In Agile (and lot's of other skills to be attained) this is not so simply achieved. Simply looking to history is not the full answer: maybe the wannabe teacher has had easy assignments and that's why he has been so succesful; maybe the teacher doesn't know what made him successful either. These things cannot be determined from past performance

[Thoughtadrian.blogspot.com]

Thanks Rachel, for this insightful and thought-provoking post. (And thanks Naresh for tweeting it, leading to my discovery of this conversation). I've been contemplating the Shu-Ha-Ri model as it relates to the agile coaching I do. I always defer to the agile manifesto when agilifying teams. This Shu phase has been disconcerting to me as I've thought through its ramifications.

To me, there is no agreed fundamental "Shu" as it relates to agile. There are practices, yes, but none are universally applicable. There may be agreed-upon fundamentals in Aikido, but I'm not well-versed in the art.

As an example of misalignment of this concept, a colleague I recently worked with preferred breaking stories down to tasks as part of the "Shu" phase. My preferred approach is to avoid task breakdown unless/until it is found to be useful by the team. My reasoning is based on the fear that the bureaucracy of task management can potentially stifle the acceptance of agile due to the micromanagement this tracking creates. It's an example, to my mind, of following a prescription rather than an approach.

My agile Shu is probably not your agile Shu.

That said, I think the concept of "training wheels" for some teams is apt as they adopt an agile approach. I prefer to introduce these training wheels with full transparency though. "Phrase your acceptance criteria as 'Given, When, Then'" is an example. But I also share that this is a structure that helps you think through the acceptance criteria, and that at some point, when you "get it", you can discard the formality. Similarly, "As a ___ I want to ___ so that I can ____" is a structure that helps as "training wheels".

Thanks for driving this conversation forward Rachel. I appreciate the opportunity to clarify my thinking based on your well-articulated views.

[Alistair Cockburn]

Hi, Rachel,

Good point about the possible difference between Shu in martial arts and Shu applied to other skill development. I stress that "Even if I know there are 10 viable techniques, I can't learn all 10 on first showing up. So I learn one to start with." That's also Shu, but a Shu with an awareness of Ha.

As Russ Rufer said: "It's clear that one Shu can't fit all." In my lectures these days I stress the importance of "Getting out of the Shu box".

So, despite the catchy title, it's not Shu-Ha-Ri that's harmful - it's the Shu without the Ha and the Ri. Probably more accurate (though less catchy) to title this "Shu Considered Harmful"

cheers - Alistair

[Paul Dyson]

It seems to me that there is one big difference between Shu as applied to martial arts and Shu as applied to agile development. Most white belts in any martial art have little or no prior relevant experience. They don't know what the don't know and are unaware of that fact. Constant unquestioning repetition long proven to be the best way to obtain the basic skills required to lay the foundation for learning; but this is not true learning and the 'teaching' at this level is very rarely tailored to an individual's needs in a traditional dojo.

When I started Aikido, after seven years of Shotokan Karate, Sensei commented that I was a "deeply unusual student"! I had more experience of martial arts than any other student there but I knew none of the basics of Aikido; I had been teaching Karate for a couple of years but most of what I knew was irrelevant. After two weeks I dislocated my shoulder trying to execute a simple roll, caught between what was deeply ingrained practice and what I was trying to learn. On a couple of occasions I hurt other students by applying power to techniques rather than relaxing in them (applying a Karate approach rather than an Aikido approach).

My point is that most individuals and teams I've met that wish (or are required) to adopt some form of agile process have been developing software for years. Most have had significant success and have learned, through repetition and reflection, what works for them. Many are at the 'Ri' (or at least 'Ha') level of software development, just not agile development.

The 'deeply unusual student' is actually the norm rather than the exception and the techniques that work for the naive student (repeat one technique over and over, then adopt one more, slowly begin to combine) cannot be applied in the case of the 'wrongly experienced' student.

[YvesHanoulle]

Great post Rachel.
I love shu-ha-ri. I don't want to force people. I have been struggling with your post to see what I wanted. Alistair reaction made me understand it. Yes Shu on it's own is bad. And then people will fall back (which I guess they also do with aikido with only shu).

So what this tells me now (after 10 minutes of reading and thinking) is that might helps me in explaining better why I want to coach the way I do. Why I want to stay longer then just learn people the shu level. I don't want to say full time on your project/team, but at least guide the people to the next level a few days a month.

It also explains why I give free live time support to my customers. I want to help them go to the next level.

[Mark Levison]

Rachel - I think that any analogy can be taken to far. Think of the misuse of building stories in the software community. Like you I don't like Shock Therapy, Boot Camps etc.

But I do think that to a limited extent Shu-Ha-Ri has value. Its a good reminder not to start tinkering with the system until you've really understood it. I've had clients who 2 days into a project ask why the standup needs to be daily - saying it wastes time or its too difficult to schedule. For them Shu-Ha-Ri or some other story is a good reminder not to play the system until they understand it.

[Siddharta]

The difference is that in most activities, we have a teacher for a long period, often years. With agile, it is usually a 1 or 2 day course and contact with the trainer is lost after that. So while we can expect continuous guidance over a long period of time in the former case, in the latter we mostly have to take decisions ourselves.

The other difference is that with most activities we know that there is a long learning period. We don't expect to compete in the world championships after day 1. With agile, most companies are looking to get productive right from the start.

I've posted a longer reply here - http://www.silverstripesoftware.com/blog/archives/240

[Kevin Thompson]

Is ‘Shu, Ha, Ri’ harmful? That’s an interesting question.

I admit to not liking the expression. Partly, this is a gut reaction against anything that seems elitist. I don’t think that martial arts are elitist, but this term strikes me that way when used in a Scrum context.

Mostly, I think what bothers me about apply martial arts terminology to Scrum is that the purpose of martial arts is so very different from the purpose of Scrum.

Martial arts is about self development and self defense. It is oriented towards individual activity.

Scrum is about getting work done. It is oriented towards team activity.

These are very different things. I’d rather talk about Scrum in terms that make sense for it, and I don’t think that martial arts terminology is a good way to do that.

Kevin Thompson, Ph.D., PMP, CSP

[TotherAlistair]

Hello, Kevin ...

Pardon me ? You write that you have a gut reaction against anything that seems elitist? And then you sign your name Ph.D., PMP, CSP?

uh, that seems like quite a disconnect... How are we to understand your post? Are we to give it more credibility than the people above because of all the titles you so carefully amass after your name?

Alistair

[TotherAlistair]

Re-re-re-reading this post, I see that the correct title would have been "Shu- without Ha or Ri considered harmful".

That's easy to agree with.

cheers - Alistair

[Rachel Davies]

Alistair,

Respectfully, I disagree with you about the "correct" title. Although, I do heartily agree with all you say about Shu-Ha-Ri in your book. I wrote this blog because I have a concern that the Shu-Ha-Ri metaphor is often abused and sometimes does harm.

For instance, if a person has been part of a Scrum rollout team at one organization, I doubt they have enough experience to direct a transition at another organization and to go in assuming that next organization is at Shu level.

Because it's not clear what it takes to be at Ri level for agile software development, people assume they are Ri too early and go around telling people what to do (when they themselves may not have enough experience to say definitively what should or should not be done).

Whereas if we use a more clearly defined model like Dreyfus it becomes clearer to determine what level you're at and there's no pseudo mystique of Japanese martial arts terminology.

I see a lot of abuse of the term "Master" in Scrum and the world of Agile consulting. I consider that the Shu-Ha-Ri metaphor can be misapplied by people, who do not have a deep understanding of agile software development, resulting in real damage. I have coached teams in several organizations in the wake of big consultancies who came in and implemented Scrum "by the book" (wrapped around their agile planning tools). I have seen Shu-Ha-Ri used to legitimize forcing people to do things that are not agile, do not make sense in the context, and lack respect for the people in those teams.

Rachel

[PostAgilist]

I agree that Shu ha ri is harmful and greatly misused. I cover that more in my blog post: http://postagilist.wordpress.com/2012/09/11/the-con-job-that-is-shu-ha-ri/

PA