Written on September 9, 2009 by Stephan Schmidt

The high cost of overhead when working in parallel

Astonishingly most companies I know work projects in parallel. This seems a good idea, because no stakeholder has to wait before his projects starts. All are a little busy.

As I’ve written in my free eBook 12 Things You can do to Shorten Your Lead Time, working in parallel is a terrible idea. It increases time to market substantially, sometime by several hundred percent. Working on one project after another – as proposed by Lean with its work in progress limits (WIP) – reduces time to market. Project managers will not attribute long time to market to developers not working, but to the bottleneck which is a low number of developers.

But there is something else to working in parallel. It produces a high overhead. Take a look at the figure:

Parallel Serial The high cost of overhead when working in parallel

Assume we have five projects going on. Each project has a biweekly or weekly status meeting. Then there will be 5 status meetings each week, and due to the longer project life time of parallel projects, we get 100 status meetings (20 weeks a 5 meetings). When work is done in serial, we have one status meeting a week (one project) for 5 months equalling 20 status meetings. Working in parallel has 5 times the overhead.

This multiplies. All stakeholders ask about the status of each project. In serial mode, when a project is not started, they won’t ask about the status. After it’s finished they will neither asked – obviously – about its status.

Projects must be tracked much longer, more documents are produced and must be tracked. All those status messages aggregate, flow upwards toward upper management, clog thinking and time. All those status messages flow to all stakeholders. Each increment per status update is small, much smaller than when working in serial mode.

I hope this gave you the same insights as it gave me. Start working in serial. There might be resistance, but in the long run people will see effects.

You can leave a Reply here. Of course, you should follow me on twitter here.

You can share this post!
Do you want to tell others about this article? Use the social bookmark icons to submit this artice to the service of your choice. Thanks.

About the author: Stephan Schmidt is head of development at brands4friends. He has more than 15 years of internet technology experience and 10 years experience in agile. He was head of development, consultant and CTO and is a speaker, author and blog writer. He specializes in organizing and optimizing software development helping companies by increasing productivity with lean software development and agile methodologies. Want to know more? All views are only his own.

19 Tweets

Comments

Metaflex » One thing at a time please – I’m a developer…

September 9th, 2009

[...] With reference to: http://codemonkeyism.com/high-cost-overhead-working-parallel/ [...]

Itay Maman

September 9th, 2009

Excellent!!

Typo: parallel -> serial (next to last sentence)

Matthew Barcomb

September 9th, 2009

What if it only makes sense to have at most 2 developers on Feature 1? (and other similar scenarios).

stephan

September 9th, 2009

@Matthew: You’re right, the upper limit is the ability to parallize tasks and features. Often one needs to be flexible during the life cycle. Few developers in the beginning, then max out, fewer developers in the end.

stephan

September 9th, 2009

@Itay: Ooops. thanks.

Harald Walker

September 9th, 2009

What is the difference between features and projects? In the text you talk about ‘projects’ but the graphics use ‘features’. And since it takes 5 developers one month the deliver one ‘feature’ I guess it could be called an epic, which can be split up into smaller features and would make a nice Sprint goal.

stephan

September 9th, 2009

@Harald: I think it applies more to features and projects, than stories. Sometimes I do slip into agile talk, because I’m using Scrum for some years. Now I mix nomenclature. I’ll try to be more focused on nomenclature next time.

Jörg Thönnes

September 12th, 2009

With regard to the upper limit of developer which could work on one feature: If you do pair-programming, you can work with 2-4 developers on a feature where no more than 1-2 developers are possible. And pair-programming gives a lot of benefits, ie constant review, better focus, higher quality of code.

stephan

September 12th, 2009

@Jörg: “And pair-programming gives a lot of benefits, ie constant review, better focus, higher quality of code.”

I totally agree.

Serialize Your Projects | Thought Clusters

September 13th, 2009

[...] Schmidt explains how doing several projects in parallel is counter-productive because of the high overhead costs involved. Projects must be tracked much longer, more documents [...]

Matthew D Edwards

October 1st, 2009

Nice, simple explanation. Well done. Reflecting on Fred Brooks’ Mythical Man-Month materials and in particular … (n^2-n)/2 the logic on complexity as it relates to human interaction alone.

What people wrote somewhere else:

codemonkeyism

September 9th, 2009

Blogged about “The high cost of overhead when working in parallel” http://bit.ly/1fnX5d #lean #agile #scrum