Knowing where to dig.

I occasionally come across the attitude that the work I do has no value. Managers love the workers who have been digging like crazy, but they give less credit to advice on where to dig. This photo is of a hole in a car park in Leicester where a skeleton with a curved back was found. It turns out it is the final resting place of Richard III. There is little doubt in the minds of the general masses that the heroes of the story were the archeologists who told the driver of the digger where to dig. No one is filming documentaries about the driver of the excavator who dug the hole.


Everyone has heard the urban parable of the Captain who boiler breaks and he needs to call a plumber. The plumber arrives and takes ten minutes to listen to the boiler before hitting it once with a hammer. When the bill for $1,000 arrives, the captain demands that it is broken down. “Hitting the boiler with a hammer: $1. Knowing where to hit: $999″. Its a parable about the value of experience.

Most people working in Agile Management are advocates of the Theory of Constraints. I certainly am one of those advocates, although I rephrase it to more understandable terms (which may not be pure mapping to the original):

  1. Agree on the goal.
  2. Identify the constraint.
  3. Prioritise the constraint.
  4. Optimise the constraint.
  5. Add capacity to the constraint
  6. Rinse and Repeat. ( Goto to Step 2 ).

Steps 3 to 5 are really about digging ditches. Once you have identified the constraint, it is fairly straight forward to do the rest. They just require effort and application. Step 2 is about knwoing where to dig. As a consultant, its my role to help identify the constraints and then dig the hole. As a coach, its my role to help others to learn how to identify the constraint. As a participant of the Agile Project, I contribute those tools ( like radar and X-Ray ) that can be used to identify the constraints. The two most significant tools I’ve discovered so far are:

Staff Liquidity Skills Matrix – Identify individuals whose skills are a constraint to the team.

Quarterly Capacity Planning – Identify those groups who are a constraint to the organisation.

If you want me to pick up a spade I will do, however unless we have a constraint on the number of people are willing and able to dig, I’d rather help people learn how to find the right place to dig.

Examples that break the model

Break the model is a process to identify a representative set of examples. The process involves creating a model through an evolutionary process of describing examples that otherwise would not fit in the model and effectively break it.

There are two types of example that break the model:

1. Examples that are different but have the same description in the model.

2. Examples that do not fit in the model.

To explore this concept, lets consider the inventory system for a comic book shop (like Stewie’s in big bang theory)

Our model for the description of a comic book consists of:

a. The “Title” ( e.g. Amazing Spiderman )

b. The issue Number ( e.g. “1” )

c. The price.

Examples that are different but have the same description in the model.

Consider the two photo’s below. They have the same description according to the model. Are they the same comic?


The answer is no. We discover that the condition of the comic is important. This is actually an extreme example. The comic on the left sold for $104,200. The one on the right sold for $2,750. These examples would break the model. We would need to include a condition indicator ( or Grade ) on the comic description. The model helps us compare examples. It allows us to sort the examples into piles. We can then compare the examples in the piles to see if any of the examples are different. The comparison of the examples often needs the expertise of the subject matter expert. The subject matter expert can tell the difference between two examples that a lay person may not be able to detect. The subject matter expert also knows where the bodies are buried. The SME knows the examples that are likely to be overlooked. They are aware of those examples that look the same but need to be treated differently. To illustrate this point, compare the two comic books below.

Spiderman 94 92

The one on the left is the same one with a grade of 9.4 and sold for $104,200. The one on the right is ever so slightly poorer condition with a grade of 9.2, and sold for $57,523. Only a trained expert can tell the difference. A difference worth $50,000. As fields develop, they become more sophisticated. The rare comic book industry now compares comics of the same grade. Two 9.4 comics might be judged as having “white pages” or “off-white pages” which can also have an impact on the price.

Another important point is that the differences we find between the examples are orthogonal to the model. They are things we never considered.

Examples that do not fit in the model.

Some examples do not fit in the model at all. These we have a tendency to ignore. In software systems, we would develop a manual or spreadsheet work around outside of the system. Typically this involves shoe-horning the example into the system and then managing the differences off-line. Once again, our subject matter experts will be able to tell us where the bodies are buried. From the systems perspective, it is blind to the examples that do not fit into its model.

As we are developing the model, we may explicitly exclude examples that do not fit the model. This can be risky as we may exclude examples that should be included. It is better to include them in the learning model but exclude them from the implementation model. This way we can better understand the implications of changes to the requirements.

