The IT Risk Manager

It is a commonly held belief that Executives and Agile are aligned and the problem with Agile adoption lies with the Frozen Middle (Management). Although Agile and Executives are aligned on many things, there are some core beliefs where some executives diverge. This is the first post in a series that explores those areas where the divergence occurs.

Sustainable Pace

The easiest way to spot an IT executive who does not have experience on the front line as a developer or manager is their attitude to overtime. Anyone with experience as an agile developer or working closely with developers knows that any code written after six in the evening has to be rewritten at some point, ideally the following day but often at a later date when it costs more to fix. One of the core tenets of Agile is the concept of “sustainable pace“, that developers work at a pace that can be sustained over an indefinite period. This sustainable pace leads to more predictability regarding the delivery of value that gives business sponsors confidence and reliability. Sustainable pace reduces cost because it reduces staff turnover , especially experienced developers who have a choice as to where they work. In order to maintain a sustainable pace, managers need to ensure they have slack which is also contrary to the goals of many executives.

Sustainable Pace is particularly important when developers are following an Agile approach to development, or more precisely Extreme Programming (or Dev Ops as it often called these days). Extreme Programming is a very disciplined and rigorous approach to developing software. Developers follow the disciplined “Red-Green-Refactor” pattern. This approach requires discipline and focus that is enhanced by the practice of pair programming which further keeps developers focused on a problem and reduces interruption. Extreme Programming is rigorous and relentless, requiring both discipline and focus. Simply put, if a developer is following extreme programming practices, they are simply unable to work beyond 6pm for an extended period without becoming tired and making mistakes. These mistakes lead to reduced productivity and introduce uncertainty into the development process.

Cheap developers reduce costs

Associated with the belief that sustainable pace is unimportant is the belief that some executives have that cheap developers reduce cost. Experienced Agile Developers and managers that have worked with them know that good developers are much cheaper than inexperienced ones when you consider productivity. Experienced Agile developers “shave the Yak” as they go along. They ruthlessly refactor legacy code bases so that they can deliver value faster. They do not have have to do massive refactorings as a big batch but rather have the skills to continuously improve the code base. All of this whilst continuously improving the velocity at which they deliver value using the “Red-Green-Refactor” pattern.

Book of Dead Code

A few years ago I visited Nat Pryce and his team. They were looking after a complex code base to support a web site for complicated financial derivatives. Nat showed me a graph that plotted the number of lines of code over a six month period. Over six month his team had reduced the code base from a million lines of code to one hundred thousand. The code base was approximately ten percent of its original size.

I once worked with Steve Freeman on a project. In a few short weeks he reduced the size of one of the most complicated areas of the code base by 80% and trained the graduate on the team in Extreme Programming at the same time. The pair also wrapped the code base in automated tests as part of the process.

If you want to understand why that is so significant, consider the following two images. In which one is it easiest to spot the bug (Waldo)?

Some Agile Developers have a practice of creating a book of dead code. Code that has been deleted from legacy code bases that was unnecessary. A book of dead code is a good way of demonstrating to business investors how much unnecessary and wasteful code they have paid for because they hired inexperienced developers.

Inexperienced developers tend to generate bigger code bases as they “cut-and-paste” to solve problems. A lack of automated tests leads to risk aversion which means they avoid touching the original code and copy it instead, tweaking the new version and leaving the original untouched.

If you want to reduce your short and long term costs, invest in Agile developers who have extensive experience in Extreme Programming practices.

Value versus Cost

Unfortunately executives do not value experienced Agile developers. They prefer to hire cheap off shore developers who are often recent graduates in the belief that cheap is better than experience.

The reason for this is well known.

IT departments in traditional organisations have a pretty poor track record at delivering value. A few years ago I heard a quote from a CEO. It was something like “I love off-shoring. Now when a project fails, it does not cost as much“. This highlights the reality that business leaders do not trust their IT departments to deliver value, so they focus on reducing cost. Agile focuses on delivering value rather than reducing cost. Cost reduction occurs by only building features that customers value and avoiding the features that are not valued and therefore not used.

Good developers want to work with good developers

So now that we understand that hiring good developers is better than hiring cheap developers for reducing overall costs. How do we hire good developers?

