Kanban and Flow

Kanban
- Not a software development lifecycle methodology or project management approach.
- Requires an existing process for incremental change.
- A method for process improvement used by agile teams.
- Teams start by understanding their current software development process and improve it over time.
- Requires the lean thinking mindset.
- Applying the Lean mindset provides a foundation for improvement.
- Focuses on eliminating waste from the process (muda, mura, muri).
- A manufacturing term adapted for software development by David Anderson.
- "The Kanban Method introduces a complex adaptive system that is intended to catalyze a Lean outcome within an organization."
- Kanban is a common way to bring lean thinking into software development.
- Kanban focuses on helping a team improve how they build software.
- Gives a clear picture of software development actions, interactions, and sources of waste.
- Improves over time by removing the root cause of waste.
- Process improvement.
- Applies agile ideas to create a straightforward process improvement method.
- Practices help stabilize and improve the software building system.
- Core practices:
- Follow foundational principles:
  - Start with what you do now.
  - Agree to pursue incremental, evolutionary change.
  - Initially, respect current roles, responsibilities & job titles.
- Adopt the core practices:
  - Visualize
  - Limit WIP (Work In Progress)
  - Manage Flow
  - Make Process Policies Explicit
  - Implement Feedback Loops
  - Improve Collaboratively, Evolve Experimentally (using models/scientific method)
- Partial implementations are referred to as “shallow.”
- Implementations gradually increase in depth as more practices are adopted.

Kanban Principles

Start with what you do now
- Kanban is not a system for managing projects, but a method for improving the process.
- The starting point is the current development process.
Agree to pursue incremental, evolutionary change
- The goal is to make small improvements to the current system.
Initially, respect current roles, responsibilities, and job titles
- These are an important part of the system.
- Kanban only works when the team understands their own system for building software.
- There is no single set of "best" practices.
- Kanban provides practices to improve the system after understanding the current one.
- Kanban does not dictate how to run a project but helps improve the existing process.

Stories Go into the System; Code Comes Out

Recognize that a system exists.
- This is the idea behind the Lean principle: see the whole.
- Stop thinking of the team as making a series of individual, disconnected decisions and start to think of them as following a system.
- In Lean, this is called systems thinking.
Every system takes inputs and turns them into outputs.
From a systems thinking perspective, Scrum can be seen as a system that takes project backlog items as input and produces code as its output.
Apply systems thinking to a Scrum team and it becomes easier to see when you’re doing work that doesn’t directly (or even indirectly) help turn stories into code.
By recognizing that all of Scrum is a system, you can understand how it works better and make improvements to it.
Kanban asks you to start by understanding the system that you and your team use.
Even if you don’t follow a methodology with a name, you can still apply systems thinking to your own team to figure out how you work.
Every software team follows a system, whether they know it or not
Humans intuit rules all the time, and once a rule gets into our heads we have a tough time shaking it.
When a new person comes onto your team, you definitely recognize when that person breaks an unwritten rule.
- Lean even gives us a tool to take unwritten rules and turn them into a system: a value stream map.
When you take an MMF (that’s the minimal marketable feature) and draw out the value stream map that it followed on its path to becoming code, you’ve written down a description of a path through your system.

Kanban vs Task board

One of the most common pitfalls that people run into when learning about Kanban is to attempt to treat it as a methodology for building software. It isn’t.
Kanban is a method for process improvement.
The way that you know they’re not task boards is that they don’t have tasks on them. They have work items.
A work item is a single, self-contained unit of work that can be tracked through the entire system.
It’s typically larger than an MMF, requirement, user story, or other individual scope item.
One difference between a task board and a kanban board is that while tasks flow across a task board, work items are not tasks. The tasks are what the people do to move the work items through the system.
The columns on the kanban board may seem similar to steps in a value stream; how‐ ever, many Kanban practitioners distinguish value stream maps from kanban boards. They will map the state of work items in the workflow separately from the value stream, something that they call workflow mapping.
The difference is that value stream mapping is a Lean thinking tool to help you understand the system that you work in; workflow mapping is how the Kanban method determines the actual steps that each work item goes through.
Scrum is focused on helping teams self-organize and meet their collective commit‐ ments.
A typical kanban board only shows those larger work items, not the individual tasks.
The kanban board will have columns for the steps that a work item goes through before and after the Scrum team gets their hands on it.
The extent use of Kanban and its metrics is likely to have a significant knock-on effect on the method of project management.

Improving Your Process with Kanban

