Position, Flow and Movement

Given some of the comments on my last post on "Why Agile, Lean and Six Sigma must die" ... I thought I'd take some time to clear up another misunderstanding in the difference between position, flow and movement.

Let us assume you've examined a line of business, starting from the point of user needs and developed a value chain. I'll assume you've also mapped this over evolution. Beyond the obvious of breaking down a system into components and the interfaces between them then there are three things to consider.

Position : the position of components simply relates to how things are connected and how visible they are to the user need. The value chain itself is a chain of needs i.e. this needs that etc. At the top of the value chain these needs are exposed as meeting user needs (i.e. customers) and can often be expressed in terms of the customer journey. This doesn't mean the lower components aren't essential but a user who wants a cup of tea doesn't care about the power provider you use to boil the water. They only care about a piping hot cup of tea.

Flow : whenever you look at a map (an example is provided in figures 1 & 2) then there are multiple flows within the value chain. These flow can cover things such as information, risk, finance and materials. Sometimes one flow is more viable than another and financial models based upon flow can be developed (see figure 3). Sometimes a flow may be inefficient because it'll have bottlenecks and improvements can be made. There's all sorts of important things to be consider from inventory to capacity to variability and time.

Figure 1 - A flow within a value chain (a TV company)

Figure 2 - Another flow within a value chain (a TV company)

Figure 3 - Analysis of a flow.

Movement : Understanding position and flow is a good start but unfortunately value chains aren't static, they evolve. Fortunately the process of evolution is fairly well defined across activities, practices, data and knowledge and there are many common economic patterns, weak signals and gameplay which can be used to anticipate and manage this. There's however little point in understanding the value chain and managing the flow efficiently if you are treating most of the components as custom built when the market treats them as commodity. You have to accept that everything in your value chain will evolve (i.e. move across the map) and therefore you might be efficiently managing the flow in your value chain but at the same time being ineffective because you're treating components in the wrong way.  

Understanding position and flow is critical for efficient provision of an in-situ situation however understanding movement and position is critical for strategic gameplay, anticipation and effectiveness. 

To give an example of this, I'll use the box and wire diagram from the previous post (figure 4). Do remember that box and wire diagrams (IT systems diagrams, Business Process Maps, Value Stream Maps etc) all have their purpose but they only show you connectedness of components (not necessarily even position relative to the user) and can only be used to analyse flow.

Figure 4 - A typical box and wire

Looking at the box and wire above. The questions you need to ask are :-

a) I outsourced B and it was a disaster. Why was it a disaster?

b) Should I outsource A?

c) What components are most directly visible to its consumer?

d) What methods (i.e. doctrine) should I use for each component? Agile, Six Sigma or Lean?

Now, whilst I can't answer these question, I can examine different flows in the box and wire (e.g. the one I've highlighted in blue is C, F, D, A). I can look at it for bottlenecks and mechanisms to improve efficiency and certainly if I have multiple box and wire diagrams then I can look for duplication. But of course, I don't know whether one of those components is representing the visible user need and hence I don't know the travel of flow towards the user unless I add arrows. I also don't know how evolved those components are i.e. if the duplicated components are suitable for provision as platform components?

Exactly the same diagram is provided in figure 5 below but in this case I've added movement represented by an evolution axis. I can now not only examine the flow but answer all the above questions.  I can even anticipate how things will change (I've added some lines for competition effects but in reality all components are likely to be moving).

Figure 5 - A map of the same process

With multiple maps I can remove bias in treatment (people custom building what is a commodity) and find not only duplication but identify those components suitable for provision as a platform.

Furthermore using the above map I can identify where we will have inertia, potential threats from disruption that can be anticipated, co-evolution of practice and even repeatable mechanisms for how I can manipulate the market (i.e. organisational learning). I can determine the appropriate methods both project management and purchasing and even determine appropriate structure. See the previous post for help on some basics or this post for a general introduction to the technique.

Hence with the above map, I can anticipate a future state (figure 6).

Figure 6 - Future State

Hopefully I won't have done the daft thing of outsourcing B but instead I will have moved from using an Agile approach to using Lean to build it (assuming I'm the one building). As for component C, then I'd probably be looking to build that as a utility service for others (ideally with a six sigma style approach) or use some sort of cloud service. With component F then I'd be anticipating to outsource it along with the hopefully already outsourced A.

