As organizations strive to gain greater business agility, many are adopting Agile methodologies, not realizing that their implementation of it is anything but agile. In fact, it’s often quite the opposite, turning the original set of guiding Agile principles on its head.
Bestselling authors Lindsay McGregor and Neel Doshi wrote an insightful article in HBR titled “Why Agile Goes Awry—And How To Fix It” that makes this very claim.
“In the spirit of becoming more adaptive,” they say, “organizations have rushed to implement Agile software development. But many have done so in a way that actually makes them less agile.” Not only that, it makes them less motivating.
The article goes on to contrast the original four guiding principles of Agile with the common practices that seem in direct opposition.
Regarding the principle of “Individuals and interactions over processes and tools,” many organizations have let their Agile process become so rigid that people feel handcuffed by it and aren’t allowed to question it. According to the article, developers and engineers have reporting feeling like “short order cooks.” Not surprisingly, I’ve heard this very term used myself in some Agile organizations.
And despite the mantra of “Working software over comprehensive documentation,” some teams spend significant time documenting detailed user stories to the detriment of the true Agile mission of getting small experiments done in a collaborative manner.
Speaking of collaboration, the core Agile philosophy of “Customer collaboration over contract negotiation” goes out the window when the process involves work being passed like a baton from product managers to designers to engineers, with the customer nowhere in sight until release time.
Lastly, the principle of “Responding to change over following a plan” has become confused with “winging it” or “picking features that look interesting” as opposed to high value, strategically-important features that have been prioritized with the customer.
None of this is theoretical speculation. On the contrary, it’s sadly become common practice in many companies. Indeed, the authors based their findings on their study of engineering practices in 500 organizations, along with anecdotal evidence.
The most striking finding of all was that these practices not only ignore core Agile principles, but they bring about the opposite result that Agile was intended to deliver. They demotivate people. As the authors put it, “Because they’re not allowed to experiment, manage their own work, and connect with customers, they feel little sense of play, potential, and purpose.”
It’s a sad, all-too-predictable, Dilbert-like situation. But all is not lost. The authors propose six changes to consider to better balance tactical and adaptive performance:
1. Software development should be a no-handoff, collaborative process.
2. The team’s unit of delivery should be minimally viable experiments.
3. The team’s approach should be customer-centric.
4. Use timeboxes to focus experimentation and avoid waste.
5. The team should be organized to emphasize collaboration.
6. The team should constantly question their process.
For projects that benefit from an Agile approach (and not every project does), I couldn’t agree more. The authors expand on each in the article, so it’s well worth a read.
