Far too many Agile development practices fail. You’ll hear excuses like, they took far too long to build or the quality just wasn’t good enough.

Getting Agile working is like getting a SCRAM jet running at full power, the engine comes to life and delivers huge power above a certain velocity.

My experience of transitioning to Agile Development was much the same, when we got the whole process working we felt like we had a made step change.

In the first part of this blog series, I’m going to break down 8 reasons why Agile transitions fail, in particular, focusing on the nebulous topic of stakeholder management, and what you can do about it.

So who are the holders of stakes?”

When I embarked on my first Agile transition project I had assumed that the guys and girls in development would be 100% behind the ‘new way of doing things’. But I was surprised to find that this was not the case.

The first lesson of Stakeholder management is testing the assumption that you know who you’re stakeholders are.

Clearly, your exec team is going to be stakeholders, as are your product managers and senior dev folks. But in my experience I’ve learned to cast the net further, as a useful exercise I sit in front of an org chart to ask “is this person or group impacted by our Agile transition project?”.

If the answer is yes you’re in the Circle.

In your Circle, you will find people who you can rely on to be evangelical advocates and people that will delight in pointing out every single bump in the road. You need to bring all of these people (and those that are between) with you.

The key to Stakeholder Management is Empathy

So you’ve sat in front of your org chart and you know who the different groups are that will be impacted by your project, but how will they be impacted? What do they think Agile means? Who out there is expecting miracles? Who’s at risk of overpromising? And who’s been in tech long enough not to believe the hype?

At some point, you’re probably going to have to build and present the business case for your transition to agile. Like any organizational change, there will be a cost, and those at the top table will need convincing the benefits to outweigh the costs.

A pat on the back and a kick in the rear!

We’re talking about the delicate art of organizational change. Some people will need their hands holding whilst others will need a more persuasive approach, and of course, some will need both!

So let’s look at how Agile will affect your stakeholders….

Agile Transition Fail #1 – Comfort Blanky

You probably expect to find your strongest advocates in the Engineering Team, but unless you’re unique you will also find some people that are positively terrified of Agile.

For some developers, the traditional line by line specification is a comfort blanket. Under our new Agile methodology, you’re going to be presenting development with problems to solve and you’ll be expecting them to demo their work.

So we’re really expecting development to stand up and be counted, and not everyone will be comfortable with this level of transparency.

Agile transition Tip

Think about the personalities in your scrum teams and try to buddy up those that chomping at the bit to get cracking with Agile and those that are naturally reserved or concerned about Agile.

Start small, take a discrete piece of work that can safely be run within your engineering team using Agile and suck it and see. Repeat until successful, then use the success to get others in the team hooked.

Agile Transition Fail #2

Which is nobler…. to protect or create value?

Your Support team will clearly be interested in how / when new releases are ready for roll out, they will also be keen to get their hands on the software before it is released. So Agile is a big step forward for them.

If you’re running a typical roadmap or feature backlog based on cost and value ratios you’ll hit the problem of small bugs not scoring high enough to get pushed up the backlog.

Fundamentally we invest in product development for one of two reasons, to either create or protect value. It stands to reason that we should throw more resource at creating value, but what is the right amount of effort to apply to protect value? It’s a balancing act that all teams grapple with, there’s no one answer that fits every situation. You have to use your judgment and expertise.

Agile transition tip #2

Try running regular maintenance sprints e.g. 1 in 4 sprints focuses on protecting value, fixing bugs, adding small features etc. Perhaps even give Support complete control over what makes the cut.

In Part Two of this series of blogs, I’ll take a look at how Product management and Marketing can help accelerate your transition to Agile.

For more information on why Agile is relevant to your business take a look at this eBook.