In the fifteen years since seventeen software developers met at a Utah resort and hammered out the Manifesto for Agile Software Development, Agile methodologies for building software have become the predominant approach worldwide. Yet, while there is broad agreement that Agile improves the chances of successful software initiatives as compared to the deeply flawed waterfall approach, Agile still faces many challenges, even after so many years.
Fifteen years is a long time in IT, after all. Technology refreshes occur typically once every three years. Given the increasingly rapid pace of change – not only in the software world, but across today’s increasingly software-driven business environment – perhaps we should move on. Is it finally time to kill Agile?
Problems with Agile Continue to Pile Up
Even though the lightweight, iterative roots of Agile go back well into the 1950s, the 2001 creation of the Agile Manifesto (as it’s come to be called) has become a watershed moment for the approach, defining its four core values and a dozen principles for driving the creation of better software.
In and of itself, however, Agile has never been a methodology. Rather, methodologies like Scrum and Extreme Programming rose to the fore, espousing the principles of Agile. Today, Scrum in particular has achieved a remarkable level of adoption.
Nevertheless, the problems and limitations of Scrum and the broader Agile movement have proven surprisingly persistent, in spite of the throngs of very smart people who have worked in various capacities with Agile over the years.
The numerous complaints about Agile include its lack of focus on software architecture, its emphasis on one-off software projects as opposed to building reusable code, and the reinforcement of the notion that the software development team is a self-contained group, as opposed to participants in a broader collaborative effort.
Perhaps the greatest concern over Agile, however, is the ambiguity of Agile’s principles themselves. Agile calls for self-organizing teams, but there remains no clear understanding of how best to self-organize. Agile also calls for the stakeholder or customer to be an active part of the team – but stakeholders have always resisted this participation, and when they do join the Agile team, they struggle with their role.
Read the entire article at http://www.forbes.com/sites/jasonbloomberg/2015/12/11/has-agile-outlived-its-usefulness/.
Intellyx advises companies on their digital transformation initiatives and helps vendors communicate their agility stories. As of the time of writing, Chef Software and Photon are Intellyx customers. None of the other organizations mentioned in this article are Intellyx customers.
Emergent architecture is probably the biggest weakness in the agile manifesto, and I’m glad you called it out early.
At the small scale architecture can emerge, it’s like figuring out to fit all the furniture in the new office, it quickly becomes obvious that there’s a right way to handle getting the pieces to fit together the best.
But I’ve never seen that approach work at the larger scale. And with that it has always felt to me that the whole manifesto has been too broadly applied. It’s a great starting point for the activity of building software. But it doesn’t adequately cover starting things off, doing the big reviews (when these are needed), and perhaps most importantly choosing when things are’ done’ and ‘finished’.
A more specific issue I have is the appearance of ‘Certified Scrum Masters’ who have never been senior software developers. It’s like providing annual accreditation to an electrician who has never actually wired up a house. I would like to see such accreditation identified as specious.
Good point. I wrote about emergent architecture at https://intellyx.com/2015/09/28/what-is-emergent-about-emergent-architecture/, although I don’t tackle your point head on.