Review: Kanban in Action

Authors: Marcus Hammarberg & Joakim Sundén

Verdict: Highly Recommended

Buy the book and hold on to it as a reference.

The Good

A very solid introduction to Kanban.
Fairly in-depth on the meta-process and gradual, piece-meal incorporation into existing workflows.
Fable style introduction to Kanban in chapter 1 - I was able to recall most of the chapter from when I first read it back in June / July of 2017, a good 9 months later.
Excellent pointers to reference material and Kanban-adjacent information to continue to build one's knowledge.
Strong focus on constant improvement.
Summary section at the end of each chapter provides a quick refresher.

The Bad

The chapter on pitfalls seems to pander to critics.
The last chapter "Kanban Games" might have been better introduced earlier; in retrospect, the "Passing the Pennies" game was a good starting point to explain WIP limits and need to focus on lead times.

The Ugly

Nothing.

Notes

Disclaimer: These are primarily written for my own future reference, but they may be useful to you, either to decide if you want to read / buy the book or as something to revisit. The information is not comprehensive, not in the least - so, please don't use it as a substitute for actually reading the book. As with all my content, some is verbatim from the original source, opinion may be interspersed & of course, YMMV.

Kanban Principles

Kanban aims to make the work flow fast through the whole value chain, from idea or concept to software in production, delighting your customers.

Visualize your work and policies.
Limit the amount of work in progress.
Control flow of work.

Visualizing Your Work

Visualizing your work is ultimately about creating the transparency and information-sharing needed to understand how the work works and to collaborate effectively together.
The process of visualizing work means making information visible that previously wasn’t, making implicit knowledge and policies explicit, and, in doing so, resolving inconsistencies and conflicts that surface.
The kanban board is a great way to visualize your workflow and share information about priorities, who’s working on what, the progress of individual work items, and so on.
By using a big, visible board, the information radiates to everyone interested instead of being hidden in people’s brains or inaccessible tools.
Creating a kanban board is easy: you map the workflow of your work items - that is, the steps they typically go through in order to be completed—to columns you create on a whiteboard or a wall.

Work Items

A work item should contain all the information the team needs to be able to know how to work with it. Of the following, pick and choose what fits your current needs and add features as needed:

A description - So you know what the work is about
An avatar or other marker - So you know who is working on the item
Deadlines and other important dates - So you know when you need to have the item done
Tracking IDs or other references to an external system - So you know where to find more information
Blockers - So you can pick out items that are blocked and therefore hindered from further progress
Type of work - So you know the type of work for each item, which is important so you can prioritize the work items against each other if needed
Progress indicators - So you know how much of the work you have done so far
Size - So you can see the differences in size and effort
Flow data, emotions, and other data accumulated during the flow through the board - So you know how the work behaved and how the team felt about it

Work in Process (WIP)

The more WIP, the longer the cycle time for each work item will be. You should limit the WIP to get faster flow and shorter lead times.
WIP can take many forms, and we looked at some common ones in software development:
- Specifications that haven’t been implemented yet
- Non-integrated code that “works on my computer”
- Untested code, which may or may not live up to your standards
- Code not in production, which sits and wait for the next release
Problems and bad things can follow from having a lot of WIP:
- More context switching
- Prolonged feedback loop, which in turn causes extra work for you
And we mentioned some ways that WIP can manifest itself:
- Increased risk
- More overhead
- Lower quality
- Less motivation

Limiting WIP

There’s no one right WIP limit for you and your team.
Limiting WIP isn’t the goal; improving flow is. WIP limits are merely a tool that helps find problems that hinder a better flow.
A lower WIP limit will move your work faster and also bring problems to your attention more quickly. You want a low WIP limit, but not too low.
When setting out to find a WIP limit, start simple—maybe as simple as the slogan “Stop starting, start finishing.”
You can limit the WIP for the whole team/workflow:
- This approach can help you improve collaboration.
- It helps you keep focus on finishing work items before taking on new ones.
You can limit WIP based on column:
- This puts focus on flowing items through the workflow.
- It can help to manage bottlenecks.
- Maybe you already have a hunch about what you need to improve and can start limiting WIP for that column.
- Work can also be limited by estimated size (story points, for example).
You can limit WIP based on people:
- Limiting the number of avatars that can be in play is one way to easily accomplish this.
- Using swim lanes is another.
- This can help you prevent too much multitasking and people being involved in every item on the board.
Most teams have a WIP limit on the work-item level, not the task level.

"The question is, are you selling keystrokes or completed features?"

Managing Flow