Executives think that paying experienced developers is enough to motivate them. They think that coersion applied through the hierarchy and the appropriate (currently in vogue) reward and appraisal system is all that is needed to achieve the goals they set.

Good developers want to write good code. They look for environments where they are respected for their ability and managers and executives are constantly looking for ways to help the developers become more effective. Good developers want to work in an environment where they have the tools they need to perform. If they do not have those tools, they will move on.

Good Agile developers want to work with good agile developers. They want to develop their skills and they are not going to be able to do that working with a bunch of graduates.

The good news is if you create the conditions that allow developers to deliver, they will come to you. There are several companies in London with large clusters of Agile Developers. As soon as an Agile developer discovers a good place to work, they reach out to their friends to pull them in. That’s why companies like Springer, Sky, Net-A-Porter, BBC, that are known to be favorable environments for Agile developers. They do not need to advertise as developers make a bee line to them.

It takes time to establish a reputation as a “go to” agile organisation. For those organisations that want a kick start and for those executives who do not have access to the network of established agile practitioners, you might consider starting with established agile consultancies rather than those whose practice is based in waterfall. Consultancies like Equal Experts, BJSS, Zulkhe, Industrial Logic, Crisp and ThoughtWorks. The ideal is to hire the alumni of those consultancies.

Teams OVER Individuals

Executives who are experienced with agile appreciate the value of individuals and appreciate the value of gelled teams of experienced individuals even more. A few months ago Microsoft closed the London Office of Skype in a strategic reorganisation. Enlightened individuals at Amazon appreciated the opportunity this represented and at the end of the same day they were standing outside of the Skype office handing out Apple Macs to developers. They did not insisted on interviews but hired entire teams in one go.

Being ready to respond to an opportunity like that. That is true agile management.

Dragon Slayers and Farmers

In the next post I will discuss the divergent attitude towards Dragon Slayers and Farmers.

My current hero is Dan Marsh. Dan is a business analyst who has just finished his apprenticeship at my client. Dan had the courage to say that what I taught about Feature Injection’s working backwards (That tea bag stuff) actually scared him. Subsequently we had a great session to understand what he found so scary. As a result we came up with the following approach to explain “Work Backwards”. I will explain the subtle but important changes at the end.

We are skipping the “Hunt the value” or “OO” part of Jennie’s “OOPSI” model. And lets assume we have designed one or more “Output” that satisfies our “Outcome” (Design Brief – “We satisfy the “Need” of a “Group of Customers” and as a result the business received value which we measure using a “Metric”).

Consider the Design Brief (As a “Super Fan” I have a need to know “where my favourite celebrities went to school and played their first gigs so that I can go on a pilgrimage” and as a result the company will get more “Super fans”). So the product squad have collaborated on and tested and user tested designs to the point they have an experiment they want to scale out to more of the “Super fans”.

The design they come up with is “A mobile phone app to enable you to do a walking tour of a city to see all the locations where your favourite celebrity lived and played). Something like…

We create an initial Epic to build the experimental product. “Mobile App One to meet Design Brief”. Normally at this point we would break the Epic into stories. Instead we write the Acceptance Criteria using the Given-When-Then format. We start with the Value in creating our value stream. the thing that gives value to the customer, the THEN…

• THEN the application displays a map
• AND the current location is at the center of the map
• AND the location of celebrity sites
• AND the name of the important celebrity sites

So what are the things that could go wrong? Lets consider these as TODO’s that we will come back to in this Epic or more likely in other Epics.

• TODO – The centre of the maps is a specified location (e.g. Zip/Post Code)
• TODO – There are no celebrity sites (An arrow at the edge of the map indicating direction of closest site?)
• TODO – There are no important celebrity sites

We now consider when the app displays the map. The normal response is to suggest when the app is opened. Alternatively it could be when the phone is near to one of the sites.

• WHEN the phone is within the specified distance

And another TODO which will almost certainly go into another Epic.

• TODO – When the app is opened.

We need to update the THEN as well to include an alert.

• THEN the application displays a map
• AND the current location is at the center of the map
• AND the location of celebrity sites
  
• AND the name of the important celebrity sites
  
• AND the phone alerts the user

Now we can look at the necessary conditions for this to happen.

