Slice Value, Not Functionality.

Product Owners often struggle to make stories small enough. Agile projects end up with “MVP”s that take the team months to build. The solution to this problem is to slice value rather than functionality, but what does that mean?

Traditional projects often have a “scope”. “Scope” normally means “As an investor I have given you this much money for this set of functionality”. As a result, product owners and business analysts often focus on the functionality of the product rather than the value of the product to the customer or user. This leads to all sorts of problems. Consider the example where an investor wants to deliver a portfolio of products to their customers. That portfolio consists of a cup of tea, and a cup of coffee. The functionality required is that the project needs to develop the capability of delivering a cup of tea, and a cup of coffee.

To me, the business analyst toolkit is focused on delivering capability (or functionality) within an organisation. By contract, the product management toolkit focuses on satisfying the needs of the customer. The product owner needs both of these tool kits in their product owner team in order to be successful.

Slicing Functionality

The first problem when we slice functionality is that the definition of the product to satisfy the needs of the customer is subjective. I worked on a project where we had to deliver a “cup of coffee”. Before we delivered the product, we had a long series of  reviews with the chief product owner where they gave feedback. One chief product owner would say “Too bitter!”, and the other would say “Not bitter enough”. The project had delivered a cup of coffee but the acceptance criteria were not clear enough. This is a failure state that product owners often find themselves in.

The other problem is the variants. The scope said that we needed to deliver a cup of coffee but all of a sudden, we discovered lots of variants. We need Cappuccinos, Americanos, Lattes and Macchiatos. We need coffee delivered in paper cup, and china cups, and tall glasses. We need full fat milk, semi skilled milk, skimmed milk, rice milk, lactose free milk, and soya milk. Whenever we speak to the investor (sponsor in Corporate speak to indicate they are investing someone else’s money), they insist we have to include whatever niche variant because they know someone who drinks it, or might want to drink it. “Bob in marketing drinks double double decaf upside down with a twist of vanilla in a bring your own sports cup with straw.”

Whenever you try to reduce the scope, it increases as you make the investor aware of a gap in their original thinking. Whenever we think of a variant, our investor thinks of someone who might need it. Our “scope” balloons out of control and we end up with massive releases.

Slicing by Value

Slicing by value makes it much simpler to create small stories. Instead of functionality, we aim to improve a business metric by satisfying the need of a customer segment (or persona). For example, our organisation has three top level metrics, “Number of Customers”, “Activity”, and “Revenue”. Based on the current portfolio of metrics values, the chief product owner agrees with the product owner which metric it would be best to invest in. The product owner team then identifies those customer segments and needs that would most likely deliver on the metric. Alternatively the product owner team might identify the best investment to make based on their understanding of the customer segments and their needs, and then agree the metric with the chief product owner.

Now the product owner team can be much more focused on the delivery of the cup of coffee. We are looking to “increase revenue by focusing on commuters who have a need for habit and ritual in their commute”. We can also agree measurable acceptance criteria, say 50% of twenty commuters tasted rate the coffee ten out of ten. Now we have our design brief (Metric, Customer Segment, Need), we can create a set of designs. Each design is a hypothesis that might satisfy our design brief. After initial team and user (in)validation (See Melissa Perri’s Bad Idea Terminator), each design becomes an Epic that feeds into the Agile Development Process. An Epic might be needed to create the output of the system that is used in User (In)validation.

Small Stories

So if you have a problem with “stories” that are mammoth beast, try slicing them by value instead of functionality.

Use the “Design Brief” format of

  • In order to move <metric>
  • As a <customer segment>
  • I need <job to be done>

And the Epic Format

  • In order to move <metric>
  • As a <customer segment>
  • I need <job to be done>
  • With the hypothesis that <“Functionality”> will satisfy the need

This is so much better than the format


  • As a <customer segment>
  • I need <“Functionality”>
  • So that <“Don’t know what to write here, so I’ll ignore this bit”>



Three top tips for using Given When Then.

Behaviour Driven Development is like Jazz. It is a constantly evolving approach to communication between all those involved in the specification and delivery of value in software development. Aslak, the creator of Cucumber, has cut a vinyl called “Kind of Green“. As the co-creator of the Given-When-Then format, this is an MP3 I knocked together in my bedroom. Its not quite my vinyl, more of a sample.

