Are there any real alternatives to agile development in commercial software?
There’s waterfall development, which overemphasizes software design in trading off the speed of iteration. It may be appropriate in specific, limited domains where accuracy and bug-free software trumps all else, but few software shops have that level of onerous requirement where waterfall is appropriate.
There’s also embracing the chaos, and having simply no system. Of course, with no tracking, there’s also no way to really measure effectiveness either. But, it’s a tempting option for smaller projects, where it’s sometimes enough to just let a bunch of senior developers use whatever they want as long as the process — or lack thereof — eventually converges to runnable software. Sometimes I wonder if Valve uses this method of development for its games.
Everybody else pretty much defaults to agile.
Nowadays, the term “agile” has been dragged through the mud, rendered inert by the many consulting seminars and conferences and books. It’s one of those mythologies that, from consultants’ mouths, sounds like a bunch of abstract concepts paired with rigorous definitions and proper nouns. In its bloated consultant-distilled form, the introduction of agile to a software team is typically met with either faint cynicism or outright contempt, and understandably so.
Of course, the alternative is to simply pick and choose the parts of agile that make sense for the team. The part that agile consultants don’t like to get into is the reasoning — the why — for all the processes that they instill on a software team, and it turns out that you don’t actually need the entire system for parts of agile to still be useful. Personally, I find tools like retrospectives useful with a clear intent on iterative improvement, but I don’t care about the exact processes that someone else has defined to be “agile”-appropriate. Similarly, I like pair programming, but I’ve more careful and judicious about its use than dictated by extreme programming.
Stuff I don’t care about? Scrums, sprints, standups, test-driven development1, and whatever other standards or values of behavior that agile advocates define a priori. These are all tools and philosophies and processes that may be a good starting point for some teams, but can and should be evolved to fit the team but otherwise eliminated.
And that gets at the heart of any process designed to increase efficiency: they only work if they’re molded to the team, and not the other way around. That requires understanding what’s been slowing the team down, finding an appropriately-sized tool (i.e., not “agile development” in its unwieldy full form), and iterating on that tool till it fixes the problem. It gets back to those original ideals, which are still powerful and applicable to building software.
I realize I’m more biased here than most here, likely due to my experience with the difficulty of testing front-end, user interface code.↩