Late last month someone on twitter called me an “anti-agile bigot” who “doesn’t understand” agile. The comment was triggered by this blog post where I pointed out, as an aside to the main point of the article, that the broad-scale adoption of Agile made it more difficult for UX designers to do good work. As a UX designer who was actively working during this time period I can personally attest to the challenges we faced.
As my twitter friend and others like him called me names and insulted my work, it got me thinking about what set them off. What was it about noting a factual challenge to good Agile implementation that instantly delegitimized my credibility?
And then it dawned on me. It wasn’t the challenges to Agile implementation that warranted my deplatforming. It was the perceived assault I’d made on Agile as an idea. I was attacking The Church, or in this case, The Agile manifesto. Except, I wasn’t.
Manifestos vs methods vs reality
The Agile manifesto has been transcribed into many different methods. Each of those methods has met with various levels of adoption, success, adaptation and critique. The methods attempt to hold the values of the manifesto in mind as best they can. When the harsh realities of domain, industry, politics, egos, agendas, new disciplines, technologies, pace of work and an infinite number of other variables are smashed up against these methods they bend. Some break. Some evolve and get better.
The methods that survive are the most agile. They take in feedback from their users and adapt the technique to accommodate for new needs. The values are retained as best they can but practices evolve to reflect modern ways of working, consuming and delivering value.
This is Agile.
Critique is key to progress
Companies hire Agile for a variety of reasons. Some of them align with the manifesto. Some don’t. Coaches, trainers, consultants, CTO’s, engineering/product/design leads understand that process differently. Some see it as a way to ensure high code quality. Others see it as a way to increase production. Yet others see it as a way to be more customer-centered (shocker!).
Each of these points of view will shape how agile ways of working are implemented in each organization. They’ll shape who will adopt it easily and who will struggle. And they’ll shape how well the adoption will work. When these implementations struggle, critique should be welcome.
Just because it’s codified in a manifesto or guide or book doesn’t mean everyone understands it the same way, applies it the same way or uses it for the same purposes.
You can laud the approach and still be critical of the implementation of that approach. Because, in the end, we value responding to change over following a plan.
I love this article. You articulated something I’ve been struggling with for the last couple of years – why is “agile” now so process heavy that it feels like it’s no longer “agile”? Thank you!
Thanks Elena. Agile ideas have tons to offer but every context is different and open to shapeshifting even if it detours from “pure” agile.
There is no pure agile, that’s the point, learn and adapt, that’s agile 🙂
Agile itself was born out of a blend of practices, and principles. It’s mush, in a good way, there’s tools and techniques and most importantly there’s people and conversations, anything that brings about a conversation earlier, some understanding sooner, that leads to reduction of waste and production of better outcomes (ie more value) is and should be incorporated, HCD principles, UX/UI design practices, User Centricity to me are just another way to be more agile… as you well mentioned each organization is different and should consider its needs when applying/evolving it’s own practices, discussions on the best way to optimize getting value to the customer and therefore the organization should be had with the team members, this should include UX/UI team members, this is agile