Pull in Practice

First published in The Agile Zone, 8 March 2014

"To pull together is to avoid being pulled apart" - Bob Allisat

Introduction

In the last article we looked at how to gather elementary metrics on team performance. Metrics are invaluable to lean and agile practice. Indeed, teams should have at least some hard data they can subject to retrospective scrutiny. Without a lodestar of objective measurement, team members could rely on anecdotal evidence to guide them on what is going well or poorly. It might then be shrewd rhetorical argument rather than objective analysis which wins the day. The cycle of inspection and adaptation will careen recklessly, and the traction of the agile initiative will suffer. Metrics help the wheels of agile transformation gain purchase and bite.

What is it though, that gives the impulse to an agile team to deliver value in the first place? What is the motive force behind the flow of work through their process? Once starting work, what drives completion? Why doesn't work simply pool in the recesses of a team's machinery, clogging its gears and stifling throughput and velocity? Something draws it through. As if to prove it, on those occasions when metrics show that nothing is being delivered, we conclude that this fundamental vitality is somehow absent or broken. So what exactly is it, this strange force...and why does it sometimes go awry?

Understanding Pull

In Lean and Agile terminology this concept is known as pull. As you'd expect, pull ultimately starts with demand for a product or service. When a team works to deliver something, we can expect there is a customer who has need of this value, and who can put the fruits of the team's labor to good use. Clearly though, pull is more than just the demand exerted by end consumers. After all, history is littered with failed projects - many in the public sector - where there was a clear need to be satisfied and yet, despite great investment, throughput was poor and the product or service was not delivered. Pull was broken.The genius of Lean and Agile practice is to translate end-user demand into an even and consistent flow across the entire development and delivery process. For example, a Kanban team may have stations for work that is done, in test, undergoing peer review, in progress, or which still remains in the backlog.

This is the direction in which pull will be applied, and it is the reason why a team board should be read from right to left. The end customer, or a proxy representative such as a Product Owner, will exert a demand for completed work. The demand will be immediately felt upon work that is currently in-test, as the Product Owner will seek output from that station which is of acceptable and demonstrable quality. Once this work is accepted it will be considered "done" and moved over to that station accordingly. The pull-driven model has begun to take effect.

Moving work into "done" leaves a vacuum of work in test, and this can only be filled by drawing work out of Peer Review. In other words, work that has been satisfactorily reviewed will be moved into test, thereby creating a potential for more work to be reviewed. This can only be satisfied by drawing off from work that is in progress. A vacuum of work in progress will cause new work to be siphoned off the backlog, and the effect of pull across the value chain is thus complete.

Limited WIP and "Stop the Line"

We can see that achieving smooth and even pull is dependent upon being able to limit Work In Progress. In fact, each station in the value chain should be given some sort of limit. Anything below the limit implies a potential for accommodating more work, and it is this which draws work on from the previous station in the chain.

The theoretical limit for achieving optimum pull is exactly one. This is known as single piece flow (SPF) and it has the clear advantage of reducing lead time, depreciation of stock-on-hand, and the cost of delay on each item to the absolute minimum. SPF requires cross-functional team members, all of whom can swarm on a single work item in order to progress it. In fact, in such cases it can be argued that a WIP limit greater than one must mean a push system. SPF can be very difficult to achieve and yet the potential rewards are indisputable. With only one item on hand at any one time, there will be no opportunity for work to pool in the team's engineering process, and very little chance for technical debt and waste to accumulate. The delivery of value can be maximized.

An implication of single piece flow is that any impediments must be resolved on the spot, since it would be unacceptable to bring other work forward and progress it instead. This means that as soon as an impediment is noticed a stop-the-line emergency should be declared and the entire team must swarm to resolve it. No work can be pushed or otherwise brought forward since that would clearly break the WIP limit.

Advantages of Pull compared to Push

A pull-driven model allows value to be delivered in small batches with frequent regularity. There are two huge advantages to this:The customer receives value as and when it is needed, with minimal opportunity for that value to depreciate before they receive it.
When demand is throttled in this way it can be propagated back through the value chain in a safe, controlled, and sustainable manner.

In a pull-driven system a gentle tug will carry down the value chain, and as long as it is maintained it will help to keep things moving. Without this pull, deliveries to a customer will have to be planned in advance. The anticipated requirements will be pushed through the team in an attempt to meet the planned "deadline". Since they are no longer servicing a regular and achievable demand, the ability to sustain controlled and frequent delivery will be forfeited. Instead, large and infrequent releases will become the norm. All of this represents unmitigated risk. Work will collect in the team's delivery process as more of it gets pushed onto them.

Like trying to push a line out to someone, this approach coils into a mess and rapidly gets out of control. Work knots in large batches where it immediately depreciates in value, and technical debt will increase. It will no longer be clear how much of this WIP represents work that is done, and how much of it remains undone. Oh, the benefit that some evenly applied tension in the value chain would bring!

When we introduce a pull-driven system we should expect a constant and gentle tug on delivery that allows value to be paid out smoothly. The demand won't be so weak that nothing is delivered for an age, nor will it suddenly become so violent that the team are jerked forwards, Wile E. Coyote style, into all-out panic mode.

Conclusion

A pull-driven model lies at the heart of lean and agile practice. A customer who exerts frequent demand for delivery, and who also orders the team's backlog of work, can have those needs satisfied on a "Just In Time" basis. These small deliveries will meet the customers immediate needs, and the cost of maintaining stock-on-hand will be correspondingly reduced for all parties. Delivered work is considered to be complete and fit for purpose. This requires a clear and shared understanding of what "done" actually means.

The supplier team will meet this consistent and regular demand by delivering "done" work in small and frequent batches. Their Work In Progress will be limited as far as possible so that maximum throughput can be achieved with minimal cost of delay. Limiting WIP in this fashion allows the demand to be propagated through the various stages of development and delivery, until new work is siphoned off the backlog. Limited WIP, and the ability to "stop the line" in the event of impediment, are essential to achieving "pull" in lean and agile practice.

Page updated

Google Sites

Report abuse