Agile Project Planning

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

Wednesday, December 24, 2008

Why Duplicating Effort on Software Projects Could be a Good Thing

So one thing I never hear software people complaining about would be "We have too many people and too much money for this project."

In fact, this situation actually occurs more than you would think in venture funded companies. Once a small startup gets an infusion of cash, the expectation is that they will build out their services to a larger scale, hire more employees to do that, and become a huge success or die trying.

But as we think about the constraints of resources, time, and scope, what is the Agile approach when time and scope are fixed, but resources are not? What should a newly funded startup do to maximize their chances of success over a fixed timeframe?

One option that is rarely talked about (and I admit, possibly because it's not such a good idea) is to run parallel development efforts. This would mean duplicating effort, but also getting a couple of chances to innovate and create a better product.

For example, if you set out to build the next great social networking platform, how can you make it better, cooler, and more compelling? Possibly by creating two or even more teams within your company, and having them try different approaches.

Sound like madness? Maybe, but here are some possible benefits:

1. You'll probably get good ideas from one team that the other didn't think of
2. You'll probably get a better *implementation* of the same idea from one team than the others
3. With more teams, the chances of one coming up with a breakthrough idea is much higher.
4. There's nothing like a little healthy competition to get some serious productivity, creativity, and execution rolling. It's a powerful motivator.
5. You'll get the opportunity to use pieces from each team's effort to make an exponentially better product (not necessarily the code, but certainly the design concepts).

In a sense, this happened at Microsoft back in the 90s when Windows 95 was being created at the same time as Windows NT. The teams liberally "borrowed" ideas from each other, and both products wound up better off as a result.

There are some obvious challenges to this kind of approach - namely what to do with "losing" teams, and the effect of competition on company culture and harmony. But even applied in the small, this approach could have an impact.

Imagine if you applied this concept to specific features rather than a whole product. Maybe take just a week, and have 2 or 3 pairs or individuals flesh out ideas on the feature, then see how it plays out.

I can't imagine this would work in all kinds of situations, but in a venture funded startup looking to become the next big thing, it might be the simplest thing that could possibly work when resources are plentiful.

Labels: ,

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

Thursday, August 07, 2008

The End of Agility?

So now that Agile software development, Scrum, Extreme Programming, and Lean thinking are all the rage, I have to wonder - is this where we thought it would all end up?

This puts me in mind of the early days of object-oriented programming, when Grady Booch first started drawing diagrams with fluffy clouds. It took about 5 years from the grassroots movement of developers finding that sort of modeling useful, to the Rational Unified Process being created, then mandated by organizations as best practice.

I see the same trend, for better or worse, with Agile methods. We now have certifications, big industry conferences, specialized tools and software (yes, my company included), consultants, trainers, and a few dozen books to help guide a fledgling agilist along the way.

Perhaps less encouraging, I also see more of a trend of mandates from upper management to the development organization that sound a bit like "We will use Scrum, whether you like it or not".

It's been about 10 years now since Agile methods (Scrum, XP, etc.) first took the stage. Ten years is usually about right for maturing a product, but what about an industry? Have we reached the peak of agility in organizations and the state of the practice?

If history is any indicator, the environment is ripe for the "next revolution". As the song goes, "Meet the new boss...same as the old boss".

Labels: , , , ,

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

Wednesday, March 12, 2008

Agile Project Collaboration and Restaurants

The software development world keeps trying to come up with good metaphors for what a software project is like. "It's like building a bridge", some say, or "Like manufacturing a car", others say.

I think a much better analogy, especially for the dynamic between the customer and the development team, is ordering food at a restaurant.

As a customer, you know what kind of food you like, how hungry you are, and you might have something in mind to impress your date, whether it's your wife, a client, or your boss.

As a chef, you know what makes food taste good, what the best way to combine ingredients is, how quickly your staff can make a certain meal, what foods are freshest, and how much things cost to get.

Naturally, as restaurant customers, we tend to order what's on the menu, which the chef has thoughfully specified in advance. This would be analagous to certain types of systems that a software team has written before, or are available as an off-the-shelf component (e.g. a blog, user forum, poll, etc.).

If some software customers used the same approach in a restaurant as they did in trying to get systems developed, the converstation might go like this:

Customer: I'd like some chicken, but it needs to be the size of a turkey, and I want it to taste like beef. Don't make it too salty, and it should cost less than a can of tuna. Oh, and can that be cooked in 3 minutes?

Chef: Well, the largest chickens known to man are slightly smaller than a turkey, we could get you that, but they don't taste like beef. We could add some beef sauce, but it won't taste very good. Extra-large chickens cost double what normal chickens do, and take at least 20 minutes to bake. I guess we could chop it into tiny pieces and deep fry it in 3 minutes, but it won't look or taste good. Sorry, but it will cost you about 10 dollars for this, a can of tuna is 60 cents.

Customer: You incompetent fool! If you can't handle this, I'll find a chef who can! My 12-year old nephew cooks all the time, and he can make eggs in 3 minutes flat, and they're really cheap, too. A chicken is just a grown-up egg, right? Why can't you do better than my nephew with all of your experience and training? Are you trying to cheat me???


Sound familiar?

Now this might seem silly in a conversation about food, surely a chef knows more about how to best prepare something that we might like. A more typical request in a "made to order" restaurant might be:

Customer: I really like chicken, but not spicy or with heavy sauce. And I'm watching my health, so too much grease or salt is a problem. Can you make me something tasty?

Chef: Of course: I could make a fresh tomato and spinach pesto chicken with boneless, skinless chicken breast with a fabulous balsamic reduction that just hits the spot.


So what's the problem in software? Is it really that hard to express requirements and constraints, and to let the experts suggest options and approaches?

The main issue as I see it is a question of trust. In a restaurant, you'll know in about 20 minutes if the chef understands your needs and can deliver something tasty. If it works out, you'll gain trust, and certainly you'll want to order from him again.

In traditional software, it can take a lot longer than 20 minutes, or even 20 weeks to see the first results. If the outcome isn't pretty close to what you talked about, trust goes down, fear goes up, and you wind up with some serious issues.

Agile software approaches to project planning and collaboration operate more like the restaurant. Order something, try it, maybe ask for less salt or more cream next time, and repeat.

Before long, you'll develop a great rapport between development team and customer, and you can start talking about what's for dessert.

Labels:

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

Monday, February 25, 2008

Agile Thinking Book now available

Well, my new book is finally ready. It's called Agile Thinking: Leading Successful Software Projects and Teams.

It's a collection of over 40 articles that I've written over the past few years (many on this blog), organized by theme, and reworked and edited for a book format. Hard to believe how much work that turned out to be.

Regular readers of this blog will see a lot of familiar themes and content, and there is an all new introductory chapter that explains Agile methods in down to earth terms - maybe something to get your boss or new team member engaged.

What I really like about how it came out is that you can read it either sequentially, or just pick a random article when you've got only a few minutes to spare. You might not agree with everything in the book, but I think you'll find some useful ideas, some inspiration, and maybe even something that challenges your current perspective.

Have a look at the preview, and get your copy while it's hot (with on-demand printing, it might actually BE a little warm).

Labels:

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

Friday, December 21, 2007

Agile Thinking

In case you're wondering why it's been so long since my last post, there's actually a good reason.

I've been working on putting together a book that distills the stuff I've been writing about for the last three years into a coherent form. The working title is "Agile Thinking".

My wife is a professional editor, so we've been busy cleaning up, cutting down, and rewriting some of the better posts from here, along with some other articles I've written, and organizing them by theme. The goal is to create a guide for real-world Agile project managers, developers, and customers to better understand, challenge, and improve their process.

Hopefully it will be ready sometime in January.

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