Why Duplicating Effort on Software Projects Could be a Good Thing
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.