ROI of Agile implementation

This article is part of my Better Return On Investment from Software Development series.
These articles are aimed at senior management funding Software Developer or IT Professionals attempting to show the ROI benefits of what can sometimes seem counterintuitive.
This ever growing library is provided free of charge and can be found here.

In this article, part of my series explaining better ROI from software development, I’d like to look at the implementation of Agile.

I’ve written previously about Agile in these two articles:

In those articles I look at the principals behind Agile. In this article I wanted to start looking at how you turn those principals into day-to-day actions.

Vision to action

It isn’t uncommon in business to tie your guiding principles to day-to-day actions.

If anything, that is exactly how a successful business should be working.

A business should exist for a reason. We generally express that is a vision statement or similar.

“A vision statement is a company's road map, indicating both what the company wants to become and guiding transformational initiatives by setting a defined direction for the company's growth.” Wikipedia

From that very board high level guiding principle, you would then define a business plan to deliver that vision.

“Why you need a business plan. A business plan is a written document that describes your business. It covers objectives, strategies, sales, marketing and financial forecasts. A business plan helps you to: clarify your business idea.” GOV.UK

That business plan is then broken down into finer granularity as it filters into your organisation and departments.

At some point you will have operational procedures which define the how to perform a particular action. For example you may have an on-ramping procedure for new customers.

In isolation, that procedure makes sense within its own boundaries. However, without the context of the business plan and vision statement, it isn’t always clear what value this provides to the organisation as a whole.

Agile implementation is very similar;

You have a vision; the Agile manifesto as mentioned in my previous articles.

You have a plan similar to a business plan. You actually have a number to choose from – they define the rough shape of how Agile can be implemented.

You then operational procedures in terms of specific actionable techniques which will help to achieve that plan which helps to make you Agile.

Bottom up or Top down?

The astute of you may now be asking the above question.

If the concrete steps help you to become Agile, should you start there? Or do you set the vision first?

Consultant answer – it depends.

There is no right or wrong way to do this. Each organisation is different and as such it is somewhat foolish to assume that a one-size fits all.

In some organisations, I would suggest they start with their development teams implementing Agile principals and processes locally. Getting used to them, and then expanding out to the winder organisation.

This is certainly the way most organisations seem to have gone – but that maybe due to the maturity of Agile. It has grown up and out of development teams. Only more recently are we seeing organisations starting from the top.

Certainly it can be easier for teams to implement if they are supported and encouraged from the top. One of the biggest problems you’ll find with Agile is when it crosses borders with more traditional project management. There is very little more soul destroying that to have any Agile benefits lost as it is translated into more traditional project management (generally poorly) as it goes up the management chain.

So if I was going to generalise on an approach;

Train everyone from top to bottom on the approach. Gain a consensus behind why this is good and that there is support for it. Then incubate it within a select number of teams and grow it out.

There is such a change to mindset here that this can (and is correct to) take time to establish itself across the organisation. Don’t be surprised if this is years rather than months.

The only path to the top of the mountain

I’m not going to pretend that Agile is the only way to get a successful software project.

We have been delivering successful software projects for years with a variety of methodologies.

And indeed it is also true that some Agile projects fail.

The general consensus though is that you have a higher chance of success with Agile. I’ll dig into that more in a future article, but for now I just want us all to be aware that Agile is not the only way.

And this is the same with the analogy I’ve been using of a vision statement. We all know that we should have a vision statement. We all know we should have business plans and supporting practices aligned to that vision. Their absence however certainly hasn’t stopped some successful businesses.

(Although you have to ask how successful they could have been … we will never know)

Where next

This article is rather short for me … but I felt a need for a bridge between the mindset/ vision of Agile and the methodologies and practices that support (or adhere).

In future articles I will look at:

And there are plenty more that can help your organisation achieve that Agility.

Each one of these can help you to achieve a level of capability and mastery within your software development. All are easy to understand, but difficult to master – but the benefits are there to be had.

Regardless of what may have been marketed to you, becoming Agile is not an easy process. The more you adopt it the more it changes the organisation. This can be an incredibly disruptive and expensive process.

I do however feel that the rewards are worth it and I will continue to explore this in future articles.

About the author:

Mark Taylor is an experience IT Consultant passionate about helping his clients get better ROI from their Software Development.

He has over 20 years Software Development experience - over 15 of those leading teams. He has experience in a wide variety of technologies and holds certification in Microsoft Development and Scrum.

He operates through Red Folder Consultancy Ltd.