Author Archives: theitriskmanager

About theitriskmanager

A IT programme manager specialising in delivering trading and risk management systems in Investment Banks. I achieve this by focusing on risk rather than cost. A focus on costs can lead to increased costs.

Starboard! It Greg Brougham about to tack.

Dear All

Please welcome Greg Brougham ( @SailingGreg ) to the itRiskManager family of blogger.


Greg is an experienced IT Risk Manager with an amazing knowledge of the Cynefin framework. Check out his Cynefin article in Infoq. Greg was the person who explained the practical usage of Cynefin that lead to my taking the course.

Welcome aboard Greg.



A tale of two Feature Injections ( A Cynefin tale )

Earlier today I listened to Liz Keogh describe Feature Injection and state that “Feature Injection is a useful model but it does not work in practice”. The Feature Injection Liz describes is nothing like the Feature Injection tools I work with. The one Liz describes is a way of breaking down projects.

To differentiate them, from now one, I’ll refer to the one I use as “Value Mapping”**. I will also describe how you can use it relating to the Cynefin framework.

The key differentiator in Cynefin is between outcomes that are certain and outcomes that can only be known in retrospect.

If you are dealing with a product where the user has choice as to whether they use it, you are almost certainly in the complex or chaotic quadrant. In complex, you need multiple safe to fail experiments. Feature Injection Value Mapping can help by forcing you to look at the value to the user and the organisation. Once the value is better understood, you can identify a number of options (hypotheses) to deliver that value (Those multiple safe to fail experiments). You can then use feature injection Value Mapping to identify the dependencies needed to deliver the value and the options to deliver them. Value Mapping in this usage is very similar to Impact Mapping.

If you are dealing with a product where the user has no choice to whether they use it, you are probably in the complicated quadrant where enterprise software hangs out. You can use feature injection Value Mapping to help the user find the value and then get them to draw the output they need from the system to deliver the value. You can then use Feature Injection Value Mapping to identify the delivery options. One extra point, in enterprise software land you often do not want to specify the user group in advance.

From experience (been using it for a decade now), people on projects tend to zoom in on complicated problems like clever maths and stuff. Value Mapping is great for quickly surfacing complex issues such as necessary changes to business practices. Complicated problems are much easier to risk manage than complex ones… you just need to do analysis or find the right expert.


** A name that Dan North came up with.

Say hi to Tony, and play nice people.

Hi All

I’m pleased to announce that Tony Grout ( @tonyGrout ) will be join me as a blogger on the

Tony and I have been working together for the past year. He has been my partner in crime as we use Theory of Constraints and a Risk Management based approach out to support an Agile Roll Out at Scale. Before his important role as Head of Agile Transformation at Skype, Tony had an important Agile job at IBM where he learnt about the importance of data and risk.

All the best


P.S. He particularly likes it when people leave snarky comments on his posts, especially about the fact that none of the stuff he talks about has anything to do with Agile.

Learning and Risk

How do people learn? Take a minute or two to write down as many ways you can think of.

Now consider the Kolb circle of learning. Below is the way I interpret the Kolb model.


Now see how the things you thought of fit into the different styles of learning.

Observation : Reading, Watching others, Watching videos, Attending lectures, ….

Modelling : Creating a model to explain the idea you’ve encountered.

Experiential : Doing the thing, pairing. In Nike terms… Just Do It.

Reflection: Talking to others to discuss the learning subject.

Have you ever thought about the risk associated with different learning styles.

From the individual’s perspective, observation and modeling are the safest options. No one need know you are learning a new subject. You can hide under the duvet reading the book by torchlight. There is also very little chance of failure if you don’t actually try to do it.

Experiential learning can knock you back if you find you are not as good as you thought. If you take hours to download an IDE, when you thought you could dance around the code within minutes. That first, ten line, program in Pascal that generates twenty pages of errors when you forget the word “program” at the start. The two hour hunt for a missing semi-colon.

Reflection can be scary as you expose your potential ignorance and naivety about the subject. Especially if the class expert / bully ridicules your mistakes.

