The perils of multiple projects

Posted on May 31st, 2010 in Kanban, Lean by siddharta || 4 Comments

One of the slides from my talk at LSSC was about multiple projects being developed in parallel. (Slide 15)

Background

This was when I was working at Innvo Systems, around 2004-05. The company had got one round of venture capital financing and we were about 20 people strong with one acquired product. We were looking for another round of funding and the pitch was to use the money to scale fast, update the current product to latest standards and complement it with a complete suite of products (3 in all). The pitch worked, we got funded and the race started to scale as fast as possible and build up the suite.

Within a few months, the company scaled from 20 people to a peak of about 50. Around 30 were to be involved with the new product development roadmap, and were split into three teams.

Work on each of the products proceeded in parallel.

What we expected

When we first started out, the plan was that each of the products would be completed in about 12 months. So we would then have a complete suite ready to take to market.

The perils of multiple=

What actually happened

What actually happened was that we were too few people to build three major products from scratch. With three teams, each of the teams ended up being understaffed. In addition, all the experienced folks were divided up among the teams, leaving each team with predominantly the new hires. A substantial portion of time of the experienced folk was spent getting new hires up to speed on the specialized domain.

The end result was that all three teams limped along and it took a lot longer than expected for the complete suite to be finished.

Lessons learned

Instead of working on all products in parallel, it would have made more sense in committing all efforts to one product. When it was complete, the team could have moved on to the second product and later the third product.

By doing this we would have got one complete product out much sooner. We could then take this product out to market and start booking revenue right then, without having to wait for the other products.

Further, it would have made more sense to have one solid team, rather than four understaffed teams. One team of about 15 might have worked out better than three teams of 10. A bonus would be that we could then put all the experienced people in this one team and thereby reduce the ratio of new hires to experienced people. This would have reduced the ramp up time before the team got productive.

One team, Sequential projects Multiple teams, Parallel projects
One solid complete team Each team is understaffed and short of resources
Best team members work together The best team members are divided up
Specialists are first class members of single team Harder to manage specialists common to multiple teams
New team members rise up to the level of other team members Experienced team members need to step down to the level of other team members
Need to manage cross-team communication Reduced need for cross-team communication
Only one team to align Need to align the direction of all teams

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

4 Responses to “The perils of multiple projects”

  1. SeanJA Says:

    You need to switch up those last two bullets points me thinks.

  2. siddharta Says:

    Good catch. Fixed.

  3. Java Development Says:

    I recently a read a article one which dwells about reasons why you should not do multi-tasking.

    Thanks for sharing your experience.

  4. How Queues Impact Business Agility » Tools For Agile Blog » Blog Archive Says:

    […] to increased lead times for all initiatives. I wrote about my own experience in a previous post: The perils of multiple projects. Limiting work in progress is key at both the high level and low […]

Leave a Reply