Kanban is an agile method focused on process improvement based on Lean values and thinking.
Traditional process improvement:
- Team gets senior sponsorship, takes measurements, identifies problems, implements improvements, and repeats.
- Aims to make the process repeatable, managed, and under statistical control.
Typical process improvement (often ineffective):
- A company decides programmers aren't efficient.
- Hires consultants to create flowcharts of existing and desired processes.
- Trains teams on new processes, but they find them unnatural and difficult.
- Teams complete paperwork and produce artifacts to appear compliant.
Kanban vs. Traditional Process Improvement:
- In Kanban, improvement is left in the hands of the team.
- Team members find problems, suggest improvements, measure results, and hold themselves accountable.

Visualize the Workflow

The first step in improving a process is understanding how the team currently works.
Unlike Kanban, traditional Process Improvement masks real problems by adding steps that people don't actually do.
If a good idea is added to a diagram, it may seem like it's already being done.
Prevents discovering and fixing underlying problems.
In Kanban, visualizing means writing down exactly what the team does, without embellishments.
It’s part of lean thinking, a Kanban team takes the Lean principle of see the whole very seriously.
Implementing Kanban helps to get into the Lean mindset and adopt lean thinking.

Use a Kanban Board to Visualize the Workflow

Consists of columns drawn on a whiteboard, with sticky notes in each column.
- Kanban boards only have stories and do not show tasks.
- Columns in kanban boards usually vary from team to team.
- Kanban boards can set limits on the amount of work in a column.

For example, one of the first kanban boards in David Anderson’s book, Kanban, has these columns: Input Queue, Analysis (In Prog), Analysis (Done), Dev Ready, Development (In Prog), Development (Done), Build Ready, Test, and Release Ready.

It is important to understand that a kanban board visualizes the underlying workflow and process in use.
In general, you should never copy another kanban board; rather, you should develop your own by studying your own workflow and visualizing it.

Limit Work in Progress

Visualizing the workflow helps the team see this overburdening problem clearly, and that’s the first step toward fixing the problem. Unevenness and overburdening— which we learned about in Chatper 8—become clear on the kanban board when stickies always pile up in one column.
Teams can only do so much work at a time.
Important part of lean thinking.
Taking on more work than can be accomplished leads to problems.
Work may be left out, poorly done, or pace becomes unsustainable.
Multitasking can reduce productivity by half due to task switching.
Quoting Mary and Tom Poppendieck, "We would never run the servers in our computer rooms at full utilization—why haven’t we learned that lesson in software development?"
Unevenness and overburdening become clear when stickies pile up in a column.
Identified unevenness can be controlled using strict limits on work pile-up.
This control is what's behind the Kanban practice limit work in progress.
Limiting WIP means setting a limit on the number of work items that can be in a particular stage in the project’s workflow.
Go back to lean thinking—specifically, the principle of options thinking that you learned about in Chapter 8. One reason that a Kanban team uses a kanban board is because it shows all of your options.
When you look at the whole kanban board, you’ll see many stickies that you can work on next. Maybe there are other stickies in earlier col‐ umns for other features that need to be designed, or ones in later columns for features with bugs that the testers found that need to be fixed.
Setting a WIP limit for a step in your workflow means limiting the number of fea‐ tures that are allowed to move into that step.
We set a WIP limit (or work in progress limit).
There is no hard-and-fast rule that says how large the WIP limit should be; instead, teams will take an evolutionary approach to setting WIP limits.
Example: each release typically has $30$ features, and that the senior managers feel comfortable that they can meet three times over the course of the release, so we’ll choose a WIP limit of $10$ .
The one thing that they don’t do is push more features into the “Manager Review” column.
The reason that this is effective is that the cycle of manager review and team adjust‐ ment is a feedback loop. When this feedback loop is too long—for example, when it’s the length of the whole release—the information that’s fed back into the project becomes disruptive, not helpful.
-When a system has a feedback loop that’s too short, it ends up in a state that’s called thrashing. This is what happens when too much information is fed back into the system, and there isn’t enough time to respond before the next batch of information is fed back.

Measure and Manage Flow

As teams continue to deliver work, they identify workflow problems and adjust their WIP limits so that the feedback loops provide enough information without causing thrashing.
The flow of the system is the rate at which work items move through it.
You already know what it feels like when work is flowing. You feel like you’re getting a lot accomplished, and that you aren’t wasting time or stuck waiting for someone else to do something for you.
-Quoting Mary and Tom Poppendieck, "Software Development: An Agile Toolkit A team can only do so much work at a time. We learned this with both Scrum and XP, and it’s an important part of lean thinking as well."