Non-Software Models.

Not all models exist in software systems. Some exist in people (cognitive models) and some exist in markets. Making our cognitive models explicit can help us spot the differences for things we consider the same. The interesting examples are the ones that do not fit our cognitive models. The examples that have no value to us. How many of you have walked past a shop / bar / building for months or years and only notice it when you need what it sells, or a friend points it out. How often have you said “I did not realise you were here!”.

Not only does this apply to shops and the like, it also applies to people. Who is that world renowned expert who sits two desks away, but in a different team or department? The examples that make it through our filters of perception (model) have much to do with the value we ascribe the examples. As we receive information, or learn more (our filters change), we change the value we ascribe to things.

An open letter to Jabe Bloom about Purposeful and Value

Dear Jabe,

Thank you for sharing your keynote with me last week. I think we were both lucky to have JB and Greg providing questions, insight and context. I want to pick up on one aspect of the talk. The use of purposeful instead of value. I understand that the general understanding of value cannot help your studies much, but I think the more rigorous definition will be useful to you. It is the rock that Real Options was built upon.

Here is the definition of value from finance.


This simple and elegant formula (definition) tells us that Value ( V ) is a Filtration ( Backwards F thing ) on an Information Set Io to In. You will note that it has no units. The units can be financial such as US Dollars or Scottish Pesos ( Had to make it topical ). Currency is useful as a means of exchange. As a means of transferring something from one entity and another.

The units could also be something internal like the “Jabey”. The “Jabey” is an internal currency that is never articulated. The “Jabey” is not used to exchange things between entities. We use the Jabey (which does not really exist) to make internal decisions, often subconsciously. What is it worth to speak to a loved one in “Jabey”?. It costs $5 to call that loved one. What’s a “Jabey” worth in US Dollars? The exchange rate between the “Jabey” and the US Dollar is constantly in flux, though we may fix some exchange rates. The constant flux is from the arrival of new information ( Io to In ) but also from changes in the way we think and feel ( changing of the Filtration Fn ). My goodness, this value concept even incorporates behavioural economics.

This constant changing of the filtration function means that the value can change even if the information set is the same. This means we have to modify our equation to cater for this shifting filtration function.


What is most glorious about this equation is that the filtration function co-evolves with information as it arrives. The purpose of Feature Injection is to spot information that should change the filtration function… but doesn’t.

The great thing about this formula is that it can be plugged into an infinitely complex network. Inefficiencies in the network will be revealed as arbitrage opportunities.

This equation is a hop, skip and a jump away from the formal definitions of Real Options and Feature Injection. < Editor’s note: You have to invent a new mathematical term… “Is better than” to describe Real Options >

So tell me, can “purposeful” give you all of this richness?

Your friend


Cynefin and the Business Analyst / Product Owner.

Its common to hear the “We need a UX expert” on our project, or more likely “We don’t need a Product Owner / Business Analyst on our project”. Its much more nuanced than that. First, lets stop talking about projects and treat them for what they truly are…. investments. Someone is investing time, money or expertise. They hope for a return, or more probably expect one. So when considering an investment, it is useful to consider which domains of the Cynefin framework the investment falls into before consider what is needed. Note that I said domainS (plural), and not domain (singular).

Simple / Obvious


In the simple or obvious domain you don’t need analysis or product management. Much of enterprise software falls into this domain. “I want this report but with this extra field.” The implementation pattern that Dan North calls “Ginger Cake” says it all really. The requirement is simply stated. This is the domain where inexperienced developers can wreak havoc with “Copy and Paste Coding” rather than refactoring the code so that it only exists in one place. Subsequent COPC leads to ever increasing complexity until the code ends up in the complex domain where the impact of changes is unknowable. (Note that the code does not fall into chaos because multiple safe to fail experiments can be run until the desired outcome is achieved.) Complex and Complicated code is likely to be written in a more elegant manner as more thought has to go into it.



This is the realm of the Analyst and the Expert. This is the domain where the investment benefits from someone with Analysis Skills working out what is needed. From my banking background, this includes things like new Regulatory Requirements, New Products, Adding or Amending Taxes. The Outcome is known and the purpose of the analysis is to identify the changes necessary in all systems. The interesting thing about this domain is that it is characterised by a lack of choice for the users. The users have to use the system if they want to keep their job. I want to use a spreadsheet so I have to use the corporate standard, normally because there is additional code and macros I need to use.


