General Lean - Kanban practice.

**Lean

What is Lean?

Lean development is the application of Lean principles to software development. Lean got its start in manufacturing, as a way to optimize the production line to minimize waste and maximize value to the customer. These two goals are also relevant to software development, which also follows a repeatable process, requires particular quality standards, and relies on the collaboration of a group of specialized workers in order to get done.

Of course, there are some major differences between manufacturing and software development, as well -- namely, that manufacturing deals with the production of physical goods, while the value is created in software development is created within the mind of the developer.

Applying Lean principles to knowledge work requires a shift in mindset however, in terms of how value, waste, and other key Lean concepts are defined. Read this post to learn how these 7 Lean principles apply to software development practices. 

Lean Development use below 7 Principles

The seven principles of Lean development are: Eliminate Waste, Build Quality In, Create Knowledge, Defer Commitment, Deliver Fast, Respect People, and Optimize the Whole. In their book, Lean Software Development: An Agile Toolkit, “Mary and Tom Penderecki” outlined how these Lean principles can be applied to software development. Here is a brief summary of each of these principles, as well as practical tips on how to apply them in software development.

Eliminate Waste

One of the key elements of practicing Lean is to eliminate anything that does not add value to the customer. There are seven wastes (or muda) defined in the Toyota school of Lean manufacturing. They are:

Over-production: Manufacturing an item before it is required

Unnecessary transportation: Moving inventory from place to place, this puts it at risk for damage without adding any value

Inventory: Holding inventory adds cost without adding any value to the customer; excess inventory takes up valuable space, increases lead times, and delays innovation

Motion: Literally refers to unnecessary movement of workers on the shop floor

Defects: Quality issues result in rework or scrap and can add tremendous additional costs to organizations who don’t habitually find ways to eliminate sources of defects

Over-processing: Using advanced, expensive tools to do what could be done with simpler tools

Waiting: When inventory waits between value-adding steps

Each of these wastes should be systematically eliminated in order to maximize customer value:

Unnecessary code or functionality: Delays time to customer, slows down feedback loops

Starting more than can be completed: Add unnecessary complexity to the system, results in context-switching, handoff delays, and other impediments to flow

Delay in the software development process: Delays time to customer, slows down feedback loops

Unclear or constantly changing requirements: Results in rework, frustration, quality issues, lack of focus

Bureaucracy: Delays speed

Slow or ineffective communication: Results in delays, frustrations, and poor communication to stakeholders which can impact its reputation in the organization

Partially done work: Does not add value to the customer or allow team to learn from work

Defects and quality issues: Results in rework, abandoned work, and poor customer satisfaction

Task switching: Results in poor work quality, delays, communication breakdowns, and low team morale

Build Quality In

It might seem self-evident every team wants to build quality into their work. But unless this is part of a disciplined practice, it’s far easier said than done. In trying to ensure quality, many teams actually create waste through excessive testing, for example, or an excessive logging of defects.

In recent decades, many Lean development teams have found success by applying the following Lean development tools to build quality into their work. In Lean development, quality is everyone’s job not just QA’s.

These are some of the most popular Lean development tools for building quality in:

Pair programming: Avoid quality issues by combining the skills and experience of two developers instead of one

Test-driven development: Writing criteria for code before writing the code to ensure it meets business requirements

Incremental development and constant feedback

Minimize wait states: Reduce context switching, knowledge gaps, and lack of focus

Automation: Automate any tedious, manual process or any process prone to human error (learn more)

Create Knowledge

The Lean development principle of Create Knowledge is another one that seems simple, but requires discipline and focus to implement. This principle encourages Lean teams to provide the infrastructure to properly document and retain valuable learning. This can be done by using any combination of the following tools:

·        Pair Programming

·        Code reviews

·        Documentation

·        Wiki – to let the knowledge base build up incrementally

·        Thoroughly commented code

·        Knowledge sharing sessions

·        Education

·        Use tools to manage requirements or user stories

·        Defer Commitment

This Lean development principle is easily misused. Defer Commitment does not mean that teams should be flaky or irresponsible about their decision making. Rather, the opposite: This Lean principle encourages team to demonstrate responsibility by keeping their options open and continuously collecting information, rather than making decisions without the necessary data.

