I came across a post by Meade Rubenstein this evening that I liked because it made me think a bit about methodology and how it evolves (or devolves) as it matures. We all want to get software out the door better, cheaper, and faster, right? And all the buzz lately seems to be around adopting agile methodologies. Rubenstein’s opinion is that that agile methods, as is typical for “revolutions” in how things are done, will become more bureaucratic as they become the norm:
[L]ike all other revolutions (this one being one of process from traditional SDLC to Agile/XP) – the new becomes the norm and the norm become bureaucratic – making further drastic changes required. I’ve always seen Agile and XP initiatives as an attempt to deliver greater value by removing the imposed management overhead and miss-steps (such as thinking mediocre can replace exceptional with the right process in place) – and, unfortunately now that many Agile/XP practices/processes have become the norm, they are now the anchor.
I can appreciate the notion that with agile, even though there is less “imposed management overhead,” what overhead there is can certainly become rigid and regimented. That said, the balance of this post won’t be quite as much a structured reaction to Rubenstein’s post as it is just a couple of the thoughts that the article spurred and that I’d like to share.
Will “Agile” Remain Agile?
While agile methodologies have been, and will continue to be a quick and obvious win for some shops, I wonder how “pure” agile methodologies will remain over the long haul for more mature, heavy-footed companies trying to transition. It’s easy to imagine some agile-adopters – even among the most well-intentioned – gradually shifting back to old ways by adding “just a few” new activities here and there that add marginal value, but that make the process of delivering good software more cumbersome. It will be hard in some shops to overcome the notion that the best way to avert risk is to produce more documents. Sure, that’s going to happen. And they’ll still call it agile.
Will Agile Become the Norm?
We’ll also probably find that in some environments, XP (or whatever other flavor of agile methodology) just isn’t the best fit. I won’t deny that we’re in the midst of an what seems to be an agile revolution, but what I’m less sure of is that methodologies like XP/Scrum will ever be the “norm” to the degree that traditional waterfall/spiral methods were for so long. I thinkXP, Scrum, and other agile methodologies are providing us with alternatives that we can all learn from, and that work great in some places, while heavier methodologies are still better suited to others.
The Agile “Discussion” Benefits Us All
What I’ve enjoyed most about this whole “agile movement” is that it is causing all of us – even those of us that use more traditional methodologies – to discuss agile principles and look at ways to make our processes leaner and more efficient.
I think Alistair Cockburn summed it up well in his book, Agile Software Development
The question for using agile methodologies is not to ask, “Can an agile methodology be used in this situation” but “How can we remain agile in this situation?” A 40-person team won’t be as agile as a six person collocated team. However, each can maximize its use of the agile methodology principles, and run as light and fast as they can creatively make their circumstances allow.
I’ve been very interested in the whole agile/traditional methodology discussion that’s been going on from the blogosphere to the break room (especially as it pertains to the role of the business analyst). What do you think?
Bureaucracy – Magritte photo by Oddstock.
JB
As you know I have been reflecting on this lately as well.
Meade is right on the money when he says Agile will grow into a bureacratic process – everything doens once it becomes the status quo. It’s an organic way the existing structure maintains itself. (Read Mintzberg on the topic of organisational structure.)
As for agile methods – scrum can already be pretty rigid compared to some more tradtional approaches. The call is for discipline within the process.
I say (and will get to it at BetterProjects in a few days);
The processes are tools. Pick them up and puit them down as you need them.
The principles are solid.
And they align with modern management principles – the same ones Bas writes about at his Project Shrink blog.
JB,
I agree the Agile discussion has been good.
Much of the embracing of agile can be traced to our changing culture rather than a breakthrough in software development practices.
We are perhaps witnessing the end of that culture in the crisis on wall street, and we will begin to witness new attitudes emerge which will emphasize different values, and finally those attitudes will emerge in the way we practice software development.