Tag Archives: slack

why kanban? why focus on lead time reduction?

nicely put by David Anderson: agilemanagement.net/index.php/Blog/why_kanban/

(my emphasis)

knowledge workers such as software developers are overburdened, and … suffer from interruptions, task switching and too much multi-tasking as a result of the overburdening. The overburdening comes from a drive to manage for efficiency (or utilization), that knowledge work is invisible and because the future is uncertain

… demand always exceeds capability to supply, and workers are always busy. Often they start more and more work without a focus on finishing it. This in turn leads to long lead times.

Long lead times are correlated with poor quality. This is almost certainly because … much of the knowledge is tacit

…Much of the work is invisible and a shared understanding of the work and the dynamics of the process that created it are often not achieved. …. Misunderstanding of invisible work require large amounts of coordination effort to reconcile and rework is often needed. Insuring quality and an outcome that matches with original expectations is a constant challenge.

Early delivery of knowledge work often creates additional value. … shortening lead times … is almost always desirable.

Short lead time … demonstrate agility. They also create liquidity in the system. Hence, short lead times (or cycle times) are desirable from a risk management perspective.

…. Kanban systems enable us to limit WIP and avoid overburdening by only pulling work when there is capacity. …. Idleness is a signal that there is an opportunity for improvement. Idleness also provides slack with which to make improvements.

Kanban visualizations …. helps immensely with shared understanding reducing coordination effort and improving quality.

Limiting WIP reduces lead time by reducing multi-tasking. Other kanban system design strategies and staff allocation strategies may reduce task switching. …. Knowledge is often stored between and across members of a network. By keeping the time from starting to finishing short, the risk of knowledge perishing or information becoming stale due to external forces, is greatly reduced. The result is a better product and usually a lot faster.


No …. throughput …. quality …. social capital …. customer satisfaction …. governance … risk …

What we care about is always contextual and has to be based on a mix of customer and other stakeholder expectations.

However, lead time is nearly always one of [the things we care about] because it provides benefits in so many dimensions of risk that reducing lead time nearly always improves the satisfaction for one or more stakeholders.

Slack creates opportunities for improvement without needing to schedule them

Finally, by having fewer work items in process, then the team is able to focus more on the larger goals, and less on individual tasks, thus encouraging a swarming effect, and enhancing teamwork. Limiting WIP like this can seem unusual for teams, and there is often a worry that team members will be idle because they having no work to do, but are unable to pull any new work. The following guidelines, in priority order, can be useful to help in this situation.

  1. Work directly on existing work to progress it
  2. Collaborate with team members on existing work to remove a bottleneck
  3. Begin working on new work if capacity is available
  4. Find some other useful work

When team members have to find some other useful work then “bubbles of slack” are formed around the work. This creates opportunities for improvement without needing to schedule them with techniques such as Gold Cards. This can be work which won’t create any work downstream, but will improve future productivity and can be paused as soon as existing kanban slots become available. Investigative work such as technology spikes, refactoring or tool automation, and personal development or innovation work, are all activities which might help the team in the future.

via methodsandtools.com, Aspects of Kanban by Karl Scotland
(my emphasis)

So, IMO, slack is unplanned improvement work.

“Recipe” for what to work on next:

1. Can you help progress an existing kanban?
Work on that.

2. Can’t do that?
Find bottleneck and work to release it. 

3. Can’t do that either?  
Do work which 
– won’t create any work downstream, 
– will improve future throughput and 
– can be paused as soon as existing kanban related work is available.