To defer commitment means to not plan (in excessive detail) for months in advance, to not commit to ideas or projects without a full understanding of the business requirements, and to constantly be collecting and analyzing information regarding any important decisions.

Deliver Fast

Every team wants to deliver fast, to put value into the hands of the customer as quickly as possible. The question isn’t why teams want to deliver fast, but rather, what slows them down. Here are a few common culprits:

·        Thinking too far in advance about future requirements

·        Blockers that aren’t responded to with urgency

·        Over-engineering solutions and business requirements

The Lean way of delivering quickly isn’t working longer hours and weekends, or working recklessly for the sake of speed. Lean development is based on this concept: Build a simple solution, put it in front of customers, enhance incrementally based on customer feedback. This is important, especially in software, because speed to market is an incredible competitive advantage.

Respect People

The Lean principle of Respect for People is often one of the most neglected, especially in the fast-paced, burnout-ridden world of software development. It applies to every aspect of the way Lean teams operate, from how they communicate, handle conflict, hire and onboard new team members, deal with process improvement, and more. Lean development teams can encourage respect for people by communicating proactively and effectively, encouraging healthy conflict, surfacing any work-related issues as a team, and empowering each other to do their best work.

Optimize the Whole

Sub optimization is a serious issue in software development, and is often a self-fulfilling prophecy. In their book, Mary and Tom Poppendieck describe two vicious cycles that Lean development teams often fall into.

The first is releasing sloppy code for the sake of speed. When developers feel pressured to deliver at all costs, they release code that may or may not meet quality requirements. This increases the complexity of the code base, resulting in more defects. With more defects, there is more work to do, putting more pressure on developers to deliver quickly… so the cycle continues.

The second is an issue with testing. When testers are overloaded, it creates a long cycle time between when developers write code and when testers are able to give feedback on it. This means that developers continue writing code that may or may not be defective, resulting in more defects and therefore requiring more testing.

As the antidote to sub optimization, optimizing the whole is a Lean development principle that encourages Lean organizations to eliminate these sorts of vicious cycles by operating with a better understanding of capacity and the downstream impact of work.

It’s based on the idea that every business represents a value stream the sequence of activities required to design, produce, and deliver a product or service to customers. If our goal is to deliver as much value to our customers as quickly as possible, then we have to optimize our value streams to be able to do just that. To understand how to optimize our value streams, first we have to properly identify them.

After identifying how value flows through their teams, many organizations decide to organize their software development teams to be complete, multi-disciplined, co-located product teams, which enable them to have everything they need to deliver a request from start to finish, without reference to other teams. This is an approach popularized by Spotify that has been adopted by many Lean organizations (including LeanKit) as a way to optimize the whole and increase the speed of value delivery.

It Operations

Your typical day in IT operations isn’t at all typical. In addition to setting up servers and consulting on projects, your team is deploying patches, responding to midnight alerts, and much more. Such broad usefulness results in a flood of planned and unplanned work, making every day unpredictable and full of context switching.

Because of all the starting and stopping, there’s little time to focus on finishing work and even less time to improve processes. Living in reactionary mode eats away at your team’s effectiveness and morale. You want things to be less chaotic and more aligned so your team can deliver more value to the organization and to your customers.

But to gain alignment around what’s most important to the business, you need a way to visualize priority conflicts and shine a light on risks. Enhanced transparency can give you a voice in implementing sustainable improvements that can positively impact your organization’s bottom line.

Project Management

As a project manager, your stakeholders and project teams depend on you to deliver quality software fast. Your customers want to know when it will be ready. The PMO is wondering if things are on track. And your teams need to stay aligned so work keeps flowing.

Because timely communication is critical, your days and some nights are filled with nonstop updates. You’re constantly sifting through inputs and adjusting the project plans, pouring time into translating spreadsheets for every level of your organization. But with all that effort, you still only have part of the story.

Rows and percentages can’t show you where bottlenecks exist, where time is wasted due to handoff delays, or where problems are hindering progress. To truly prevent problems and improve project delivery, you need more insight and more visibility.

**KANBAN

Each step in the Kanban Roadmap is comprised of these elements.

CORE KANBAN

The Kanban principle and concepts upon which the step is based.

Let’s start

