Getting buy-in on agile

So you've decided to adopt an agile approach to software development. Agile has plenty of benefits over more traditional methodologies like waterfall, with its focus on speed of delivery and working software - but chances are you already know that . What you need to know now is how to implement it.

This is no easy task - as with any behavioural change, you can't force people into it. Rather, you need to make a convincing case to the business about why agile is the way forward for your organisation, and you need to show your developers why it will make their lives easier, too.

Find people who agree with you

The first step is to find people who share the same goal as you.

"People are important as they are the ones that drive as well as adopt change," says Andy Cureton, MD of DevOps specialist ECS Digital. "Finding people that are tired of their current ways of working increases the likelihood of buy-in and adoption of proposed change as they will be looking for ways to improve."

Forming a small group (or groups) filled with these people, rather than focusing on people with specific knowledge of the projects you want to tackle, is essential.

But while it's key to identify developers who support an agile approach, it's harder to get the business to buy into it upfront.

"What we find is that by and large it's relatively easy to get the IT staff on board," says Nathan Wilson, principal research analyst at Gartner for agile development. However, business people used to a more confrontational relationship with IT will not be won over as easily.

"[Businesses are used to] an IT model that says every few years we will do a big project, make something a whole lot better, then go away", says Wilson. Asking businesses to adopt to a continuous delivery model, where improvements are fractional but constant, is a difficult jump for them to make.

"It's really hard for the business to do this because they are used to thinking 'if I don't get my change now I will never get it'," Wilson explains. "The strategic goal is to earn the trust of the business and to build on it."

Or, as Tirrell Payton, managing consultant at SolutionsIQ, a management consulting firm, tells IT Pro: "Organisations are like living, breathing beings in that they have 'organisational antibodies' that will seek to derail any major change and keep things the way they were. People hate change."

To gain business trust, the next step is to find a project that you and your developers can embark on to show how agile benefits the business.

Find the right project

However, picking that project is a difficult step itself. You probably don't want to take on an important IT project with a lot of risk involved for your first agile endeavour.

"You are pretty bad at agile the first time because it's completely different to anything you have ever done before," explains Wilson. "Do it in a controlled environment and build competency and then expand."

But while a small project is a good choice to try out agile, you also want it to demonstrate success, so your business people see the value of the approach.

"Pilots, proof of concepts and MVPs require minimum investment to demonstrate the potential for the organisation," says ECS Digital's Cureton.

Wilson added: "A most effective project to apply this to is one with very low expectations. If everyone is expecting it to fail, that seems to be the broad benefit. I do get the call saying 'we want to try agile out on this major SAP deployment', and after I get done screaming no, I say 'we want to start a little small and someplace where the risk is different'."

But both acknowledge that while small projects are good choices, they are by no means the only choice.

"We don't believe that there is an ideal type of project," says Cureton. "A 'greenfield' project developing a new application or service may have less complexity, but selecting such projects may fuel speculation that agile can only be successful for 'new'."

As Wilson says, if you believe the benefits of agile can apply to a big, problematic IT project, then perhaps that's a logical place to start.

"We have clients where they have an innovation group doing agile stuff but their [bigger, more traditional IT projects] are over-budget and under-delivering, and we see it makes sense to implement agile there first," he says.