The Shu, Ha, Ri of Scrum

Shu Ha Ri „is a Japanese martial art concept, and describes the stages of learning to mastery.“ (see [1])

Aikido master Endō Seishirō shihan stated: „It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebearers created. We remain faithful to the forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.“ (from [1])

Shu-Ha-Ri in Scrum

These learning stages can be applied to Scrum, too. A team starts with Shu. It practices Scrum by the book: the flow with the roles, the meetings/ceremonies and the artifacts. Premature adaptations to Scrum in the Shu stage often lead to the famous ScrumBut situations (see [2], [3]). A team enters the Ha stage only after it has shown its ability to use Scrum as it was intended and has achieved a deep understanding of the spririt of Scrum. Then it may (and I think it should) adapt Scrum on their understanding of the spirit of Scrum. After a team has been in Ha state for a probably long period of time it may enter Ri and dismiss all rules.

From Shu to Ha

Two interesting (and interrelated) questions arise here:

1. How do you know that you have practiced enough in Shu state and you may enter Ha state?
2. What are typical adaptations for Scrum in Ha state?

For question 1 you could use the ScrumBut test defined by Jeff Sutherland on the base of work from Bas Vodde. Another option would be the Scrum checklist from Henrik Kniberg. Both focus in the practices and my miss checking the understanding of the spirit for Scrum but as a starting point both seem reasonable. At least if you score badly you can be pretty sure that you should practice more. If you adapt Scrum without having it mastered you normally end up with the so called ScrumBut (see [3]) – something that is similar to Scrum but only reveals a fraction of the possible improvement. Typical ScrumBut adaptations move in the opposite direction of the Agile Manifesto (see [4]) and the principles of Scrum. These are examples I have seen:

• We don’t have that much time for talking face-2-face. Therefore the Product Owner creates a detailed specification of what has to be implemented.
• We had problems that the Product Owner won’t accept the product increment during the Sprint Review. Therefore he has to comply to detailed checklist for new requirements.
• We do the testing after the last Sprint of a release with a seperate QA team. Just to be sure.
• We don’t have real users/customers in the Sprint Review because we want our product to work for thousands of users and not only the few that would be there.
• The Product Owner does not participate in the Sprint Retrospective since that would discourage the team from speaking openly. During the retrospective the team creates a list of things the Product Owner has to change and the ScrumMaster has the job to force the Product Owner to comply to the list.
• The team isn’t committed to the Sprint Goal and gets distracted from the project by doing other tasks (like preparing a presentation for the boss).
• The Sprint Planning lasts far more then the recommended max. of 5% of the Sprint duration since the team tries to estimate the Sprint Backlog very accurately to guarantee that they would deliver the whole Sprint Backlog.
• The team members don’t participate in the Sprint Reviews to save costs.

Don’t get me wrong. I totally understand the problems that occur when a team/company starts using Scrum. And during the transition it is often neccessary to do ScrumBut adaptations – and that is OK if you work on removing the Buts.

For question 2 I have seen very different things but I think there is a pattern. Teams in Ha state tend to work more closely together and do things more often, even in a continuous flow style. Some examples I have seen:

• Do the Daily Scrum every 2 hours (and change pair partners in the same rythm).
• Do the Daily Scrum continuously during the day (an observer may not even notice that you are doingDaily Scrums).
• Do the Sprint Planning in only 15-30 minutes and only talk about the Sprint Goal (create user stories and tasks just-in-time during the Sprint).
• Shorten Sprint cycles from weeks to days, to one day or to two hours. Notice that this is not only a question of releasing something. You also need to collect feedback and adapt to it in this short time frame.
• Release within the Sprint and  do the Sprint Review on feedback of real users using the live system. (The definition of done would then include „released“, „feedback from live users collected“)
• Working with Single Piece Flow (the whole team works on the same single story until it is done).
• Stop using timeboxed Sprints. This is a tricky one since there is the danger of just stopping the Sprints because it feels more comfortable that way. Often the Sprint constraint is replaced with another constrain, like in Naked Planning (no Sprints but Single Piece Flow and release after every story/MMF).
• Product Owner und Development Team write all user stories together.

But: If you just copy things from the above list you are definitely not in Ha state, you are still Shu! The point with Ha is that you create an innovation from practicing. But it can and should be part of advanced practicing to experiment for a defined period of time (e.g. one Sprint) with unusual things.

From Ha to Ri

There are very few – if any – people in martial arts that reached Ri level. I wouldn’t expect to reach Ri level in agile software development before doing it a really long time. I don’t think I have seen a Ri level team in the 11 years I am in the agile community. Therefore I can’t say much about it. I would expect absence of any regular meetings, roles and artifacts (except the product) and creating a very successful product in a sustainable way.

References

1. Wikipedia article about Shu Ha Ri: http://en.wikipedia.org/wiki/Shuhari
2. My presentation about ScrumBut and Shu-Ha-Ri (in german): http://www.slideshare.net/roock/scrum-but-agil-aber-xpdays-germany-2010
3. ScrumBut from Ken Schwaber: http://www.scrum.org/scrumbut
4. Agile Manifesto: http://agilemanifesto.org