5 reasons your Agile transformation is failing (and how to fix it)

The gritty, honest truth

Ever sat through a talk or read a book extolling the virtues of agile delivery and thought this just doesn’t apply to my project, team or company? What if you lack sponsor buy-in, or internal UXD, have a broken vision, an impossible backlog or an unachievable deadline?

In these scenarios, ideal-world theory feels redundant. Sometimes irritatingly inapplicable.

 A toolkit of tips covering those worst(real) case scenarios for those working at the forefront of agile transformation

This is a collection of key learnings gathered from projects with not-for-profits to enterprise scale businesses and everything in between, focused on what to do if:

1. You have no sponsor buy-in
   
   
2. You have a cross-functional team, which isn’t cross-functional
   
   
3. The problem you’ve been trying to solve doesn’t actually exist
   
   
4. Everything’s a must-have, don’t ask why JFDI
   
   
5. Everything you depend on is broken or flakey

So whether you’re in delivery, tech, management, product or user experience, this blog is designed to help you to deliver great products, even when everything feels like it’s gone tits up. 

Grab yourself a cuppa and settle in for this long read.

1. What to do when you have no sponsor buy-in

Ideally, the project sponsor is your ultimate enabler; your champion to the rest of the business, your high-powered escalation point and, of course, the chequebook.

But what happens when they move on and are replaced by someone who isn’t convinced of the benefits of Agile?

Too big to fail? Think again.

Halfway through a million-pound digital transformation programme, with a collection of MVPs, a CMS and an expensive user experience study and the key sponsor is replaced with someone that does not buy into agile delivery.

That’s fine, you’re thinking, agile as a methodology was created to enable projects to flex and bend in the face of inevitable change. But there’s change, then there’s bloody revolution.

And by carrying on as normal it’s only getting worse.

They don’t like the work done to date, don’t want to attend reviews, see an in-house delivery team as a risk and are repulsed by the idea of an unpolished MVP going live to customers.

So what was the outcome?

In this case, the whole team were made redundant. The headway that had been made slowly dissolved into a sea of politics.

And by burying our heads in the sand and stubbornly carrying on as usual we had probably only made things worse.

The writing was on the wall and we hadn’t read it; our sponsor was risk-averse and we were pushing for beta releases, they were worried about money and security while we were open-sourcing, they requested design amends and we pushed back citing mobile responsiveness.

While we were focused on the small battles, we lost sight of the war. 

The lesson learnt: Look lively and be ready to compromise on all that you hold dear.

Sometimes the worst can happen especially in a fast-changing market where in-house teams are competing with agencies. You need to be ready for it:

1. Empathise with ignorance; just because you know that agile is the best way to deliver software it doesn’t mean everyone else does. And aggressively banging the agile drum is probably only going to make someone more resistant.
   
   
2. Get creative to keep engagement; to drive attendance at reviews we started doing blog driven. development - the basic rule is that if you couldn’t write an interesting blog about it, don’t build it.
   
   
3. Get saboteurs on the side with appeasement; if your sponsor wants to change the design because he wants the boxes to line up just bloody do it. If there’s a red line in product builds, this isn’t it guys.

If this seems the exception, it shouldn’t. It happens far more than you would think, especially in a volatile and fast-moving sector.

And while it may seem like bleak reading, it shouldn't. All those affected by the redundancies went on to get awesome jobs elsewhere. 

Read more:

• An Estimote post on blog driven development
• A nice post about the correlation between Sponsor involvement & project success

2. What to do when you have a cross-functional team, which isn’t cross-functional

Despite UX and Design (UXD) being an integral part of delivering a product, you still often find it excluded from the delivery team. In fact, this is sadly an extremely common issue for many software delivery teams.

What do I mean by a cross-functional team?

Before getting into the detail it’s probably worth describing what I see as a cross-functional team. In its simplest form, it is a group of people with different functions and skills working together to achieve a shared goal.