A group activity to make each step an interactive, team-based journey (includes a materials list, time involved, and instructions and a real-world example).

·        OBSERVATION POINT: What team leaders need to be on the lookout for during team exercises.

·        HELPFUL TIPS: Extra guidance for the team.

·        THE BOTTOM LINE: The main point.

KANBAN BOARD EXAMPLES

We include sample boards and cards throughout this guide. They’re not the only way of doing things. We encourage your team to make them your own.

Note: MANAGE YOUR EXPECTATIONS

Kanban is less about finding the perfect process and more about continuously improving your process. It can take as few as six weeks to more like two or three months to complete these exercises with your team. During the first month, you’ll spend the majority of your time observing how your newly visualized process shakes out and solidifies. The next month or two will be more about continuous improvement, which can (and will) repeat indefinitely.

Suggestion:

Teams that are already practicing Agile can include these exercises in their two-week sprints.

In this guide, the following terms are interchangeable:

·        Board/whiteboard

·        Lane/a column on the board/a step in your process

·        Card/sticky note/work item

Lean and Kanban Introduction

Introducing Lean and Kanban with short history and how it works.

In the late 1940s, Toyota found a better engineering process from an unlikely source: the supermarket. They noticed that store clerks restocked a grocery item by their store’s inventory, not their vendor’s supply. Only when an item was near sellout did the clerks order more. The grocers’ “just-in-time” delivery process sparked Toyota engineers to rethink their methods and pioneer a new approach — a Kanban system — that would match inventory with demand and achieve higher levels of quality and throughput.

HOW’D THEY DO ALL THAT?

In the simplest terms: by better communication through visual management KANBAN is Japanese for “visual signal” or “card.” Toyota line-workers used a Kanban (i.e., an actual card) to signal steps in their manufacturing process. The system’s highly visual nature allowed teams to communicate more easily on what work needed to be done and when. It also standardized cues and refined processes, which helped to reduce waste and maximize value. A new application of Kanban emerged for knowledge work as early as 2005, and an inquisitive community formed in 2007 around the leadership of David Anderson, Jim Benson, Corey Ladas and others. Their resulting body of knowledge was influenced not only by the Toyota Production System but also by the work of W. Edwards Deming, Eliyahu Goldratt, Donald Reinertsen and other thought leaders. Kanban is now gaining traction as a way to smoothly implement Agile and Lean management methods in tech and non-tech companies around the world. Throughout this fresh take, Kanban’s core elements have remained rooted in the following four principles:

VISUALIZE WORK

By creating a visual model of your work and workflow, you can observe the flow of work moving through your Kanban system.

Making the work visible along with blockers, bottlenecks and queues instantly leads to increased communication and collaboration.

LIMIT WORK IN PROCESS

By limiting how much unfinished work is in process, you can reduce the time it takes an item to travel through the Kanban system. You can also avoid problems caused by task switching and reduce the need to constantly reprioritize items.

FOCUS ON FLOW

By using work-in-process limits and developing team-driven policies, you can optimize your Kanban system to improve the smooth flow of work, collect metrics to analyze flow, and even get leading indicators of future problems by analyzing the flow of work.

CONTINUOUS IMPROVEMENT

Once your Kanban system is in place, it becomes the cornerstone for a culture of continuous improvement. Teams measure their effectiveness by tracking flow, quality, throughput, lead times and more. Experiments and analysis can change the system to improve the team’s effectiveness

NOTE

There are many ways to define Kanban. Our intent in listing the core elements in this manner is not to introduce a new definition but to distill the common principles

Let’s began KANBAN within few steps,

01 MAP YOUR WORKFLOW

Core Kanban

VISUALIZE YOUR WORKFLOW

Unlike other methods that force fit change from the get-go, Kanban is about evolution, not revolution. It hinges on the fundamental truth that you can’t get where you want to go without first knowing where you are. Your first exercise will help you define your team’s workflow and show you how to map the process on a whiteboard. Do this not only with your team but also as a team. Every team has a process for completing its work, even if the workflow is as simple as to do, doing, done.

Start

YOU WILL NEED your team, in a room, around a whiteboard. Dry-erase markers. A pen/pencil and at least five sticky notes for each team member.

TIME