From the team or organisation’s perspective, experiential and reflection are the safest options. Experiential is good because the first thing you do is a simple program like “Hello World”. You then try and do something real that reveals your “… in 21 days book” don’t hack it and you hit Bing ( or Google ). Thirty minutes later you solve it or are e:mailing someone to ask for help (Its never anything profound, normally its syntax). You pick another problem to solve, you hit a snag, and before you know it, it sparks an insight that inspires you to write a blog that evokes a response from world experts. You are a world expert* in approximately 0.0001% of the subject and are completely unaware of 99% of the subject. You also have a healthy respect for the subject and the depths of knowledge required.

*An expert in something no one else in the world will ever use, or care about. That’s the beauty of context.

You discuss your successes and failures with your colleagues and friends and anyone vaguely interested. You make a joke about your failure and tell everyone. The joke travels and you inoculate your team and possibly your organisation and community against making the same mistake. The guys who are reading books share what they learned, and guide you to the right books to read. Everyone respects each other for the value they bring, especially the world expert in 0.0001% of the subject.

There is a risk line I draw on the Kolb Model.

kolb risk line

On one side of the line is safe learning for the individual in a culture where a fear of failure is dominant. A risk averse culture.

On the other side of the line is the place where the organisation needs learning to feel good. Not every individual needs to be on this side of the line but the organisation needs a healthy proportion on both sides to ensure that the risk associated with learning is managed effectively.

Just in case you think this is new, Kaplan of Organisational Learning fame said the most important factor in the success of creating a learning community was the leadership’s attitude to failure.


If you find yourself in a culture where no one turns up to learning sessions that are challenging or controversial. A place where leaders create fear or conflict or disrupt learning or make it hard to learn in the way you want…. Run! Run fast!… to avoid the blast radius as the company implodes. Your culture is sitting on top of problems that you do not want to acknowledge. Problems that will blow it up sooner or later, and take the company with it. <Cynefin>Chances are you are in a complicated culture.</Cynefin>

Cynefin as a filter of perception. – Part One of N

For the past few months I’ve been studying and practicing (Praxis) as I move from conscious incompetence to conscious competence about Cynefin (A journey that I’m starting rather than finishing). I treated myself by watching every video of Dave Snowden, John Seddon and Don Reinertsen I can find on vimeo, youtube and infoq. ( Check out wonderful Anthony Green’s playlist on youtube. ). I heartily recommend watching as many of Dave Snowden’s videos as you can. Dave is a bit like Eddie Izzard, the jokes are the same but the delivery is different and as a result fresh. It also means the emphasis is different and you pick up something different from each video. I took his course last year in two sittings because it is modular in nature. I think there is benefit in seeing the whole thing in one go so I’ll probably take it again at some point.

When I originally encountered Cynefin I thought it was a model to classify problems and situations. At some point the penny dropped and I realised it is more a filter of perception with much broader application. In particular you can use it to classify behaviour of agents, people, cultures and organisations. A bit like learning models, people and cultures have preferences when it comes to the five quadrants of the Cynefin model.

These days, most organisations are operating in a complex or chaotic world. Although some situations are obvious (the new name for simple) or complicated, the situations are realistically only those where the organisation can control the outcome (by defintion). The model divides the ordered and the unordered. I prefer emergent to unordered. I also think of the divide as certain and uncertain. From our experience using real options, we know that people would rather be wrong than uncertain. This means that we have a strong in-built preference for certainty over uncertainty, we have a strong preference for obvious and complicated problems to the extent that we will see complex and chaotic situations as complicated ones. The links between Cynefin and Real Options are not circumstantial. Dave used Real Options in the creation of the Cynefin model a decade before Olav Maassen and I started talking about them. ( I urge you to read the paper Dave wrote on Real Options in 1857 ).

Once I realised this I started to see some really interesting behaviours and memeplexes. I have a preference for chaotic and complex situations as I find them easier to solve than complicated ones. Here are some of my observations to date.

