One SHU Not HA RI, These Things!
Have you been on a team or in an organization that adopts a new methodology or framework of getting work done and then stops using parts of it almost immediately? Or they don’t implement parts of the framework because that won’t work for them? All to often I have seen this happen when implementing an Agile framework like Scrum. Someone hears about it and/or takes a course and is very enthusiastic about bringing it to their team or organization but then quickly discards certain parts that “won’t work for their situation.”
Some teams and organizations that I have heard about very quickly take a framework like Scrum, find the pieces they like and call themselves Agile. Fast forward a few months, they find they aren’t getting much out of it and still performing about the same as before. Additionally some organizations that I have worked with have had a bad taste in their mouth regarding their dip into Agile waters. Typically, when I dig deep enough, I find that when they tried to adopt, they rushed through the Shu Ha Ri stages of development. And even worse they blame the framework (i.e. Scrum) and don’t want to ever hear the name again.
Shu Ha Ri is nothing new, it has been around for centuries in Japanese martial arts. Alistair Cockburn was one of the original thought leaders to use Shu Ha Ri in the Agile space. Recently I was reintroduced to it during an Agile Coaching Workshop and inspired this post (along with some help from a colleague, Ken Furlong (@kenfurlong), who has a very good website). If you aren’t familiar, Shu is the beginning stage where you learn the rules without understanding the underlying theory, Ha is when one starts to break the rules, understands the theory and learns other disciplines, Ri is the stage where one transcends the rules because they have gained the understanding why they do what they do. They have also integrated other moves from other disciplines.
Other ways to think of each level:
- Shu – Imitate, Follow, Embracing, Learn techniques
- Ha – Assimilate, Break, Diverging, Collect techniques
- Ri – Innovate, Fluent, Discarding, Blend Techniques
Some that try to adopt an Agile framework (i.e. Scrum), don’t get to understand why each of the ceremonies are necessary and how they map to the values and principles in the Agile Manifesto. They begin changing it when it reflects something back to them that they don’t like. Inability to deliver something working in 1-4 weeks comes to mind. Or a daily stand up that never even is about the team self-organizing and synchronizing to accomplish the sprint goal but is just a status meeting. Or, “Our planning meetings need to be cut down in length, because they aren’t very effective, most of the people disengage.”
I think moving too fast through these stages is the equivalent of walking into a karate dujo, taking one lesson from a black belt demonstrating all the moves and then thinks they know enough. They stop taking lessons, alter the moves or don’t use some of the moves for some reason (e.g. dexterity, flexibility). Or makes up different combinations. Then they enter a tournament and can’t figure out why they are still getting the snot beat out of them.
Don’t Break the Rules (Ha) To Soon!
Please be rigid for at least a few months when taking on a new framework. Even better give it a couple of years. Many of the companies that we hear about (i.e. Google, Spotify, Motley Fool, etc…) that have discarded some parts of the initial framework they chose, spent multiple years being rigid to the framework (i.e. Scrum) and only when they understood the principles and values did they experiment. These experiments are then conducted in the spirit of moving the team or organization to realize the Agile Manifesto values and principles more fully for their situation.
Please be patient. Don’t rush through Shu (learning) and then blame the framework. Think about why you feel it is necessary to modify the framework. And then ask yourself why again and again.
Good luck out there. Would love to hear your thoughts on this.
Credit to Seph Coster (@sephcoster) for the great title. Thank you.
Additional links that may be of interest:
- ShuHaRi by Martin Fowler
- Clark Terry’s 3 Steps to Learning Improvisation (Imitate, Assimilate, Innovate)
What an interesting way to describe this!
One of the more frequent conversations I have with non-Scrum individuals is how inter-connected every aspect of Scrum is to every other aspect. The best way to come to that understanding is to embrace it as a whole and practice that way. It will take time to understand. If you move forward without really understanding the function and how everything fits together you are going to have a sub-optimal time of things. I have seen teams right out of the gate take one or two aspects of the Scrum framework, say they are doing Scrum, and wonder why its so painful.
Not only are these people and those that rush the Shu Ha Ri, hurting themselves and their team, but also the Scrum community as a whole. I have had people in my departments literally groan when I told them I was considering Scrum for their area. When I pressed on why and delved into past experiences it almost always turned out to be something that was not Scrum but was labeled as such. It took time and and an intervention to cure them in some cases. Sometimes it was easy:
Q: “You hated daily stand ups? Why?”
A: “They were an hour long”.
Scrum is a framework that allows for a great deal of variation and customization WITHIN IT. In my opinion you cannot only adopt part of it and say you are doing Scrum. When you have transcended Scrum and have entered the “Ha Ri” aspects, you are back to doing Scrum but, or something new.