Wednesday, July 02, 2014

Agile, Agile ... everywhere.

I'm a huge fan of agile techniques (particularly XP & Scrum). They're very specific methods designed to deal with uncertainty and change whilst maximising the benefit to the customer in terms of achieving their needs. However, it's not a universal method i.e. certain classes of problems are not ideally suited to agile techniques.

I'm also a huge fan of six sigma, it's a specific technique designed to deal with reducing deviation and waste in a mass repeated process. However, it's not a universal method i.e. certain classes of problem are not ideally suited to six sigma.

I'm also a huge fan of lean, it's a specific technique designed to reduce waste and maximise customer value. However, it's not a universal method i.e. certain classes of problem are better dealt with by agile or by six sigma.

I do enjoy listening to agile, six sigma and lean fanatics rip shreds out of each other on why their technique is the right one, especially when it comes to large complex projects. I usually jump in with the statement "you're all right and you're all wrong" which at least paints a target on my back for all of them to shoot me down with cries of "you're wrong". It's one of the rare moments they do tend to agree with each other before they get back to infighting about why their approach is better.

I've said the same for the best part of a decade, I see no reason to change. I always start with a map.

Figure 1 provides a hypothetical map (it is based upon an existing large project map within UK Gov).

Figure 1 - a hypothetical map.

There are several things to note with the map.

1) The map starts with user need i.e. the customer. It doesn't start with shareholder value or how you want to make profit but instead the visible user need that you wish to provide. It assumes that meeting user need is the route to creating value.

2) The map consists of chains of needs i.e. Customer needs B, B needs C, C needs D and so on. The further you get away from the customer the more invisible the components becomes to the customer. In other words, a customer for a tea shop needs a cup of tea. Now obviously power (for the kettle) is an essential part of meeting that need but it is an invisible component to the customer. As the supplier you however care about power. Hence the map has one axis of value chain from visible to invisible with a specific focus on the user needs.

3) Value chains alone are fairly useless for strategic planning, gameplay, risk mitigation and management because they have no concept of change.

4) The second axis of the map therefore reflects change and the process of how things evolve due to competition. In the above I've added the classifications for activities (genesis, custom built etc) but I can equally add data, practice and knowledge as they evolve through an identical pattern.

5) The map can be as coarse or fine grain as you need it. The components shown can be broken down into subcomponents. 

6) The accuracy of the map improves as you involve more people with experience of the business / system etc. This reaches a plateau normally around 5-10 people. Effective mapping requires people with direct experience which means that only people within a business can map it. Consultants don't help you.

7) The map is not static as everything is shifting from left to right due to supply and demand competition. This can be manipulated and such manipulation is an important aspect of gameplay.

8) As a component evolves, its characteristics change from the uncharted space (the left hand side) where it has properties of chaotic, uncertain & unpredictable to the industrialised space (the right hand side) where the same component now has properties of order, known, measurable etc.

9) The uncharted space is where we're focused on differentiation & experimentation. The industrialised space is where we're focused on repetition and operational efficiency.

10) The techniques needed to manage these two extremes of uncharted and industrialised which have polar opposite characteristics are different. Agile is strong in the uncharted space but weak in the industrialised compared to six sigma (see figure 2).

Figure 2 - Which method?

11) If you have a map (as per figure 1) you can then apply the right methods and techniques to components (see the legend in figure 1).  It turns out that understanding the landscape (i.e. good situational awareness) through the use of maps is essential for avoiding one size fits all and the risks associated with it (e.g. cost overruns through outsourcing activities which will change)

It is important to break systems down into components (see USAF FIST - Fast, Inexpensive, Simple and Tiny), to apply the right methods (Agile, Six Sigma and Lean) and to understand that components will evolve causing a change in applicable methods. It also turns out that mapping is useful for comparison between competitors, strategic planning and organisational learning but that we can leave for now.

This approach is brought to you courtesy of 2005.

For the fanatics, well ... they'll probably continue their arguments for another decade with various attempts to combine methods to make the perfect method. Good luck in combining opposites into a single technique.

Wagile etc - waste of time. Oh, I can see I'm going to get shot down for that as well. Must go and find my albatross costume.