8 Reasons Why Agile Transitions Fail

8 Reasons Why Agile Transitions Fail

8 Reasons Why Agile Transitions Fail

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 test the assumption that you know who you're stakeholders are.

Clearly your exec team are going to stakeholders, as are your product managers and senior dev folks. But in my experience I've learnt 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 over promising? 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 organisational change there will be a cost, and those at the top table will need convincing the benefits outweigh the costs.

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

We're talking about the delicate art of organisational 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 Transiton 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 road map 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 protecting 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 judgement 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.