I still have the same flow C, F, D, A (along with the other flows in the diagram) but the characteristics and the manner in which this flow is provided has evolved. If I'm stuck making the flow efficient using C, F, D all as products (as it used to be) then as efficient as I am, I'm likely to be outcompeted by the market. I can also see from the map that I don't really have anything differentiating me from others, so I'll probably be taking a few gambles to create components that meet others needs built on the components that I already have.

Gamble? Did I say gamble? Yes ... alas with a map, there are some things you can plan but a lot of spaces in which you have to experiment. Remember that evolution axis is determined from ubiquity vs certainty and the uncharted spaces are not only rare ... wait for it ... they're uncertain (see figure 7). Of course, that doesn't mean we can't mark on a map that we suspect something is over there in the uncharted space (a gut feel, an intuition etc). We might even give it a name, we just don't know what it really is yet or even if it'll be successful. Of course, if it is then over time it'll become more defined, it'll become more certain ... you get the picture.

Figure 7 - Plan vs Experiment.

Anyway, the point of this post is rather simple. Position and Flow can only get you so far - even if I've build a customer journey between high level needs. If you really want to learn strategic play and to become efficient and effective then you're going to need to understand Movement (i.e. how things evolve).

Remember ALL maps are imperfect and they are simply communication tools used to describe an environment. They enable collaboration, communication and gameplay but you still have to apply thought. These maps are by no means the ideal way of visualising, they are more like Babylonian clay tablets as opposed to ordinance survey. Mapping business is a field in its infancy but even these are better than no maps.

However, trying to describe an environment based upon position and flow and not allowing for movement prevents you from determining direction and applying any concept of strategic manoeuvring for both yourself and opponents. Unfortunately these box and wire concepts are exactly what most company strategy is built upon normally mixed in with SWOTS, meme copying and other story telling devices.

I cannot emphasise enough how fsck'd your company is if you come up against a player that knows what they're doing when you're trying to use old approaches. I've seen examples of vendors who've taken a beating with Government in the recent past and still haven't clocked why. This is only going to get worse for those companies if they don't adapt, focus on user needs, sell components appropriately and don't try the old "outsource everything" game. I know many departments that are getting better at situational awareness and gameplay. The days of Government being a soft touch are slowly (very slowly) disappearing.

Why Agile, Lean and Six Sigma must die ...

Every large system (whether a line of business or specific IT project) contains multiple components. Those components have a relationship with each other (known as position) but they're also evolving. 

Every components start as something novel and poorly understood - the uncharted space of the new e.g. the first telephone - and over time through demand and supply competition becomes widespread and well defined or in other words industrialised. The properties of these two extremes are polar opposites. As Salaman & Storey said in 2002, any structure needs to manage both of these polar opposites. Before you shout "Bimodal" or "Two Speed" or "Dual Operating System", there's also the issue of the transition between the two but we've covered that in previous posts.

If you start with user needs, you can map this landscape out in the form of a Wardley Map - named after me! Well, I've been doing this for over a decade now and I did invent the technique, so fair enough. What's interesting with maps is that they not only give you position (the relationship between things) and movement (how things are evolving) which is essential for any form of strategic play but you also find that different techniques and methods (i.e. doctrine) whether it's project management or purchasing are stronger at different parts of the map. None of this is new.

In figure 1, I've provided a map showing the position and movement and how maps can enable you to determine where to attack. In figure 2, I've shown how different methods (including insourcing and outsourcing) can be applied to areas of the map. In figure 3, I've provided a map with different methods applied.

Figure 1 - A Map

Figure 2 - Techniques and Changing Properties

Figure 3 - A map with techniques applied. High Speed Rail

Maps are mainly communication vehicles but they're also useful for organisational learning. However, when it comes to doctrine (e.g. techniques & methods) in IT, let us emphasise the following.

In one part of the map you'll tend you use an Agile approach (right back to the core principles, possibly with a technique like XP or SCRUM) focused on exploring the uncharted and reducing the cost of change. As Michael O. Church points out, agile is best in situations when "dealing with finicky clients who don’t know what they want" i.e. when exploring the uncharted space where no-one knows what is wanted.

Of course, as an act is explored and becomes more widespread and well defined (i.e. we start to understand it) then the focus changes. We start aiming to build a product, sometime in era of custom built examples. Whilst we may continue to use underlying techniques such as XP or SCRUM, our focus is on reducing waste, learning and creating a minimal viable product and improving measurements. Lean rules the waves here.

Of course, as the act continues to evolve becoming more widespread and defined then we're now into the world of volume operations. It's increasingly heading towards commodity and our focus is mass production of good enough which means reducing deviation. At this point, Six Sigma (along with frameworks like ITIL) rules the waves.