• GIVEN user has selected a celebrity
• AND there are celebrity sites nearby
• AND user has marked celebrity site as important
• AND user has enabled location services
• AND user has enabled alerts
• AND the user is logged in.

With an associated set of TODOs that go in additional Epics…

• TODO user has not selected a celebrity
• TODO there are no celebrity sites nearby
• TODO user has not marked celebrity site as important
• TODO user has not enabled location services
• TODO user has not enabled alerts
• TODO user is not logged in

Each GIVEN becomes a THEN in another scenario… For example

• THEN the user has selected a celebrity
• WHEN the user “snapz” the celebrity
• GIVEN the user has selected a celebrity site
• AND the user is logged in

… with associated TODOs, And the GIVEN in this scenario becomes a THEN in another scenario.

• THEN the user has selected a celebrity site
• WHEN the user “snapz” a celebrity site
• GIVEN the user is viewing the map
• AND a celebrity site is visible on the map
• AND the user is logged in

… with associated TODOs (Only a couple mentioned)

• TODO – User is looking at the list of celebrities.
• TODO – User selects a band with more than one member.

And the GIVEN in this scenario becomes a THEN in another scenario.

• THEN the user is logged in
• WHEN the user presents their thumb print to the phone
• GIVEN the user has entered the app
• AND has registered using their thumb print

TODO – User name and password… because everyone does it that way. Just like putting the engine at the front of the car because people are used to seeing the horses before the cart, and like the idea of putting the “Cart before the horse”.

We can visualise the pattern of the scenarios evolving from the output to the inputs as follows:

Which we can summarise as:

And then we can reveal the pattern more clearly if we zoom out even further (and I’ve changed the TODO’s to clear boxes) as follows:

This is the insight that Dan Marsh gave me. This is a natural way for people to work, from left to right. That means the output is on the left and the inputs are on the right which is contrary to the way I have represented this in the past. Also the natural way to write for THEN-WHEN-GIVEN is top to bottom whereas I have been teaching them to write GIVEN-WHEN-THEN from bottom to top which is also counter to the way people think. The right to left representation that confused people is below:

Dan also helped me understand the follow representation that I had used was also confusing.

So from now on, the process flow to write scenarios is left to right, top to bottom, with the arrows pointing left to right.

Thank you Dan for being honest about your thoughts. I think this is a huge insight. 🙂

From now on, I’m going to remove the cognitive dissonance. From now on, Its all about working forward from the output to the inputs.

The Theory of Constraints offers a simple five step process:

1. Identify the constraint
2. Prioritise work at the constraint
3. Optimise the constraint
4. Add capacity to the constraint
5. Goto 1

Often the hardest thing to do is step 1, to identify the constraint.

One of the main frustrations for a coach is that they can see the constraint but cannot convince the organisation that they need to address the constraint. This is because the organisation has not reached the state of conscious competence about the constraint. They may see the constraint but they do not value it. Paul Adams talk reveals that famous people make us aware of new things but we only adopt them (value them) if one or more of the four people close to us in that context value it.

This means that often before the organisation will accept the constraint, they must first see the coach as a close trusted advisor. In order to achieve this, the coach must first help the organisation remove the constraints that the organisation think are the most important. Even though the coach might be torn because Theory of Constraints shows that working on anything other than the constraint has no impact, they are actually working on the Zeroth Constraint. The Zeroth constraint is that the organisation do not see the coach as a close trusted advisor.

Coaches who do not address the zeroth constraint may find themselves frustrated or in conflict with the organisation they are coaching. They find themselves in this state because they are acting with integrity, they are trying to focus on the most valuable work for the organisation. However first, they need to align themselves and the organisation in terms of understand the value of fixing the true constraint. To do this, the coach may need to demonstrate that they can fix the constraints that bother the organisation even if they are not true constraints. Demonstrating this ability to address these constraints will give the organisation more confidence that the coach can help them fix constraints they might otherwise prefer not to acknowledge.

If you are coach who is worried about working on improving the system away from the constraint, feel confident that you are acting with integrity because you are working on the zeroth constraint.

This insight came out during a conversation with Tony Grout (of course). I would say it was his idea, he might say it was mine.