photo 3

This is the realm of product management. This is the realm where Data Scientists and UX Specialists come to the fore working together to create statistically viable multi-variate tests. Multi-hypothesis Safe to Fail experiments as Dave Snowden calls them. A portfolio of tests that includes one hypothesis at odds with the rest. Imagine several different screen layouts that make it easier for the user to achieve a specified task, and one that makes it harder. The harder option may activate “System 2″ and give the user a more pleasurable experience, which is why it is there. The complex domain is characterised by the non-functional requirements… Performance, Cognitive Load, Ease of Learning, Risk. These come to the fore when the user can choose how they complete a particular task. How do I keep in touch with my friends and colleagues?



OK. So no one really knows for certain. We can make educated guesses but there is no way to even test a hypothesis to tune our understanding. This is the realm where wisdom of the crowds comes to the fore. We want our analysts, experts and product owners to come up with an independent hypothesis and the answer is probably somewhere near the average.

The kind of questions you have are “Why are our customers leaving us?”, “What is the next big thing?”. They are the questions we ask when we can no longer feel the world beneath our feet as a business. Questions that come when the market shifts.

Sometimes we are going to get it wrong and have to play a game of catch up. In which case it might be nice to have some Real Options to help us catch up faster. This is the time that we realise a mono-culture is detrimental to the future of the organisation, and having a few heretics around the place is of huge value if we need to scale our experience. Many organisations fail with Agile because they do not have enough employees deeply engaged in the community to act as pilots steering them between the ice burgs.

Chaos sometimes comes from total choice to the user. How do I spend my free time? When I’m connected the interweb? And when I’m not? Getting them to chase after the football* at the birthday party long enough for me to perform some safe to fail experiments. If only someone would get rid of the rugby ball.

The implication for Business Analysis and Product Management

Each investment can be different. One investment might be to increase the network (Marketing), another might be to increase usage or conversion (Product Management), yet another to introduce a new tax law because the government want a slice of our success (Analysis). Then we need to improve the UI our employees use to improve speed and reduce errors (Product Management). Then we need to find a new market to play in (The Crowd) and then the CEO wants to add some new graphs to the investor reports (Ginger Cake).

If you are an analyst or product owner working on simple requirements, you are adding no value. Even worse, you are adding delay. You are a worse than a waste.

If you are iterating through a complicated problem, you are incurring unnecessary transaction costs and taking longer than you should. Your duration will be much longer than it needs to be.

If you are analysing complex problems hoping to identify the ideal solution, you will take significantly longer to find the optimum solution and the reality is you will find a sub-optimal solution and stick with it until your competition eventually steals the world away from you. You are like a mad man fighting the wind with a sword. A modern day King Canute.

Finally if you are trying to create hypotheses, or analyse in a Chaotic environment, you are simply blind to the world around you. Like a starving man digging coal with a golden spade. You are disconnected from Reality, a modern day Silas Marner.

An investment (Project) may involve a number of these. A portfolio of investments (A product or an organisation) certainly will. Its no longer a case of this approach being the best or that approach being the best. It a case of understanding that each investment might need a fundamentally different approach or even a different set of approaches. If you only have a hammer, every problem in the world starts to look like a nail. If you don’t understand the different approaches, you may be bashing your head against a screw.

Anyone who tells you they have the perfect tool is deluding themselves as well as you. Build your toolkit of options, and always be on the lookout for new tools that reveal a context you do not understand.

*Note for American readers. Soccer is a word made up by the English to help us spot Colonial Spies.


Viewing the Scottish Devolution Debate through the Cynefin Framework

A few nights ago I watched the debate on Scottish Devolution with my two boys. They are interested in this historic decision and were keen to discuss the debate.

I used the debate to help them understand a little of what I do at work, namely the Cynefin framework.

Scottish Devolution is a complex situation. No one knows whether it will be good for Scotland (and Great Britain) or otherwise. When considering whether its a good thing, we won’t find out for a generation or two…. Its that big a deal. Think back to Ireland joining the Euro. For years, Ireland was one of Europe’s fast growing Tiger economies. Then the credit crunch happened, and Ireland struggled within the Euro. I do not know whether Scottish Devolution with work or not, and I do not think anyone else does either. That’s the thing about complex situations.

That said, there are aspects of Scottish Devolution that are simple, and those that are complicated.

