Working with leading blue chips, we've identified 5 common reasons why agile transformations fail and identified how you can get back on track.
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.
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:
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.
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.
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:
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:
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.
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:
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
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.
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:
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
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.
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:
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
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.
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;
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
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:
Add a Comment: