The BADD Formula – a business case for Agile

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.

Related content