Calling bullshit on ‘agile’ catchphrases
Teams are abusing Agile maxims to cover up bad work. It’s time to call it out.
First, a confession…
…I’m actually a big fan of Agile.
As a designer, I believe in regular engagement with customers, learning through making, and continuous iterative development amongst many of the other great practices Agile methodologies promote.
I should also admit that I am not Agile certified. My stance is Agile should be used as a pragmatic means to reach desired outcomes, and discarded or adapted if it is not reaching these outcomes. Over the last couple of years, I’ve seen more and more teams start to focus on the methodology, rather than the outcome. And that’s not a good place to be.
Two camps of poor agile implementation
Agile was originally created as a process for software development. It’s great if you work in a digital-only business, but can be harder to apply if you are – say – designing a brick and mortar store experience, or trying to stand-up a new call centre.
Problems start to arise when multi-channel organisations looking to coordinate seamless customer experiences implement Agile poorly. I’ve seen these poor implementations fall into two camps:
- Dogmatic Agile – Those that unwaveringly follow a step-by-step Agile process without proper consideration, or without adapting to their working context.
- Pseudo Agile – Those that distil Agile down to some well-known slogans or catchphrases without actually following any process at all.
I’ve worked with teams that would fall into each of these camps, and no matter where they are, there are four catchphrases which pop up again and again – often leading to disaster when applied in the wrong business context.
“Move fast and break things”
The well-known early-Facebook mantra used to inform the internal design and management processes at Facebook is still a favourite within Agile teams. But as someone who specialises in designing services in highly-regulated industries, I’m shocked by how liberally some teams have used and abused this ideology and amazed at how many issues such abuse creates downstream.
If the Cambridge Analytica scandal hasn’t already convinced you things have been broken enough, even Chris Hughes (Facebook’s co-founder) acknowledges that it’s less and less appropriate as Facebook grows into new areas.
When talking about Facebook’s new digital currency in the FT, Chris said:
“Move fast and break things – our mantra in Facebook’s early days – was an appropriate slogan for a college social network. It’s not appropriate for the global monetary system.”
I thoroughly believe that movement is better than inaction, but irresponsible design can prove disastrous for normal human lives — especially in healthcare and financial services contexts.
To dismiss the collateral damage of bad design with an old Silicon Valley catch-phrase is at best a dereliction of duty as designers, and at worst, irresponsible and ethically wrong.
“We don’t have a strategy, we’re Agile”
Yes, that’s a quotation. A prospective client said this me.
I’ve met a number of teams that believe an Agile methodology mitigates their lack of strategic direction.
Agile teams love to break programmes of work into small pieces, which is a great means of delivering products or features. However, without a clearly articulated North Star there is little guarantee you’ll be where you need to be from both a customer or market perspective when all the pieces are put back together.
Even if there isn’t a specific strategy for your area, there will always be an overall business strategy that Agile workstreams need to be aligned to.
“Customers don’t know what they want until we’ve shown them.”
The famous Steve Jobs line. And if you work in Apple in the 2000s then maybe there’s an argument for this being true.
But you probably don’t work at Apple. And it’s definitely not 2007.
Teams often pull out this line to justify failing to conduct customer research upfront. The idea being that feedback you get on a prototype will always easier to translate into action and design changes, whereas upfront design research is hard. It needs a more sophisticated ethnographic approach to identify customer behaviours and opportunity spaces – not skills native to most designers.
There is always a need to have baseline empathy with the customer at the start of the design process. This becomes essential if you are working in an area where you yourself are not a consumer. For example, are you designing an app for farmers but have never been on a farm? Why waste time building and testing a prototype, when up-front user research could tell you all you need to know right now without even typing a line of code?
Learning as much as you can, as early as you can, and as quickly as you can, saves time and makes killing patently bad ideas less painful and less expensive.
“Done is better than perfect”
Another favourite quote from Facebook. Those guys get around don’t they?
Great designers and developers are usually detail-orientated and seek perfection in the work they deliver. Even at our own company, Nile, we have developed the cultural navigator, “Progression, not perfection”, to address the same behaviour in our team.
But what if you don’t have great designers or developers?
Time and time again I have heard product owners use this catchphrase to rationalise launching a poorly developed product. They’re often wallpapering over capability gaps in their team, or sometimes just don’t know what good looks like themselves.
However, if you are genuinely struggling to get things out the door, and anything that does make it into the world is hugely over-engineered, then you’re dealing with perfectionism as a cultural challenge. So this statement actually does apply to you.
Agile is a victim of its own success. We now understand a need to move faster in an era of disruption, and many leading companies attribute their success to this methodology. But the dark side of Agile’s success is to create an environment where some people and teams can hide behind processes.
Remember: Agile processes are great, but they’re little more than the delivery mechanisms for the Agile principles that sit behind them. When teams are working without appropriate evaluative frameworks for success, or without being constructively challenged, they’ll frequently default to prioritising visible outputs over harder-to-measure outcomes. That means you miss out on producing genuine customer value and behavioural change (the outcomes Agile aims for), instead just producing more and more products or features (the outputs) while proclaiming the success of your process.
So the big question is, next time you see processes being misused or failing to deliver, what will you do?
Luke McKinney is a Client Partner, designer, strategist, and rugby player. He doesn’t fully understand anything until he breaks it and puts it back together again.