As a coach I spend most of my time with Product Owner Teams and Managers in large enterprises with established products, normally with millions of existing customers. The product team who create the stories, or the “Three Amigos” consists of the Product Owner (Product Owner, Chief Product Owner, Product Director), A developer, A testers,…. and A business analyst, architects (business, technical, and security), UX Researchers, UX Designers, System Designers (Lean Services representing the call centre), Data Analysts, and the occasional tastapod. I find the tester is normally best placed to facilitate the “Three Amigos” session.

Top Tip 1: Start with the value

Most product investments start with a “Tea Bag”, a partially formed idea. No one ever wants a tea bag. The conversation goes like this:

  • Someone: “I want want a tea bag!”
  • Product Owner: “Why?
  • Someone: “Because I want a cup of tea”
  • Product Owner: “Why?”
  • Someone: “Because I’m thirsty and cold and its a habit OK?”
  • Product Owner: “What customer segment does this someone represent?”
  • UX Researcher: “The are a commuter, represented by Warren the Worker”
  • Product Owner: “So if we meet this need for the Warrens, we should increase activity in our stores.”
  • Chief Product Owner: “Activity is a good and righteous metric to move given the current state of our metrics.”

The role of the Chief Product Owner is to ensure that the Product Owner is investing in the right metrics. They ensure alignment across the portfolio. They are an optional member of the product owner team.

  • Product Owner: “We will deliver a cup of tea to satisfy the habit and thirst need of Warrens to drive up in-store activity”
  • Lean UX Smarty Pants: “Isn’t that like a whole load of hypotheses?”
  • Cynefin Smarty Pants: “And that is why we will engage in multiple safe to fail experiments, some of which are oblique.”
  • Agile Coach: “That means small Stories and Epics, respond to feedback from real customers.”

The “Find the Value” activity can involve the whole team, however the risk associated with certain aspects is owned by certain roles:

  1. The product owner owns the risk that the investment should be moving an appropriate metric.
  2. The Chief Product Owner owns the risk that the right metric is being moved given the wider organisational metrics.
  3. The UX Researcher / Data Analyst owns the risk that the right customer segment / persona is identified.
  4. The UX Reseacher owns the risk that the customer need identified is done so in appropriate manner.

The output of the “Find the Value” Activity is a design brief.

The design brief consists of:

  1. The metric to be improved.
  2. The customer segment / persona.
  3. The need to be satisfied.

At this point, the chief product owner and product director can check to ensure that the investment is aligned with all the other investments in the portfolio.

Please note that this is quite a long post and I still have not got to the bit where talk about user stories and given when then scenarios. You need to do the “Find the value” step first, otherwise as the Cat from Cheshire would say “If you don’t know where you want to go, any way is just as good.”

Top Tip 2: Work Backwards

Once we have a design brief, the entire team can engage in creating designs to satisfy the brief. The UX designer owns the risk that the design process is righteous and good, even if non designers are involved, especially in the original brainstorming.

The first step moving backwards is to start with the need and take one step backwards to consider the output of the system that will satisfy the need of the customer. (The value to the customer is in the output of the system, the need that it satisfies). When we have a design, we can test it on users to get early feedback.

Consider an app that is a music version of IMDB. An example design brief might be “Increase number of customers (metric) for super users (User Segment / Persona), by meeting their need to know where significant events occured for one of their favourite artists.“. The designs that satisfies that output might look like the following, one of which has been discarded as a result of user testing. The user testing has suggested we are best focus initially on the design on the right.

Screen Shot 2015-03-14 at 11.14.53

There are two considerations when working backwards from the design. The first is the data that needs to be displayed on the output which is covered by information smells (article video). The second is the behaviour of the application, which is normally expressed using the Given-When-Then format.

Note that identification of data is a complicated problem that is the domain of the business analyst and the architects. There is a right, knowable answer that can be verified by research using information smells.

The behaviour of the application needs an understanding of the value to be delivered, the needs of the customer segment, the technical constraints, and the possible failure states, or “quality” paths. As a result, all of the product owner team should be involved at various points.

When specifying the behaviour of the application, the team should start with the output, which means the first thing they should write is the “THEN“. For example:

  • THEN the app displays a map
  • AND the user location
  • AND the location of any “Lady Gaga sites”
  • AND the description of any “Lady Gaga sites”

