LinLog

Author's note: This is based on some notes and links I started collecting in November of 2015.  The bulk of the commentary is actually relatively new - from last year, August 15th, 2019 - so it's not too out of line with my current thinking.

As might be clear from my review of Bertrand Meyer's Agile!: The Good, the Hype, and the Ugly, I've been rethinking the whole agile development craze that has swept the industry.

There are a number of good presentations online questioning the "agile" movement.  For a more provocative point of view, I recommend Erik Miejer's One Hacker Way talk.  Dave Thomas, one of the "pragmatic programmers", also has a good talk on the topic. There's also a good one by Fred George on the hidden assumptions of agile.

My current thought (note: we're back to 2019 now) is that "agile" has become pretty much a meaningless buzz word.  Pretty much everybody is "doing agile" now - or at least claiming they do.  It's come to mean "anything that's not waterfall".  And we all know that "waterfall" doesn't work, which is why everyone is doing "agile".  (Side note: Winston Royce, in his paper that initially described the waterfall process, actually says that it doesn't really work.  But, of course, that didn't stop people from trying.)

Not that agility is a bad concept.  It isn't - being flexible is a good thing.  Responding to change is almost a requirement in most shops.  The values in the Agile Manifesto are all good things to emphasize.  But none of that amounts to a process.  It's just a loose collection of principles and ideas that are useful, but aren't a road-map for how to build software.

That's why, in practice, most shops that "do agile" are using some variation on Scrum.  And while I have no problem with Scrum per se, it's hardly the be-all and end-all of development processes.  In fact, the main problem with Scrum is probably that it's not a software development process - it's more of a project management framework.  It doesn't have a whole lot to say about the details of how to code, how to test, how to manage defects and other quality issues, how to manage releases, etc.  It's up to each shop to figure that stuff out for themselves.

Of course, that's not bad.  Every business is different and you should expect that you'll have to adapt any process to a certain extent.  Scrum is useful in that it gives you a framework for tracking what needs to be done and creating a feedback loop to improve your process.  But you still have to actually use that feedback loop to improve your process, i.e. you have to do the hard work of self-improvement.  Simply going through the motions of what the "agile consultant" says you should do it's going to cut it.  As with everything else in life, there are no shortcuts.