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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)