Fragile Agile

Taking the time to metabolize failure

Are any teams "actually" agile? There are approximately one zillion articles debating what "agile" is or should be, and I can even take some blame for this myself. Even to say that "agile has become a meaningless term" is its own cliche at this point.

But is agile even something we should aspire to?

It might be a case of ‘yes, and.’ It’s great to be value-delivering, iterative, and to work collaboratively in empowered teams. But the problem-driven approach to agile product development has some problems in itself.

Focusing on solving problems rests on an assumption that what drives people to use something is that the product solves a problem. That, in my experience, is not actually the case. What drives people to buy or adopt a product is a motive, a goal, a hoped-for anticipated state. This is why perfectly good solutions for a problem often fail. Either the problem didn't matter that much, or the way it was solved didn't actually match the motivation of its intended customer.

What’s more, when we understand the systems at work, we might begin to uncover how many “problems” are simply side effects of other solutions. While this kind of metastisizing technology problem space may be good for technology company profits, it’s only making the underlying problems we are collectively faced with worse, inluding climate collapse, war, dwindling natural resources, and individualism/isolation/polarization. So while we’re “solving a real problem” in our minds, we may actually be creating problems that someone else will need to deal with (and you know, also profit).

'Agile' processes on a development team might be great for churning out features, but long-term product strategy doesn't work well when we're just looking for problems to solve and prioritizing the low-hanging fruit. Modern approaches to product, like the product model and continuous discovery, help us understand that 'solving problems' is only one piece of the puzzle when it comes to developing a successful product company.

Moving fast

When it comes to ethics, we need to question the agile fail-fast mentality. Yes, we do live in a world where there's a premium on getting things out the door and getting things in people’s hands, and real learning is more holistic. Design justice principles suggest slowing down, to not skip over the need for trust and relationship with the people we are building for and with, to consider the implications of our releases. If we are building things that have an actual impact on people's lives, then to fail fast can sometimes mean harming the very people we're building for and with.

If we want products that actually support our wellbeing, we need to balance velocity and integrity. Otherwise, we're accelerating right past the caution signs and crashing in the curves. And while we might have an airbag, our passengers may not.

Methods like the Google Sprint or IDEO framework often lead to us treating "users" as means to an end, rather than collaborators. The kind of research they incorporate, "identifying problems," "empathy," and "getting feedback" can reduce people to subjects in our technocratic system. "Design thinking" generally places the designer in a position of omnipotence, able to imagine all that "users" might think, believe, and need.

Not only is this hubris, it's not even a great way to make products that people love. In fact, we may even be creating product traps, products that people would rather not use, but because we've preyed upon their natural reactions for our own ends, because we have exploited network effects and human insecurity, we're "successful."

Surely "good people" wouldn't do these things! Except we are human, with blind spots, with good intentions and, often, an addiction to our own inWe are lnocence. The system that we're not just participating in, but advocating as designers, leads us to overlook what is right in favour of what is 'working.'

This isn't to say 'agile' is the “cause” of designer/developer-as-god. It's a symptom of a system that rewards us for as much offloading of responsibility as possible. (Let's not go into binary thinking here! So-called 'waterfall' is possibly worse, since it disincentivises continuous relationships with people who might use the product.) What could happen, what kind of innovation might be possible, when we put more emphasis on understanding our products in the context of living systems rather than markets?

When we develop systems that are trust-based, we end up going more quickly, because there’s less waste involved building iterations that are not actually important and we have alignment, as well as a deep understanding and partnership with those whose lives we are impacting through our work together.

When we look at the current systems at work, we can understand why we get attached to the ethos of agile. Making things, shipping things, growth: all serve to help us extract value. What might happen if we pull one of the Jenga pieces out, if we look at the social and environmental consequences of all this solutioning? What would agile look like if we stopped trying to find all the problems that we could solve and instead imagined what the root causes of the problems are. At least wondering, is what we build actually reinforcing the problem?

Agile is a blueprint for winning a battle, but perhaps it's a Cadmean victory. The need for speed makes sense in a system in which you're ‘competing to win,’ and the measure of success is accumulation of resources. If this isn't the world you want to enact, you might try being more deliberate, building in partnership with those who will use the product and the communities and ecosystems that surround them. Failing, perhaps, but failing and learning together.