Agile Transformation: For When Things Fall Apart

Ever sat through a talk 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 user-experience design (UXD), have a broken vision, an impossible backlog or an unachievable deadline? In these scenarios ideal-world theory feels redundant. Sometimes irritatingly inapplicable.

This article is based on a collection of lessons learnt from agile transformation in not-for-profits up to enterprise scale businesses, grouped into:

• no sponsor buy-in
• a cross-functional team, which isn’t cross-functional
• the problem you’ve been trying to solve doesn’t actually exist
• everything’s a must have
• everything you depend on isn’t working and you have to hit a deadline

The result is a toolkit of tips for all those worst (real) case scenarios.

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, and, of course, the cheque book. But what happens when they are replaced by someone who isn’t convinced of the benefits of agile?

Too big to fail? Think again.

Half way through a million pound digital transformation programme, with a collection of minimal viable products (MVPs), a content management system, and an expensive user experience study, and the key sponsor is replaced with someone that doesn’t buy into agile delivery.

That’s fine, you’re thinking, agile is a methodology that enables projects to be flexible in the face of change. But there’s change, then there’s 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 was made redundant. 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 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 volatile 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 that everyone else does. 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 – if you couldn’t write an interesting blog about it, don’t build it.
3. Get saboteurs on side with appeasement; if your sponsor wants to change the design because he wants the boxes to line up, just 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. While it may seem like bleak reading, all those affected by the redundancies went on to get awesome jobs elsewhere (like me at Red Badger). The real loss was for the users, both internal and external, whose voices were no longer heard.

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

Despite User Experience & Design (UXD) being an integral part of delivering a product, it’s often still excluded from the delivery team.

Before getting into the detail it’s worth describing what I mean by ‘cross-functional team’. In its simplest form, it’s 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 you have someone representing:

• Product/Strategy (to provide vision and requirements)
• Delivery (to unblock, analyse and improve ways of working)
• Tech (to develop the things)
• Test (to ensure quality of the things)
• Design (to develop the look and feel of the things)
• 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 build it or there’s a separate design agency or 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. While a cross-functional team without UXD is an oxymoron, it’s often a fact of project life.

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 means design is waterfall, UX is an afterthought.

The lesson learnt? In order to deliver a product, pragmatism (over dogmatism) is key

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 work you can quickly see what share of team effort it occupied.
2. Brief in technical and user requirements; get the 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 wants to mediate, but will they still want to mediate if you’re sending multiple emails a day?
4. 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.
5. Build understanding around iterating; the team can build an MVP which doesn’t satisfy all the initial design requirements, test, learn, 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 can get results for users and stakeholders much quicker.

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 a mismatched vision? Epic waste

An ambitious business wants to 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 and then achieving is better than failing entirely:

1. Set realistic expectations straight from the off; promising to deliver the 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 or over coffee, 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; a product, which added value for customers and the business alike

By continuing the challenge the basis of our initial scope we eventually delivered the right thing for the business, and it was a lot cheaper than a fully fledged fancy new service too.

What to do when everything’s a must have

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 with looming deadlines. However, there’s no way everything can be done on time based on the team’s throughput (he number of features delivered per week) 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 are the key performance indicators (KPIs)? How can we measure it? What is this features return on investment?
3. Visualise it; Demonstrate how far the team will go down the to-do list using data. By seeing the cut off point, it 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 had to drop out. This shifted the conversation from team capacity, to value to the business and meant that all the real must-haves could get delivered, in time.

What to do when everything you depend on isn’t working and you have to hit a deadline

Though a truly autonomous team is the 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 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. The result; a buggy release and a demotivated team – exactly what agile is meant to counter.

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

In order to safeguard against this as much as possible;

1. Call out all assumptions and dependencies; if you’re providing dates in unpredictable and unstable environments, caveat them.
2. Provide a range forecasted dates; from enabled to impeded (e.g. 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 cut 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.
5. Tackle the culture; finger-pointing and slopey shoulders help no one, instead do you best to collaborate with your colleagues and call out culture you see as unproductive.

The outcome: the focus moved from one of delivery at all costs, to enabling that delivery

By focusing our stakeholders on all the things which stopped us delivering our backlogs, we helped to foster a culture of enablement rather than one of pressure. It’s important we do our best to not reproduce and perpetuate these sorts of cultures, especially if in leadership positions.

Lani is a delivery lead for red badger, a consultancy focused on the digital transformation of large companies through innovation and practical delivery expertise.