In Blog

It is a well-known fact that Agile projects deliver value early. The excellent book Software by numbers showed how software development is linked to value creation and can be optimised through incremental delivery to improve return on investment (ROI). David Rico went on to show in his book The Business Value of Agile how Agile projects have delivered on average a considerably higher ROI.

We (Paul Dolman-Darrall and Joshua Arnold) had seen lots of anecdotal evidence which supported these claims and yet in our search for business cases for Agile, we failed to find an approach which calculated the benefit of increasing how often we release to the customer. Instead we often found badly calculated business cases which focused on non-existent cost savings rather than improved value.

One of Emergn’s clients led by Chris Berridge challenged us to solve this problem; Write a formula that can be used within a business case to show the benefits of faster delivery (increments).

Through three days of solid maths, several arguments, falling out and not talking to each other and quite honestly our client helping us solve the problem, we created the Berridge, Arnold, Dolman-Darrall formula – better known as the BADD formula.

The results are very exciting, leading to a very simple formula, which has so far stood the test of time. This leads to an astonishingly strong business case for the implementation of Agile without any assumed benefits from productivity. This has to be combined with other information we use to determine whether increments will lead to increased costs. The formula is here …

1/2 (1 – Cn/Co)

Cn = New Cycle Time or Split Down Delivery Time
Co = Original Cycle Time or Delivery Time

For example, if a company takes 180 days to deliver something, delivering that in two increments of 90 days leads to the following result.

BADD Formula

So if the current cycle time is 180 days and the new projected cycle time is 90 days. We get the following results.

Cn/Co = 90/180 = 0.5

then Percentage Increase in Benefits = (1/2 (1 – 0.5) ) = 0.25

This means there is a 25 % Increase in Benefits.

It almost becomes impossible when applying this information not to consider breaking down work, and agile provides the best way for managing these increments through iterations. Of course, the formula has many assumptions, for example, it assumes we can bring value forward, that bringing something forward does not mean doing the highest value work first, that there will be no productivity gains, and that we will suffer no increase in costs amongst others and that every cycle ends in a release. Yet it provides a formula showing the power of increments.

Nothing like this, comes without some debate. We will post another blog with a similar formula showing how you can calculate the differing values of each cycle from one of my colleagues in the coming days.

Recommended Posts
Showing 5 comments
  • Bob Marshall

    E=mc2 is a formula. BADD, whilst interesting, is a hypothesis. Until you can explain the underlying causations.

    – Bob

    • Paul Dolman-Darrall

      It’s based on the work of Mark Denne and Jane Cleland-Huang – that discusses the underlying causations. This aimed to turn that into a formula that could be used to quickly calculate the value (with a set of assumptions).

    • Joshua J. Arnold

      A hypothesis is a proposed explanation of something. We’re not trying to explain that getting a portion of value early (and therefore starting to generate benefits earlier) is valuable – merely calculate what it would be worth, if it is true. Thus the formula, which simply attempts to show the relationship between a bunch of variables.

      Have you found that the idea of getting value early (and often) has required a lot of explanation? Maybe we need to put together a good explanation for this?

  • Mike Burrows

    I suggest and attempt to justify a formula for a lower bound to the cost of delayed delivery here:

    Will you be explaining how your formula was derived?
    – Mike

    • Paul Dolman-Darrall

      Yeah cost of carry is interesting.

      I would be happy to provide more details on how the formula was derived and its use. I will find some time to write that up.

Leave a Comment