A simple aspect is whether Scottish people want more independence from Westminster. Its simple that Scotland can use the British Pound or any other currency including the US Dollar and the Euro.

There are complicated things that can be analysed or resolved with help of experts by looking at how similar problems .

Will Scotland need to create a physical border between itself and England? Will joining the EU require Scotland to join the Chingen agreement that allows Europeans to move between countries without passports.
If Scotland creates a more beneficial and successful health service, how will they ensure that hoards of English don’t cross the border to make use of the service?

There are complex problems such as what currency and mechanism will Scotland use?
Use the Pound or another Currency.
A Scottish Pound Pegged to the Pound, Euro or US Dollar.
Co-manage the pound with the Bank of England. This is not only Scotland’s decision as the Bank of England’s responsibility is to manage the Pound for the benefit of Great Britain, and Scotland would not be part of Great Britain.
Blah, blah, some other thing.

The interesting thing about the debate is that Alex Salmond was making simple arguments, and Alistair Darling was making complicated and complex points. Since the time of Lenin’s success with “Peace, Land, Bread!”, politicians have known that electoral messages need to be simple, simple, simple. This is why the Sun newspaper is so powerful and hire some of the best journalists, it keeps things simple.

So from looking at the debate using Cynefin, the big question I had was, why isn’t a seasoned politician making things simple? Why isn’t he pointing out that Westminster was run by Scottish Lawyers? Unless he’s hedging Labour’s bets. If the “No to independence” win, then OK. But if the “Yes” vote win, when the inevitable problems occur (There are bound to be at least teething problems rebuilding Hadrian’s Wall) he can say “I told you so” and Labour will see a resurgence in Scotland.

Of course, if Scotland devolve and we build a wall, the Cornish might want to go next. If so, we will need to rename the conference to “Agile across the Breach”.

Sailing – Complex or Complicated?

I was lucky enough to meet Dr Alistair Cockburn at the first Agile Development Conference in 2003. He “rebooted” my brain in a bar. The next morning I asked him what book I should read. Without hesitating he recommended “Situated Learning” by Lave and Wenger. I read it a year or so later. A heavy book but brilliant. It introduces the concept of legitimate peripheral participation which is similar to an apprenticeship.

I’m currently on holiday with my boys and they are learning to sail. They wanted me to teach them. The first day we listened to the refresher course being given to those who had lessons on previous years. The training was on the beach in a mock up dinghy without a sale. They were learning how to tack (turning by going into the wind) with one of the students simulating the wind by moving the boom. The key skill seemed to be getting the right hand grip so that the sailor could easily pass the main sheet from one hand to the other when they tacked. On previous holidays I have always seen a blackboard with arrow representing the wind to explain the different points of sail. The instructor was great and helped me pick out a boat that I could easily control with both of the boys in it. Safety is obviously the first priority, and we took it out for a spin.

The first skill they had to learn was balancing the boat. Where to move when the wind changed. The next obvious thing to learn was how to spot a gust of wind (a dark patch on the water) or a lull (smoother water), so that they could get ready to move. I taught them to steer using the main sheet* and the centre board. They had a go at steering with the main and they are constantly adjusting the centre board at my command. When the wind blew up I was able to instantly take over the main as I had a hand on it at all times. It struck me that learning to sail this way is a classic example of legitimate peripheral participation. Their balancing of the boat by leaning out, and the raising and lowering / raising of the centre board are real work. They are also learning craft like spotting gusts and lulls. They are also close to the other tasks like steering, and they are learning what is involved in tacking and gybing. This is Legitimate peripheral participation and I realised it is a fantastic approach when context dominates the practice. The three days we have been out, the wind conditions have been different and changing, and we have used two different classes of boat.

By contrast the shore based learning stripped away context entirely. White boards showing wind models and forces. Grounded craft with people simulating wind. Complicated learning strips away context. It shows you skills that are needed with certainty. One thing is certain, the hand grip I use is nothing like theirs and it doesn’t seem to matter.

I think this explains why Real Options and Feature Injection are not as popular as other techniques. Both are complex tools for resolving uncertainty, and the problem with uncertainty is that it is uncertain. They do not lend themselves to classroom training where the context is stripped away. In fact, the problem is that they are tools for managing context. If you want to learn how to do real options, the best approach is probably legitimate peripheral participation.