Flow (or continuous flow) is an ideal state that describes a process in which every step in the process creates value, with no interruptions or waiting time.
Pursuing this ideal state is a never-ending quest that will help you not only get a smoother, faster flow but also find problems in your process.
Everything that isn’t value in the eyes of the customer is waste. Eliminating waste leads to better flow.
“Managing flow” is one of the principles of kanban, and there are a lot of things you can do to help the work flow:
- Limit WIP.
- Reduce waiting times in your process: for example, by ensuring that the work is always ready for the next step or by making the work items smaller so that they move faster through the process. Remove blockers as fast as possible. Or why not strive to “never be blocked”?
- Avoid rework by building quality into your process from the start. How much of the demand you have in your system today is failure demand? How can you have less failure demand and more value demand?
- Create cross-functional teams that can minimize waiting times.
- Use goals and targets like SLAs to get clear timeboxes and objectives to strive toward.
Many teams use the daily standup to collaborate well together. Here are some practices to help make a standup great:
- Keep it short and energized: never more than 15 minutes (that’s why you stand up).
- Keep it regular: same time and place every day.
- Keep it disciplined: start and end on time.
- Keep it focused: complete discussions afterward.
Many kanban teams have some practices that they follow:
- Focus on the work, not the workers.
- Walk through the items on the board from right to left.
- Focus on deviations - the smells in your process.
Here are some other things to think about to get the most out of your standup:
- Is all the work visible on the board?
- Are we working on the right thing?
- Do we understand the work?
- Encourage spontaneous ''kaizen'' meetings after the standup in which small improvements are made every day.
Standups can be scaled to more than one team, but make sure each layer adds value and isn’t just another reporting instance. Think about the following:
- Run before or after smaller team standups?
- Who attends?
- What kinds of visualizations are needed?
- How will statuses be synchronized between local team boards and other boards?
"What should I be doing next?" is a common question at standups. With explicit policies on how to handle that question, you minimize the risk of hindering the flow of work.
A bottleneck is something that slows down production. With queues, you can get leading indicators and discover the bottlenecks.
The Theory of Constraints is a management theory built around finding and eliminating bottlenecks in a process.

An activity in itself isn’t a value-add or waste; it’s the return of time invested (ROTI) in that activity which determines if it’s waste or not.

Optimizing for flow vs. optimizing for resource utilization is a strategy decision. Lean as an operations strategy aims to increase resource efficiency through focusing on increasing flow efficiency.

The Seven Wastes of Software Development

Partially done work - Work that isn’t completely done is in reality just work in process. It lies around waiting for you to complete it and adds to your WIP.
Extra features - Taiichi Ohno famously said, “There’s no greater waste than overproduction.” Build the right thing. On an individual level, if you’ve ever thought “This may come in handy” or “Maybe they want this to be configurable,” it's likely wasted.
Relearning - Software development is, to a great extent, learning. Failing to remember mistakes you’ve made before and having to redo them (and relearn the solution) is a great waste. This can happen both in teams and for individuals.
Hand-offs - When you hand work from one person to another, a lot of extra work is created in order to convey necessary information to the next person. Even with that extra work, a lot of information will be lost in the hand-off.
Delays - Delays create extra work.
Task switching - Context switching and the wasteful effect it can have on your focus and capacity can be as high as 10% per switch.
Defects - Defects are work that comes back to you because you did something wrong the first time around. Not only does this create extra work, but typically that kind of work comes at a bad time, slowing down the things you’re working on right now.

Specification by Example: Write your specification in the form of acceptance criteria or concrete examples (real numbers and real data used) of how a feature will be used. The feature will be complete when the example is fulfilled: nothing more, nothing less.

Five Focusing Steps

Identify the constraint of the system: for example, a single machine that all the parts in a factory need to pass through.
Exploit the constraint to get the most out of it. For example, make sure the machine is running all the time.
Subordinate all other work to support the exploitation of the constraint. For example, make sure you don’t send faulty parts to the machine; that would be a waste of time for the constraint.
Elevate the constraint. For example, buy another machine to share the workload.
Rinse and repeat. Go over your system again, and see if the constraint is still the biggest constraint in the system.

Never be blocked: Like a good pool player who always makes sure the shot he is taking sets up the next shot he expects to take, every step a good agile developer takes enables the next step. A good agile developer never takes a step that stops his progress, or the progress of others.

—@unclebobmartin

Classes of Service

Classes of service are a powerful way to make your policies explicit around the service level for certain type of work.
Assigning a class of service to a work item can influence the work item: visualization, prioritization, impact on WIP, and workflow.
Classes of service help the team to self-organize around
- Work selection and scheduling
- Work distribution
- Making sure the work capacity is distributed as decided
Common classes include
- Urgent (or Expedite) - Prioritized over other work
- Fixed Delivery Date - Needs to be completed on or before a certain date
- Regular - Normal items, increasingly urgent, pulled FIFO-style
- Defects - Rework produced by bad quality (you want as few of these as possible)
- Intangible - No tangible business value now, but later: paying off technical debt
Use classes that suit your needs and situation, using the examples in this chapter as inspiration. There’s no one right answer for everyone.

Planning and Estimating