Those who crave certainty love hierarchies. Experts love hierarchies as their expertise is formally recognised. If not, they have a certain path to recognition. Those who do not want to be experts can defer to experts. The experts can help them convert complex or chaotic into complicated problems by stripping away context ( and hence uncertainty ). As problems travel up a hierarchy, knowledge of the context is lost or ignored until they become general enough for an expert to be able to opine. The epitome of the complicated quadrant is the “Thought Leader”.

Politicians are masters of the obvious domain. They take complex and chaotic and convert them into simple problems with simple solutions. They also know that they will be out of political office before they can be held to account. For example, Global Warming, the solutions are complicated but the implementation of the solutions are complex/chaotic and much to do with local versus global political aims. A complicated problem that politicians have turned into a complex/chaotic problem for political reasons. Politicians should implement multi-hypothesis safe-to-fail experiments but that removes the politicians from the equations. The leity do not perceive the difference between complex and complicated, this is the realm of the high priest.

People with a preference for complex and chaotic situations favour self organisation and social networks. Communication in networked organisations is much more effective than efficient. Complex problems need collaborations between parts of the hierarchy that typically are not designed to work together. Communication in hierarchies to solve complex problems requires information to flow up the hierarchy which strips off context which is all important. It is also slow. People and Cultures who prefer complex situations also have a preference for flatter organisations where communication across and up and down the organisation is faster.

A culture that is moving from complex to complicated will see the introduction of more layers in the hierarchy as effectiveness is replaced by efficiency. In addition, the culture will discourage communication that by-passes the hierarchy unless through established social networks. Meetings in complicated cultures tend to be bigger, whereas meetings in complex cultures will be more ad-hoc and managers will defer to subordinates with more detailed knowledge. In complicated organisations, meetings will be dominated by more senior individuals. In complex organisations, meetings will be facilitated to ensure that those with the most pertinent information speak about on the problem.

A culture that is moving from complicated to complex will see an erosion of the hierarchy. The CEO will “Go to the Gemba” to acknowledge the cultural importance of front line workers and their superior knowledge. Town halls will be be more spontaneous and less likely to be formal. Communication will be inconsistent and chaotic, and workers will be expected to work based on principles and commander’s intent rather than to be told what to do. As such, there is more risk they will do the wrong thing. People will respect the bandwidth of senior members of the community. They will only communicate if necessary but they know that they have the option. People in complex and chaotic situations are respected for their ability to do things. Respect is afforded by relaying stories of daring deeds and acts of greatness rather than qualifications, publications and accolades (Side note. This explains my unease at being a fellow of the Lean Systems Society. None of the people have worked with me). The epitome of the complex world are “Trail Blazers”, those who travel beyond the map and come back with scraps of maps on paper to show the way. There are lots of them and their names tend to be lost in the mists of time (Historiography)

The opinion of experts (Hippos) is more valued in a complicated culture. After all, if an expert makes the decision, you are absolved of making a bad decision. Data, Metrics and Lean Startup type thinking is more valued in Complex and Chaotic situations.

Gotta go now. This has grown as I started to write it down. I’ll be back to talk about the behaviour and risk surrounding learning in the different quadrants.

P.S. I know that they are not quadrants as their are five of them. I also know it winds up Dave when I refer to quadrants. Pleasure wins over accuracy every time. )

P.P.S. I also know I’m not discovering any new ground here. Simply sending a few postcards from the edge of Dave’s thoughts. Then again, they sell postcards so I’m guessing I’m nowhere near the edge of the map.

Feature Injection and Value Stream Mapping

Feature Injection is a process to help guide Agile Business Analysts. It is formed of three steps*:

  1. Hunt the Value ( An adaptation of value from “The Goal” )
  2. Inject the Features ( Value Stream Mapping )
  3. Break the Model ( Inspired by Kolb’s Circle of Learning and Test Driven Development )
  4. Reduce User Costs / Increase Return on Investment ( UX Metrics )

* Kent McDonald originally devised the three steps.

