18

Lean pipelines

Lean is a group of methodologies developed within the manufacturing sector (the Toyota Production System in the 1990s) to help run the business and deliver work on demand and just in time. It aims to deliver products in the most efficient and effective way possible. Lean pipelines provide a different way of visualising workflow, which is based on the stages of work over a length of time rather than blocks of time, as on the agile dashboard.

The primary goals of lean practice are to take out cost by being able to repeat and reproduce things efficiently through an optimum workflow with minimum waste. As well as optimising the flow of work, lean works to add value through continuous improvement of both the product itself and the means by which it is produced. This can also be applied to the phased delivery of a service.

The word ‘lean’ has a number of different definitions and can be used in a number of contexts. Lean can be used to describe leaning upon something or somebody for support, or, to describe the condition of something where it is perceived it carries little or no excess, or, a process or way of doing something that is efficient and economical to carry out, again with little excess or waste.

If we review these definitions in the context of delivering work, lean would be:

• Supportive – a dependable approach that we can rely on to provide support to help maintain perspective and provide insights.
• Streamlined – highly efficient with little waste and excess.
• Economical – delivering value in the most cost-effective way.

Lean pipelines provide a visual representation of the flow of work: the boards show what stage a product, project or customer is at within a defined journey. This could represent the production of a product or a customer journey that progresses through defined stages of work from start to finish (see Figure 18.1).

At each stage the item has a status of to do, which represents work that has been received but not started, doing to show current work in progress, done when an item is ready to pass on to the next stage, and waiting for when an item cannot be progressed due to a delay. This delay might be because there is a wait for resources to become available, or a response is needed in order to progress further.

Mapping work in this way helps to highlight when flow of work may be at capacity, and where bottlenecks or gaps may occur. For example, in Figure 18.1, a number of items are blocked at stage 2, which means that currently there is no actionable work at stage 3, leading to a break in activity at this stage. If the block continues, this will have a knock-on impact at stages 4 and 5, unless the block is released and work can continue to be passed on to the next stage before work runs out at stages 4 and 5.

Lean helps to visualise work to understand systems better, to identify and eliminate constraints, and to find the optimal workflow that meets demand and balances resources. The pipeline is demand-driven, where work is pulled through based on demand, rather than pushed along based on the volume that can be produced. Performance targets are based on current demand, which helps to ensure that we do not over-produce and create unnecessary waste. It helps to coordinate and organise work so that it can be delivered as needed, sometimes referred to as ‘just in time delivery’.

Figure 18.1 Lean pipeline template

Using pipeline mapping can help to break current unwieldy processes or systems into more manageable chunks of activity, helping to focus on achieving better workflows. By breaking work into stages, we can create more economical systems and ensure the best use of resources to meet needs.

Pipelines help to raise awareness of progress and help track and calculate the work that remains to reach milestones or targets. Pipelines also help to forecast when work will be delivered. Lean works to identify and reduce variability of delivery and outputs performance. When blocks and bottlenecks become visible, work can be directed to resolve issues to regain workflow.

Pipelines are useful tracking tools to help identify issues when workload is increasing, and so systems and processes need to scale in order to manage the additional volume of work. If workload increases significantly, existing approaches may no longer be efficient or effective, and change to systems and processes may be needed in order to optimise delivery of the larger volume of work.

If new activities or stages are added to the workflow, tracking can help to identify the impact of that new activity on other areas of the pipeline and help to identify ways to integrate them into the pipeline effectively.

Lean sales pipeline

Even a simple board, like the sales pipeline to help track customer acquisition, delivery and retention in Figure 18.2 can be of great value as a visual aid. A card will move through the board, representing a customer or product, dependent on the stage at which they are currently.

Lean workflow boards work well to help teams hand over work between each other and see what work is coming and how work already completed has progressed. Individuals can see their effect on teams and can see what is next and what happens to their work once it is complete. The use of lean across teams is discussed further in Part 4.

By analysing the work on the board, capacity can be managed, ensuring that bottlenecks or issues that affect one stage of the board can be seen and addressed quickly. If issues that are stalling movement within the pipeline do arise, priorities can be revised to address bottlenecks and return to an even flow of work. Managing the pipeline ensures that capacity is assigned appropriately to maintain optimum flow.

Figure 18.2 Sales pipeline

Use of pipelines to track activities, customers or products really helps to provide a real-time visualisation of work in progress: a snapshot of where we are, which we can review and find ways of improving by becoming smarter, leaner and faster at what we do.

Lean Lego: building the Millennium Falcon

A long time ago in a galaxy office far, far away . . . This is a story about a team of software developers who love Lego and Star Wars, who used lean to build the Lego Millennium Falcon. The manual for the build was 300 pages long, and contained over 5,000 Lego pieces. The team comprised five people.

At the start, the team plunged straight in to the box to find the needed pieces and then put those pieces together. Lego was flying everywhere, as the team tried to find and assemble the first pages of the manual. It went very, very slowly.

The team mapped a simple lean pipeline to track and measure progress (see Figure 18.3).

Figure 18.3 Initial lean Lego board

This helped the team to model their process and workflow and establish, at the current rate, how long it would take to finish the project, which was 48 hours. This felt like forever to the team and not viable.

By visualising the process, the team could see the constraints, namely finding the right pieces for assembly. This changed the team activities from everyone doing the same thing to the team splitting into two groups: some finding pieces and some putting pieces together. The team formed a queue, with an additional status for when a group of pieces had been found and was ready for assembly.

The team finding the pieces analysed the time it took to find pieces, which varied, based on their size and the number of pieces there were in the box. This varied greatly, but the team were becoming better at finding pieces as time passed and they did it more often. They added a new activity and the finding team began to pre-sort the pieces, grouping the same pieces together before picking them for assembly. This greatly reduced the variability and the time to find pieces, thus making it far easier to collate them ready for assembly, as per the manual (see Figure 18.4).

The team also created sticky notes to identify the pieces they could not find after extensive efforts of searching. Based on the rate at which the assembly team were working, the finders filled the pipeline to ensure there were groups ready for assembly, and then switched to sorting the pieces when a number of groups were ready.

Figure 18.4 Lean Lego optimised pipeline

They also introduced limiting work in progress in each stage of the pipeline, which they had to, as they could not turn the page of the manual until those had been grouped in piles on the page ready for assembly. So, when all the parts on a page had been found and grouped, or problems occurred that stopped work in progress, the team swarmed around the problem to solve it. For example, if the piece needed to complete the page was still unfound, everyone would work to find that piece.

The time taken to build the finished model was 28 hours and the team were very happy.

Thanks to James Lewis for allowing me to share his story. (Lewis, 2011) You can watch him on video telling his story, complete with Lego action slides, at: www.agileonthebeach.com.