It also shows the dangers of trying to learn using the wrong approach. Whilst classroom training will appeal because it ensures coverage, it may cover the wrong skills. You run the risk of learning the wrong things. As a result, you will have a false sense of competency. You will know how to hold the sheet in your hand but you wont be able to spot a strong gust of wind. Ask yourself this. How many times have you been on a training course and applied almost none of what you learnt on the course? You were probably attending a course to learn the complicated things and not the complex ones. Complex skills are best learnt on the job from practitioners rather than in a classroom from thought leaders.

So is there a role for classroom training for complex subjects? The answer is a resounding yes. Classroom training is good for helping you achieve a state of conscious incompetence in a complex subject. You know a skill or tool is available and you understand its value. The transition from conscious incompetence to conscious competence is probably best learnt using legitimate peripheral participation.

*The main sheet is the rope that pulls the sail in.

Capacity Planning

Capacity Planning is a process whereby an organisation comes together to agree on what they are going to focus on in the medium term. There are two outputs from the Capacity Planning process:

1. An ordered backlog of initiatives (MVDs) that the entire organisation agrees on.
2. A list of the constraints and options within the organisation.

The Capacity Planning does NOT produce a plan or schedule of work.

The purpose of Capacity Planning is to provide the organisation with focus. To agree a backlog based on the constraints that exist within the organisation. Rather than determine the capacity of the organisation based on its headcount, the capacity is based on the capacity of each group within the organisation.
Without an organisational backlog, there is a very real chance that the organisation will end up with too much work in progress because each group will seek to develop their own locally optimised priority.


The start of the process is to create a roughly ordered list of Minimum Viable Deliveries (MVDs*). This provisional list is then pruned to create a list that is probably about twice the size of the eventual backlog. I call this a list of unicorn horns as it little to do with reality.

The groups are the set of Scrum Teams that look after a particular system, service, component or function within the organisation. In fact, any potentially limited resource that needs to participate in the delivery of an MVD.

The (product) owner of each MVD then engages with the product owners working with the groups. The groups create an Epic for each MVD they need to contribute to, and provide a SWAG, a Sweet Wild Assed Guess. The minimum effort required is that the group’s product owner makes up a SWAG. It would be too much to involve the team in a story point style estimate (even if bulk estimation is used) as they are only needed to help order the backlog and identify constraints. They are not a commitment by the team. The units for a SWAG are team weeks, the work that a single “Scrum” team can do in a week. One of the main reasons for the SWAG is to ensure that there is engagement between the MVP Owner and the Group’s Product Owners, To ensure that the groups are aware of any work that may be required of them in the medium term.

You will probably want control reports to help product owners spot any gaps.

Each group calculates its available capacity. The default is the number of weeks in the period multiplied by number of the “Scrum” teams in group, multiplied by 50%. The 50% is based on the work of Todd Little.

<strong>Capacity Planning</strong>

Capacity Planning should involve all key decision makers. If any are missing they may go outside the process to get their MVD done.

Now that you have the ordered list of MVDs, you go through them in order. For each MVD, you check to see if there is enough Capacity in each of the groups to deliver all of the Epics in the MVD. If there is enough capacity, the MVD is included in the backlog and the remaining Capacity of the groups is reduced by the amount on the Epics. Whenever the Capacity of a group becomes zero, the group is identified as a constraint. If there is not enough capacity in one or more of the groups, then the following can be done:
1. The decision makers decides to deselect one of the MVDs that has already been selected in order to free up the capacity.
2. The MVD can be reduced in scope. Theoretically it should be impossible to reduce something that is minimal but given the choice between nothing and something, the MVP Owner will find a way to shave some functionality off.
3. The MVP Owner and Group Owner can defer the decision to reject the MVD by looking for additional Capacity.

Eventually, it will not be possible to do any further MVDs as they all rely on groups that have run out of Capacity.

You will find that about 20% of the groups will be constraints, having used all of their capacity. About 60% will have some work on the Corporate Backlog, and 20% of groups will have no work on the Corporate Backlog. This list is gold dust for the IT management team.

How the spare capacity is allocated will be the subject of a subsequent blog post.

You now have a backlog agreed by all the key decision makers, and the list of constraints in the organisation. You have done step one and two of Theory of Constraints, namely Identify the constraint, and prioritise the constraint. The rest is easy from here on in.

* I have deliberately avoided defining an MVD. Its the smallest piece of work to deliver value.


Get every new post delivered to your Inbox.

Join 58 other followers