Agile Project Planning

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

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: http://www.extremeplanner.com

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

2 Comments:

  • The trick is to convince developers who have been trained that they must get it right the first time that it is OK to fail.

    By Anonymous Wayne Allen, at 8:13 AM  

  • Absoutely right. It helps to have strong management support, since most developers haven't seen anything good come from admitting failure in any form.

    By Blogger David Churchville, at 9:57 AM  

Post a Comment

Links to this post:

Create a Link

<< Home