Find the right time to plan - not too early nor too late, just in time:
- Order points are one way to run event-driven planning.
- Planning more often involves stakeholders around you more and builds trust, but it can also be costly. You need to balance it so that you plan with the right frequency.
- Using Disneyland wait times is a way of showing expected delivery times.
Plans and estimates are often requested by others around you, extend the workflow upstream and downstream.
Estimating in exact terms is much harder than giving relative estimates, so prefer doing relative estimates:
- Story points and T-shirt sizes are two common ways of doing relative estimates.
Estimation techniques:
- A line of cards ➜ Pick any work item and then compare the next one to the first: smaller or bigger? When all are laid out, assign T-shirt sizes.
- Planning Poker (see below).
- Goldilocks ➜ Change work items so that they're just the right size for your convenience.
Cadence is the natural rhythm or heartbeat found in your process. In iteration based processes, there are natural cadences when iterations start and stop.
With kanban you can have the cadences you see fit for activities: reviewing, planning, demonstration, and retrospectives. You don’t have to tie it to the flow of your work.
Need for plans and estimates:
- Teams that use kanban see the need for detailed plans decreasing with the tightening of feedback loops.
- Customers don’t want plans and estimates; they want business capabilities.
- Estimating and making plans is useful as long as you’re uncovering new information.
- The #NoEstimates movement talks about abandoning estimates altogether and finding effective ways to work without estimates.

Planning Poker

Have a domain expert explain the requirement in question to the team, to ensure that everyone understands what it’s all about.
Perform the following estimation rounds, and only continue to the next round if you aren’t in agreement of the size of the estimate:
- Round 1 - Conduct silent voting using cards. No discussion, but cast votes. Show votes, for example on the count of three.
- Round 2 - Let people think for a minute or two before doing a new silent vote, still without discussion.
- Round 3 - Let the team members explain why they voted as they did, and then vote again.
- If you’re still not in agreement, then park that story for a separate session, and continue with the next requirement.

Process Improvement

Core to kanban:

continuous improvement
respect for people

Common practices for improvements:

A retrospective is a way for a team to look back on their process and see how they can improve it.
Root-cause analysis is a tool that helps you find the root problem so you don’t only fix the symptom.
Root-cause analysis also guides you to see why the problem is worth solving.
Kanban Kata is a continuous-improvement tool that is based on how Toyota makes improvements.
There are three katas within Kanban Kata:
- Daily Kata ➜ Including improvement work in your daily work
- Improvement Kata ➜ A formalized way to improve your process
- Coaching Kata ➜ Improving the learners
Kata ➜ follow a set way of working toward a goal, until the routine becomes second nature and making improvements becomes the way that you normally work.

Retrospective - Five Distinct Parts

Set the stage w/ the retrospective prime directive: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
Gather data: The team looks back (hence retrospective) at the past period and gathers data about what happened.
Generate insights: Analyze the data to determine what conclusions can be drawn from it.
Decide what to do: Find a suitable set of actions that can be completed before the next retrospective.
Close the retrospective: Good practice is to ask what people about the form of the retrospective and how it can be improved.

Metrics

In order to know if you’re improving or not, you measure your process behavior and analyze these metrics.
Metrics are like a visualization of your process’s health.
The following are common metrics that kanban teams use:
- Cycle time ➜ time taken to complete part of the process
- Lead time ➜ time taken to complete the whole process
- Throughput ➜ number of completed items in a week (or month or some period)
- Due date performance ➜ do you keep your promises?
- Quality ➜ do you deliver with quality?
- Value demand vs. Failure demand ➜ demand on a system caused by failure to do something or do something right for the customer
- Discarded ideas ➜ do you innovate enough or too much?
These are common diagrams that kanban teams use:
- Statistical process control (SPC) chart ➜ A visualization of lead and cycle times
- Cumulative flow diagram (CFD) ➜ Shows a lot of information about your process based on the number of items per stage in your process per day
Finding a good metric can be hard. Remember the following:
- You get what you measure.
- Don’t focus on a single metric - use balanced metrics.
- Use metrics that are easy to capture, or make them so.
- Prefer real data over estimates.
- Use metrics to improve - not to punish.

Principles of Theory of Variation

You should expect things to vary - they always do.
Understanding variation will tell you what to expect.
Work on the causes of variations, which are always found in the system.
Understanding variation tells you when something has happened.

Pitfalls

Kanban can end up just being a long flow of work that seems never-ending - it’s just work, work, work. Make sure that doesn’t happen to you by adding cadences for reviews, retrospectives, and planning as needed.
No timeboxing is suggested when using kanban, which can remove the constraint you need to finish stuff and make trade-offs to do so. To tackle this, add timeboxes to individual items; use deadlines/due dates or SLAs.
Kanban is great because it starts where you are: you don’t have to change a thing about how you work to get started with kanban. But sometimes you need a revolution:
- Nothing is hindering you from taking on new roles or ways of working.
- You can also control the tempo at which you improve by limiting WIP , more or less. Less WIP means more opportunities to improve.
Kanban is a meta-process—an improvement process for an already-existing process. Don’t remove things that work today merely because kanban doesn’t say anything about them.
The number-one mistake when starting with kanban is to begin without any WIP limits. This means there’s no constraint pushing you to improve.

Vijay Talks Tech

Other articles

Review: Getting Results the Agile Way

Review: User Story Mapping

Review: Software in 30 Days

Other articles

links

social