Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Saturday, August 06, 2005

Agile Development For MicroISVs

So agile planning and development sounds great and all, but it doesn't apply to one or 2 man software teams, does it?

Let's see, the basic principles are:
  • Keep it simple
  • Get quick feedback from customers
  • Make sure you're working on the most important stuff first
Sounds reasonable, especially if you're trying to run a small software business (micro-isv) or internal development project. I suppose the alternative could be:
  • Design everything you can think of up front
  • Don't release anything to customers until you're "completely done"
  • Implement every minor feature that occurs to you
If you're strongly in favor of the above approach, you should probably stop reading now, I won't blame you.

Still with me? OK, "agile" isn't a religion, it's a practical, common-sense way of building software, and yes, even doing business. For a small software shop, it may be a matter of survival.

So you've got a list of features that you want to implement, but it will take you until 2010 to get it all done. So what do you do? Pick the most important ones to work on based on customer feedback, or if you don't have customers yet, use your best sense of what the market wants.

Don't have a clue if your product offering is good enough to ship? One easy way to find out: Ship it! I'm not advocating putting out low quality software, but rather putting out the simplest software you can that meets its intended use.

What if your customers don't like it? You'll find out quickly based on sales (or lack thereof), and from comments by potential users. How's that for quick feedback?

On the development side, keep a list of features (and bugs as they appear) and prioritize them. Choose a release cycle that works for you, but I suggest a short cycle early in the product lifecycle (3 months or less). Now given a release timeframe, you'll have to choose the set of features that fits into that (allowing time for testing, documentation, etc.). You may find that it's better to implement just one useful part of a major feature than to do the whole thing.

At this point you might be thinking "Duh! This stuff is obvious." And you'd be absolutely right. But what's not obvious is that many small companies drown because they don't get this. What good does it do to be focused on what your customers want, if you never ship software to them? How much value is there in perfecting a "killer" feature, when no one wants it? Why scrap a product just because the first release wasn't a major hit?

I feel so strongly about this, that my company is now offering a free version of our web-based agile project planning software (ExtremePlanner) that supports up to 2 users. Perfect for small development teams (or a single developer) to track your project features and releases. Am I doing this purely out of altruism? Not really, I want your feedback! Haven't you been reading this article? :-)

For more on agile project management:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


Post a Comment

<< Home