This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: How Man-Eating Turtles Can Save Your Software Project
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
Imagine you're on a safari, and your guide tells you that there are hungry man-eating turtles all over the place. The good news is that you can outrun them as long as you see them coming. The bad news is that it's nighttime. Don't you wish you had a flashlight?
OK, there aren't too many man-eating turtles I'm aware of, but this is a metaphor, so bear with me. The same kind of dangers await any software project, just in the (non-man-eating) form of shifting business needs and priorities, technology obstacles, personnel issues, and politics.
The main advantage you have, either on safari, or as a stakeholder in a software project, is to get rapid feedback about where you are, and where the lurking dangers are. Sure, it's possible to get to your destination without it, but it's more likely you'll wind up as turtle food.
In software projects, there are 2 dangers that rapid feedback helps you avoid: failing to deliver the right functionality, and failing to build the right technical infrastructure. You might say these are the man-eating turtles and malaria of software projects.
Much has been said about involving customers in the development of a project, but the point I'd emphasize is that delivering working features that can be used is the most meaningful way to involve them. It's great to get early input, have them review specifications, sign off on technical documents, and so on, but until you get something into their hot little hands, you won't know how you're doing.
Similarly for technical infrastructure (a.k.a system architecture), it's important to know whether you've got a clean, flexible design that can accommodate changes. Here, keeping things as simple as you can is a step in the right direction. If the software you build is more complex to explain to a new developer than for them to write it from scratch in a simpler way, guess what's going to happen in a year or so? Another valuable practice is what XP calls "merciless refactoring" - which means clean up after yourself. Don't make a delicious chocolate cake and leave the kitchen too messy to make anything else. And make sure your customers like chocolate!
So the next time you think about about spending more than a couple of months working on a new feature without delivering it to a customer somewhere (internally or otherwise), think about those turtles that could be nipping at your heels. They may be slow, but they're cunning, and have tremendous closing speed.
Previous Topic
