Agile Project Planning

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

Sunday, August 28, 2005

How do you know if your project is Agile?

Some recent posts about Big Design Up Front being a good thing have stirred the Agile pot. The main problem with a defense of Agile methods today is that there is no definitive statement of what exactly "agile" means. The typical explanations by proponents sounds something like "I know it when I see it."

If as an Agile community we are to clearly communicate, this kind of "bob and weave" argument will have to stand and fight. Skeptics make good points about the dangers of "extremists" in the Agile camp shunning documentation, up front design, solo programming, and other common practices. In turn, agile "thought leaders" make well-reasoned replies, generally of the form "Our community is a big tent, there's room for everyone".

Alistair Cockburn provides the most coherent definition I have seen to date, with his work on Crystal methods, and especially the idea of properties of successful agile projects, not practices.

Most of these properties (e.g. frequent delivery) are easy to measure and to determine if your project is "in the zone" or not. Rather than asking "Do you pair program?", Cockburn asks "Do you deliver software to your users at least once every 3 months?" So a team that has a waterfall style method, but delivers every 3 months, has access to customer experts, communicates well, does automated builds and testing and so on, may still meet the criteria for success, and even agility.

Much of the debate thus far has focused around controversial practices (of XP in particular) such as pair programming and limited design documentation (which although not explicitly stated, is clearly the perception of most practicioners).

In truth, the benefits of agile approaches are easy to see, but the practices are hard to dictate. Can a project produce a lot of clear documentation and still be agile? Can you NOT pair program and still be agile? Can you not do test-first design, aggressively refactor, or have an onsite customer and be agile?

The answers will always depend on the context, the team, the leadership, and the nature of the problem being solved. Trying to codify them into practices may be an exercise in futility. To the credit of the original XP founders, they clearly state that XP is not for every project, and are fairly precise about saying that you are not doing XP if you don't follow all of the practices. However, in the current reality, many teams are practicing variations of XP and other methods with some success and some failure.

It's probably more useful to talk about the properties that an agile approach facilitates, and call any method that generates those outcomes "agile", than to try too hard to define agility as a set of practices.

Then the debate can be about whether a particular property is desirable, instead of whether a certain practice is allowed or not.

For more on agile tools and techniques:

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

Thursday, August 18, 2005

Big Design Up Front Considered Essential?

In a recent article on Joel On Software , Joel writes about functional specs, and concludes:

"I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that."

However, the actual spec he's talking about is a high level description of what the software is supposed to do, along with the screens and what should be on them, generally.

It's about 15 pages of heavily white-spaced, image-laden (OK, they're text images) content that clearly explains the intent of the software, without defining exactly HOW it will be built, or even exactly how it will look. In other words, it's really useful!

To me, BDUF is more about the mindset of planning everything out in advance, down to the smallest detail. It's about behaving as if you have all of the answers, when you don't.

No one ever said thinking wasn't allowed to happen up front. Or writing for that matter. There may some XP or agile proponents who think writing documents of any kind is a Bad Thing. I am not of that crowd. To me agile isn't a religion, whose laws can be pointed to in a Book of Agile. It's a philosophy, and a set of principles that basically say "Don't get carried away trying to predict the future".

So if your project can benefit from some clear thinking, try writing a functional spec. Keep it simple, make it clear when you're just guessing about something, and see how it feels. You may just discover that it's a pretty agile thing to do.

For more on agile tools and techniques:

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

Sunday, August 14, 2005

Do agile software teams make more mistakes?

Does an agile software team make more mistakes than a non-agile one? The answer is a resounding yes, if they're doing it right.

OK, before you flame me with religious fervor, let me explain. Traditional methodologies are about one thing primarily: reducing risk. They say, "Let's get as much right up front as possible, and this will reduce the chance of a big screw-up later." Now, this can work on a project where everything is well known, and everyone on the team has done this exact exercise several times before, all with successful outcomes.

Ever work on a project like that? Yeah, me neither.

For the rest of the projects you'll encounter, there is always a degree of uncertainty and risk. So if we're not going to try to analyze everything to death, what alternatives do we have? Well, one approach is to take more risks in the form of what XP calls "technical spikes." We try things to see if they'll fail or succeed. We do this as much as we can.

In a nutshell, we reduce risk by failing more often. Don't take my word for it. Thomas J. Watson, Sr., founder and former CEO of IBM was quoted as saying:
"Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure. You are thinking of failure as the enemy of success. But it isn't at all. You can be discouraged by failure or you can learn from it. So go ahead and make mistakes. Make all you can. Because, remember that's where you will find success."

So instead of trying to plan our way out of risks we don't know about yet, we wait until we get nervous, and instead of guessing about how hard a problem will be, we try something to see if it will fail.

But what to try? Yes, I'm going to say it: "The simplest thing that can possibly work". OK, it seems trite or silly, but it's a powerful way to look at problems. Often, as developers, we think we'll need a sophisticated solution to a problem, and this is even more so when we try to analyze everything in advance.

So when I see an agile team that's overly concerned with messing something up (and sometimes this even takes the form of worrying about messing up execution of the methodology), I know something's wrong. Why aren't they trying to mess up?

Now, I'm not saying we should stumble around like cats after a particularly invigorating ride on a catnip-laced merry-go-round. Certainly let's start with a plan. And let's agree that we don't know enough today to take that plan too seriously. Let's look for risky areas hiding in dank basements and drag them out into the sunlight. And if some of them skitter away, scaring the beejesus out of us in the process, so be it.

It's not failure that kills most projects, it's fear of failure. So have a little courage, which means be afraid, but take action anyway. The more you fail, the easier it will be to try. And the closer you'll get to succeeding.

For more on agile tools and techniques:

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

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