Block out at least 1 hour. You might need more time, depending on the size of your team and the number of your team’s external touchpoints. Don’t shortchange this part of the process. The workflow mapping exercise will encapsulate all of the politics of the group. Many high-value conversations will happen while your team is mapping out its process.

Here the OBSERVATION POINT is

It’s common for team members to debate how the process works and not come to an immediate consensus. See how each person works and thinks. Different personalities may show preference for more or less rigidity. Talk through each reason. Encourage transparency, respect and perspective.

ACTIVITY

·        Each team member writes down the top three to five things that he or she has in process, using one sticky note per work item. Be granular rather than sky level. “Building the week view of the new calendar feature” is better than simply writing “Calendar” on your sticky note. Specifics help the whole team understand the details of each work item.

·        Each team member picks a sticky note from their selection of current work items, sticks it to his or her shirt and “becomes” that piece of work.

·        Below diagram out where your piece of work is in your team’s process by asking the following three questions:

o  Where am I right now?

o  Where did I come from?

o  Where will I go next?

·        Make sure you’ve taken into account not only the work of your team members but also how work flows into the team from leaders, customers and other parts of the organization. REMEMBER, THERE’S NO RIGHT OR WRONG PROCESS.

·        There’s only your team’s process, as simple or as complex as it may be, at this very moment.

Suggestions

·        Resist the urge to redesign your process. Notice specific places in your process where the work isn’t really under your control. Maybe it’s waiting on approval from someone outside the team, or a piece of work is in process somewhere else. Recognize where there are queues in your process and/or where work sits and waits between steps. Include these as steps in your workflow.

·        Now go to the whiteboard, divide it into columns and/or rows, and write the title of each step in your workflow at the top of a column, leaving a bit of whiteboard on each side for a “To Do” lane and a “Done” lane, if they’re not already in your process. Keep your process on the whiteboard for the next exercises. You’ll keep building on it.

·        Be honest about your workflow. This first step is all about taking a snapshot of how your team works so you can improve the big picture later.

02 PUT WORKS ON THE BOARD

VISUALIZE YOUR WORK

Today’s workforce may be armed with retina worthy smartphones and tablets, but plenty of information still comes our way as words on a screen. Emails, spreadsheets, task lists — text is everywhere. While it fits certain scenarios, textual information is not a one-size-fits-all communication vehicle. Its effectiveness is lower than you might think.

Kanban is about teams working towards a shared goal. When putting work on the board, avoid dividing work by the person responsible. Instead, group work items together by project, type of work or other process-based identifier.

YOU WILL NEED

Your team. The whiteboard with your team’s process from exercise one. Dry-erase markers.

A pen/pencil and sheet of paper for each team member. A plethora of sticky notes that are several different colors. A pack of multicolored, round stickers. A pack of sticky flags or index tabs.

TIME

Block out 1 hour. You might use more or less time, depending on the size of your team and how much work is currently in process?

ACTIVITY

·        Each team member writes down his or her work items on a separate sheet of paper. Allow about five minutes for this task. An informal list is all that’s needed; try not to be too granular.

·        Post the lists and compare, looking for themes among the work. Pick one person and analyze his or her list first. For each work item, ask, “What kind of work is this?” (A development team, for example, might have these types of work: feature, defect, user story or task.) As your team members identify different types of work on the first list, they should label their lists accordingly. This part of the exercise continues until a type of work has been assigned to each work item on very list.

Suggestions

Although this exercise correlates card color with type of work, your team may want to use card color to indicate priority, source of demand or some other theme unique to your work. Think about how you will want to analyze the work later. By bug? Feature? Task? This will help you discern which types of work are present with your team. Use the language you use among your team to describe the work. Recognize that you may have different priorities of work. Instead of high, medium and low, use meaningful descriptions of priority that indicate how you will treat each type of work (e.g., expedite, production break fix and regulatory requirement).

·        Designate a different color of sticky note to each type of work.

·        Each team member transfers his or her list of work items to individual sticky notes of the appropriate color.

·        Team members post their sticky notes on the whiteboard in the lane that corresponds with the work item’s current status.

·        Indicate who’s working on what by writing team member names on the flags/index tabs.

·        Use round stickers for blockers.

BOTTOM LINE