However, any significant project (as show in figure 3) has components in all these stages. Those components aren't static but evolving and as they become more commodity like they enable rapid development of new higher order systems. But, at any one moment in time, you'll have components at all stages and you will need to use a mix of agile, lean and six sigma throughout the project.

Of course, most companies have no map of their environment and so are forced to plummet for a one size fits all method e.g. all agile, all lean, all six sigma. All of these methods will have their devotees and so regular arguments of agile vs lean, lean vs six sigma, agile vs six sigma break out along with various attempts to create new magic one size fits all methods which combine different stages e.g. lean six sigma or agile lean or prince agile etc. 

This has been going on in one guise or another for a decade now. Suck it up. There's no one size fits all method. [Cue endless rants from agile, lean or six sigma devotees].

You need to use the appropriate methods according to how evolved the component is. Since most companies have no form of maps (i.e. no understanding of position AND movement) or confuse box and wire diagrams (e.g. IT systems diagram, Value Stream maps, Business process maps, Kaplan Strategy Maps - which all have uses) with maps then generally there is no hope of this happening. If you're going to insist on acting blindly and picking a one size fits all method then choose Lean. It's far from ideal but better than focusing on the other extremes.

Personally, I'd learn to map and use all the methods. Personally, I think the idea of being ALL agile, ALL lean or ALL six sigma should die.

I know it won't. A decade of using maps, speaking and writing articles in various publications that point out the need for multiple methods has taught me one thing. In a decade from now, I'll still be hearing people arguing over whether agile, lean, six sigma or some equivalent method is better everywhere. It isn't. It'll never be. Alas, there are two solutions to Ashby's Law of Requisite Variety in management - you either accept the complexity and manage it or you pretend that what is being managed is simple and apply single methods or simple KPIs. The latter tends to rule because the former is hard.

Before I go, some quick notes on the question of strategic thought and mapping. The two most basic properties of a map are position and movement. It doesn't matter whether this is a physical map or a chessboard, they show you where things are and how they can move. More complex maps can include other details. For example in a Wardley map, along with position and movement then you can look at the flow of information, risk and finance in an existing value chain (NB. Value Stream maps also do this but they only show flow within the value chain and not movement i.e. how components will evolve). Without position and movement though, strategic play is guess work.

Hence, look at table 1, print it out and tick off each area that your business knows well or undertakes.

Table 1 - Understanding of the Purpose, Climate, Landscape and Doctrine.

If you haven't ticked off ALL of the first seven steps then any strategy you have is most likely meme copying others. You're running blind and you don't have a hope of understanding where to attack and hence determining why here over there. I strongly suggest you throw away your strategy and replace it with the following ...

Our strategy is to try and understand what we do, for whom, why we do it, what they need and what's involved as efficiently and as effectively as possible without breaking the bank.

... or at worst, don't pay consultants for any future strategy - just click the link here. It'll auto generate you a strategy based upon the common memes around. It's useless but it's free rather than being useless and costing a fortune.

Until you can do the most basic stuff of understanding purpose, landscape (map) and doctrine (methods, techniques etc), there is no point in talking strategy. Anything you'll do is just simply shooting in the dark.

Oh, and to really rub it in, I'm going to emphasise the point about the importance of movement. I've taken a simple process diagram, replaced the terms with letters and provided this glorious BOX and WIRE diagram in figure 4.

Figure 4 - Box and Wire

Now, in the above you can clearly see the relationship between things but I've got four simple questions for you to think about.

a) I outsourced B and it was a disaster. Why was it a disaster?
b) Should I outsource A?
c) What components are most directly visible to its consumer?
d) What methods (i.e. doctrine) should I use for each component? Agile, Six Sigma or Lean?

Can you answer these? I can't. For your interest, in corporations around the world people are trying to manage stuff and answer these questions with diagrams just like the above.

Ok, I've now provided exactly the same diagram in mapping form in figure 5. No additional information was added other than position and movement.

Figure 5 - Map

Now, try answering those questions. If you need help, look at figure 2 above again. It should be trivial.

If you want to know how to organise around this. Start here.
If you're entirely new to mapping then this set of posts should help.

If you're thinking ... "is this mapping the answer!" Let me emphasise that we're roughly at the Babylonian clay tablet stage and not the ordinance survey stage of business mapping. This technique will give you a better map than no map.

Finally ... the only people who can map a business are those that operate in that business i.e. no consultants. The technique is all creative commons share alike, so you've got everything you need to get started.