Posted on

The aggregation of marginal gains

As you might know, I spend a lot of time travelling in the car, and I have a lifelong interest in aviation. So to pass the time, I listen to a lot of podcasts, some of them aviation related.

One podcast I subscribe to is Fast Jet Performance, created by Tim Davies. Tim is a Squadron Leader in the Royal Air Force who has been flying fast jets for almost 20 years. His podcast is fundamentally about how you can optimise your performance in and out of work, often with aviation related analogies.

Recently Tim touched on the subject of The Aggregation of Marginal Gains. I won’t copy the detail of what Tim covered (visit his site to hear the podcast), but this resonated with me in my role as a coach and mentor for teams and organisations wanting to optimise delivery of value, often using Lean/Agile approaches.

One key aspect that I help clients with is the vital importance of feedback loops.

Agile delivery is all about the early and frequent delivery of small slices of value and one of the benefits of this way of working is the ability to continually test assumptions by getting feedback on what you’ve delivered to customers so far. That mitigates the risk of you working very hard to deliver the wrong thing.

Releasing early and often also tests the entire delivery process, from concept to cash. Far better to learn where you have problems in testing, integration and operational support quickly with those small first slices, than getting unpleasant surprises near the end of a traditional project, when it may be too late to sort things out without compromising the budget and timescales.

The way that individuals and teams are working together is regularly inspected at retrospectives. At the end of each retrospective, the team identifies actions that will help them to be more effective. At the next retrospective, the team should be honest and review if the actions were carried out, and what impact there was.

These are all elements of feedback in Agile delivery.

Something I often see with clients new to this way of working is an unrealistic expectation of rapid dramatic improvements. It doesn’t work that way.

Sure, in the very early days, the adoption of collaboration, colocation, information radiators and other basic aspects of Agile delivery will often provide really significant improvements in ways of working, but it is the employment of the principles of Inspect and Adapt by means of feedback loops that embed marginal continuous improvement across the board into teams and organisations.

Marginal Continuous Improvement Across the Board – that’s the key phrase to bear in mind.

Agile organisations understand the importance of metrics, so I’ll use some to explore a hypothetical scenario.

Let’s consider a team working in a cadence of two week sprints, with a retrospective at the end of each sprint. After each retrospective, the team implements simple actions that make them just 2% more effective in the following sprint.

After three months, they’ll be 12% more effective. This is often where those unrealistic expectations that Agile delivery is a ‘Silver Bullet’ start to surface.

But if the values, principles and practices of Agile delivery continue to be applied, and those 2% improvements continue, things start to look very interesting.

After six months, the team is nearly 30% more effective, and after a year, they are over 60% more effective.

What would your organisation look like if it was 60% more effective one year from now?

In summary, short feedback loops and small, positive improvements are at the heart of optimising delivery of value. Just don’t expect too much too soon, and KEEP GOING.


Posted on

Prioritising the portfolio – value modelling

Note: I first published this post on Linkedin in July 2015. – Col.

I’ve often seen organisations start the transformation to become agile and to focus on a model of accelerated delivery of value. Starting small, a pilot team learns this new way of working and (in a limited way) the organisation sees the benefits of accelerated delivery.

The urge then is to scale, with multiple teams all aiming to replicate the early successes. This can be challenging. At a portfolio level a backlog of ideas for products and services will exist and potentially will grow.

No organisation has unlimited capacity – all have limits to the amount of work in progress. Therefore, it’s important to prioritise this portfolio backlog of potential products and services, just like we do for features and capabilities in a team backlog.

Let’s recap on some fundamentals that organisations need to be mindful of if they are focusing on accelerated delivery:

  • Don’t do things that add no value
  • Focus on finishing the highest value things first
  • Make decisions based on metrics
  • Accept that metrics improve over time – start with what you have
  • Use feedback loops and make them short

So, the high-level portfolio prioritisation needs of an organisation might be expressed like this:

  • The highest value things are prioritised for completion
  • Resources are directed to the place where they will deliver the most value for the company
  • We can measure the relative value of work being delivered across teams
  • Senior leaders can make informed decisions on when and where to redeploy people and money to focus on the highest value waiting to be delivered

How can an organisation meet those needs? We can create simple models to:

  • Forecast the potential cost/value ratio of delivering a change
  • Compare the relative value of things not yet started
  • Compare the actual return on investment against the forecast
  • Make more informed decisions on what to start next, what to finish first and what to stop now

Types of Work

Fundamentally, work can have value in three ways:

  1. Work that mitigates risk to the company
  2. Work that delivers cash value to the company
  3. Work that enables delivery of type 1 or 2 work

We can create models for each type of work that help us estimate in advance:

  • How much it will cost to complete the work
  • How much value there is in the work
  • When the value will be delivered to the company

At a simple level, the different types of value models have different profiles.

Risk Value Products and Services

A Risk Value Product is one where the majority of the value delivered by that product is by mitigating risk. Example risks might be legal non-compliance, health and safety of staff or reputational damage to the company.

The profile for a Risk Value product or service might look like this

Sample Profile for a Risk Value Product or Service

 Enabler Value Products and Services

Enabler Value Products deliver most of their value by allowing other Products and Services already in the Portfolio to be delivered. An example might be to select a 4G network provider across the enterprise, enabling a range of mobile products for staff to be developed, that in themselves deliver cash value or mitigate risk.

The profile for an Enabler Value product or service might look like this

 Sample Profile for an Enabler Value Product or Service

Cash Value Products and Services

Cash Value Products and Services deliver most of their value in direct financial terms, such as cost savings or increased revenue. I’ll go into a little more detail on Cash Value Products and Services.

We need to consider how long we will count the value realised before we say, “This isn’t a new thing any more, it’s just how we do business” otherwise we’d be measuring the cash value of a new product or service indefinitely, which would be unrealistic. So we might say, “Two (or some other period, depending on the product) years after the delivery starts, we won’t measure the value realised any more”. This is a very important factor in assessing the ROI on a piece of work.

Now let’s compare two profiles for the delivery of the same Cash Value Product. One Profile will reflect a traditional, “Waterfall” approach and the other will reflect an incremental, iterative agile delivery approach.

Approach 1 uses a traditional delivery model:

  • Small team on 1 year delivery timescale
  • Phases of design, development and test
  • Big bang release near the end
  • Value delivered snapshot after 2 years from work starting

The Profile looks like this.

Sample Profile for Approach 1 – Waterfall

Now let’s consider the delivery of the same Product using an agile, iterative, incremental approach. This is Approach 2.

  • Small team on 1 year timescale
  • Cross-functional team
  • Small incremental releases every month
  • Value delivered snapshot after 2 years from work starting

The Profile for Approach 2 looks like this

 Sample Profile for Approach 2 – Agile

If we do a comparison of the key metrics for the two different approaches, we see some important differences.

Approach 1 – Traditional

  • Cost of team = £316k
  • 1st value delivered = M11
  • Breakeven = M16
  • Net value realised 2 years after work started = £424k
  • ROI after 2 years = 133%

Approach 2 – Agile

  • Cost of team =£316k
  • 1st Value delivered = M1
  • Breakeven = M10
  • Net value realised 2 years after work started = £722k
  • ROI after 2 years = 227%

However, it’s important to note that the improved ROI in Approach 2 is only realised if value is delivered early and often.

Metrics needed for models

To develop these models, we need to estimate some key metrics about the work and the product or service being considered:

  • The size and composition of the team needed to deliver it
  • The duration we estimate it will take to deliver it with that team
  • The frequency and incremental value of each release
  • The time when we will no longer measure the value of the product

Preliminary work needs to be done before that estimation can take place

The use of Vision Boards and Product Roadmaps will provide important pointers to the overall business value model and prioritisation of features and capabilities.Roman Pichler’s excellent work in this area will provide advice and guidance (as well as tools) to help define the overall proposition for a product or service. This initial definition will give you enough to start assessing the estimation metrics I’ve described above and begin creating a profile.


