Reducing delivery time by limiting work in progress - Projects and Agile community of practice

I kicked off our third 'Projects and Agile Community of Practice' event in early December with two teams of six participating in a 'work in progress' exercise. Each team had a timer, four project team members and a project manager. The four project team members were assigned a Greek character - Alpha, Beta, Gamma, and Delta. They had a backlog of 30 cards, where card by card each team member would put their specific colour sticky dots on spots on the card that referenced their character, before handing it onto the next team member. The project manager collected the completed cards (work) at the end of the line. Two rounds of work were completed.

Round one: work as fast as possible

In this round the project manager's job was to wrangle the team to work as fast as possible. Each team member worked on each card and 'pushed' it to the next person once they had completed their sticky dots. The exercise had been deliberately set-up so that the fourth team member 'Delta' had more coloured dots to stick on. As the team worked as fast as possible this person became a bottleneck and a good amount of work in progress (WIP) began to queue up waiting for this person.

The last card in the round was coloured red and the timer, as well as timing the whole round, also timed the cycle time taken for this red card to go through the workflow.

At the end of the round most of the team sat waiting for several minutes for the work items queued up to make their way through the last process step. It's fair to say that any new work item added to the team after this point would take a very long time to emerge from the other side as there was such a big queue of backed up work.

This is exactly the situation many organisations find themselves in, with too many projects in flight, too much multi-tasking, and long wait times for work to be finished. If we were dealing with physical outputs, rather than more 'ethereal' knowledge work, you would see piles of partly finished work lying everywhere and take steps to improve your processes. Unfortunately in IT projects partly finished work is not so obvious, which is where Kanban can be invaluable for helping visualise work in progress.

Round two: limit work in progress

In the second round I asked both teams to manage WIP by waiting for the next team member to 'pull' the card from them. In other words, each team member could only go onto their next card once the subsequent person in the line had completed their previous card and was ready to accept another. This in effect throttled the whole system to the pace of the bottleneck - team member Delta.

Once again the last card in the round was coloured red and the timer recorded the cycle time taken for this red card to be completed.

Results

What we found in both teams is that the time to complete all of the work took a bit longer in round two. This was a little unexpected as for previous attempts at this exercise the total duration across both rounds had been roughly the same. Because the team can only work at the pace of the bottleneck usually the throughput (quantity of work completed over time) is pretty much the same whether a push system (round 1) or a pull system (round 2) is used.

Given all other results for the two teams (time to start the red card in round one, and all times in round two) are very similar, it's possible we may be looking at an incorrect measurement where team one's finish time for round one is actually 5.42 not 4.42. This in retrospect is much more likely than the team suddenly getting much faster after the red card went in, and would mean the cycle times for team one are 2:11 in round one down to 37 seconds in round two.

In both cases the cycle time for the red card went down substantially using a pull system. If we accept there was a measurement error for team one in round one, then both teams achieved a cycle time reduction of over 70%. In terms of delivering value earlier and being responsive to changing business needs this would deliver massive benefits to most organisations.

What we learned

Using a 'pull' system to limit WIP, means that work doesn't queue at the bottleneck in a workflow. Work flows steadily through the system, and the cycle time for a piece of work from start to completion is thus much shorter.

• High WIP lengthens cycle time and makes the system less responsive and predictable
• High WIP leads to over-burdening of teams, but typically has no positive effect on throughput
• Systems with high WIP over-compensate by starting work earlier, which creates a vicious cycle (high WIP > long cycle times > low predictability > start earlier > create more WIP)
• Teams achieve the same or better throughput with lower WIP, often have higher quality outputs, and it is much more satisfying work.

In many organisations where the business asks for a new feature or enhancement, the cycle time to deliver can be quite long due to the system already being full with other work items. Expediting a single work item doesn’t magically fix that – you are stealing flow from other work items, whose cycle time will increase as a result. Often multiple work items are expedited, with negative impacts across the whole system. Running with limited WIP will significantly reduce the cycle time to deliver value to the business.

Portfolio Kanban

Following the exercise, I presented to the group on the Lean principles and Portfolio Kanban as ways of applying the lessons from the exercise in their workplace projects.

I spoke about the Lean principles of:

• Defining value
• Mapping value streams
• Creating flow
• Establishing 'pull'
• Pursuing improvement.

I spoke about Kanban and the ability to 'start where you are' for visualising work and establishing a 'pull' system in projects. The change required to implement Kanban is much less jarring than other approaches like Scrum, because you simply start by mapping whatever your current process is.

You can then identify process issues and incrementally improve over time. Once you have visualised your current process using columns to represent process steps Kanban allows you to set WIP limits for the maximum number of work items in each column. This helps you to keep WIP low, but also manage variation through raising and lowering WIP limits and perhaps adding queuing or waiting columns where required. It's always a careful balancing act as lifting WIP limits or adding queues creates extra work in progress.

Increasingly Portifolio Kanban is being used to manage WIP for complex multi-team programmes using a single value stream and across an enterprise as a whole to manage WIP for an organisation. This system is set up by creating higher level boards that abstract the work of teams and focus management more on selecting the next candidates to enter the pipeline. These will be pulled into teams as they finish current projects or features, keeping WIP low, and responsiveness high.

Carl Weller is a Principal Consultant specialising in Project Management and Agile Leadership, based in our Wellington office.