Dear PropellerHeads: I manage a small IT group at work and some of my employees are trying to sell me on “agile development.” It sounds interesting, but also pretty risky. Does it really work?
A: It was smart of your employees to use the term “agile development” instead of “extreme programming,” which conjures up images of tattooed snowboarder-types staring wild-eyed at monitors and smashing cans of Red Bull against their foreheads. “XP,” as the kids call it these days, is one of several software development techniques considered “agile.”
But there are others, and whether or not any particular one will work for you depends on several factors. Applied correctly, by the right people and in the right environment, agile development can greatly increase the quality of your software projects.
So what, exactly, is it? The details are spelled out at agilemanifesto.org, but the general gist is that a “lightweight” approach to writing code – one that is flexible and plans for changes upfront – results in better software. While the original manifesto site is cute, the agilealliance.org site is going to be a better resource for you to learn and transition to agile development practices.
The classic or “heavyweight” development approach focuses on upfront design and burdensome documentation. This leaves little room for customers to make changes or for programmers to make design improvements once the project begins.
A good analogy here is imagine you’re a customer and you need to make a change to the software you’ve asked to be made for you and it was only just discovered as you were testing the product. Now imagine yourself being a salmon that has to swim upstream to spawn. The challenge in front of you and the salmon are pretty much the same. Any guess how many salmon can swim up a waterfall? Surprisingly few, it turns out.
The “agile” part comes partly from emphasizing people over processes. Programmers work directly with customers throughout the life of the project, delivering incremental but frequent improvements. No more hiding in a cubicle for months before presenting a product and hoping for a good reaction.
Complications arise when teams are too large or are spread across the country, or these days, the world. There are benefits to increasing communication, even if it’s not face-to-face. This might sound like common sense, but it’s still not the way many IT shops do things today.
Other aspects of agile development will sound scary because they’re different from legacy techniques. I recommend implementing a few of the safer ideas and adding more intense techniques later if the first ones prove effective.
Extreme programming (extremeprogramming.org) might be the most well-known flavor of agile development. Other examples include Scrum (scrum.org), Adaptive Software Development (ASD, adaptivesoftwaredevelopment.wikidot.com), and Feature Driven Development (FDD, agilemodeling.com/essays/fdd.htm).
Give one a try and the multiply-pierced, weekend base jumpers on your team can stop putting in 60-hour weeks and start training for the X Games. You’re likely to find that your customers will be happier too.