Real World Kanban: Do Less, Accomplish More with Lean Thinking

My personal notes on the book Real World Kanban: Do Less, Accomplish More with Lean Thinking.

• What Is Kanban?
  • Kanban was originally a tool used by Toyota to balance demand and capacity across the value chain. The idea is simple: a Kanban card is sent upstream when there is a need for parts. It is only then that production for the needed number of parts is done. The arrival of a new card is a signal to produce more parts, and a lack of cards is a signal to stop. The number of cards is limited to prevent overproduction and to reduce the parts needed in production. Keeping half-finished parts ties up valuable working capital that can otherwise be used for investments.
  • The Kanban rules (as applied in manufacturing) are in fact much more interesting than the Kanban cards: A later process tells an earlier process when new items are required. The earlier process produces what the later process needs. No items can be made or moved without a Kanban. Defects are not passed on to the next stage. The number of Kanbans is reduced carefully to lower inventories and to reveal problems.
• How the six core practices of Kanban apply to knowledge work
  • Visualize workflow. Knowledge work is largely invisible, often hidden in hard drives and in email inboxes. Visualizing workflow allows us as a team to act and learn based on a shared overview. This is helpful to spot bottlenecks and recurring quality problems.
  • Limit Work-In-Progress (WIP). The purpose is to balance demand and capability. By limiting the work-in-progress, we allow our teams to work at a sustainable pace with quality output. Limiting WIP is often the first step to shift the emphasis from starting to finishing. Manage flow. To improve, we manage our constraints and measure flow. The two most common measurements for flow are throughput and lead time.
  • Make process policies explicit. It is hard to make improvements if every team member has a different standard. An explicit policy is necessary so that there is a shared agreement among team members working with the Kanban board. An example can be a definition of “done” per column before moving work forward.
  • Implement feedback loops. A Kanban system will only reflect your side of the story, how you see your quality. You will need to implement a feedback loop as well to help you learn if you are getting it right during product development.
  • Improve collaboratively, evolve experimentally. Evolve using problem solving, experiments, and scientific methods. The big idea behind the Kanban method as applied to knowledge work is to improve evolutionarily from the current state using small steps.
• What Is Lean?
  • Lean is a production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination.
  • In Lean, we judge value from the customer’s perspective.
  • The final leap is to shift focus from optimizing flow to optimizing value. This means organizations go through three phases as they improve. They start off by focusing on resource usage efficiency, and then move on to flow efficiency, and finally to optimizing value.
  • Improvement initiatives need focus and direction, especially in a collaborative setting.
• PDCA (Plan Do Check Act)
  • Understand current state. This describes where you are now. Understanding your current situation is the precondition for setting out a direction.
  • Define expected improvement. This describes what you expect to happen. By clarifying your hypothesis before running your experiment, both you and your peers stand a better chance of detecting unexpected outcomes (new information).
  • Run experiment. Try new things! In product development, we deal with interdependent factors and multiple solution options. Without further ado, run one or more experiments to find the best path to your target condition.
  • Sustain or pivot. If no new information has been generated during the timeframe as set out, you should consider killing the experiment and moving on. If it has produced a positive outcome, implement it as a new standard. A standard in product development can be a consensus on quality as work moves across organizational compartments, or it can be the skills needed to do quality work.
• A sanity check for long-term leadership is that a change should never come as a surprise. Follow this rule, and it will help you build up trust capital. This trust capital is hard currency when it comes to taking risk in periods of uncertainty.
• The goal should not be to implement the perfect process, but simply to make it easy for great people to deliver value and to fix quality problems as soon as possible.
• The way we introduce changes is actually really simple:
  • Talk about it. Talking to people before initiating a change is treating people you work with as thinking, intelligent beings. This is a necessary prerequisite to taking responsibility for the process and the quality produced. Talking with people gives them the chance to weigh in on what is going on and to provide better options.
  • Try! People often have many opinions about how things should work. But there’s only one way to find out how things really work, and that’s by trying them out. It is often helpful to implement a change on an experimental basis for a limited time and then evaluate whether things get better.
  • Evaluate output. It’s easy to confuse actions (fulfillment of your implementation plan) with real improvement. You only really know whether your actions generated the desired effect by observing real outcome (product quality, lead time, predictability on delivery, and so on). The first role to connect with output is management. As a rule of thumb, management is responsible for the outcome of repetitive systems, because they have significant influence on system conditions such as who to hire, how the work is done, and what investments to make.
• Leadership is your ability to seize opportunities and to turn information into action. This requires building up people and managers who are problem solvers and who take initiative when opportunities present themselves. Their efforts need to be supported by a system that is conducive to experimentation.
• Flexibility in organization is your ability to adapt structures, rebalance teams, change processes, and build skills to seize market opportunities.
• Flexibility in technology is the ability to adapt your architecture and technology choices to late information.
• Focus on the Whole, Not Just the Parts.
  • The trouble with successful management of parts is that you lose focus on the whole, and this inadvertently becomes someone else’s responsibility.
• Solicit Fast Feedback to Stay on the Right Track.
  • The trick is to leverage feedback throughout development to find out if you are on the right track.
  • Feedback loops can help us understand if we are solving the right problem and if we are solving the problem the right way.
  • For both hardware and software, time to feedback is a leading indicator of innovation speed.
• Speed Up Time Spent on Decisions
  • An organization’s ability to solve problems and make good decisions is key to keeping up pace.
  • Getting the right information at the right time is crucial to your ability to make shrewd decisions efficiently.
  • One of the solutions that will shorten decision cycles is moving to a more decentralized organization.
  • Communicating the decision coherently so that people understand why it was made and what it means to them is a challenge, too.
• Adopt Modular Design
  • One thing we can do to both give us a faster time to market and reduce the number of late surprises is to modularize our products with loosely coupled dependencies.
  • A modular design has the following merits:
    • Knowing your dependencies up front, instead of being surprised by them
    • Decentralized decision making within components
    • Faster flow of customer value
    • Clarity of purpose for each module
    • Component reuse (preferably extracted from business needs)
• Cultivate an Experimental Culture
  • We need to continuously challenge the status quo. If we don’t, we risk getting stuck in old processes, rigid structures, and obsolete tools simply out of familiarity and habit.
• Key Points to Remember
  • Evaluating output. We achieved three things by shifting management’s attention away from executing detailed plans and toward evaluating and improving output.
  • Optimizing end-to-end. By shifting focus from improving the parts to improving the whole, we can begin to recognize factors outside IT to improve on.
  • Talking to people. Have frequent conversations about where you’re going and why.