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


  • Although the plural of "anecdote" is NOT "data," the history of Apple Computer's Pink and Blue OS teams is interesting:

    By Blogger Reginald Braithwaite, at 6:56 AM  

  • if you really had such an over-abundance of staff, the possible benefits of this approach could yield high rewards.
    You wouldn't want to put an excess amount of staff on one development anyway. PairProgramming alone can have it's problems, what about say.. QuadProgramming? Too many cooks..


    By Anonymous Anonymous, at 2:15 AM  

  • There could be a trade-off between better results and increased cost due to additional resources allocated to a project. We use Microsoft Project 2010 ( and we run on controlled resources. Having additional resources on board must be a helpful scenario.

    By Blogger Unknown, at 11:51 PM  

Post a Comment

<< Home