Comparing profiles

Once a profile has been created for a proposed product or service, it can be compared with others waiting in the portfolio backlog.

Senior leaders can then rationally assess the relative value of work not yet started, and fundamentally decide one of three things for each profile:

  1. Don’t do it – the value proposition isn’t strong enough
  2. Do next – it’s the most valuable thing in the portfolio backlog
  3. Do later – when it becomes the most valuable thing in the portfolio backlog

Comparing Profiles to aid prioritisation of the portfolio – Product A delivers better ROI than Product B

Tracking profiles

Once work gets underway, the initial baseline profile (that informed the investment decision and the prioritisation of starting the work) can be compared to the actual value profile that emerges as things progress. This allows senior leaders to make measured decisions on whether to continue the work on a Product or Service or to terminate it (because it is not delivering the value expected or because enough value has already been realised).

A Product not meeting expectations of value – Fewer releases and higher delivery costs than forecast

Apples and oranges – comparing Risk, Enabler and Cash Value profiles for prioritisation

A portfolio will inevitably comprise of a mix of the three different types of products. Comparing one Cash Value profile against another is relatively straightforward, as described above. But how can you assess Risk profiles against one another, Enabler profiles against one another, and a mix of all three?

Comparing Risk Value products

You could use a simple matrix with a scoring system to rank the most valuable Risk Products against one another. A sample is below.

 A simple scoring matrix of categories of risk mitigated by different products

You may also be able to use existing risk assessment techniques to quantify a financial value of mitigating a risk – a simplistic example could be

“There is a 20% risk of us incurring £500,000 of fines within one year if we do nothing”.

Reducing that risk to 5% within one year might be worth say, £75,000. If the cost of the product to mitigate that risk is £100,000, you may decide to live with the risk or you may not. But you have applied some structured thinking to assessing the value of delivering the product, and you can compare the relative value to other items in the portfolio.

Comparing Enabler Products

Enabler products might be quantified by applying a percentage of the value released by the Risk and/or Cash Value products that are blocked until the enabler is in place.

If an Enabler product will cost £100,000 to deliver, unblocking one Cash Value Product in the portfolio with a projected Net Cash Value of £90,000 over its measured value period, you probably won’t do it.

But if the Enabler Product unblocks that £90,000 Net Cash Value Product AND a Risk Product that will have a net mitigation value of £30,000, it starts to make sense to deliver the enabler.

Again, the metrics won’t be perfect, but it might well be better than what you have in place right now, and it gives you an evolving toolset to compare the different types of Products and Services in the portfolio. 

It needs to work for your circumstances

There is no simple once size fits all approach to this. Your organisation will have to determine the best approach to apply. Then try it, review it, and adapt it periodically to get it better.

When to review your portfolio profiles

How often you should review new profiles looking to enter the portfolio backlog and benchmark “in progress” Product work on actual value realised will vary from organisation to organisation.

I’d suggest perhaps every one to three months. More than one review a month will create too much reporting overhead.

Waiting more than three months between reviews risks waste, because of a lack of feedback, and a product that potentially delivers enormous value could languish in the shadows for too long.


Having read this far, I commend your perseverance. I have covered quite a range of topics. If you only take away one piece of information from this article, I suggest it should be the following points:

  • Organisations can’t do everything at once
  • The portfolio must be prioritised on value
  • Metrics should drive prioritisation
  • Metrics should check if reality meets expectations
  • If a Product is failing to meet expectations, consider stopping the work and redeploying people and money on to high value work not yet finished

If you lead an organisation, you have a portfolio backlog. It just may not look like one yet. In amongst the dozens of ideas and concepts, there are quite possibly one or two that will deliver more value than all of the others combined. This approach for assessing and prioritising the portfolio backlog will help you identify those gems, and weed out the lame ducks.

End note

The foundations to this idea are not new. I’ve drawn upon many concepts such as the Cost of Delay, Real Options and Black Swan Theory amongst others. I don’t claim it to be perfect either – far from it.