The product team can then discuss the ways that the user would access the output. What event would cause it to be displayed. There may be several. The ones that are not an initial focus become TODOs that become part of subsequent Epics.

  • WHEN the user is within one mile of an “Lady Gaga site”
  1. TODO: When the user selects map from “Lady Gaga” page

The “Three Amigos” product team can then create the Conditions necessary, or GIVENs.

  • GIVEN the user has selected “Lady Gaga”
  • AND there are “Lady Gaga” sites within a mile
  • AND the user has enabled notifications on their phone
  • AND the user has enabled GPS

Out tester with a black hat is recording the quality paths as TODOs for other Epics:

  1. TODO – Lady Gaga not selected
  2. TODO – Notifications not enabled
  3. TODO – GPS not enabled

The product owner decides the tester can handle 1 and 3 on their own but wants to be involved in 2 as the product owner would like to design an e:mail to tell users what sites they missed.

Which gives us the following first scenario:

  • GIVEN the user has selected “Lady Gaga”
  • AND there are “Lady Gaga” sites within a mile
  • AND the user has enabled notifications on their phone
  • AND the user has enabled GPS
  • WHEN the user is within one mile of an “Lady Gaga site”
  • THEN the app displays a map
  • AND the users location
  • AND the location of any “Lady Gaga sites”
  • AND the description of any “Lady Gaga sites”

The product team then takes each of the GIVENs and turns them into a THEN as they continue to work backwards:

  • THEN the user has selected “Lady Gaga”

The event that triggered that was:

  • WHEN the user selects “Keep me informed of nearby Lady Gaga sites”

In the following conditions

  • GIVEN the user is on the Lady Gaga page
  • AND the user is logged on

Top Tip Three – GIVEN-WHEN-THEN first, stories second.

The product owner team can then slice the Epic into Stories.Starting with the GIVEN-WHEN-THEN, work out which bits of the Epic are the riskiest to complete.

  • GIVEN the user has selected “Lady Gaga”
  • AND there are “Lady Gaga” sites within a mile
  • AND the user has enabled notifications on their phone
  • AND the user has enabled GPS
  • WHEN the user is within one mile of an “Lady Gaga site”
  • THEN the app displays a map
  • AND the users location
  • AND the location of any “Lady Gaga sites”
  • AND the description of any “Lady Gaga sites”

The developer and architect might suggest starting with the map as they have not used the map service before. Or they might suggest the “Lady Gaga sites” because that uses a service on the new untested architecture.

The tester might suggest the location trigger (WHEN) because they are not sure how to test it effectively.

The UX researcher might suggest the location trigger (WHEN) because they are unsure how users will respond and they want to test it with a screen mock up.

The security architect is worried about whether people will enter bogus artist sites to spam friends or enemies.

The team orders the stories with the riskiest first. They do the story that is most likely to fail so that they can get quick feedback.

Note that this different to the way that many people advocate. I am suggesting you create the GIVEN-WHEN-THEN scenarios for the design first and then create the stories whereas most other people advocate creation of the stories and then the GIVEN-WHEN-THEN scenarios.

Bonus Top Tip – Micro-Service Design

Starting with the output makes the design of micro-services easier as well. You start with the last thing to be displayed. To do that, you need look no further than your THENs and combined them with your domain model generated using information smells. The input to the last service becomes the output of the preceding service.


  • THEN the app displays a map
  • AND the users location
  • AND the location of any “Lady Gaga sites”
  • AND the description of any “Lady Gaga sites”


  1. getMap (Location)
  2. getArtistSiteDescription (ArtistSiteLocation)
  3. getArtistSiteLocations (UserArtistList)
  4. getUserArtistList (UserId)
  5. getUserId(Username, Password)

Hopefully working backwards will rid the world of projects where the Login screen is the first thing developed.

When do you book a flight and hotel for a conference?

When do you book a flight and hotel for a conference?

A friend recently booked a flight for a conference six months in advance. Another friend suggested they should wait. This is a great discussion to explore some of the subtleties of real options, and especially the lesser known fourth law:

“The value of options increases with uncertainty.”

The flip side of this law is that options have no time value when there is certainty. The option value collapses to the intrinsic value.

