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 Booking.com 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 booking.com 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.

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.

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

………..blah…………

………..blah…………

Portfolio Owners strictly order Portfolio backlog: Hippo

………..blah…………

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

………..blah…………

………..blah…………

Team demonstrate reduction of technical debt: Extreme Programming

………..blah…………

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.