Kanban in Action

Authors: Marcus Hammarberg, Joakim Sunden
Apr 30 2018

Contents

1. Review
   1. Verdict: Recommended
   2. The Good
   3. The Bad
   4. The Ugly
2. Notes
   1. Kanban Principles
   2. Visualizing Your Work
   3. Work Items
   4. Work in Process (WIP)
   5. Limiting WIP
   6. Managing Flow
      1. The Seven Wastes of Software Development
      2. Five Focusing Steps
   7. Classes of Service
   8. Planning and Estimating
      1. Planning Poker
   9. Process Improvement

Review

Verdict: Recommended

The Good

• Fable style introduction to Kanban in chapter 1 - I was able to recall most of the chapter from when I read it back in June / July of 2017, a good 9 months later.

The Bad

• TBD

The Ugly

• TBD

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.

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.

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.

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.

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

Five Focusing Steps

1. Identify the constraint of the system: for example, a single machine that all the parts in a factory need to pass through.
2. Exploit the constraint to get the most out of it. For example, make sure the machine is running all the time.
3. 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.
4. Elevate the constraint. For example, buy another machine to share the workload.
5. Rinse and repeat. Go over your system again, and see if the constraint is still the biggest constraint in the system.

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
• You should 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
  • Planning Poker
  • Goldilocks
• 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

1. Have a domain expert explain the requirement in question to the team, to ensure that everyone understands what it’s all about.
2. 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: on the count of three as described earlier, for example.
   • 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