Do your best to capture all of your work in process. Don’t worry too much about the granularity of work items at this point. You’ll have items of varying size (i.e., tasks that require more or less time to complete) that will unfold later

Sample Board & Card Example

SAMPLE CARD EXAMPLE

NOTE:

We include sample boards and cards throughout this guide. They’re not the only way of doing things. We encourage you and your team to make them your own.

03 GATHER ‘ROUND THE BOARD

Core Kanban

FOCUS ON FLOW

Now that your work is on the board, it’s time to start moving it. Work items move across the board, from left to right, as progress occurs. When a team member is ready to start work on something new, he or she pulls a new work item into the appropriate lane on the board.

Treat the board — and all of the works on the board— as an asset that belongs to the entire team, rather than work items that are owned by the manager or individual team members. It’s important to think about the entire board as a single system. It has a purpose and a capacity, as well as capabilities and interactions. Focus on managing the flow of work through the system, rather than directing the work of each team member. As you look at the board, notice: How does the work flow? Or, conversely: Where does the work get stuck? The best way to start observing the flow of work is with routine meetings called daily standups and weekly retrospectives. Daily “standups” received their name because teams meet while standing, rather than sitting, when gathered around a board. Standing encourages brevity and staying on task. “Retrospectives” are held on a regular basis (we suggest weekly). They give the team a focused opportunity to evaluate the health of the system, make adjustments and devise experiments. When implemented effectively, standups and retrospectives are powerful tools for teams that seek transparency and open collaboration. Without targeted discussion, however, standups can morph into what’s-on-my schedule recitations, and retrospectives can turn into personnel critiques. The next two exercises will help keep your team focused on the work and the process, while laying the groundwork for a team culture of continuous improvement.

Note: Traditional leadership often manifests itself in rank-and-file rules of engagement. As a team lead or project manager, you may be tempted to jump in and steer standups and retrospectives. Empower your team members to see the bottlenecks and flow for themselves. The best results come from engaging the entire team.

Now you will need your team circled around your work on the board. Extra sticky notes, pens and stickers.

TIME

Block out 30 minutes for each daily standup during the first couple of weeks. As you become more familiar with the routine, you’ll optimize the meeting to a maximum of 15 minutes. Block out an hour for your first few weekly retrospectives. You might use more or less time, depending on the size of your team, how much work is currently in process and if you currently hold standups or retrospectives.

ACTIVITY

HOW TO HOLD A KANBAN STAND UP

·        For optimal efficiency, team members should update the status of their work items prior to stand up, so everyone sees a current picture of the work in process.

·        Each day, a different team member leads the discussion. The leader begins by “walking the board” from right to left to focus first on work items that are closest to completion and asks of those cards, “What do we need to do to advance this piece of work?”

·        Always favor finishing something over starting something new. When the team views the entire system as belonging to them, then the most important outcome is for the team/system to get something all the way to “done.” So when the leader asks, “What do we need to do to complete this piece of work?”, and a person assigned to the work answers, “I just need a little help today to push it over the line,” a team that’s working as one system won’t be short of volunteers.

Suggestion: Try this exercise even if your team already works with standups and retrospectives. The Kanban format is a bit different than Scrum’s and offers a new vantage point.

After walking the board, ask the team:

IS ANYONE WORKING ON ANYTHING THAT’S NOT ON THE BOARD?

No: Continue to the next question.

Yes: Pause to let team members add work items.

WHY: To gain the truest possible understanding of the team’s workload.

WHAT ARE WE LOOKING TO FINISH, AS A TEAM?

Look at business value, encroaching deadlines or your team’s chosen unit of value to reprioritize or reassign work, as needed.

WHY: To reinforce that all work is the team’s work and to help move prioritized work over the goal line first.

CAN WE SPOT ANY BOTTLENECKS OR OTHER IMPEDIMENTS TO THE FLOW OF WORK?

Look for queues of work, loaded lanes or other indicators of risks and issues.

WHY: To observe both the upstream and downstream ramifications of stalled flow and to below diagram out how to get work flowing again.