But if it has delivered value to you in thinking about how to prioritise and track the delivery of products and services based on value, and it has stimulated you to talk to colleagues about how you might go about it at a portfolio level, I’m happy.


I’d like to thank the colleagues I’ve bounced these ideas off over the last few months, in particular Kenny Grant of GrantWorks Blue, a trusted friend and excellent coach, and Alan Simmonds of Preterlex, a terrific man with enormous experience and a very gifted mind.

Posted on

Agile product development for Startups (Part two) – Getting the initial Product Backlog

Note: This post and its companion were first published back in July 2014 after I was approached to provide a primer for startups.  I think the content still holds true today, and as this site is changing direction for 2016, I thought it worth reposting here. – Col.

In the first part of this article, I provided some high level steps to get you from an idea to a user-centred Product Vision supported by personas.

In this final part, I’ll touch on one of the tools you can use to build on those artefacts and get an initial version of the Product Backlog.

Now, irrespective of how you are going to deliver this product or service, you will need two vital foundation elements to make sure you build the right thing, and build the thing in the right way.

The first is a business value model. What are the goals you are trying to achieve from this product or service? You should have a pretty good idea of these from the work you did in defining the Product Vision.

The second element is a list of the critical success factors that will determine if you have met those goals. In short, how are you going to measure if you are delivering the value you want, and how are you going to ensure that you are not wasting time and money over-engineering this to a point beyond what is actually needed. Agile organisations and teams are focused on delivering “just good enough, for now”, and no more.

A simplistic example might be to have a goal for the next car you are going to buy of “carrying my immediate family”. Initially, that might be just you and your partner. You only need two seats. But over time, your family may well grow, and you’ll need more seats. But you don’t need them right now.

The element of time, and the order in which the product or service may evolve over time is missing from the Product Vision. So we move to use the next Product definition tool in our toolbox – The Product Roadmap.

Again, I’ll refer you to the excellent resources made available by Roman Pichler. His Go Product Roadmap is an excellent tool, although of course other roadmap formats are available. The Go Product Roadmap was published late in 2013 by Roman, and I have recommended it to clients ever since.

I won’t go into the details of how to work with the roadmap, as Roman does an excellent job of that.

So I’ll skip forward in time to a point when you have completed your roadmap. I suggest you read through the presentation and explanatory material on Roman’s site before going further.

Now with your roadmap completed, you have versions of your product or service identified, each with a target completion date, goals, a high level list of features and the metrics you will use to track if you have met the goal for that version. It will look something like this

Product Roadmap Example

Now if you look at the features, goals and metrics across the different versions of the roadmap, and rotate them by 90 degrees, you might end up with something like this.

product backlog example

Let’s review what we expect to see in a Product Backlog, at a very basic level.

1.A Prioritised list of features.
2. Each feature should have an associated business value that aligns with
the overall business value model.
3.Each feature should have measurable success factors associated with it to
ensure we deliver to the right levels of quality – “Just good enough for
now, and no more”.

You have created a very high level Product Backlog!

Going through the steps in part one and two of this article will give you a simple framework to get you to this initial Product Backlog. It can be considered the Launchpad for the project.

Be aware though, that there will be a lot more work that will be done on reviewing and refining the backlog throughout the life of your project to make this brilliant idea into a successful product or service.

I wish you all the luck in the world.

Posted on

Agile product development for Startups – Part one – First steps

Note: This post and its companion were first published back in July 2014 after I was approached to provide a primer for startups.  I think the content still holds true today, and as this site is changing direction for 2016, I thought it worth reposting here. – Col.

So you think you have a brilliant idea that will become a hugely successful product or service. Congratulations!

But how do you turn that idea into a well considered, structured game plan for how you will turn your concept into reality?

Traditionally, you’d do a bunch of stuff around market research, business plans, big project plans and a whole heap of things before you get anywhere near building the thing. But you’re an Agile startup right?

In these short posts, I’ll be referring to the great work of Roman Pichler. I consider Roman to be at the top of the tree when it comes to Agile Product Management specialists. His site has loads of detailed background and resources on the areas I will just skim over.

