A Strategy Deployment Diagram

I came up with an initial diagram to visually summarise Strategy Deployment when I wrote about the dynamics. However, while it showed some of the collaborative elements, I never felt it was sufficient, and still had a hint of hierarchy about it that I didn’t like.

More recently, while reading “Understanding Hoshin Kanri: An Introduction by Greg Watson“, I saw a diagram I liked much more, and was inspired to tweak it to fit my understanding and experience of the approach.

Working from the outside of the picture…

The outer loop shows the people involved and their interactions as a collaboration rather than as a hierarchy. Whilst levels of seniority are represented, these levels describe the nature of decisions being made. Thus the three primary groups are the Leadership Team, Operational Teams and Implementation Teams which reflect the three primary roles in Catchball, and which are responsible for co-creating and owning the various A3 Templates. The bi-directional arrows between these teams show how they collaborate to discover, negotiate and agree on the Outcomes, Plans and Actions. (Note: the original diagram had the arrows only going clockwise, which suggested a directing and reporting dynamic to me).

The three inner circles show the main focuses of each team. The Strategy Team set direction through the True North and Aspirations. The Operational Teams maintain alignment to the intent of the Strategies by making Investments in improvement opportunities. The Implementation Teams have autonomy to realise the strategies by determining and carrying out Tactics and generating Evidence of progress.

The intersections of these circles map onto the three elements of Stephen Bungay’s Directed Opportunism (from his book “The Art of Action”), and they describe the essence of the collaboration between the different groups. The Strategy Team and Operational Teams work together to establish positive Outcomes. The Operational Teams and Implementation Teams work together to define plausible Plans. The Implementation Teams and Strategy Team work together to review the results of the Actions.

Finally, the central intersection of all the circles, and the combination of all of these elements, is a continuous Transformation –  the result of everyone working together with both alignment and autonomy.

Given this visualisation, we can also overlay the three A3 Templates on top, showing which teams have primary responsibility for each.

Like all diagrams, this is a simplification. Its the map, and not the territory. The collaborations are not as separate and clear cut as it might imply. Rather, much of this work is emerging and evolving, collectively and simultaneously. I still believe, however, that it is a useful picture of Strategy Deployment as “any form of organisational improvement in which solutions emerge from the people closest to the problem.”

VN:F [1.9.22_1171]
Rating: 3.0/5 (1 vote cast)

Evolving a Workflow

Mary Poppendieck gave a talk on Workflow is Orthogonal to Schedule at Agile2009, during which she very neatly transitioned a schedule-focused view of work, into a flow-focussed view. At least I thought it was neat, so I’m going to try and reproduce the basic elements here, using my favourite agile workflow.

4 Week Time-box Schedule

workflow1

Here we have a schedule showing an average of 4 features being delivered every 4 week time-box. Each time-box is preceded by 2 weeks understanding the next features, and a release is made every 8 weeks. Its not a bad schedule. There’s a regular release every two months which is better than a lot of projects, but it could be better.

2 Week Time-box Schedule

workflow2

Now we reduced the time-box to 2 weeks, meaning that we do an average of 2 features in each time-box. This means that the preparation now takes only 1 week. Additionally, we are now releasing at the end of every time-box, which is also reduced to 1 week. Much better.

One Piece Flow

workflow3

If we continue the evolution we end up working on a single feature at a time and releasing it immediately. Each feature only takes a week to build, and preparation and release times are now down to 1/2 a week. At this point, we don’t really have a schedule anymore, but a natural workflow.

Cumulative Flow Diagrams

One of the things that strikes me about the diagrams above, is that each step in the evolution transforms them more into a smooth Cumulative Flow Diagram. In fact, in the same presentation, Mary showed the following picture taken from Building the Empire State. This is the building schedule from from around 1930, and itself looks remarkably like a CFD. Another example of how we are not inventing anything new, but can learn from other industries and successes.

empirestate

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)