Lean Thinking

The Scrum Guide says Scrum is founded on empiricism and lean thinking (see Scrum at a Glance), and Kanban comes straight from lean manufacturing. This page explains where those ideas come from and what they look like in an IT department such as Kestrel Energy's.

The Toyota Production System

The Toyota Production System (TPS) is the way of organizing production that Toyota developed in the decades after the Second World War. It is most closely associated with the engineer Taiichi Ohno and with the Toyoda family who founded the company. Toyota could not afford the huge warehouses and long production runs of American car makers, so it looked for ways to make many models in small quantities without waste. Ohno described the whole system as an effort to eliminate waste.

Two ideas carry the system:

• Just-in-time: make only what is needed, when it is needed, in the amount needed. Kanban cards (see Kanban) are the signal that makes this work.
• Jidoka, often translated as "automation with a human touch": stop as soon as something goes wrong, so that a defect is fixed at its source instead of being passed on. Any worker may stop the line when they see a problem.

Behind both is respect for people: the workers who do the job are the ones best placed to improve it.

Lean in five principles

The word "lean" was introduced by Western researchers who studied Toyota in the late 1980s, and it spread through books in the 1990s. Lean is a way of thinking about work that focuses on delivering value to the customer through a smooth flow of work, removing everything that does not contribute, and improving continuously with the people who do the work.

James Womack and Daniel Jones summarized lean in their book Lean Thinking (1996) in five principles, usually presented as:

1. Value: define value from the customer's point of view. For a Kestrel customer, value is a working portal, a correct bill and a fast answer, not a well-filled ticket form.
2. Value stream: map all the steps that deliver that value, from request to result, and see which add value and which do not.
3. Flow: make the value-adding steps follow each other without interruptions, queues or batches.
4. Pull: let customer demand (or the next step) trigger work, instead of pushing work on a schedule.
5. Perfection: keep repeating the cycle; there is always more waste to remove.

Waste

In lean, waste (Japanese muda) is any activity that uses time or resources but does not add value the customer cares about. Some waste is unavoidable today (a security review, an audit trail required by law); the aim is to keep that to the minimum and remove the rest.

The seven wastes and their software versions

Ohno's seven wastes are the classic list of waste in production: overproduction, waiting, transportation, overprocessing, inventory, motion and defects. He considered overproduction the worst, because it hides all the others. Mary and Tom Poppendieck mapped the list to software in Implementing Lean Software Development (2006); the pairing below is the one commonly cited.

Many people add an eighth waste: unused talent, people whose skills and ideas are not used because they are only asked to follow instructions. Lean literature also often mentions two related problems next to muda: muri, overburden (people or systems pushed beyond a sustainable load), and mura, unevenness (work arriving in irregular bursts). Both create waste further down the line.

Pull systems

In a push system, work is started because it is planned or available, whether or not the next step has room for it. In a pull system, work is started only when the next step signals that it has capacity, so the amount of work between steps stays small and limited.

Pull is why a Kanban board has WIP limits, and why in Scrum the Developers select work for the Sprint themselves instead of having it assigned. In IT operations, pull means engineers take the next ticket from a shared queue when they finish one, instead of a coordinator assigning ten tickets to each person on Monday.

Flow

Flow means that once work starts, it moves through its steps without long stops. Three habits help most:

• Small batches. One change deployed today flows; forty changes bundled into a quarterly release wait for the slowest one, and if the release fails, finding the cause is hard. Continuous integration and frequent deployment (see DevOps and CI/CD) are lean ideas in software form.
• Fewer handoffs. Every handoff adds a queue and loses information. Cross-functional teams exist largely to remove them.
• Flow over utilization. A team in which everyone is 100% busy has no slack to absorb surprises, so every new piece of work waits. Lean optimizes how fast work moves, not how busy people look.

A useful number is flow efficiency: the time someone actually works on an item divided by its total lead time. In office and IT work it is often strikingly low, because most of an item's life is spent waiting in a queue.

Kaizen and gemba

Kaizen (Japanese for roughly "change for the better") is the practice of continuous, small improvements made by the people who do the work, every day, rather than occasional large reorganizations designed elsewhere. A Sprint Retrospective that produces one concrete improvement each Sprint is kaizen; so is the continual improvement practice in ITIL, with its improvement model and register (see Continual Improvement).

Gemba: go and see

Gemba (Japanese for "the real place") is where the work actually happens. "Go to the gemba" means that managers and improvers should look at the work itself instead of relying on reports. In IT the gemba is the service desk during the Monday-morning peak, the ticket history of a recurring incident, or the deployment pipeline at the moment a release fails. A manager at Kestrel who sits next to the service desk for two hours learns more about why password resets take so long than a month of dashboards would show.

Value streams

A value stream is the series of steps that turns a request into value for the customer, and value stream mapping is the technique of drawing it with the working time and waiting time of each step. Both are explained on The Product and Service Lifecycle, including a mapping example. Here is the lean view of one Kestrel value stream: a request for a new firewall rule for the customer portal.

About 75 minutes of work take seven days. Working faster during the 75 minutes would change almost nothing; removing the waits would. If this kind of rule is low-risk and repeated often, it can become a pre-approved standard change (see Change Enablement), which removes the four-day wait at a stroke.

Lean in IT operations and the service desk

Operations and service desks are full of lean opportunities, because so much of their work is repetitive and waits in queues:

• Approval waits. Routine requests (a software license, access to a shared folder) that wait days for a manager's click. Pre-approve the low-risk ones.
• Handoffs between teams. Tickets bouncing between the service desk, second line and a specialist team. Giving the first line the knowledge and permissions to solve common issues (see shift-left) removes handoffs.
• Relearning. The same incident solved from scratch by different people. A known error and a knowledge article turn it into a two-minute fix.
• Defects that create demand. Every confusing screen in the portal generates calls. Fixing the cause removes work instead of handling it faster; lean calls this kind of avoidable demand waste too.
• Too much work in progress. An engineer with fifteen open tickets finishes each one slowly. WIP limits (see Agile in IT Operations) help here as much as in development.

Common mistakes

• Copying the tools without the thinking. Boards, stand-up meetings and tidy desks do not make an organization lean if decisions are still made far from the work and nobody may stop the line.
• Optimizing one step. Making the developers twice as fast does nothing if changes then wait two weeks for testing. Look at the whole value stream first.
• Chasing utilization. Keeping everyone 100% busy creates queues and long lead times; some slack is what lets work flow.
• Removing necessary steps. A security review or a legal check may not add value the customer sees, but skipping it creates bigger risks. Make such steps fast and small instead of removing them.