UPDATE – The proof is flawed. I have found an example that breaks the model. See update section at the bottom of the post.

I love applying Real Option thinking to things to see what pops out. This is an example of how Real Options makes proving Theory of Constraints really simple.

A few weeks ago Marc Burgauer (@Somesheep) introduced us to Klaus Leopold’s excellent boat game to demonstrate the benefits of limiting WIP and its impact on lead time. The game is elegantly simple, a line of people take turns making origami folds to turn a sheet of paper into a paper boat. Each person does the same one or two folds each time. The last person records when each boat arrives since the start of the exercise.We had a bit of a challenge to get the point. i.e. The rate of completing things remains the same, but the lead time becomes stable and predictable. After some discussions, Marc, Nick Poulton and I decide to modify the experience to hit people over the head with the results. We modified the game to record the time at which each boat was started as well as the time at which each boat was finished. Then we plotted a Cumulative Flow Diagram of the start and finish times…

When you push work into the system, you build up work in progress (inventory) and the lead time increases.

Next you introduce single piece flow and plot the start and finish times…

This results in a fixed amount of work in progress (inventory) and a fixed lead time.

IT DOES NOT INCREASE THE RATE AT WHICH VALUE IS DELIVERED! THAT IS FIXED.

Any additional work (investment) entered into the system above the finish rate is waste. It simply builds inventory. The area in the triangle formed by the two start lines (red and blue) below is pure waste. It is investment that is trapped in the system that is not generating a return.

I plotted the graph to complete each item of work as it moved through the process. To do this I considered that there are two ways to express the rate at which a process can be expressed.

1. The number of widgets in a fixed time.
2. The amount of time a widget takes to process.

We tend to use the number of widgets in a fixed time. It is easier to discard the time elements and easier to compare one rate to another. In software development, we refer to velocity which is the number of widgets in a fixed time. Plotting the graph of each work item is easier when you use the amount of time a widget takes to process.

One thing that jumps out at you is that the rate for finishing a widget is the same as the rate of the slowest process step. This is not intuitive, especially when the process is a network rather than a linear set of steps. But why was I surprised? This is surely just the Theory of Constraints.

And then I realised. Theory of Constraints was a belief for me. It contained uncertainty. I did not know for certain that it always worked, in all situations. I had doubt and because I had doubt, I did not always apply it.

So I created a reasonably complicated network process:

<Warning – Possible bad maths ahead. I’ve not checked this with an expert yet>

And I created a spreadsheet to see how long it would take things to complete. This is where Real Options thinking came in (or value stream mapping if you prefer) and we work backward from the end of the process to the start. For each process step, the time to the end of the process step Pn(k) is:

1. The time to complete the process step T(Pn), plus
2. The earliest time the process step can start.

Pn(k) = T(Pn) + ET(Pn(k))

The earliest time the process step can start is the latest of:

1. The time the previous Pn piece of work finished ( Pn(k-1) )
2. The latest time the preceding x process steps finished

Therefore the earliest time the process step can start is:

ET(Pn(k)) = MAX ( Pn(k-1), Pn-1(k) … Pn-x(k) )

The rate for Pn (expressed in seconds per widget) is

Rate(Pn) = MAX ( T(Pn), Rate(Pn-1) …. Rate(Pn-x) )

This leads through recursively to

The rate for Pn (expressed in seconds per widget) is