For my friends who are Cynefin fans, it means that options have no time value when you are in the “Obvious” and “Complicated” domains (oops, sorry Dave, I meant quadrants, all five of them). Options play a major role in the “Complex” and “Chaos” quadrants, which is no surprise as Dave Snowden used Real Options to help create the Cynefin Framework well before Olav and I started talking about them.

But here is the real kicker. Dave tells us that Cynefin is a multi ontological sense making framework. What does that mean in English? It means that Cynefin considers the Ontology, Phenomenology and Epistemology of a situation, or “How it is”, “How we perceive it” and “How we act upon it”. These three are all very different, but do impact upon each other.

Olav and I have given many talks on Real Options. The focus of much of those talks is about the Phenomenology of Real Options and Commitments. The third law of Real Options “Never commit early unless you know why” is about the Epistemology of Real Options or “How we act”. It says never to commit unless you have enough certainty or in other words, never commit unless the time value of the option is zero due to certainty. This statement weakens the phenomenology of the commitment by putting the emphasis on certainty before the commitment. The ontology is that there is never certainty, certainly not until the end of the universe. There is always a itsy witsy small chance. Uncertainty hides in that 0.001% chance. That itsy witsy small place that is home to the black swan. That itsy witsy small place according to the phenomenology which is actually rather large according to the ontology. In fact, the phenomenology is the exterior of the tardis whereas the ontology is the inside of the tardis. Two different dimensions, and Real Options tilts us towards the ontology.

So what does this have to do with booking flights and a hotel for a conference?

Lets handle the easy one first, the hotel booking. Most hotels give us a free option. They give us the option to stay in the hotel at a fixed price. The option expires and becomes a (financial) commitment on the day of the stay. Therefore as soon as we think we might go to a conference like Agile20xx where the hotel sells out, it is worth taking up that free option. If closer to the conference we decide not to use the hotel reservation, we simply cancel it, or even “sell” it (probably for kudos as currency rather than cash). In other words, hotels give away free options which is something that is trying to monetize by allowing hotel to offer cheaper rooms if the guest pays in advance and makes a commitment.

Airlines do not give away free options. A more subtle strategy is needed. In addition, airlines use utility based option pricing models for their flights. As the flight date approaches the price goes up, especially as the flight starts to sell out. As a result, flights are often much cheaper if purchased well in advance.

For a big conference like Agile20xx that is often in a location that is poorly served by international flights, the routes are often illiquid. (Illiquid means there are few options). Illiquid routes often spike in cost. As such, as soon as I think I’m pretty sure I’ll go to a conference like this, I buy a flight. This is an option to attend. From experience, leaving the flight to Agile2006 too late resulted in a flight that cost £1400 whereas the flight the following year cost about £350. I had bought the option to attend for £350. The point I buy the option is the point at which I’m pretty sure I will attend.

Another key point about Agile20xx is that the conference pays a fixed fee rather than cover travel expenses. Most conferences pay for expenses, and possibly a fee. That means that the risk of flight costs going up is borne by the conference rather than the speaker. So the best option is to attend the conference as a speaker so that the cost of flight risk is managed for you. Either that or get a sense of how much flights cost change closer to the time of travel. I generally book a month before travel but have been caught out once or twice.

Sometimes we need to constrain a situation in order to make things “obvious”. Anyone who has to work with an ex-partner to coordinate holidays for children, or provide certainty of dates for work colleagues, or clients attending a training course will recognize this situation. In other words, sometimes we need to give up our own options and the ability to respond to uncertainty in order to make things easier for others. This in turn helps us.

So coming back to “When do I book a flight and hotel?”

  1. Book the hotel as soon as you think you will need it. You can always switch to a cheaper up front cost on closer to the time.
  2. Either book the flight as an option well in advance, or book the flight when you have constrained your options enough that the uncertainty is removed for other.

This post was inspired by a great conversation on Twitter between Gitte, Yves and Samantha.

Seven FAQs about Agile Frameworks