After walking the board, ask the team: During the first month of holding standups, it’s likely that you’ll notice discrepancies in the granularity of work items. Continue to divide work into smaller tasks and subtasks, as necessary. Look to have your cards represent not only the units of value that your team is expected to deliver but also your capacity to deliver them. The finest of fine-grained tasks may not need to be separate cards on the board; instead, attach them to the main card as to-do lists or subtasks. Work items should be small enough to move across the board at a relatively uniform pace.

Some suggestions: When is a work item truly done? It should mean that a card will not move backwards after reaching “done.” If it does, add a verification, policy or definition of done to your process.

How to Hold a Kanban Retrospective

At the end of every week, gather around the board to evaluate your Kanban system. Observe the flow of work and add a new question each week. By week four, you’ll be asking four questions.

WEEK 1

Is there any hidden work in process (wip) that we haven’t gotten onto the board yet?

Searching for hidden WIP will be an ongoing theme for your first few weeks. It’s not always evident and can take time to reveal itself. As you find it, add it to the board. (Stop here, or if in weeks two through four, move on to question two).

WEEK 2

Can we identify any impediments to the flow of work?

Look at where work is piling up on the board, where work is getting blocked, or parts of the workflow that may be “starved” for something to work on. Discuss ways in which the process or the team’s policies could be modified to remove impediments to flow. Even after you finish these exercises, ask this question during every retrospective. (Stop here, or if in weeks three or four, move on to question three).

WEEK 3

Are we tracking things at the right level of granularity?

If some of the work items are so big that they’ll take months to move across the board, break them down into cards you can complete in a few days or weeks. If your board is littered with very small tasks, consider using task lists associated with the card instead of a card for every small task that must be done in a day. (Stop here, or if in week four, move on to question four).

WEEK 4

A queue or buffer happens when work is in a holding pattern before it goes to the next step. Are there queues or buffers in your workflow that aren’t represented on the board?

If yes, add lanes into your process to represent these queues. Managing the size of queues in your Kanban system is a key success factor to improving the flow of work. Identifying queues will be an ongoing activity, even after you’ve completed the exercises in this guide.

Sample Board

Pay special attention to the start and end states. Where does the work for this team originate? What is the source of demand? If you find that you have two teams working towards separate goals, and those teams’ work rarely intersects, you may have more than one process. Try to reserve one board for each process to the team board to show there are parallel processes at work

Suggestions: Empower individuals to work together toward a common goal. Kanban is about continuously improving your system and managing the flow of work, rather than managing team members and their work directly.

04LIMIT WORK IN PROCESS

Core Kanban

Limit your work in process

It may sound counterintuitive, but limiting your work in process can help you finish more work, more quickly. The more you dive into multiple tasks at once, the less effective you become.

WORK IN PROCESS (WIP) can be defined as all of the tasks you’re working on right now. Although often revered in today’s culture, task switching also known as multitasking or context switching has less than glamorous effects. Juggling simultaneous work doesn’t make you more productive. It just makes you more distracted.

Single task VS multitask KANAB board

Each time your attention switches to a different task, your brain slogs through a neurological warm-up period that prevents you from being wholly present with your work. Error and delay increase. The drain of multitasking on the team, as a whole, manifests in repeatedly re prioritized work. Too much work in process also leads to larger and larger queues, further decreasing productivity. The practice of limiting your work in process is what makes this a Kanban system, rather than a visual to-do list. By using WIP limits, you can improve the flow of work through the process steps you’ve defined on your board. Limiting WIP also helps to focus the team’s attention on shared goals and encourage collaboration. Having less work in process creates shorter feedback loops within the process and gives more flexibility to learn from how your work is flowing through the system, allowing you to make adjustments on the fly.

Some Suggestions: It’s not important that workers stay busy; it’s important that the work keeps moving. Hitting a WIP limit isn’t a failure or a problem to be avoided. On the contrary, it’s an opportunity to change your system so it benefits the team and its effectiveness. You should run up against your WIP limits regularly. If you don’t, they’re probably not low enough. Team buy-in is critical; let the team set its own WIP limit. WIP limits won’t prevent our cultural proclivity for multitasking, but they will show you the detriments that task switching can have on your work.

YOU WILL NEED

Your team circled around your work on the board.

TIME

Block out 30 minutes. You might use more or less time, depending on the size of your team and how much work is currently in process.

ACTIVITY