So how do you quickly get from a concept to an initial Product Backlog you can start working with? Here’s a high level of the first steps you probably want to take.

Step 1 – Understand your users. You should create personas for the different types of user your concept is aimed at. A persona is a fictitious person who represents as closely as possible a typical type of user of your product or service. Personas are important because they remind you that you are developing a product for people, not generic user types like “Author”, “Editor”, “Administrator”, “System User” etc. In most cases, you’ll have multiple personas to represent the different types of people your product is for. Make your personas visible in your team space to remind you everyday whom you are designing for. You don’t have to define loads of detail up front. Your personas will evolve as you learn more about them through user testing and other forms of feedback. Here’s a short definition from the Agile Alliance.

Step 2 – Develop the Product Vision. In short, you need to define who are your users, what of their needs are you going to address, a super high level view of the capabilities your product or service will provide to meet those user needs, and finally, what’s in it for you? You should also define a one sentence “vision statement” to encompass the whole concept. A vision statement for YouTube might be “A free online video hosting, sharing and streaming service funded by advertising”.

The Product Vision is important because it provides scope boundaries. We know that things move in and out of backlogs as we gather insights and inspiration.

We may define a Product Vision for a new car, and as we learn more about our users and our needs, an initial view that they want four seats may change. They may want six seats, because in our target market, people often travel with the whole family. But it’s still a car.

However, if our Product Owner explains that we need to provide 50 more seats, spread over two decks, that’s not a car any more. It’s a bus, and that doesn’t fit within the overall Product Vision.

That’s not a bad thing. It doesn’t mean we say “No, we’re building a car, so we won’t do that”. If our users really need a bus, we should reset the product vision and the steps that follow it. What we have discovered is that the car is not the right product to build.

The Product Vision is also very important to align understanding and expectations early from stakeholders. If you are going out to angel investors or other routes to seed funding, the PV and other artefacts will be absolutely vital to get your concept across concisely and professionally.

Roman Pichler’s Product Vision board is a fantastic resource that I have introduced to many teams. I wholeheartedly recommend it. Here’s a link to Roman’s site.

Once you have your Personas and Product Vision established, you have a solid foundation to work from. The PV is vitally important, but it lacks a critical dimension – time. In my next post, I’ll explain how you build on the Product Vision to move towards creating that Initial Product Backlog.

Posted on

The Scorpion jet – Agile/Lean in military aviation

Scorpion for wp

Great product development starts from an understanding of the customer and a problem statement that describes the as is world in which that customer lives.

For Textron, their primary customer is the US Government, and the problem statement was that budgets are incredibly tight compared with the days of the Cold War and that the current generation of military combat aircraft are complex, expensive to buy and operate and designed for a war that no longer reflects the major threat to the defence of the USA.

So they took a radically different approach that illustrates some great practice in Lean/Agile thinking.  The end result was getting an aircraft from first concept to first flight in only 20 months (in comparison, the very complex and advanced F-22 Raptor took nine years), that costs a fraction of traditional combat aircraft (F-22, $150M each, Scorpion, $20M) and has an operating cost of less than 20% of those traditional jets (F-22, c. $20,000 per hour flown – Scorpion, c. $3,000 per hour).

What made those results possible included the following key principles.

  1. Focus on the minimum viable product.
  2. Wherever possible, reuse existing components, particularly those that take a long time and cost a lot to get off the drawing board, such as engines.
  3. Build a cross-functional team that are co-located and eliminate redundant processes, documentation and administration.
  4. Let the team self-organise and self manage.

To be clear, the Scorpion is not as capable as the F-22.  But, many of the missions that a more complex jet would have to fly at $15-20,000 per hour can be carried out perfectly well by the Scorpion, allowing the expensive aircraft to be used only when their advanced features are really needed, extending their operational lives and saving money.

Already, the team is attracting a lot of interest, and it’s likely that the Scorpion will be a major export success to friendly governments outside of the USA.

Here’s a webinar I delivered on the subject early in 2015.