Let me start by welcoming you to this Age of Agile[1], all-time permeating everyone, everything, everywhere, ailment to anything from a petechial rash to world inequality.
At the height of the software crisis, the “Manifesto for Agile Software Development” came about with the proposal of valuing more some items on the left than the ones on the right, along with a dozen of principles so sensible nobody would even bother to question.
And it felt right, not just from its authors’ perspective — a well-recognised bunch with plenty of scars to show for from applying conventional engineering process methods to software development under the then-dominant life-cycle approach — but for the broader community as well.
It didn’t go without some commotion though. In a “Letters to the Editor” to the Dec. 2001 IEEE Computer[2], regarding an article, published three months before[3] by no other than two of the Manifesto’s authors, the approach was viewed as nothing more than an attempt to legitimise hacker behaviour, eschewing predictable software engineering practices.
The article in question had some ambitious goals. Bearing the assumption the business environment would continue to change at a dramatically increasing pace, the Manifesto’s approach would enable businesses not only to thrive in such a turbulent environment but would also forge a future workforce culture, addressing both the need for dynamic, innovative approaches and the desire to build workplaces not described in Dilbert cartoons.
Shortly after, Barry Boehm came up with an article[4] stressing the idea that fully embarking on the items on the left and taking the ones on the right as polar opposites might not be the best thing to do, and that care would have to be made with the adoption of such Agile methods.
To demonstrate the importance of balancing agility and discipline, he applied risk management to address the question of how much planning is enough, taking into account what he called home ground characteristics, such as developers, customers, requirements, architecture, refactoring, project size and its primary purpose.
“Both agile and plan-driven methods have a home ground of project characteristics in which each clearly works best, and where the other will have difficulties. Hybrid approaches that combine both methods are feasible and necessary for projects that combine a mix of agile and plan-driven home ground characteristics.”
From then on, of the several emerging software development methods, most waned off, such as Adaptive Software Development (ASD), Dynamic System Development Methodology (DSDM) and Feature Driven Development.
Agile Modeling morphed into Disciplined Agile and Crystal Methods into Heart of Agile, both shifting from the intricate minutiae of software architecture, design and programming issues, towards people management.
Extreme Programming (XP), Lean Development, and Martin Fowler’s Refactoring are still around, pretty much faithful to their original tenets. Maybe that’s because they did uncover some better ways of developing software. But these approaches — that actually get into the specifics of how the software should be built — are for programmers at the bottom of the food chain, since the practices of test-first, incremental design and refactoring require a lot of painstaking work and aren’t that much popular.
Just watch this presentation by Alistair Cockburn — from not so long ago — where he leans towards a more disciplined practice of Agile and goes on to say that The Agile Manifesto invites low discipline.
His frankness in this talk goes very well with the following quote from the playwright and novelist Max Rudolf Frisch:
“A joke is a good camouflage. Next best comes sentiment… But the best camouflage of all — in my opinion — is the plain and simple truth. Because nobody ever believes it.”
Scrum — and its derivatives, scaled or otherwise — became the overwhelmingly dominant approach, which is curious since it’s the only method — I mean framework — that is entirely devoid of the purpose of uncovering better ways of developing software, with no further intent than managing whatever process one eventually comes up with to do the actual development work.
Scrum is a framework for developing, delivering, and sustaining complex products, within which people can address complex adaptive problems.
The Scrum Guide — which completely defines Scrum — is all about roles, events, artefacts, and rules — in which the latter binds the previous three. It mentions that tactics vary but are defined elsewhere — ok then. It’s also about values that bring the three pillars of transparency, inspection, and adaptation to life.
Scrum is lightweight, simple to understand, but difficult to master, very much like the “Golden Snitch” from Harry Potter’s Quidditch game.
I’m particularly fond of the Scrum Master, responsible for promoting and supporting Scrum; so doctrine-laden that reminds me of the Red Army’s political commissar.
Another exciting aspect is the in media res appearance of the Product Backlog since there’s no explicit provision in the guide on how to come up with it in the first place — we then have things like Sprint Zero with a Design Sprint, and so on. That figures, in the original OOPSLA paper, Scrum is portrayed as “a management, enhancement and maintenance methodology for an existing system or production prototype.”
Twenty years are about to pass, and Agile now dominates not only the tao of uncovering better ways of developing software but of product development in general, marketing, HR, and even corporate strategy.
Nobody wants to be clumsy, and everyone is Agile nowadays, or in the process of becoming so.
Agile workplaces are still being described in Dilbert cartoons though.
It made the cover of Harvard Business Review in May-June 2018. Not just Agile, Agile at Scale, a well-written article, but no longer a bit about uncovering better ways of developing software. Agile, it seems, turned into the quintessential approach to organisation design, and even management, irrespective of the domain of application, apparently with a much more significant and everlasting impact on business results than software development alone. Gosh!
Even Mckinsey unearthed its oozing insights into the democratisation of information unleashing the new war for talent for the quickly evolving introduction of disruptive technology at an ever-accelerating digitisation environment with chummy nuggets like the following:
“Agile organisations maintain a stable top-level structure, but replace much of the remaining traditional hierarchy with a flexible, scalable network of teams.”
It seems Agile is only suitable for the Hobbits, according to McKinsey.
No, it’s not. There’s even an Agile C-Suite now. There you go, McKinsey!
It has turned pervasive to the point of hearing people say it is just common sense rebranded, leaning into a sort of pensée unique that sometimes feels like one is living inside of an “All Hail Jay” locker.
Enough now. Here’s The Clumsy Manifesto, originally meant for software development but currently also seemingly applicable to all walks of life:
Work the craft — there’s still one.
Please don’t lose sight of what is it you’re doing.
Mind the stakes and don’t fool around.
Don’t be a weathercock.
Now it might be ripe for a deep, slow breath, the smell of a rose, hence this longing for some clumsiness into the future.
“I would like to create something simple, something graceful
A living symbol that maybe represents some sort of positive thing in this world
I don’t know
But I just want it to be simple, graceful, beautiful, there in the crowd
Then what’s this?
I’ve told you everything I know,
I’ve been straight with you from the beginning”
Flashback, Talamasca, from the Album Obsessive Dream, 2007
[1] Denning, Steve (2018). The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done. New York, NY: AMACOM.
[2] Rakitin, Steven R. (2001). Manifesto Elicits Cynicism — Letters to the Editor. IEEE Computer, Dec. 2001.
[3] Highsmith, Jim & Cockburn, Alistair (2001). Agile Software Development: The Business of Innovation. IEEE Computer, Sep. 2001.
[4] Boehm, Barry (2002). Get Ready for Agile Methods, with Care. IEEE Computer, Jan. 2002.
