Shu Level Agile Isn’t The Same As By-The-Book Scrum
A couple of years ago… gosh, probably more than that now… I got turned onto the idea of Shu-Ha-Ri by Alistair Cockburn. Alistair talks about this concept in both Crystal Clear and Agile Software Development: The Cooperative Game. While it’s been a few years since I’ve read these books, what’s stuck in my head is that Shu means Beginner, Ha means Journeyman, and Ri means Master.
The idea is that, when you are just getting started, you need to follow one way of doing something. As you progress, you’ll learn the limitations of that one way, and ultimately discover that there are other ways to achieve the same or better results. Once you have mastery, you blend and adapt approaches without even thinking about it. That’s the point where the student has become the master.
Quite often though, I hear people using the idea of Shu-Ha-Ri as a way to mandate that new Scrum teams follow the rules of Scrum by-the-book. In a sense, this is fairly consistent with Alistair’s quote from Ron Fox in Agile Software Development. The Shu level student is copying techniques without fully understanding why and that Shu implies an allegiance to a single instructor (page 18, 2nd edition).
I think this is fine when we are learning a given style of martial arts, but what about when we are applying process or methodology to a complex business problem? What if the teachings of the instructor aren’t working? What if the teachings are not applicable to our given context? Should the student blindly apply the teachings without understanding why and without modification?
I think that some of us have taken the concept of Shu a little too far. I think some of us bring a certain arrogance in believing that any one approach is applicable to any given student in any given context. That said, I do believe that as students we progress through a Shu-Ha-Ri process as we learn… it’s just that my Shu isn’t necessarily your Shu when it comes to process.
I have always taught that Shu means the beginner must have one way that can work. If we give the beginner too many choices up front, they won’t know how to choose and may be overwhelmed. As the student gains experience, that one way will inevitably have limitations and need adaptation. Once the student has achieved mastery, they can adapt and blend techniques as necessary.
Let’s say I want introduce agile into a large complex organization like the one I wrote about in my last post. I can teach team level Scrum all day long, but it won’t solve their fundamental business problem. The problem is too large and too complex for team level Scrum. For this organization, a Shu level approach might be an implementation of Leffingwell’s SAFe model.
While SAFe is more complex than Scrum, it may be minimally sufficient for the more complex needs of the enterprise.
When LeadingAgile engages an organization, we’ll bring our skills and experience with Scrum, XP, Lean, Kanban, and SAFe to blend an approach that is minimally sufficient to run that particular enterprise at scale. From the receiving organization’s point of view, this approach is a Shu level implementation… even thought we’ve brought Ha and Ri level understanding to help develop the solution.
Even though we have blended approaches to create the Shu level implementation, there are many more options available to solve even more complex problems. As the client learns, they will learn the limitations of our Shu level implementation and begin to adapt their own process. This is Ha level understanding. In time, and with practice, the organization will progress toward mastery and achieve Ri.
In summary… don’t confuse a Shu level implementation of enterprise agile with a by-the-book implementation of Scrum. Your organization may require more advanced mechanisms to implement agile at scale. What you need is one combination of approaches that works consistently while you are getting started. Once you’ve got that working… you’ll learn, inspect and adapt, and make it your own.
Check out the next post, Should You Use Agile To Build Your Next Home?
Check out the previous post, How to Structure Your Agile Enterprise.
Comments (11)
George Dinwiddie
Nice post!
As Rob Myers summarized on Twitter (https://twitter.com/agilecoach/status/432218029640777729) “Shu is not ‘basics’ but one way that works.” When teaching Agile to an organization, the teacher also needs a “way that works.” Going strictly “by the book” isn’t that way. If the book were sufficient, then the teacher wouldn’t be required. A by-the-book implementation of Scrum may be just fine for an organization’s starting point if their situation is similar to that in which Scrum was invented. I suspect the odds are pretty low, however.
The teacher needs to be pretty good at Agile before being prepared to teach. The teacher needs to help the organization find a “way that works” for the moment, given everything that’s currently going on in the organization, the people involved, and what they currently know. This is their starting point. This does not make them then capable of teaching others. As a teacher, they have not yet reached the Shu level. Knowing a way to do Agile is not the same as knowing a way to teach Agile.
To me, this is the origin of the problem. Many people who have been part of a successful Agile adoption now consider themselves ready to be Agile coaches for others. They have made it work, once. The same process implementation and the same way of learning is unlikely to work in the next situation in which they find themselves.
I was part of that thread at one point and it’s what inspired the post ;-) Thanks for the comment George!
Adam Yuret
I agree with George and much of the post.
My issue with Shu Ha Ri as a coaching model is that I’ve gone many places who have a defined “Shu” process. Either the consultancy I’m subbing for defines “Shu” and explicitly tells me that they will come supervise me to ensure I don’t pollute their “Shu” (again disclaiming that this was not LeadingAgile) but also some clients learn about SHR from previous coaches and say “You can come in but you will do it ‘The client way’ which is something I know Mike has experienced. Interestingly when I did not do things in this way but saw successful impact that client wanted me to codify my methods so they could use it to define the new “Shu” for the entire enterprise.
I think when learning a martial art it makes complete sense that I should not divert from “Shu” so I don’t hurt myself or others. When working with professional adults discounting their greater knowledge of context and problems they have within their organization is foolish. I’ve run into problems where people have said “We feel like is waste, we think we’ve solved this problem another way.” and I’ve said “Okay sounds good, why don’t we list the things is intended to address and see if they’re neglected after eliminating .” Somebody who likes SHR then says “You said what?! Don’t you know why you’re supposed to force those people to do that ritual?!” In the end I think including adult professionals with judgement in guided collaboration over their process as a partner and trusted advisor flies in the face of dogmatic Shu Ha Ri. I also worry when I see clients of other consultancies who have been “Following the Shu process without diversion” and are not only completely disengaged from their own process but have no clue why they’re doing what they’re doing.
Praxis can be a more powerful approach to helping people understand theories that solve their actual problems and then practicing those theories. When things fail they’re more likely to understand why and be able to adapt something new rather than continue down the prescribed path.
So essentially I don’t think the martial metaphor is sufficiently helpful to justify the pain of it’s abuse. I think that’s mostly what you say in your post and thank you for it. :-)
Allison
This seems like a continuation of our dinner conversation. The easy thing to do as a coach is focus on getting a team to Shu, but an organization full of Shu teams does not make the organization itself Shu! With an organization full of Shu teams, the coach and the organization then have more insight into the context and impediments to add the other practices/processes/whatever needed to reach organization Shu.
George Dinwiddie
Adam, one of my primary goals when helping a new team is to help them observe how they are doing and what effects their choices make. It can be difficult at that point in the journey to imagine the consequences of some decisions, so I share what I’ve seen elsewhere.
What you describe sounds like a dead end. It doesn’t sound Agile, at all. Too often I encounter people who just want to go through rituals without looking for the benefits that those rituals should provide. Too often I see upper management asking for Agile “by the book” without realizing that the principle of self-organization (which is in the book) precludes following a cookie-cutter template.
Fredrik Vestin
I guess it depends on where the organization is coming from. If the organization doesn’t have any experience in agile/scrum I would think that trying to do things “by the book” is the right way to start. Help the organization understand the rules of the game and understand why the rules matter. Otherwise I see the risk of cherry-picking. E.g. we do scrum but don’t have time for a dedicated SM, retro take too much time so we only have them every other sprint, work is assigned (the list goes on indefinitely). Following the rules has a value in that it often exposes dysfunctions in the organization which are otherwise hidden/worked around. Once they got it, evolve and make/break the rules.
Scrum is not very prescriptive and has deceptively few rules, which allow it to be used in a wide context.
Adam, thanks for the comment. I wholeheartedly agree that we need to listen to the customer and help them figure out a Shu level expression of a process that works for them. Again… I think that Scrum isn’t Shu level agile and therein lies the problem with many of your experiences. The company has taken their Shu level implementation as the ONLY Shu level implementation. If we collaborate with the customer to come up with something unique, we can still implement the one way… it’s just that it’s not my way, or Scrum’s way, or even fully the client’s way. It’s one way that we all agree will work and are ready to try. How long we stay with that one way before we begin adapting it would all depend on the maturity of the organization, but that is probably a topic for a different post ;-) Great comment!
Allison… agreed, this has been on my mind for a few weeks now ;-) Even at the team level, Shu can be different for different teams. The mistake that many companies make is that they take Shu level team practices and assume they are the same for the broader enterprise and IMO, that assumption almost never holds!
George… what I find in our practice is that in large complex enterprises there is so much corporate bullshit surrounding the team, there is almost no way they can self-organize into anything resembling an agile team without totally walling themselves off from the rest of the organization. I’ve seen this pattern tried and fail many times over because the new team can’t exist for long in the face of this level of external pressure. Our approach is to get people moving from point A to B as quickly and as safely as we possibly can. Personally, I’m okay with agile not being step one on the journey. Quite often I’ll take a team based, iterative and incremental model over agile. It will get us more than half way there, create safety for the larger enterprise while it’s in transformation, and allow the new team for form, deliver, and start realizing some of the benefits of an agile-like approach. They can’t inspect and adapt however they want at this stage because there are too many connection points with the rest of the organization. As the enterprise begins to transform around these teams, there can be a greater openness to letting go, decoupling the output of these teams from each other; and allowing for more emergent outcomes, more inspection and adaptation and team based self-organization. Many of these legacy organization are on a multi-year journey to really move the entire enterprise. In that context, I think some Shu level practices that allow the agile enterprise to begin to emerge and form is perfectly acceptable and not inconsistent with our end goals. Sure… probably not agile in the sense the word is often used. But can definitely lead to more agility in an enterprise context. Great post, thanks for the comment.
Fredrick… I think they should do agile by the book too. The question is who’s book? Ken Schwaber’s book? Jeff Sutherland’s book? Alistair Cockburn’s book? Jim Highsmith’s book? Dean Leffingwell’s book? How about Mike Cottmeyer’s book (haven’t written it yet) or their own book that was created with guidance from any or all of the above? That is the point of this post. In agile, the author of the book does’ matter. Finding one way that works matters. If we have one way that works, and we follow that way consistently, and without adaptation… at least initially… we have a greater chance of being successful.
Sridhar
Mike
I am in agreement on ppl discovering what flavor of agile works for them.
IME, Enterprise agile transformation means that the consultant (or whoever is coaching) needs to be a realist and not an “purist.” Most organizations don’t drop everything they are doing now and start with agile. Waterfall and a host of other models will coexist and even agile implementations will have a “process wrap” around them.
To move from Shu to Ha is difficult, since the mindset, culture and even org structures need to change (performance appraisals, anyone?).