Making a business case for agile starts by understanding what agile is about and considering how agile can help you. You have to define your own metrics and track them to see if agile is bringing you business value, and reflect on your agile journey to learn, and adopt.
Your mileage may vary
Over the years I’ve heard many managers wanting data that shows the business value of agile as a whole. They look for things like:
- Agile is xx% cheaper
- Agile makes you yy times faster
- Agile will give you zz% less defects
It doesn’t make sense to think of agile as “a thing” that delivers a specific value that you can know up front. Yeah, if agile would just do that, that would be easy, but it simply doesn’t work (literally) that way.
Agile is not a thing that you implement, it’s a mindset and a collection of values, principles, and practices, that you apply where the results will vary depending on the situation and specific needs of your organization. Which is actually good news: Agile does bring a lot of business value if applied in a sensible way.
People who like to see business value stated in the above format might think of agile as a silver bullet. It isn’t, as the agile manifesto clearly states:
We are uncovering better ways of developing software by doing it and helping others do it.
The word “uncovering” implies that there is no right answer, and we will never find one. Trying to look for the one best solution is futile, it’s a waste of time and energy and you will only frustrate yourself and other people. Stop doing it!
Why do you want to become agile?
Organizations have different needs, different problems, that they need to solve. Where in one organization it’s essential to deliver faster because the competition is attracting more customers that you are and stealing market share, for another organization quality can be key because customers are walking away and switching to the competitor’s products.
You need to find out why you want to become agile and what the specific business benefits are that you want to aim at. Is is faster delivery, more innovation, better quality, empowered employees, or reduced costs? Think before you start!
Thinking of agile as a framework which you use to replace your processes will not help you to get real benefits out of agile. We know this from organizations that implemented CMMI as just another process, or any model or framework. You need a culture where agile helps you to continuously improve and increase your business value.
Exploring the business value of agile
There has been little quantitative research into the results of agile. We cannot prove that agile works better than traditional methods. There’s still insufficient data on which agile practices are useful in which situation.
If you want to make a business case for agile, my suggestion is to define your own measurements. Know why you want to become agile and quantify your needs.
If faster is key for you, how would you define and measure faster? Does it have to do with the time between a request entering the IT department and delivering new functionality to the business part of your organization? Or between recording a first customer signal of something that is needed and having it used by a significant number of customers? When do you get the value?
Your definition will impact the way that you need to implement agile, so spend enough time to make it good (or good enough for now and safe enough to try).
If you want to increase the quality of your product with agile, then I suggest to read The Economics of Software Quality to explore how to define quality and build a business case. A book that I recommend if you want to invest in improving your software products is Value-Based Software Engineering.
The Business Benefits or Agile webpage contains reports of research and studies on the results of agile, containing data that you can use to create a business case for the goal you want to achieve with agile. If you need some help with that, feel free to contact me.
As a note aside: Most organization tend to measure too little or the wrong things. Be aware that not everything that can be counted counts, and not everything that counts can be counted. Many organizations don’t know how to analyze the data, draw conclusions and take actions. Any ideas on we can improve that, and support agile adoption with measurements are appreciated. If you have them, feel free to comment on this post!
Traveling the agile journey
Although measurements are important, as they are one the prominent tools use by CxO to manage organizations, I’m unsure how a change in measurements by management or engineers could help us to get a change in mindset. I prefer to do it the other way around, first focus on the mindset and the agile values, then think about your business needs and quantify them. To become agile managers must think agile.
Becoming agile is not a project with a fixed deadline and an upfront known investment. It’s a journey into continuous improvement that never ends.
My suggestion is to focus on how you travel it. When you want to start your journey, think about what to pack. There’s the agile journey backpacking exercise that helps you to prepare for your journey.
Becoming agile will be a learning journey. It’s not about reaching a goal, it’s eagerness to keep getting better by reflecting, finding out what doesn’t work and what does.
Making a Business Case for Agile
Summing up here’s my advice if your organization wants to go for agile and needs an business case:
- Start by understanding what agile is about. Get familiar with the agile values and principle, dive into agile practices, and consider what and how they can make sense for your organization. An agile awareness session tailored to your organization’s needs can help you to get through this stage.
- Know why you want to become agile, your specific needs, and quantify that. Define your metrics and start tracking them to see if agile is bringing you business value.
- Become agile by reflecting on your agile journey, learn, and adopt.
How did you make a business case for agile?
Originally published at Ben Linders.