Shu Ha Ri - A must know for Agile Adoption

If you are a change agent and you are helping an Enterprise or a team to move to Agile, you ought to know this Japanese martial art principle called Shu Ha Ri

Don't like reading? Never mind, instead watch the video!!!

Japanese believed that martial art learning went through three sequential phases called Shu Ha Ri. Martin Fowler & a few other thought leaders redefined this in context of Agile

Shu means following the exact practice that your Master is teaching without any variation - Follow the rule

Ha means realising the principles & theory behind the practice and learning new styles & improvements from other Masters - Adapt & learn new rules

Ri means breaking away from earlier practices and re-inventing your own rules & practices - Be the rule

Lets take the practice of Backlog Refinement meeting of a Scrum team called The TradeBull and see how they transitioned across these phases

In their Shu phase, in the first few Sprints, TradeBull implemented backlog refinement As-Is i.e. they allocated 10% of their current Sprint effort to refine the PBIs for the next set of Sprints and the team & PO discussed and refined the PBIs

TradeBull from their past Sprint experience realised that they couldn’t do justice to the backlog refinement with just 10% of the Sprint effort for backlog refinement. Also, over a date, one of the TradeBull member learnt from his girl friend, who works in a different team that they were inviting the maintenance team for backlog refinements, so as to help deriving maintainability requirements

The next day, he spoke to TradeBull’s maintenance team and learnt that the average fix time needed by the maintenance team which handled field issues of their product was very high. They realised that implementing certain debug logs will improve the average fix time during maintenance

Therefore in the Ha phase, TradeBull decided to modify their practice by

1. increasing the time spent in backlog refinement and
2. adopting the other teams practice of inviting maintenance team in the backlog refinement meeting

As TradeBull kept progressing in the Sprints, the Maintenance team was elated because their average fix time had reduced & Customer’s were happy

Currently the lead time by when the logs were implemented & the software released to Customer was 1 Sprint + 1 week i.e. maintenance team gave requirements in the current Sprint’s backlog refinement meeting, which was taken in the next Sprint for implementation & release

The Maintenance team discussed with TradeBull and asked if they can give requirements for the running Sprint itself based on their daily analysis of issues. The TradeBull team considered this request & in the interest of the Customer decided to go ahead and accept the requirements in the same sprint

So in the Ri phase, TradeBull team decided to have their own rules

1. They will accept requirement inputs from Maintenance team in two phases for the running Sprint - one before Sprint Planning meeting & the other during backlog refinement
2. To advance the backlog refinement meeting to the middle of their Sprint
3. In their current Sprint, they would allocate 3% of buffer to accommodate debug log requirement which comes during refinement meeting and
4. Continue with their existing practice of refining PBIs for their subsequent Sprints

Thus Maintenance team had the additional window to squeeze in any important requirements they came across between the start of Sprint & backlog refinement meeting

You can thus see, how TradeBull sequentially went through each of the phases

A word of caution, many a times, I have observed teams attempting to skip the Shu & the Ha phase and directly go to the Ri phase. They go ahead with a lot of Scrum-Buts & eventually fail. 

Therefore as a Change Agent, it is imperative that you ensure that the team goes through these phases & only advance to the Ri phase when they have understood the principles and sprit behind the practice