If parallelism is bad, why are we all doing it?

Reading time

4 min

There is no obvious “upside” to working on multiple items in parallel.

We increase Work in Progress, which reduces agility and adds cost.
We force individuals into context switching which adds cost and delays and increases stress
As a result we deliver later and at higher cost.
There’s good evidence that quality also suffers.

And yet in my own experience it is the normal behaviour, especially in start-ups and scale-ups and fairly frequently persists into larger organizations. It’s almost like something is pushing teams into this behaviour.

If we are to understand how to counter this we first need to look at why it occurs and why it is so attractive…

Start-up mindset

A key feature of start-ups is the high level of uncontrolled change. There is likely no alternative, while there is no “north star” of a product/market fit to steer to. There is no long term roadmap yet. New work keeps appearing. Often the new work is suddenly now the most important item.

The previous work has to be halted or slowed to make way for the new. This generates a significant volume of incomplete work or Work in Progress.

Teams may move off the old work but continue it in the background through inertia or continuing pressure. People find themselves unable to make a decision to cancel a work item, perhaps because they have no agreed decision making process yet.

Maybe there are still commitments on the old work which need to be delivered. Maybe people just feel that having spent some effort, the work should be finished, a common failing known as the “sunk cost fallacy”.

Blame and parallelism

Management style is a key driver to parallelism. In particular, a Scientific Management tendency for managers to focus on failure. It is not an obvious link, but introducing a less blame-based approach will itself tend to manage parallelism. Let’s look at the relationship between blame and working in parallel.

Imagine you have four features A to D in development. They are a similar size, with similar teams. And initially we plan them all to end at similar times.

Teams will perform at different levels. Some teams are stronger. Environments are complex and teams may discover problems that slow them down. Development is unpredictable and, for whatever reason, there will always be a spread of performance.

After some time we find that teams B and C are close to the original plan. However, A is well ahead and D is significantly behind. How do you, as a leader, respond to this?

The traditional manager

In traditional management, we would say that Feature D is “late”. We don’t want to be late because we will look bad for missing our objectives. Maybe we will miss a bonus or will be shouted at by our own manager. So a fear of failure keeps us focussed on trying to deliver Feature D less late.

Do you recognise this way of thinking? It is the focus on “carrot and stick” external motivation we see in Scientific Management or in McGregor’s Theory X.

How can we “recover” Feature D? Looking at classical project management, we see that Feature A is ahead of schedule. It has some “float” in project management terms. We can use some of that capacity to accelerate Feature D.

There will of course be some cost to this change. Overall there will have been an efficiency loss, some retraining and reforming of teams, some context switch losses. However, the result is that we have a chance to avoid being seen to fail on Feature D.

In the traditional view we haven’t lost anything. We moved some resource. We increased overall cost across all the projects. But we delivered Feature D on time. We achieved our objectives. Most importantly, no-one got fired.

This is because traditional viewpoints put a cost on failure but no value on opportunity. Delivering late is punished, but delivering early is generally not rewarded. This encourages teams to remove focus from their successes.

A focus on blame and failure drives increased parallelism.

Thinking as an Agile Leader

As an Agile leader we should approach this differently.

In Lean and Agile the overall objective is to maximise the delivery of value to the customer. And the mindset should be based on a belief in internal motivation and self-managing teams.

Let’s ask the question – what if we kept people working on Feature A instead of moving them to Feature D?

We would complete Feature A early. What would be the consequence of this?