Mention the word Agile to anyone in software development and you’re likely to get a strong reaction. The person will either jump down your throat if you even merely hint at suggesting at implying that it may not be absolutely, completely and without a doubt the most perfect way to manage a project EVER (blessed by the programming gods themselves). Or, perhaps the person will roll their eyes and prepare for a sermon (having been on the receiving end of one too many). These reactions are so strong that I’ve taken to “not talking about it”, the same way I stay away from talking politics or religion while drinking in pubs:
“them’s fightin’ words, boy!”
Of course, there’s more than just a little irony in the fact that “doing lots of planning before you start coding” has somehow become a laughable thought (you know, the idea that changing a Word Doc is easier than ripping out code if you change your mind early in the process). How did this happen? Perhaps in another post.
Anyway, I came across this post by Steve McConnell recently, about Agile – the pluses and minuses. Minuses?! What?!
Steve is thought to be one of those programming gods and as usual, his articulation is top notch. He seems to have a balanced, non-partisan view of the whole thing. He goes on to suggest that certain styles of management are more applicable to certain environments, but less applicable to others (commercial software development being one he mentions). Very similar to my own thoughts, though I marvel at Steve’s ability to boil a complex topic down to its essential elements. It’s tough to argue with the guy.
Just like programming languages, software development processes need to suit the task at hand.
I’ll argue for it where it belongs. The people that can’t listen to valid counter-arguments to agile aren’t the people that should be defending agile in its proper place.
While I love many of the attributes of agile development, I don’t try to cram it into projects where it doesn’t make sense to use it. Not all of the agile zealots are unreasonable.
Steve makes some great points for and against agile development but I’ll disagree on one though: agile isn’t gaining traction as fast as people think. The people that buy into agile may do so very quickly but the rest of the software development world either has blinders on or is disinterested in anything new (there’s a lot of money in legacy development, like COBOL).
Agile development will take 10 years or more to become anywhere near mainstream. The practises have been around for over ten years already and only a small percentage of people use them. But even in the future agile won’t solve all of our problems. BDUF and CMM aren’t going anywhere, and they shouldn’t.
Steve made this point, but indirectly: Agile projects are notoriously hard to budget because an agile process puts an emphasis on project success instead of budget and time constraints (ie. good estimating).
What good is a project on time and budget if it doesn’t solve the customer’s problem very well or at all? Is the customer to blame if they can’t get their requirements right in the early stages in a Word document? I see that as the primary argument for an agile approach for some projects. The industry needs more successful projects and happy customers, not successful budgets.
Sorry about the long comment!
Actually, careful about describing the spectrum as “successful projects” on one end and “successful budgets” on the other. Success can be defined many different ways.
Steve’s spectrum was “requirements flexibility” on one end, and “predictability” on the other. This is the best description I’ve heard to-date of the inherent differences between Agile and design-up-front methodologies.
Also, remember that in commercial software development, the customer (the market) doesn’t choose their requirements directly (as they do in contract or in-house development). They either accept or reject them when the product is released into the wild (voting with their dollars). In that case, the designer chooses them on behalf of the market, and yes, the designer should be able to get them straight before development begins (with some obvious fudge factor).