Rate(Pn) = MAX ( T(Pn), MAX(T(Pn-1), Rate(Pn-y), ….), MAX(T(Pn-x), Rate(Pn-z) )

As the MAX function is associative, We can write

Rate(Pn) = MAX ( T(Pn), T(Pn-1), T(Pn-x), T(Pn-y), T(Pn-z) )

i.e. The rate for any process step is the max rate (expressed in seconds per widget) of itself or any preceding process step in the graph.

<Math note – I’m not up to snuff on how you annotate graphs. Hence its a bit of a mess.>

Conclusion – Theory of constraints is not a theory. It should be easy to prove mathematically by someone with better math and more rigour than me.

It also means that pushing more work into a system beyond the rate of the constraint is quite simply a waste of money. IT Executives should be judged on the rate at which money is invested into the IT department and the rate at which that investment delivers value. In effect, a CFD based on money in and money out which is just another way of representing lead time.

If you want a copy of the spreadsheet, leave a comment here, or ping me on twitter.

UPDATE – The following example has a rate faster than the constraint.This is due to inventory building up behind the constraint before work items through the other path reach the convergence process point (P4).

It looks like it still holds over the long run in the steady state. Need to think more about the start up phase and the implications of that.

More details to follow.

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.

One of the key risks that organisations need to address, is building the wrong thing. No one willingly builds the wrong thing, so why do Product Owners build the wrong thing?

The first question to understand is “What is the wrong thing?”. The wrong thing is building anything other than the right thing?

So the second question is “What is the right thing?”. The right thing is a subjective decision based on the context of the organisation and the needs of the customer. At least Product Owners always prioritize the building of what they think their customers or organisations need. Or do they?

There is a nasty cognitive bias built into most organisations that Executives need to actively manage. That bias is your architecture and organisation structure. Everyone knows that it is easier to deliver something if only your team is involved. They know that involving another team in their department is harder so will try to avoid doing that. They know that involving another team in another department or division makes it even harder, almost impossible in fact. So as a result the way that many product owners approach the problem is not to ask “What does the customer need?”, they ask “What does the customer need, that I can do with my team or another team in my department?” As such, the Product Owner is more focused on their capability than the needs of the customer. They will (often unconsciously due to the culture) pre-filter those things they know are hard to deliver.

So the answer is simple, the reason why building the wrong thing is so so easy, is because building the right thing is hard.

Some Agilistas around the world have attempted to avoid this problem by creating “autonomous product” groups such as Spotify’s Tribal Model or SAFE’s Agile Release Train. My experience is that no matter how hard you try to architect your product solution to remove dependencies, there is always a customer or organisational need that crawls out of the woodwork that requires work by two or more groups. There is always a new regulatory regime, or a new way of servicing the client, or a new operating system that requires coordinated changes across multiple “autonomous product” groups.

So instead of trying to build autonomous product groups, or constructing projects from scratch, lets consider a middle ground. What would that look like?

1. Create long lived teams based on a carefully (and continuously) thought out but dynamic architecture. Smaller components supported by a handful of teams are more stable than massive chunks of the business.
2. Use Quarterly Capacity Planning to optimise the delivery of value from the portfolio, and make it easy to pull together teams needed to deliver the customers needs. Ensure that all of the business have an agreed ordered backlog.
3. Understand that pulling together a group of teams who do not normally work together is constructing a value stream from scratch. Get the teams to collaborate and coordinate using “scrum of scrum” stand ups and regular retrospectives (rather than plan up front). Assign responsible to facilitate the collaboration and coordination to an individual for each piece of work. Make it easy to reassemble groups of teams by doing it frequently as required by the work rather than try to avoid it.
4. Build what the customer and organisation need rather than build what is easy.

This was the approach Skype took to managing the risk of building the wrong thing. We may not have built the right thing every time, but at least we did not build the wrong thing because it was easier than building the right thing.

Its another genius thing worth studying that Mark Gillett created.

Estimates are crack cocaine for managers and executives. Estimates are an emotional crutch that give managers an illusion of control over an inherently risky process. As well as being an expensive waste, estimates can drive unhealthy behaviour in teams. The problem with estimates is that there are different forms of estimate that are appropriate for different decisions and different levels of understanding, and unfortunately managers do not always use the appropriate estimates.

To begin with, an estimate is a “tea bag”, it is part of the solution needed to create an output for the manager. The output is required to satisfy a need for the manager. There are two outputs from an estimation process:

1. How much will it cost?
2. When will it finish?

In actual fact, you need to answer the second question before you answer the first.

The cost of an IT investment is the duration of the investment multiplied the day rate of the investment. Consider a team of eight developers who spend half of their time on support and half on new investments. In addition to the developers are a product owner, UX, managers, etc. amounting to a further sixteen head count on the project. If the investment is estimated to run for a further thirty days, then the cost will be 30 * 20 person days = 600 person days. i.e. All the people involved in the investment rather than just the four developers. That is why an understanding of Theory of Constraints is so important to managers, especially those who have been trained in cost optimisation which tends to create constraints and increase costs.

So the cost of the based on the duration of the investment, or rather, when will it finish. How do we determine that? There are two measures we can use:

1. Count of stories
2. Story Points

According to the work of Todd Little and Troy Magennis, there is little extra accuracy using story points over the count of stories. However there is a real advantage of the story count as it is available much earlier in the process than the story points. A reasonable estimate of the count of stories is normally available very early on in the process. Story point estimates are normally available about a sprint before the story is developed. That is, after the product owner has worked with the UX and Data dudes in the Product Owner Squad to create the prototypes, test them with users, write the gherkin format acceptance criteria and then slice the epic into stories that can be estimated by the team in the product refinement session. The alternative is to create a whole bunch of pure waste to create faux story point estimates much earlier than they should be available. Faux story point estimates that are not following the normal process and are thus not really story point estimates, and provide a false level of comfort.

Estimating when an investment will finish is best done by looking at a Cumulative Flow Diagram and projecting based on the rate stories are being created and completed. Consider the following Cumulative Flow Diagram. The black dotted line is “now” and the red dotted line is when the investment is due to finish. The red dotted line is calculated by projecting the rate at which stories will be created and finished. (Troy Magennis’s “Cool and Fabulous Spreadsheet” does something similar with numbers instead lines, and in a much more grown up way using statistical confidence intervals).

A week later, the manager looks at the CFD and sees that the estimated finish date has moved because the rate at which the stories have completed has increased. This may be because the amount of support work has reduced due to higher code quality, or because the team are improving and going faster. The manager can investigate and potentially identify changes to the process to improve the estimate of the number of stories.

A week later (in an alternate reality), the manager looks at the CFD and sees that the estimated finish date has moved because the number of stories has increased. This may be due to unforeseen functionality, or because a story was more complicated than expected and needed to be broken down. The manager can investigate and potentially identify changes to the process to improve the rate of delivery of stories.

A week later (in yet alternate reality), the manager looks at the CFD and sees that the estimated finish date has not moved because the number of stories has increased but that has been offset by an increase in the rate that stories are completed.

As well as understanding that there is a change in the estimated finish date, the manager can understand the source of the uncertainty that has created the change.

Now lets consider the same graphs drawn using story points. To begin with, we need to get some “experts” in room to estimate all of the stories, because we would not want to get the whole team to give an estimate as that costs too much. That means we have guess what the stories will be (before user testing and all that). Our “experts” will only be too pleased to provide a story point estimate, even though it is not a story point estimate. It is an expert “estimate” rather than one by the team doing the work, and it is not based on a “Definition of Ready” story, its a faux story point estimate. This means at some point during product refinement, the estimate will change to a real story point estimate and we will have some stories estimated using story points and some using faux story points. This mixture of story point methods is misleading and as a result, the manager will pressure the product owner to complete all the stories to a state of “definition of ready” so that they can get a reasonable estimate. There is no sensible* intervention that a manager can do to improve the quality of the estimates.

( * We could adopt a waterfall approach to creating stories. In order to improve the estimates, we could increase the risk and cost to the organisation substantially which isn’t really sensible ).

Even worse, there are now three reasons for a change in the estimated finish date, as well as the number of stories created and completed, we now need a third dimension for the change in story point estimates. In other words, to understand what has happened, the manager needs to study two graphs** and the difference between them. What was obvious on the CFD, has now become complicated to understand and needs an “expert” consultant to explain. This lack of transparency leads the manager to fail the Agile Risk Framework Audit that requires them to know and understand what is going on in their investment.

( ** I tried to think how you would represent in a useful way this but gave up as it was too complicated, and it was silly anyway)

One day, the manager has a revelation! Instead of using faux story point stuff to estimate the finish date (and hence cost), lets encourage the product owners to write stories of a broadly similar size. From now on, the largest story allowed will be an “eight” (or a “five” for teams with one week sprints). No more stupidly massive “thirteen” or “twenty” stories. That will mean I can get my estimates for free without any stupid and wasteful “faux story point” estimation sessions.

So if you consider yourself a competent manager, go read Todd Little and Troy Magennis stuff on estimation and prediction.

Todd Little Key Papers

• Story Points versus Story Count
• Uncertainty surrounding cone of uncertainty