The skills and functions required may well vary depending on the goal but generally speaking in a Red Badger project you have someone representing Product/Strategy (to provide business leadership and requirements), Delivery (to unblock, analyse and improve ways of working), Tech (to develop the things), Test (to ensure the quality of the things), Design (to develop the look and feel of the things) and User Experience (to ensure the user can use the things).  

The problem of isolated User Experience & Design

Whether the UXD work has been completed before the developers are enlisted to build it or there is a separate design agency/department producing designs upfront the results are often the same; the feedback loop is broken, time is wasted and quality suffers.

It’s everything the lean and agile approach emerged to counter.

And while a cross-functional team without UXD is an oxymoron it’s often a fact of project life. And stamping your feet while extolling the virtues of agile, cross-functional teams to your sponsor may vent some frustrations, it doesn’t get you closer to delivering a product.

So why is the UXD gap so widespread?

UXD resources cost money, so why pay for them if you have some on tap already?

It represents great cost savings for your company and you’re getting visual designs from a trusted partner that knows your brand inside and out. In reality, it usually means the design is waterfall, UX is an afterthought, responsive-huh, and long, stilted email threads.

The lesson learnt? In order to deliver think pragmatism (and forget dogmatism)

While there’s no way to compensate for a massive gap in the cross-functional team there are a number of ways to ensure it doesn’t completely hinder delivery:

1. Highlight the waste; getting lots of requests to amend existing code can add up but if it’s captured as cards on the Kanban board then you will quickly be able to see what share of team effort they occupied, and that team has a cost.
   
   
2. Brief in technical and user requirements; get the technical team into scoping sessions to reduce the risk that the designs can’t be built and that users can’t use the product.
   
   
3. Build up regular lines of communication with the designers; maybe the client/company wants to mediate, will they still want to mediate if you’re sending five emails a day? 
   
   
4. Keep talking, in person; people tend to be much nicer face to face than via email, simple, but true. 
   
   
5. Negotiate, negotiate, negotiate; rather than saying no to a request, suggest an alternative which is simpler to build and thus saves your client or stakeholders money and time and delivers value to users sooner.
   
   
6. Build understanding around iterating; the team can build an MVP which doesn’t satisfy all the initial design requirements, test, learn, and then add more enhancements later if required.

All of these outcomes make for a much happier delivery team too. By making pragmatic compromises, the team got results for our users and stakeholders much quicker. 

Read more

• Insight from our Director of People and Culture and former Chief Design Officer on cross-functional teams without UXD

3. What to do when the problem you’ve been trying to solve doesn’t actually exist

A clearly defined vision to guide the team and priorities, key performance indicators and an empowered and knowledgeable Product Owner.

Great stuff, but what happens when you realise there’s a mismatch but your Project Sponsor is adamant that they know what they want?

The problem of mismatched vision? Epic waste.

An ambitious business wants you to build an expensive new product which will be the face of a new service which doesn’t yet exist. Whatsmore, they lack the infrastructure and logistics to fulfil their ambitions.

Inevitably this will lead to the ultimate waste; a product no one will use delivering no benefit to the business.

The lesson learnt? Don’t be afraid to revisit absolutely everything

It can be hard to admit you’re delivering something pointless, especially if your stakeholders think they know what they need. But failing small is better than failing entirely:

1. Set realistic expectations straight from the off; promising to deliver the ask of a big glitzy product when they actually just need something much simpler (and cheaper) will only end in reputation loss and waste.
   
   
2. Think end to end; Who are the current users and will they want this? What’s the full user journey? How will this get fulfilled?
   
   
3. Continue to ask the tough questions; whether it’s in workshops, over coffee or a glass of wine, keep having those honest and difficult conversations.
   
   
4. Be ready to pivot; the more upfront work that’s done, the more waste there is when you need to change direction.

The result is a product, which added value for customers and the business alike. By continuing the challenge on the basis of our initial scope we eventually delivered the right thing for the business, and it was a hell of a lot cheaper than a fully-fledged fancy new service too.

Read more

• Top tips from one of our Strategy Lead's on product strategy and validation of it
• Lots of great tools for helping to understand business value from the people over at Strategyzer

4. What to do when everything's a must-have, don't ask why, JFDI

