To calculate the cost of an investment, we multiply two amounts:

1. The total day rate
2. The duration of the investment

For example, for a day rate of £20,000, and an investment duration of 20 days, the cost is £400,000.

We then receive a “memo” from the finance department that the CFO has failed to do his job properly and secure funding for the investment and you need to cut costs. How do we do this? There are two options, we can cut the day rate, or we can cut the duration of the project.

In the day rate example, we decide to slash and burn the team. We cut the team size in half to £10,000 per day, but what happens to the duration of the project? Well the same amount of work needs to be done, so the duration doubles to 40 days. Have we reduced the costs? No, not at all.

In the duration example, we increase the size of the team (ignoring mythical man month for now) to 40 people, and the duration halves to ten days. Have we reduced the costs? No, not at all.

Now lets consider the overhead costs.

Not all of the day rate goes to the value stream delivery capability. Not all of it is spent on product owners, developers and testers… A lot of the daily rate is due to overhead, people on the project that:

• Assist the value stream. e.g. Scrum Masters who facilitate the developers.
• Support improvement in the value stream. e.g. Agile Coach.
• Governance. e.g. Architects, Finance or Assurance individuals
• Management. e.g. Project managers and Line managers
• Administrative support. e.g. PMO or personal assitants

Normally, some of the “overhead” is considered specialist in nature or it is not acceptable for a single individual to wear two hats (for fear of conflicts of interest).

In addition, we assume that the overhead is already as small as it can be, and that the overhead does not have to scale if the value stream delivery capability increases (which is a fair assumption).

As such the overhead part of the day rate is more fixed. It is the value stream capability that is often adjusted.

Now lets consider our example from earlier and consider the impact of the overhead costs. The costs now look like the following:

Reducing the daily rate results in doubling the overhead costs.

Reducing the duration results in halving the overhead costs.

The following graph shows the impact on the overall cost of adding or removing ten percent capacity to the value generating capacity for different percentages of cost overhead.

This leads to the conclusion that there are two effective strategies for reducing the cost of an investment:

1. Reduce overhead (or Muda as it is known in Lean)
2. Reduce the duration of the investment (or lead time as it is known in Lean)

Why do people reduce the day rate?

The reason people reduce the day rate is because they can immediately demonstrate to their superiors that they are reducing costs. In other words, they do it because it is easy.

A more effective demonstration of competence would be to show that less investment dollars were stuck in the development machine by reducing the weighted lead time of the department. By reducing the weighted lead time, we create more options for the business investors.

I would like to thank Dale Steanson for having the patience to let me ramble through this explanation and get it straight in my mind.

A few years a go I was recounting the Skype story to a colleague. He introduced me to the architect who had been tasked with solving the Portfolio problem we solved at Skype. The conversation went a bit like this.

1. Me: We did “X” at Skype. It took us eighteen months to get to that point.
2. Architect: We are not going to do that, we are going to do “Y”.
3. Me: We tried that and it did not work.
4. Architect: Well then we will do “Z”
5. Me: We tried that and it did not work.
6. Repeat 4 & 5 for a few minutes
7. Architect This is not working. We both have opinions and we do not agree.
8. <End of Meeting>

As I left the meeting, I thought to myself “No. You have an opinion, I have experience. And sadly you do not know the difference between opinion and experience.”

So what is an opinion? An opinion is a hypothesis in the complicated domain of Cynefin. The architect was expressing an opinion that contained a great deal of uncertainty.

And what is experience? Experience is a hypothesis that has been tested in a (safe to fail*) experiment. So when I said “We tried that and it did not work”, I was was speaking from certainty, I was an genuine expert.

Unfortunately we were in a culture that saw all problems as complicated and deferred to the expert as a result. In a culture that sees all problems as complicated, experts express opinions as fact as uncertainty is scorned, and the high power distance rules! In such a culture, no one understands the difference between an opinion and experience. In such a culture, the most senior person’s opinion, OR HIPPO as it is known, rules supreme.

So as an executive, how do you handle such a situation? Simple, listen to experience OVER opinion. Executives know how to do this in spades… Most executives will have given hundreds of job interviews during their career, carefully sifting the facts from theory (How did you do that? talk about what you actually did? not what the group did, what did you do? You say “I think”, what happened”). Most people do not lie and will be honest about their experience when challenged, they will retreat and admit they are expressing opinion.

This highlights one of the differences between Communities of Need and Communities of Solution. In Communities of Need, the keynote are “Trail Blazers” who talk about their hypotheses and their tested hypotheses or experience. In the Communities of Solutions, the keynotes are normally “thought leaders” who are  talking about Opinion. They talk about the work that others have done as if it is proof for their opinion. By contrast, they tend to strip off the context implying that what works in one context will work in another. (See Dave Snowden’s Lean Agile Scotland keynote for more detail on this)

Context is everything with some techniques. Tony Grout, myself and a large supporting cast first implemented “Delivery Mapping” at Skype. Dan North then invited me in to help one of his large Banking Clients who faced the same portfolio issue. (Note – Pretty much every organisation has the same issue). Subsequently I have implemented it in two other organisations. I am currently working to implement it in another client.