·        Consider how a piece of work flows through your system by looking at a card that’s recently made it to “Done.” Preferably, choose a card that several team members worked on while it moved through most of the defined workflow on your board.

·        Ask: “How long did that card take to complete?” For this example, let’s say that 10 days passed between the card being pulled onto the board and reaching the “Done” lane. (This is known as a card’s cycle time.)

·        Now, ask each person who worked on the card how much time they spent actively working on it. You’ll probably hear a much smaller number. For this example, we’ll say that your team invested a total of six hours of active work. So why did the card take 10 days to complete? One reason to consider is queues. When step one was finished, the card waited in line for 1.5 days before anyone picked it up to start step two. The card continued in this fashion until it reached the “Done” lane. It’s fairly typical — and sometimes even worse — for a card to spend 85 percent of its time in a queue. Using WIP limits, you can keep the size of the queues in your process lower, so that each item moves more quickly from step to step.

Suggestions:

·        Kanban seeks to “pull” rather than “push” work through your process. A push system “pushes” finished work to the next step, whereas a pull system “pulls” work from the preceding step only when it has capacity. Limiting WIP based on capacity (a pull system) can help work flow smoothly through the board at an optimal rate. Pushing large amounts of work into the system clogs it up and slows everything down (and often makes for poor quality, too).

·        This is why many Kanban teams have acquired a “no-estimate” reputation. Once you see that asking people to estimate how much time something will take makes up only a small percentage of how long it takes to realistically complete the work, many people feel the freedom to stop estimating small- to medium-sized tasks and focus instead on improving throughput of the Kanban system.

·        As a team, identify all of the queues in your process. (Any place a handoff occurs is most likely a hidden queue.) Now identify the largest queues.

·        Add a WIP limit to your board to try to reduce the size of one or more of the largest queues. You may add the WIP limit to the lane that has the queue, or you may find that adding a WIP limit to the lane before or after the queue reduces WIP better. If the queue is a child of some top-level lane, you may consider putting the WIP limit on the parent lane. In the sample board above, a WIP limit covers the “Develop” lane so it applies to the number of cards in both sublanes.

·        If a team member is consistently responsible for too many work items, experiment with personal WIP limits (e.g., “Jason has a WIP limit of three. Only three items can be assigned to him at any one time.”). In general, we recommend process stage WIP limits, but if there’s a particular person who is often overloaded, it’s appropriate to use personal WIP limits.

·        Limiting work in process is the primary way to modify your Kanban system to improve the flow of work. Reducing the size and number of queues present in the process will lower overall WIP and tend to make the work flow through more smoothly.

WHAT TO DO WHEN YOU RUN UP AGAINST THE WIP LIMIT

When you hit a WIP limit, stop doing the kind of work that adds to that queue. Instead, let the work continue to flow through the system. Go help a teammate or work on a task that doesn’t add WIP on the board. Go run some errands. Start an online class. But whatever you do, don’t pile on more WIP at this point.

05 MEASURE AND LEARN

Core Kanban

CONTINUOUS IMPROVEMENT

Managing your work via a Kanban system reveals how the work is flowing through your process. It also gives you the tools to measure flow and the levers to pull to improve it. The exercises you’ve gone through so far can lay a foundation for a team culture of continuous improvement. Now that you’ve tried your first WIP limits, narrowed down the granularity of your work items and found as much hidden WIP as possible, it’s time to start measuring flow.

YOU’LL START BY TRACKING FOUR SIMPLE THINGS:

TOTAL WIP

Total work in process is all of the tasks currently on your Kanban board. It’s anything that’s been started (by anyone) but not completely finished. As you start limiting your work in process, you’ll start seeing this top-line number decrease. As a gut check, divide your total WIP by the number of members on the team to get an average WIP per person. Does it show that each person is “doing,” for example, an average of 15 things? Does that seem like too many?

BLOCKERS

A blocked item can’t move to the next stage in your process because of an issue. While similar to a bottleneck (both create delays), a blocker typically signals an unfinished dependency, a defect or an unavailable skillset. For example, a blocker may arise when you’ve sought information from an external source and can’t complete further work until you receive a response. Focus on three things when measuring blockers: How often are items blocked? How long do they stay blocked? Where in the process do blockers happen? In each daily standup, add “1” to the “blocked days” for that card and note where the block occurred.