Feature Injection is a variant form of Value Stream Mapping that adds steps 3 and 4, and explicitly calls out step 1. “Hunt the value”. Without step one, there is a possibility that the “Value Stream Mapping” will create a local optimisation of the process. Hunt the value ensure that the system optimisation is not localised. Some users of Value Stream Mapping start in the middle in their part of the process. As a result they may inadvertently create a local optimisation.  They may also start from the beginning of the process and work forward rather than work backwards which slows the process as you need to keep checking decisions against the value being delivered.

Step 1 of value stream mapping is to identify the value. If you do not know what the value is, how can you map the value stream. If you do not start with finding the value, you are not performing value stream mapping. As the value is always in the outcome, you have to start at the output and work back to the inputs in order to optimise the value stream.

This was first documented in comic strips that were published on Agile Journal by Amr Elssamadisy. These strips were collected into “Real Options at Agile 2009″ that is available here.


Responding to Change over Following a plan.

The Agile versus Waterfall argument divides software developers. There are those that believe iterative development to be superior way of developing software, and those that believe up-front planning to be a superior way of developing software. A couple of weeks ago I had a short but passionate argument with one of my co-workers. They are super super smart, and we each stand on opposite sides of the up-front planning divide. My colleague’s argument is that you need to plan in order to execute fast and efficiently at scale. That fast execution at scale requires considerable up-front planning.

This puzzled me greatly. Real Options shows that up-front planning is inferior as an approach because you commit early and destroys lots of options. Lean tells us that planning is a form of Muda or waste. This is particularly interesting because if people smarter than me think this, then real options could be a flawed concept and I break the model… and learn as a result. After much discussion and thought, I think I may understand the problem. The insight comes from thinking about the problem using the Cynefin model for social complexity developed by Dave Snowden.

The Cynefin model consists of four quadrants (snigger – In joke) of “Simple”, “Complicated”, “Complex”, and “Choatic” and a fifth quadrant “Unordered” for when you do not know which of the other quadrants you are in. A “Simple” system is over constrained and has cause/effect behaviour. “Complicated” is the realm of the expert. “Chaos” means there are not enough constraints. “Complex” means there are just enough constraints to create an emergent behaviour which can be nudged and tweaked into a system with desirable behviour. “Complicated” means an expert can reduce the problem to component parts with predictable behaviour. “Complex” means there are feedback loops, agents and limits that create an emergent behaviour that cannot necessarily be predicted. Essentially, the difference between the two can be two can be distilled to “A complex system interacts with its context and evolves as a result, and a complicated system does not interact with its context or evolve.”

If you know in advance what is needed, you are in a complicated system. You can specify and plan in detail to create an optimal delivery at scale (A long lead time and short duration). Hence the space shuttle. Complicated systems struggle to react to changes in context which can cause analysis paralysis. In product development, complicated systems are managed and dominated by experts. The axioms of this paradigm are untested assumptions. This is the realm of early commitment and the slaying of valuable options. As a cautionary note, these systems have the potential to suffer a catastrophic failure if they choose to ignore the context changes.

If you are in a situation where the context is dynamic and an expert cannot predict in advance, you are in a complex system. You cannot specify and plan in detail because the context changes before you can deliver. Development in a complex system consists of several safe to fail experiments followed by fast developments to enhance beneficial developments and dampen non-beneficial developments. In product development, decisions are made by studying data and the impacts of safe to fail experiments and small iterative investments. Products and their context co-evolve. The axioms of this paradigm are hypotheses which are to be challenged and tested. This is the realm where real options are an optimal strategy (Check out Dave’s paper from 1857).

So the answer is quite simple. If your product is in a complicated context, use experts and up-front planning. If you are in a complex context, create options and learn to respond faster than your competition.

A final note. If you think you are complicated context, and you are operating in a market with competition… I’m sorry, you are wrong. You are actually in a complex context.

Despite my best efforts, I now find the Cynefin framework to be a useful tool to understand* and operate** the context within which I work. If you want to find out more about Cynefin, sign up for one of Dave’s course at Oh, and refer to the quadrants as quadrants. He love’s that.



Get every new post delivered to your Inbox.

Join 55 other followers