There has been so much hype and debate about Agile ways of working over the years that sometimes we lose track of the fundamental benefits to the business that can be found in the famed Agile Manifesto.

If you are a business owner wondering why your CTO is recommending you move to Agile, get better at Agile or even engage in an ‘Agile transformation’ you may be wondering what are the tangible benefits that are going to be received from moving down the agile path. If so, read on.

There are so many benefits of moving toward an agile model; in many cases it will make your software delivery quicker and more cost-effective and it should definitely help your company work together as a combined team in delivering software.  That said, how do you quantify and measure such abstract achievements?

Are you iterating?

It’s actually simple. With an agile process, gone should be the long delivery cycles, the phase 1, the phase 2 and the months of unreleased code and delays followed by further missed timelines and eventual disappointment that the software does not deliver what it was supposed to in the first place.

With a well structured agile implementation you develop your software iteratively. Your delivery team establishes a vision of what they intend to build but then they deliver that software in small increments of 1 to 2 weeks, or smaller. Each iteration should be demonstrable to interested stakeholders as an “increment of business value” and should ideally allow you to discover something about your customers as a result.

Are you improving?

As a sponsor you know the metrics you care about; sales, conversion, CAC, NPS? Your delivery team should also know all about these KPI’s – how they are measured, why they are important and the strategies you are using to improve them. Every story (item of work) they deliver should be based around improving these metrics and each showcase should review the effect of the latest work on these metrics.

Ideally, each iteration should deliver a way of measuring the value of your software and its impact on these metrics, but equally the gain may be in discovering a more accurate idea of how long the software will take to be delivered. At the very least it should allow the delivery team to share working software early with the stakeholders that are sponsoring the development so they can:

1. See tangible benefits being achieved
2. Ensure that there is alignment between the sponsors vision and those doing the building
3. Review agreed metrics to measure the rate of progress

For more on how an agile approach can transform the way your business works through iterative processes it’s worth reading Eric Ries’ The Lean Startup where he describes the approach of using a Minimal Viable Product (MVP) to test your hypotheses around your business ideas and projections.

An agile approach is unlikely to magically make your team deliver software faster immediately but.. if you are looking for simple metrics on how to judge your team’s adoption of agile look for the following:

1. Are the iterations relatively short (less than 2 weeks)?
2. Do you get to see an increment of business value released at the end of each iteration?
3. Are the estimates of what can be delivered becoming increasingly accurate each sprint?

Are you releasing to Production?

To achieve any of the benefits of the aims outlined above, your software must be released to a production environment to put the changes in the customer’s hands. If you are not releasing to Production, not only can you not measure the benefits of the changes in terms of impact to metrics but it may be that you are seeing an illusion of progress; the test version of the software you are reviewing may have undiscovered bugs or just not work in the real world. By keeping your iterations short and scope small for each release you maximise your opportunity to learn and minimise the likelihood of introducing compounding issues.

If you work as described above, it allows you as a sponsor to quickly determine if the return on investment is positive and consider changing course if not.

This article was originally published on the Pragma.Team blog