My thanks to Martin Burns, Erik Gibson and David Morris for great challenges and questions about the Framework:

  1. Is the Framework a Trojan Horse? – No. Quite the opposite. The Framework makes it easy for control functions to clearly identify whether an investment is operating within the risk limits. The framework consists of risk management constraints that also act as enabling constraints that encourage improvement. Once control functions become familiar with the framework, they will start to appreciate that their existing SDLC style stage gate processes are not as effective.
  2. Does the Framework Support Incremental Implementation? – Yes. Organisations should start by getting good at the team level. The framework specifies the limits that team level investments should operate within in order to be effectively risk managed. If an organisation choose to go full in and create a multi-team program level “Flagship” agile project, the Framework will constrain it so that it does not become a rogue Water-Scrum-Fall or Scrum-Fail project. The control framework can identify those risk factors that are out of limits and as such require more careful monitoring.
  3. Does an investment need to to fully comply with the Framework before it can be considered safe? The framework acknowledges that organisations will need to go on a journey. The framework introduces limits, and the processes for monitoring the organisations journey towards compliance. e.g. Each investment needs a weighted lead time of a month or less, unless all of the executives have committed to be within the limit within an agreed timescale AND CAN DEMONSTRATE PROGRESS TOWARDS THE GOAL. Simply saying you’ll do it is not enough, you need to demonstrate you are on the journey and take the limit seriously. As Martin puts it, they just need to deliver.
  4. Does the framework compete with Safe. DAD and LESS? Quite the opposite. The framework compliments the scaled Agile frameworks. Safe, DAD and LESS can be plugged into the framework. Organisations have a clear idea about which controls am approach covers and what else they need, like Cynefin, Real Options and Beyond Budgeting.
  5. Is the Framework commercially available?  Not yet. If anything, the framework will be available as an open source framework. That way, it can evolve to identify new controls and limits that might be needed to cater for contexts that were not originally considered. Associated with the framework would be a list of methods and tools with associated strengths and weaknesses describing the context where each method and tool has a sweet spot, and where each may create risk for the organisation. Expect a wikipedia style process with approapriate editing controls.
  6. Does an organisation need to reach a certain level of maturity before they can adopt the framework? The framework is a good game in “Reality is Broken” terms. An organisation can adopt it at a very low level of maturity and have transparency that it has a lot of risks that are not managed effectively. As the organisation matures, it can use the framework to demonstrate progress. Rather than maturity levels, the framework can be used to build a backlog of targeted improvements. The backlog could be ordered using a WSJF style process where the value is the amount of risk reduction.
  7. Does the framework require a big up front implementation of a process. Quite the opposite. The framework shows the risk hot spots that the organisation needs to address. The organisation can incrementally adopt methods and tools to address the risks and then choose the level of control that is necessary according to the context of the investment. The same organisation might have different levels of control depending on the context. e.g. A mission critical investment might be required to operate within more limits than a small innovative investment. The framework creates transparency into risk and helps the organisation choose their preferred adoption path for a scaled agile framework. It helps people who are not experts understand how to pick and choose the best elements from each approach. Philosophically, its similar to Alistair Cockburn’s Crystal Methodology for organisations. Risk limits for how an organisation creates transparency around the improvement backlog are covered in he “Deliver Value” and “Governance” control.
  8. Will certification be available? If people want to pay me money, I will happily give them a certificate that they can sign saying that they are “Aware of” and “Value” the framework. Ideal for “control” professionals.

Framework, Options and Process

The framework specifies the limits and constraints that a delivery organisation must operate within. If we consider one such section of the framework… Deliver Value within the Portfolio, the obvious constraint is that the Portfolio has a strictly ordered backlog. Note that the framework does not state how the backlog should be ordered.

The decision on how to order the backlog is the responsibility of the portfolio owners. However, given that the portfolio owners may not be experts in Agile Techniques, it is useful to present them with a set of options. giving the pros and cons of each option.

Options for strictly ordering the portfolio in order of preference:

  1. The backlog is ordered with a process that takes account of complexity, informed by a quantitative version of Cost of Delay.
  2. A quantitative version of Cost of Delay / Joshua Arnold’s CD3.
  3. Don Reinertsen’s Wisdom of Crowds version of Cost of Delay.
  4. Safe’s Fibonnacci based version of WSJF.
  5. A value based approach to prioritisation.
  6. HIPPO based prioritisation.

Option 1: Complexity Based Solution, informed by a quantitative version of Cost of Delay

Description: Calculate the cost of each backlog item of interest. Convert the cost to the value that should be delivered expressed in business value metrics. Wisdom of Crowds the idea to work out which is the best for items in the Complex and Chaos domain. Use a quantitative version of Cost of Delay for items in the Obvious and Complicated Domain. Common sense prevails hopefully to order the backlog properly. This is a social structure informed data rather than following a rigorous “equation”.