Suggestion: As you get better at analyzing these metrics, you’ll want to segment them by card type, priority or another dimension that’s important to your team. For example, you could say that your lead time for standard priority items is an average of 8.5 days but that your lead time for production break-fix items is 1.8 days.

THROUGHPUT

Throughput is the number of items completed per time period. At the end of each week, record how any items were completed (i.e., moved to “Done” and never moved backwards). Track this number from week to week to see how changes made in your Kanban system affect how much total work actually gets done.

LEAD TIME

Lead time is how long a card takes to travel across the entire board. The clock starts when a card is pulled onto the board and stops when it reaches the “Done” lane. On the back of each card, record the start date. Then, when the card reaches “Done,” record the date and calculate how many days (or working days) passed since its start date.

Many calculations are possible with lead time and throughput metrics. Keep it simple in the beginning and only record the average lead time of every card that was finished that week (i.e., the cards you counted to measure throughput).

CONTINUOUS LEARNING

On an ongoing basis, compare these four metrics to see what effect they have on each other. As you reduce the size of queues in your system, it should start to reduce your average lead time. As you experiment with ways to manage blockers more effectively, you should also see lead time reduced. As you continue to limit your WIP, and work together as a team to complete work collaboratively, you should see throughput improve.

Suggestions: As you continue to seek improvements to your process in the coming months, follow these ideas to keep the energy up among your team:

·        Focus your experiments and metrics on improving one or more of your team’s capabilities, whether it’s quicker delivery, predictable delivery or the capability to deliver higher quality, measured in lower defect rates and instances of rework. 

·        Continue to encourage team ownership of the process and focus improvement efforts on the Kanban system, rather than individuals.

YOU WILL NEED

Your team. On the whiteboard, data collected from the last three to four weeks since you began recording metrics on the back of the cards.

TIME

Do this during your weekly retrospective.

ACTIVITY

As soon as you’ve finished the exercise in step four, take time during every weekly retrospective to record data on the back of your cards for blockers, start date, completed date, throughput and lead time.

AT EACH WEEKLY RETROSPECTIVE, CALCULATE AND RECORD:

·        Throughput: the number of cards completed this week

·        Lead time for each card (completed date and start date)

·        Average lead time for this week

·        Cards completed with > 0 blocked days

·        Total blocked days

·        A list of places where cards were blocked

Tally the above for three to four weeks before beginning this exercise.

Suggestion: Continue to study ways to improve your Kanban system by using the resources section of this guide.

SAMPLE CARD EXAMPLE

RUNNING EXPERIMENTS IN A KANBAN RETROSPECTIVE

Instead of asking the four questions from exercise two, you’ll run experiments out of your retrospectives. An experiment, in this instance, isn’t much different from a basic scientific experiment. Evaluate the current state, form a hypothesis, test the hypothesis with an experiment, measure the result and then draw a conclusion. As a team, review your throughput, average lead time, blocker data and total WIP metrics. Have the team pick one of those four metrics for your first experiment. For example, if your average lead time for the past three to four weeks is 11 days (varying between two and 19), you might decide to shoot for less than 10 days. If your blocker data suggests that you might be leaving items blocked longer than necessary, your experiment might be to modify the way your team responds to blockers. Perhaps your team will decide to adopt a “stop the line” mentality; if a card is marked as blocked, it’s “all hands on deck” to remove the blocker as quickly as possible.

Or, if your throughput is three items per week, you might decide to try to increase it. If your total WIP still says that you have, on average, seven items in process per person, your team might try to reduce total WIP to see if it affects throughput. You could then look for queues in the process where you could reduce the WIP limit and watch to see what it does for throughput.

One final example, coming at it from another direction. If your blocker data suggests that you could improve by managing blockers differently, your team could adopt a change in policy for how lockers are managed and monitor lead time, WIP and throughput to see what effect the policy change has on those metrics.

From this point forward, think of your retrospectives as a place to formulate and evaluate experiments. You may have more than one experiment running at once, but always run at least one.

Suggestion: Kanban is an evolution, not a revolution. When you understand the why and how of your process, your team can begin to make small but continuous improvements.