Improve Agile adoption with "Shu Ha Ri"

During my last two missions, I was involved in coaching a project team for Agile adoption. What struck me about these missions is that although both missions were very similar (same objective, same OCTO team, same team characteristics on the client side) we were able to significantly improve Agile adoption by our client by using “Shu Ha Ri”.

This article aims to explain “Shu Ha Ri”, to show how we have applied it and the benefits that it can bring.

Presentation of "Shu Ha Ri"

Originally, "Shu Ha Ri" is a concept describing the different stages of learning martial arts. This concept was applied in the Lean approach at Toyota ("The Toyota Way to Lean Leadership: Achieving and Sustaining Excellence through Leadership Development", Jeffrey Liker, Gary L. Convis).

"Shu Ha Ri" consists in three steps that a novice has to follow to acquire a skill or master a technique:

• Shu: the disciple learns the basics by following the rules laid down by the master
• Ha: having mastered the fundamentals, the disciple applies the rules but begins questioning them, understanding their subtleties and seeking exceptions to rules
• Ri : the disciple who has mastered the rules can transcend and adapt them

We have successfully used "Shu Ha Ri" to structure our mission to support Agile adoption by the project team. We chose this model because it is simple and has proven itself in the Lean approach at Toyota. In the following sections, we will detail how we did it.

Applying “Shu Ha Ri”

Before getting to what Shu Ha Ri is and how it works, we will give you some context about the two missions that we will use as examples. The first one was conducted without "Shu Ha Ri" and the second with it.

Similarities between the two missions

Considered missions are very similar:

• Same client type: medium size insurer
• Same project typet: redesign in Web technology of a Mainframe application
• Same OCTO team (same people!)
• Same team organization on client side
• Neutrality of the client's project teams towards Agile: they were not resistant but awaiting to see what Agile could bring
• Same mission objective: coach a project team to adopt Agile
• Same mission duration: 6 months

Differences between the two missions

The major difference between the two projects was the coaching approach that we adopted

Approach without “Shu Ha Ri”

In the first project, we agreed with the client to position his team members as decision makers. Each one was accompanied by an OCTO consultant to assist and coach him. For instance

• Project manager : 1 client team member + 1 OCTO consultant assistant
• Product Owner : 1 client team member + 1 OCTO consultant assistant
• Tech Lead : 1 client team member + 1 OCTO consultant assistant

In this configuration, it is the client's team which was responsible for the results of the project from the beginning.

Approach with “Shu Ha Ri”

In the second project, we managed to convince the customer to proceed incrementally by planning three deliveries of the application with intervals of 3 months. So we agreed with him to proceed as follows:

For the first delivery ("Shu" phase), Agile experts (OCTO consultants) are the decision makers of the project (project management, functional trade-offs, technical trade-offs) and Agile trainees (client's team) shall comply with decisions of experts. Therefore, OCTO team bears the responsibility for the results of this first delivery.

• Example: being in the business analysis team, in this phase I was responsible of organizing the team, of organizing and moderating business analysis rituals and of the  delivery of user stories, tests and screens

For the second delivery ("Ha" phase), the Agile experts transfer the decision making role to Agile trainees. Therefore, Agile experts position themselves as assistants to support trainees in their work and to advise them. Hence, the results of the second delivery are the client's team responsibility.

• Example: being in the business analysis team, I created a list of tasks to perform business analysis. Those tasks were distributed to the client’s team members. For my part, I wasn’t responsible of any task. However, I continued to participate in specification tasks, I warned the team when necessary and I acted when someone asked for my help.

In the third and final phase ("Ri" phase), the consultants leave the project to let the client’s team manage it.

Benefits of “Shu Ha Ri”

In the mission without "Shu Ha Ri", a perverse effect made the Agile Adoption particularly difficult. As they were under pressure for results, Agile trainees (client's team) had a tendency to cling to models and methods they knew best because it feels reassuring (which is quite natural!). Therefore, whenever we tried to introduce an Agile practice, it was followed by endless discussions where Agile experts (OCTO consultants) had to convince the client’s team of the benefit of such a practice for the project. What makes it complicated is that, for the Agile trainees, the benefit is theoretical in the sense that it is a promise when he needs certainty and immediate results. Therefore, in order to advance, the Agile expert had to seek a compromise by twisting the Agile practice (which is far from being beneficial!).

• Example: we lost a lot of time and energy to convince the client’s Product Owner and the Tech Lead of benefits of the specification and development in incremental mode (start by simplest functionalities and compexify them progressively). Indeed, they were used to waterfall project logic where everything must be specified and predicted before beginning any development. Moreover, they had difficulty accepting bringing to end-users an application without all the features (including vital and not so necessary ones). In fact, they feared the users’ reaction and it was difficult to reassure them on this aspect. Therefore, the Product Owner tended to create User Stories that were too big, hoping to implement the largest amount of features. Developers were regularly complaining about such User Stories.

As for the project with "Shu Ha Ri", the perverse effect mentioned above was neutralized. Indeed, in the "Shu" phase, Agile experts bear the responsibility of the project success. Therefore, Agile trainees have less pressure and they have time to observe and understand the mechanics and the values ​​of Agile. Moreover, they can see concretely how the Agile practices allow the team to deliver the project and achieve users satisfaction.

• Example: In our project, after the first delivery, the client’s project manager was surprised that users were satisfied with the result even if we were not able to deliver all what was planned. Indeed, users were happy to be able to use certain critical features after only 3 months and were confident in our ability to deliver new features in the next 3 months.

As a result, with this first success, Agile trainees were convinced of the effectiveness of Agile and were more confident to abandon their old practices in favor of those of Agile. This has greatly increased the efficiency of the phase of "Ha". Indeed, OCTO consultants noticed that Agile trainees were scrupulously applying principles and tools used in “Shu” stage. In addition, the client’s team began to want to push the model to see its limitations and propose process improvements. Obviously, the OCTO team remained present to answer questions and to provide support.

• Example: the development team began to master their development cycles (iterations) and wondered if it wasn't more effective to go toward a continuous-flow development model. This question interested the project manager and we decided to study it together to measure the benefits and disadvantages compared to the context and constraints of project.

Finally, the phase of the "Ri" will soon take place and everyone is confident in its success.

Conclusion

Through the two experiences I have described, I was totally convinced by "Shu Ha Ri" effectiveness. Personally I'm going to use it for any situation requiring skills acquisition (being the trainee or the expert). I strongly encourage you to experiment it (even in a private context) to see the benefits.