Use CFDs and WIP Area Charts to Measure and Manage Flow

The kanban board is an important tool for managing flow specifically because it visu‐ alizes the source of the problem, and lets you limit work in progress where it will be most effective.
When you look for the work that piles up and add a WIP limit to smooth it out, you’re taking steps to increase the flow.
An effective tool for measuring flow is a cumulative flow diagram, or CFD.
The CFDs have stripes that correspond to the columns on a kanban board.
The CFDs in this chapter have additional lines on them that show the average arrival rate and average inventory.
The CFD can also show the average lead time.

How to build a cumulative flow diagram and use it to calculate the average lead time

Start with a WIP area chart. But instead of gathering data from a value stream map, you’ll gather the data from the number of work items in each col‐ umn on the kanban board.
Most teams don’t draw them incrementally on a wall; they use Excel or another spreadsheet program that supports charting.
-One reason—aside from ease of managing data—is that the spreadsheet can automatically add a linear trendline to the arrival rate and inventory line charts.
Assigning letters to these values: we used $L$ for the average long-term inventory, $\lambda$ for the average arrival rate (or the number of work items added every day), and $W$ for the average lead time (or the average amount of time a user is waiting for the team to finish a work item request).
You’ll need to add WIP limits to stabilize your system, and you’ll be able to tell that the system is stable once those lines flatten out.
If you have a stable workflow, the average inventory is always equal to the average arrival rate multiplied by the average lead time. That’s a mathematical law: it’s been proven and if a system is stable, it is always true.
Little’s Law, $L = W \times \lambda$

Use a CFD to experiment with WIP limits and manage the flow

One of the core ideas of Kanban is that once you visualize the workflow, you can measure the flow, make your system stable, and actually take control of your project’s lead time by managing the rate that you start work on new work items.
Let’s say that every patient starts out by taking a seat in the waiting room. Eventually, a nurse calls the patient back to one of the exam rooms, where she gets weighed and has her blood pressure and tempera‐ ture taken. Then she waits for the doctor to see her.
The staff sets the policy that there’s a WIP limit of six patients in the waiting room. They enforce this policy by calling up patients and rescheduling them as soon as the waiting room hits its WIP limit.
In this office, there are five exam rooms and two doctors, and they’re almost always occupied. More importantly, that means there can never be more than five patients in the exam rooms, or two patients seeing doctors. Those are WIP limits, imposed by the real-life constraints of the system.
For example, if the office staff sched‐ ules $11$ patients to arrive every hour (so the arrival rate $\lambda$ is $11$ /hour), and the office has average inventory of seven patients over the course of the day (so the inventory $L$ is $7$ ), then Little’s Law tells us the average time patients have to wait: $W = L \div \lambda = 7$ patients $\div$ (11 per hour) $= .63$ hours $= 37$ minutes By using a kanban board and a CFD and experimenting with WIP limits, the office staff discovered that they could reduce the patient waiting time by almost 15 minutes just by scheduling one fewer patient per hour. This works because Little’s Law tells us that lead time in a stable system is affected by exactly two things, inventory and arrival rate—and WIP limits let you control one of those things.

Managing Flow with WIP Limits Naturally Creates Slack

Developers need slack, or “wiggle room,” in the schedule.
When a devel‐ oper feels like he doesn’t have enough time to think about the work, he cuts corners and adds technical debt.
Teams using Kanban also value slack, and understand the impact that slack has on each team member’s ability to do their best work. This is one of the main reasons that they limit work in progress.

Make Process Policies Explicit So Everyone Is on the Same Page

Kanban teams don’t need to write long documents or create huge Wikis to establish explicit policies.
Policies can be as simple as WIP limits at the tops of the columns.
Teams can also write down their policies by adding “definitions of done” or “exit cri‐ teria” bullets to the bottom of each column on a kanban board, so that the team members know exactly when to advance the work items through the workflow.

Emergent Behavior with Kanban

This is why Kanban looks at the entire system in aggregate.
Instead of trying to micromanage every little activity, a team using Kanban uses systems thinking to understand, meas‐ ure, and incrementally improve the system as a whole.
Example: The team used the Five Whys technique to find the root cause of the lead time problem, and introduced WIP limits to help fix it. Visualizing the workflow with a kanban board helped to un-fracture their perspectives. Managers could see that work was piling up, and that helped convince them to agree to WIP limits, and to hold their reviews more often.