Here’s the thing about delivery mapping. It is easy peasy. The concept is easy. The training is easy. The hard bit is getting the buy in from both IT AND even harder, THE BUSINESS. It will not work unless a large chunk of an organisation agrees to it, or if the “CEO” overrides a whole bunch of self interested senior executives, effectively forcing them to ignore their performance management system. Getting that kind of buy-in either involves luck (and the right dominant culture which is also luck) OR a hell of a lot of effort and influencing. It requires you to gradually and methodically build support for YOURSELF. Building credibility in your own brand so that the people in the “Complicated Culture” trust your experience more than their expensive “experts” and “thought leaders”.

So if you want to a simple test the people around you. See whether they value

Experience OVER Opinion

OR

Cannot tell the difference between Experience and Opinion.

If you picking a conference to spend your precious training budget on, look for one where the keynote is talk about THEIR experience, or instead is simply expressing opinion and using other peoples experience to justify their opinion. If you are not sure which keynotes do this, go and watch some videos on InfoQ, youtube and VIMEO, its easy to spot when you know what you are looking for.

Scaling Agile needs a culture which values Experience OVER Opinion. Without it, we will see more catastrophic failures where Thought Leaders express their opinions as fact and the people who suffer are the dozens of people whose careers are ruined a year later.

* Even though it should, not all experience is gained in a “safe to fail” experiment. Some experience is gained in a non “safe to fail” experiment at great cost to some of those involved.

Most people and organisations suffer from confirmation bias. Confirmation bias prevents us from learning, it means that we seek out information that confirms our belief, and fail to learn as a result. If you or your organisation want to learn, you need to develop a failure bias. A failure bias means that you seek out information that confirms our beliefs are wrong, or have failed. This does not mean we seek to fail but rather we seek the information that we may have failed.

The consequences of the failure bias are:

1. We actively look for information that refute our beliefs. We need to see failure.
2. We construct experiments that optimise our learning rather than prove that we are right.

Seeing Failure

Our natural inclination is to seek information that confirms our beliefs. Unfortunately, confirmation bias is a subconscious activity. We are unconsciously competent in the beliefs we trust the most. This means that we must put a great deal of effort into spotting things that refute our beliefs. Even more than that, we must construct strategies that even allow us to perceive the information that refutes our beliefs. This is the heart of the “Break the Model” part of Feature Injection.

Optimising Learning

Claude Shannon’s information theory tells is that learning is greatest when uncertainty is greatest. We learn the most when the chances of success are 50/50. When developing products we have two phases, the first is to learn about our customers, and the second is to exploit that learning. During the learning phase, the experiments should be focused on learning (50/50) rather than confirming our belief. This is a huge challenge in risk averse cultures where failure is not tolerated. Executives in risk averse cultures should focus to ensure that there is a healthy balance of failure and success. During the learning phase they should ensure that confirmation bias does not obliterate learning. Given the nature of risk averse cultures, they should hold up a lack of failure during the learning phase as the worst kind of failure.

The failure bias is what separates startups from traditional organisations. It also separates those that will survive from those that will not.

In 2004 a colleague helped me try to create a learning organisation. My colleague had studied learning organisations for his MBA thesis. I have never forgotten his counsel…

“The single most important factor to the success of a learning organisation is management’s attitude to failure”.

Failure and its relationship to learning as individuals and organisations is well established with popular books like “Black Box Thinking” by Matthew Syed providing an accessible Gladwell style summary* of the subject.

The unspoken assumption is that Executive’s do not understand the relationship between failure and learning. That organisation fail to learn because executive do not understand the importance of “safe to fail” experiments and as a result do not create environments that allow them.

Over the years I have worked with a number of senior managers and executives who do get it… Who are supportive, but still the learning and the failing fail to happen.

So I am going to operate using a new set of hypotheses to see if I can create the elusive organisation learning:

1. Most executives are unconsciously competent learners.
2. Most executives do not have a theory of learning and coaching.

Expanding on this:

1. Most executives are excellent learners. Quite often they have an experiential learning style where they construct safe to fail experiments to find solutions to problems they have not encountered before. This experiential learning style means that they often use strategies that they have not studied but rather developed using their own knowledge and experience. An anthropologist may use a concept from anthropology to solve a problem in organisational design. In effect, they have exapted a concept from their own field of study rather than adopt a standard Harvard Business Review approach. This makes it hard for them to communicate their approaches to their organisation as they do not have material for them to refer to.
2. Although executives are unconsciously competent at learning by creating safe to fail experiments to learn, they do not have a theory or model that they can use to communicate to their organisation. Although they know how to learn themselves, they do not know how to coach their organisations to learn, and more importantly they do not know how to coach their organisations to manage the risk around learning and ensure that all experiments are safe to fail.

The implication of this shift is that we should not encourage executives to create environments that promote learning by tolerating failure. Instead we should coach executives so that they transition back to conscious competence by building a theory of learning that they can use to coach their organisations.

Its a hypothesis as I need to try a new approach. I’d love to hear from anyone who is ahead of me in this journey.

* Check out Dave Snowden’s Lean Agile Scotland keynote covering Pseudo Science et al.