Lean tools: Pull systems

In the next few articles of this series based on Lean software development: an Agile toolkit, we will explore the Deliver as fast as possible principle, the cornerstone for gaining feedback on design, usability, and whatever else matters about your product.

Pursuing a faster delivery of value (which is, working software) has a series of advantages:

• value starts to be experienced earlier by your users: especially in the financial/monetary/insurance businesses, this is real money.
• Work In Progress is reduced, and the risk that derives from it due to change in requirements and obsolescence is lowered too.
• Bugs do not remain in the value stream (let's say, not deployed) instead of being discovered and fixed while they're still hot. The team members rework a feature while they are still familiar with their code and not weeks later.
• The Decide as late as possible principle works at its best: the faster you deliver, the later you can start to finalize the product or to code at all.

Pull systems

The base model that we can think of to compare methodologies is a system of stories and task, each with its own weight. These tasks must pass through the whole value stream, in the analysis, development, testing, and deployment or release stages.

A classical (in the old sense), ordinary workflow consists of:

• requirements and analysis of a feature are carried out by people in another room or city.
• Documents are pushed to the development team, that must implement them in a fixed period of time no matter if they become obsolete by then.
• Features are then tested and deployed after several months.

Really, I've heard people being proud of the need for 3-months staging processes while tinkering with Java XML configuration and EJB.

A more Agile approach consists of a backlog of features, containing all the unprocessed stories to implement. Only the current iteration is pushed to the team for analysis and coding: the rest of the work remains in the backlog withoutentering the value stream.

A Lean approach usually proposes a pull system, where local signaling replaces global decisions: control is distributed to the team members, which coordinate with each other directly. Work is then not pushed forward when finished, but pulled from the next phase of the value stream.

If you pull your own work into the relevant phase, a bottleneck is detected easily: it does not matter if someone can churn out requirements documents at typing speed if no one can pull them into the development phase. It is just a lot of WIP that does not earn money to your team.

The challenge is to transition from a fixed schedule that gives the illusion of certainty about the timing of the various phases, to a globally optimized system that tries to take as much tasks as possible from the initial to the released state.

Kanban

Unless you have lived under a rock, you certainly have heard of the Kanban concept, which is closely related to pull systems.

A Kanban, originated from the factory world, is a system for ensuring that work elements flow through the system as they are pulled from the last phase of the value stream.

WIP limits are put on each column, so that no phase can contain too many elements; these limits also reduce multitasking and context switches of the people in the team.
Work elements cannot be pushed on the following phases if these are already full; the rates of production at the analysis, development, testing and deployment phases must be harmonious. A bottleneck is detected as a full column that blocks the stream.

The pull of a card off the last column frees a spot, where a card from the previous phase can now be pulled in turn, and worked on. The cycle repeat with the previous phases, in an ideal chain of frequent releases where the lead time of a feature remains short.

In the physical world, this corresponds to a supermarket metaphor: products on the shelves are replaced once they are sold, and not just pushed from the factory or the warehouse on a fixed rate.

The information radiator

This information radiators are a constant: wherever I work, I find it or build it in case it's missing.

Each column corresponds to a phase in the value stream. I've learned that the difference between the Scrum and Kanban version of these boards is mainly the absence (or presence) of WIP limits on the columns.

The problem that has still to be solved is how to interface these boards with remote workers and distributed teams: having the board on a 20" screen is not the same as the wall-wide version that you can touch and move cards upon.