How to reconcile two seemingly conflicting ideas for setting up a workflow: a linear series of steps vs. parallelization of steps?

On the one hand, we have a reasonably typical Kanban board that facilitates a linear series of steps. Like the board seen in the background of the cover image of David J. Anderson's 2010 book Kanban: Successful Evolutionary Change for Your Technology Business. A single row of multiple columns represents a step or stage that a work item can pass through as it progresses towards fulfillment. On the board, a work item is represented by a card. The work item's progress is indicated by which column it's in on the board.

This helps us see progress and see which parts of the process are smooth and which parts could use some improvement. Great.

On the other hand, Jez Humble, co-author (with David Farley) of the 2010 book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, tells us to "reduce the number of stages as much as possible, and parallelize each stage as much as you can." https://continuousdelivery.com/2010/09/deployment-pipeline-anti-patterns/

This makes sense. Why wait to make a pie's filling until the pie's pastry is made? If both can be made simultaneously, the pie can go into the oven that much sooner.

But how can I represent an item's progress through parallel steps on my kanban board and continue to see which steps are running well and which are the steps at which progress is slowest?

2 Answers 2


Creating the pie's filling and the pie's pastry are two separate work items. They can be worked on in parallel if you have a sufficient number of workers, or sequentially if you're working alone. Each item has its own position on the board.

If you don't cut your work sufficiently that each work item can be represented as a card in one place, you're trying to work on too large items which can't be managed by the process. The "correct" way of slicing work items depends on your particular work, of course.


The examples are unfortunate, they are comparing apples and oranges.

In Kanban, parallelization of work would imply a higher WiP, which in turn reduces lead time. This is because the effort would be scattered different items.

In a Deployment pipeline, you have a (theoretical) infinite effort (because the work is automated) so it won't imply increased lead time.

That's why in Kanban it does make sense to serialise work and in a Deployment pipeline it does make sense to parallelize work.

For the second part of the question...

how can I represent an item's progress through parallel steps on my Kanban board and continue to see which steps are running well and which are the steps at which progress is slowest

For these cases, you have to drill down into the specific parts that composes the most effort consuming step of your Kanban. Assuming you have a car building Kanban board that is:

Car Ordered > Raw Material obtained > Build Parts > Assembly > Car Delivered

where the part consuming more time is Build Parts. So, you should break down this into another Kanban, where there'll be

Part Requested > Cut > Nail & Screws > Painting > Dry > Part ready

You'll then realise that some parts (like windshield, for instance) won't fit it, so you should have a different Kanban board for them. And that's perfectly fine.

You'll then observe the different lead times across both Kanban boards, identify the one taking longer, address it, rinse & repeat.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.