Hoshin Kanri

Most organisations that I come across that introduce Agile techniques focus on a set of tools and practices that are applied at a working level only - test driven development, continuous integration, stand-ups, user stories etc. Even the best organisations that I get to work with only focus on the next level up and start to change governance processes, business engagement models, financial controls and other surrounding process infrastructure. I’ve only had the pleasure of working with one organisation where they changed the IT organisation from the top down as well as the bottom up. Guess which model was the most successful?

If we think of our IT divisions as socio-technical systems that our managers and leaders control, it becomes more apparent why any change has to encompass the whole organisation. Here’s an example of what I mean…

An Agile team have been happily working together for a number of weeks and are approaching a release of the application. In the final build the tester notices a few defects that have been missed until this point and highlights them to the developers and the customer. The developers decide that there is about one weeks work required to fix them and that the release would need to be delayed. The customer doesn’t feel that fixing the defects is worth one weeks wait so asks the team to deploy the application. Unfortunately the tester has an incentive that hasn’t surfaced until this point - they don’t get their bonus unless all production releases are defect free. The organisation has also setup the tester as the gatekeeper to production - the team are paralysed without their support. A bunfight ensues!

In this case the tester is acting perfectly sensibly based on the incentive system that has been created for them; people behave based on incentives and disincentives. Unfortunately the encouraged behaviour doesn’t achieve the best result for the team and the organisation. When Deming said that it was the role of managers to work on the system and not the output of the system this is what I think he meant.

So, how can we change this? One of the things that I’m looking to closely to help resolve these kinds of issues, and the story above is just one example, is Hoshin Kanri. Hoshin seems relatively overlooked in the Agile world and even Lean IT areas, which I think is a real shame as it’s often referred to as the tool that brings all of the other Lean tools together at an enterprise level.

I like Hoshin Kanri for a few reasons. Firstly, I’ve been told that literally translated it means ‘Shining Metal’, which I think is properly cool! Secondly it helps resolve systemic alignment issues through a highly collaborative strategy deployment process; Hoshin Kanri is to Lean organisations what the Balanced Scorecard is to Command & Control organisations.

The best description of Hoshin I’ve heard is a collaborative strategy deployment process that ensures organisational alignment downwards, upwards and side-to-side. I’ve attached a document from Owen Berkeley-Hill that I found really useful in developing my understanding and comparing Hoshin to Balanced Scorecards (Hoshin Kanri - November 2000). Owen did point out that his thinking has moved on but I insisted on posting this anyway as I found it such a useful introduction.

I think that the next Everest facing the Agile community is scaling our current success to a true enterprise level. I think Hoshin Kanri is one of the tools that can help to get us there.

Introducing Agile and having organisational alignment issues? Think Hoshin Kanri could help?