Ha, Not Ready to Ri: The Shu Ha Ri Approach to Agile Development
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 too often we have seen this happen when implementing an Agile […]
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 too often we 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 we 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 we have worked with have had a bad taste in their month regarding their dip into Agile. Typically, when we dig deep enough, we find that when they tried to adopt, they rushed through the Shu Ha Ri stages of development. And even worse they may blame the framework (i.e. Scrum) and don’t want to ever hear the name again.
So, what is Shu Ha Ri you ask?
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 some Excellians were reintroduced to it during an Agile Coaching Workshop and inspired this post. 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 you can transcend the rules because you have gained the understanding why you are doing what you are doing. You have also integrated other moves from other disciplines.
- Shu– Imitate, Follow, Embracing, Learn techniques
- Ha– Assimilate, Break, Diverging Collect techniques
- Ri– Innovate, Fluent, Discarding, Blend Techniques
We think 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. The ability 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 planning meetings need to be cut down in length because they aren’t very effective, most of the people disengage.
We find this is the equivalent of walking into a karate dojo, taking one lesson from a black belt that demonstrates 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.
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!
You Might Also Like
Many organizations without any Agile experience want to immediately jump right into a fully scaled...
Your organization implemented Agile practices and saw success in delivery speed, employee engagement and customer...