A quick glance at the dictionary gives us a definition of the word agile – “marked by ready ability to move with quick easy grace.” The IT community has co-opted this word and extrapolated a meaning that is really beyond description. Of course, what else were we supposed to do?
Much comparison has been drawn between building software and physical construction (e.g. building a house). But this comparison really isn’t fair. While it’s true that it’s extremely costly to make changes to a building after it is erected, the same multipliers used in that industry cannot be applied to software. Seriously – have you ever had to bring a demolition crew in to remove a section of code? The delete key is our wrecking ball.
At some point, I’m sure a manager looked at this software construction like building construction parallel and said, “I need you guys to work in a more agile manner.” And there it began. Sure, there were puzzled looks in the conference room, but then they all went back to their war room or desks and started figuring out what the manager meant by agile. Today, we have a half dozen agile methodologies that address this perceived need to move fast. Each of them has their own caveats of “this may not be the best approach for you.” Unfortunately those sections seem to be often skipped.
The Software Development Life Cycle you choose for your project should not be dictated by whichever magazine article is sitting on your desk at the moment. It is a choice that needs to be carefully made based on your entire situation. What is the makeup of your team? Do they work best on well-defined tasks or are they better when left to find creative approaches? What is your relationship and level of involvement and commitment with your customer? What type of project is it – are you solving a well defined problem or is further research required?
My parting thought for today is a continuation of the last paragraph’s them – ask questions. If you are the team lead or project manager, your value comes from applying the experience you’ve gathered from past projects. When your customer or manager makes a broad statement, dive into it and understand what he is asking for. You will then have a much clearer shot at success, no matter what methodology you choose to deliver it.