It’s a classic, you’ve got a backlog and you work with the business to prioritise, but as you work through the list you realise that virtually everything is falling into the must-have category. And you have a finite amount of time to deliver it all.

The problem of everything being a must-have? You can’t possibly deliver it all in time.

There’s a backlog that needs to be delivered ready for a campaign but there’s no way everything can be done in time based on the team’s throughput and the number of things to do.

The lesson learnt: How to say no, without saying ‘no’

It can be hard to say no to your stakeholders, but there are plenty of ways to re-frame things so the onus is on the business to prioritise rather than on the team to deliver the impossible:

1. Say yes; you can deliver it all, but based on the average throughput and that backlog, it will take twice as long as you want it to.
   
   
2. Reframe to focus on value and outcome; What is this feature’s KPI(s)? How can we measure it? How much will this feature generate in income compared to the rough cost of building it?
   
   
3. Visualise it; demonstrate how far the team will go down the to-do list using data - seeing the cut off point forces the difficult calls to be made.
   
   
4. One in, one out; if last-minute requests come through, make it clear something else will need to give.

The outcome: the conversation moved from team capacity to one of business priority

Quite quickly the Product Owner could see that if they wanted something new on the backlog, something else needed to drop out. Instead of the team being pressured to deliver the impossible, the business was pressured to make value-driven decisions on priority.

This shifted the conversation from team capacity, to value to the business and meant that all the real must-haves could get delivered, and in time too.

Read more

• A great post on how to prioritise according to value and effort

5. What to do when everything you depend on is broken or flakey

Though a truly autonomous team is ideal, large enterprise-scale projects can mean major dependencies and debilitating constrictions.

If you have no autonomy, how can your team have accountability?

You have a hard deadline. But then your dependencies aren’t delivered in time, your environments are going down every day and your shared monitoring tools keep falling over when other teams decide to do load testing without telling you.

Missing the deadline isn’t an option, so your stakeholders ask you to work late to get it out of the door. The result; a buggy release and a demotivated team - it’s exactly what agile methodologies were developed to counter.

Lesson learnt: Protect your team and don’t compromise on quality

It’s the magic triangle we’re all so familiar with; scope, quality and time. If scope or time can’t give then let’s face it, quality probably will suffer. In order to safeguard against this as much as possible;

1. Call out all assumptions and dependencies; it’s an obvious one, but if you’re providing dates in unpredictable and unstable environments caveat the hell out of them.
   
   
2. Provide a range of forecasted dates; from enabled to impeded (usually plus and minus 20%), putting the onus on the business to enable you rather than pressure you to work late.
   
   
3. Shield the team from the pressure; a rushed team produce mistakes and cuts corners, leading to duplication, waste and low motivation in the long term.
   
   
4. Get the data out again; if you’ve been pushed to get a release out and it’s full of defects (which you then need to fix in a further deployment), show that to your stakeholders. Quantify the impact of impediments and blockers, and make that visible to stakeholders.
   
   
5. Tackle the culture; Finger-pointing and slopey shoulders help no one, instead, do your best to collaborate with your colleagues and call out culture you see as unproductive.

By focusing our stakeholders on all the things which stopped us from delivering our backlogs, we helped to foster a culture of enablement rather than one of pressure.

It’s easy to fall into the trap of reproducing cultures which are prominent, but by remaining aware and conscious we can do our best not to perpetuate unproductive or negative behaviour. 

Read more

• Great blog on culture by Jocelyn Goldfein about culture as the behaviour you reward and punish  

This was a pretty long read. But hopefully a good one.

I wrote this because I felt so little out there honestly reflected the daily challenges of agile transformation. And so few honestly talked about key attitudes and processes which aren’t in the theory books but which are vital to delivering in the face of seemingly insurmountable challenges.

To summarise the key learnings: 

• Look lively and be willing to compromise on all that you hold dear
• In order to deliver think pragmatism (and forget dogmatism)
• Don’t be afraid to revisit absolutely everything
• How to say no, without saying ‘no’
• Protect your team and don’t compromise on quality