Strengths: This approach combines the power of Dave Snowden’s Wisdom of Crowds with Don Reinertsen’s Cost of Delay.

Weaknesses: Even Chris Matts cannot find the write up of his piece. Possibly because he forgot to post it. This is an hypothetical ideal solution that has not been tested for a real portfolio.

Further Reading: Links to Dave Snowden videos, and Don Reinertsen books and videos.

Option 2 – A quantitative version of Cost of Delay / Joshua Arnold’s CD3.

Description: A quantitative version of Cost of Delay / Joshua Arnold’s CD3.

Strengths: The approach creates a clear unambiguous ordering of the backlog. Ideal for portfolios in the “Obvious” and “Complicated” domain, such as efficiency innovation.

Weakness: Care must be taken for portfolios containing investments in the “Complex” and “Chaos” domain, such as sustaining and disruptive innovation. May lead to a bias toward efficiency innovation.

Further Reading: Links to Black Swan Farming and Don Reinertsen.

Blah…. Blah…

Option 6: HIPPO based prioritisation

Description: The most senior person in the room dictates the order of the backlog.

Strengths: The most senior person gets to grab all the constrained resources to make themselves successful, but once they do this, they have no excuse if they fail to deliver the value that they promised. This approach is simple to implement, especially in traditional cultures with a high power distance index. The strict order of the backlog makes success or failure transparent and so HIPPOs are likely to support successful ideas after an initial attempt to simple support their own.

Weaknesses: It fails to harness the wisdom of the crowd and limits the IQ and knowledge of the Portfolio decision process to the experience, education and intelligence of the highest paid person in the room. This approach limits the organisation’s ability to grow its a more agile and self organising culture that uses distributed cognition instead of command and control.

Further Reading: Snakes in Suits by Paul Bablak

Organisation can help those pulling together a method by explaining the context in which an option works, and contexts where care must be taken.

Some organisations might prepare “Strip Maps” to illustrate the process that act as the “Easiest to implement” set of methods and tools to satisfy the framework in an organisation. For example

Example Strip Map (Partial)

Executives ensure a balanced portfolio of investments: Cynefin



Portfolio Owners strictly order Portfolio backlog: Hippo


Teams lead time is less than a month: Lean Value Stream Mapping and Kanban



Team demonstrate reduction of technical debt: Extreme Programming


Process and Framework

What is the difference between a process and a framework?

Currently we are bombarded with stories about how an organisation has adopted Scrum or Kanban or Safe or DAD or something LESS. The main narrative about scaling agile is about implementing a process or method. Instead I will argue that organisations need a framework instead.

Lets use Feature Injection (Value Mapping) to explore this idea.

We start with a tea bag. Some clueless consultant (i.e. Not you Martin) sells their client on the idea of Safe or Less. Safe and Less are the tea bag. They are part of a method or process that cover the program and team part of the organisation.

The client really needs a cup of tea which means they also need something to cover the portfolio, governance, executive and enabling functions (We decided enabling functions was a much more respectful name for Finance and HR than Supporting Functions).

Given the cup of tea, we can explore the needs of the different segments. The “Control” organisation consisting of leadership, management, executive, governance and risk functions have a need to demonstrate control to those they are accountable to (internal and external/market stakeholders). In a small organisation this is easy peasy. In large complicated and complex organisations, some structure is needed to make sure risks are properly managed.

The “delivery” organisation needs the freedom to choose whichever method or tool that suits their context. They need to be freed from the burden of oppressive SDLC deliverables.

The value for the organisation or business value is much faster and more effective innovation… Disruptive innovation, Sustaining Innovation and Efficiency Innovation. And that innovation should be demonstrated to hit the bottom line (as the organisation defines it).

When we look at the scaling methods, we find that they do not meet these needs. They do not provide effective control for the “controller” and they do not provide freedom for the “builders”

Now we understand the needs and the value to be delivered, we can see that a framework meets those needs. Rather than specify the process that the organisation needs to follow, the framework specifies the risks it needs to manage, and the limits for those risks that a delivery organisation can take on. e.g. We know that the longer the investment, the riskier it gets, so we limit the lead time to XX months. Truly Agile teams do not even perceive these limits. If you have a lead time of two weeks and your reporting infrastructure can demonstrate this to the “control” functions, then you are never going to be a worry to them. You get freedom to deliver as you choose.

So does that mean we do not need Safe and DAD and LESS? Quite the opposite. The framework provides the means for an organisation to implement these methods, processes and tools. It helps the organisation clearly identify those gaps in the process that need to be addressed. For example, Lets use Safe for Team and Program. The framework helps us see the gaps, so we add on Delivery Mapping for Portfolio, Real Options for Governance, Beyond Budgeting for Finance, Cynefin for HR, and Lean, TOC and Cynefin for Executives, with transparency provided by Jira/VersionOne/NameYourPoison. All the teams need to do is demonstrate they have the recipe for a cup of tea, and then just get on with it. The operations department of an organisation might adopted Safe as it fits better with its culture. A front office or customer facing organisation in the same organisation might choose LESS as it suits their culture. A small innovative lab might choose to have no process as long as it operates within the framework. The framework gives different departments in the same organisation the freedom to adopt a process and method that’s appropriate for its context, provided it stays within the limits of the framework.

By all means buy a tea bag, but make sure you buy the milk (or lemon), sugar, cup and hot water as well. The framework is your shopping list, to ensure you make a damn fine cup of tea. “Would someone please pass the honey?”

Next up, I will share how an organisation can implement a framework to free its departments in a controlled way.

Real Real Options – A European Passport

Brexit has shown up some fascinating behaviour. Like him or loath him, you have to admire David Cameron’s use of Real Options and the Strategy of Conflict (Game Theory) on Friday Morning. Real Options in the sense that he deferred the commitment to leave the EU until September. That gives the British People three months to scrabble around and find an alternate course of action. “Strategy of Conflict” states that you should never allow the opposition negotiator to speak to the decision maker. Cameron has removed the decision maker from the field. He declared himself a lame duck and that he wont be replaced until September. No one in Britain can negotiate with the EU because we effectively do not have a government.

The EU obviously want the commitment so that they can reduce uncertainty.

We are faced with a situation where we appear to have no options. However, we do. There is no legal commitment on the British Government to leave the EU. The British people have advised them that they would like to be out. At time of writing 2.8 million people have signed a petition asking for another referendum. The Leave campaign cannot oppose this as their defacto leader (Farage) said he would demand another referendum if the vote were as close as it is. By now the lies about the £350 million going to the NHS have been revealed.

What we need now is a proper realisation of where we are. Some of the British people might think they want to leave, but really they do not. Brexit was a protest vote and the message has been received loud and clear. We need to sort out our broken society and get proper jobs into those parts of the country impacted by global changes in the economy.

One of the problems with Leave is that there was never a real discussion about what Leave actually meant. What aspects of the EU were people voting to reject? It would seem that the Leave campaign voters were primarily concerned about immigration and the effects it has on them personally. So negotiation point point one should be that Britain gets a points based immigration system. Now they question should be… how much is that going to cost us. How about Britain funds two hundred thousand refugees (A couple of billion Euros a year) in one the European Countries seeking to increase its economy. In other words, Britain pay to have the points system. That would be a hell of a lot cheaper than the mess we have now. It would also show respect both to the Leave voters of Britain and the EU.

In times of uncertainty, options increase with value. Many people in Britain feel very uncertain. I have a European passport which means I consider myself a European first and British Second. Brexit will possibly result in my being forced to have a British Passport instead. The British Government and the EU are violating my human rights by taking away something from me without my say. In addition, myself and my family lose our human rights as Britain has no such human rights. We need options and I suggest we create the following option though crowd funding.

We need to take a case to the European Court of Human Rights to insist that every European Citizen in Britain is given the option of:

  1. Dual European / British Nationality, or
  2. European Nationality, or
  3. British Nationality.

This is not about the British Government, it is about the European Citizens in Britain. Obviously the Brexit supporters will choose the British Option. My children were born European. I was born British and became European. Should governments have the right to force a new nationality upon me, and take away my rights and options (Options have value)? I do not think so. Leave a comment if you support this idea and I will set up a just giving page to crowdfund it, and find a human rights lawyer to defend us Europeans and our children.

In the words of the Clash “The future is uncertain, know your right”. Human rights as it turns out.