One main aspect of product management is working with a product team to deliver the solution to the problems you’ve identified.
In order to work effectively with your team, you need to understand the approach your team uses to organize your work. The Kanban method is one approach that teams use so we wanted to explore it in more detail.
This guide takes a look at:
What is Kanban?
Who invented Kanban?
Values and principles
Kanban practices
Kanban lifecycle
What is Kanban?
The Kanban method is an approach you can use to to design, manage, and improve flow systems for product development work.
When you adopt Kanban, you start with your existing workflow and drive change by visualizing workflow, limiting work in progress (WIP) and finishing in progress work before starting new work.
This means you can successfully use Kanban without going through a wrenching cultural transformation.
Given Kanban’s approach to start with your existing process and evolve it, you don’t have to adopt any new roles in order to adopt it. Use the roles you currently have on your team.
The Kanban method gets its name from the tool used to visualize work progress - Kanban boards. That said, there’s more to Kanban than tracking your work on a board as you’ll see below.
You can use Kanban for product development and several different knowledge work settings. Kanban is particularly applicable in situations where work arrives in an unpredictable fashion and/or when you want to discreetly deploy work as soon as it is ready.
Kanban is often viewed as an alternative to the scrum framework as a way to organize work. Some teams even combine the two approaches in an attempt to gain the benefits from both approaches.
Who invented Kanban?
In 2004, David J. Anderson, inspired by the theory of constraints and the Toyota Product System, incorporated a Kanban pull system in Microsoft’s IT department.
A couple of years later David established the Kanban method when he applied it at Corbis. David produced the first full description of the method when he published Kanban: Successful Evolutionary Change for Your Technology Business in 2010.
Kanban values and principles
The Kanban method is built on a foundation of values and principles. Your team should keep these values and principles in mind as you adjust your approach to product development.
Kanban values
Kanban values guide how your product team behaves in your product development efforts. These values are:
Transparency – share information openly using clear and straightforward language
Balance – balance different aspects, viewpoints, and capabilities to work in an effective manner
Collaboration – the Kanban method improves the way people work together
Customer Focus – make decisions that optimize the value you deliver to your customers
Flow – view work as a continuous flow of value
Leadership – you need the ability to inspire others to act via example, words, and reflection to realize continuous improvement
Understanding – start with knowledge of where you are as an individual and an organization in order to move forward and improve
Agreement – get joint agreement from everyone on your product team to improve in a way that respects differences of opinion and approach
Respect – value, understand, and show consideration for involved with and impacted by your product
Kanban Principles
While the Kanban values guide how your team behaves, the Kanban principles provide guidelines for managing change and approaching work as a collection of services.
Change Management Principles
Adopting the Kanban method does not require a dramatic change in how your team approaches work. The Kanban change management principles reflect this evolutionary approach to change.
Start where you are at. Understand current processes as you actually practice them and respect existing roles and responsibilities
Pursue improvement through evolutionary change
Encourage people to exhibit leadership regarding their position in the organization
Service Delivery Principles
Organizations are a collection of interdependent services. In a product development setting, it’s helpful to think of every product team as a service.
These service delivery principles ensure you focus your improvement efforts on the work, not the people doing the work.
Understand and focus on your customers’ needs and expectations
Enable people to self organize around their work.
Evolve policies so that you can improve customer and business outcomes
Kanban Practices
A set of practices for managing your Kanban system form the core of the Kanban method. These practices include:
Visualize
Limit work in progress
Manage flow
Make policies explicit
Improve collaboratively, evolve experimentally
Implement feedback loops
Let’s take a closer look at each of these practices.
Visualize
When you use the Kanban method you visu
alize your workflow as well as the work going through that workflow. Your team will use a Kanban board to provide this visualization. That Kanban board serves as the focal point for many of your team’s discussions.
An effective visualization of your workflow exhibits the following characteristics:
Identifies your workflow’s commitment point, where your team agrees to work on a specific item.
Identifies your workflow’s delivery point - where your team delivers the work item to your customer
Policies that indicate the work items that exist in each stage of your workflow
Work in Progress (WIP) limits that indicate how many work items can exist in each stage of your workflow
Limit work in progress
Use WIP (work in progress) limits to guide the amount of work your workflow has at any given time. These WIP limits help your team determine when to start new items and when to move items from one stage of the workflow to the next.
When your team uses WIP limits effectively, you can smooth out the flow of work through your workflow and more successfully manage flow.
Manage flow
You want the flow of work through your team’s workflow to exhibit three characteristics:
Deliver the outputs that get you closer to your desired outcome
Minimize lead times
Produce predictable results
To find the balance between these three characteristics, you need to continuously adapt your workflow by inspecting how work progresses through the workflow. The main items you typically keep an eye out for are:
Bottlenecks that slow work down in your workflow
Blockers that stop your workflow item’s progress altogether
Make policies explicit
To describe your workflow you identify the specific stages in the workflow and the policies that govern moving from one stage to the next. You make the stages in your workflow explicit so that everyone on your team understands the key steps in your workflow. You make the policies governing your workflow explicit so that everyone on your team understands how work moves between stages.
Your policies should be simple, well-defined, visible, consistently applied, and easy to revise when your team identifies an opportunity for improvement. A well formulated policy may include WIP limits and some aspects that you’d typically see on a definition of ready or definition of done.
Improve collaboratively, evolve experimentally
Some software development frameworks, notably scrum, require you to upset your current roles, responsibilities and processes. In contrast, Kanban starts with your current process and provides principles and practices you can use to incrementally revise your process.
This incremental change relies on your team to collaborate to identify evolutionary changes in your workflow. The Kanban practices of visualizing your workflow and implementing feedback loops support this practice.
Implement feedback loops
When you use a method based on continuous improvement, you rely heavily on feedback loops. The more feedback loops in different time frames you have the more information you have to make adjustments in your workflow.
The Kanban method introduces a variety of different feedback loops at different time frames ranging from quarterly. The Kanban lifecycle section describes the feedback loops built into the Kanban method in more detail.
Kanban Lifecycle
Kanban relies on your team to establish its own workflow and policies in contrast with agile frameworks such as scrum that establish a process and a time frame in which teams work.
Given this difference, the Kanban “lifecycle” is really a series of feedback loops that provide a regular cadence for your team to inspect work and make adjustments.
Those feedback loops include:
Strategy review (quarterly) - Select the outcomes to tackle and the context in which delivering those outcomes are appropriate.
Operations Review (Monthly) - Understand the balance between and across products, including deploying product teams to address the right outcomes.
Risk Review (Monthly) - Understand and respond to delivery risks that your product team faces.
Service Delivery Review (Bi-Weekly) - Examine and improve the effectiveness of a product team. This is similar to a retrospective focused on improving your workflow.
Replenishment Meeting (Weekly) - Identify items that the team works on and determine which work items may be selected next. This is analogous to a sprint planning meeting in scrum.
The Kanban Meeting (Daily) - Your product team coordinates your activities for the day. This is analogous to a daily scrum.
Delivery Planning Meeting (Per Delivery Cadence) - Plan and monitor deliveries to customers.
What does Kanban mean for product managers?
The Kanban method provides a way for your product team to evolve it’s practices without starting radical reorganization. It gives your team a way to establish a workflow that works best for your development approach. You can also use the Kanban method to guide your discovery process.
Kanban won’t tell you how to do development, or discovery, but it will help you establish and improve the workflows you use for both of those activities. Understanding how the Kanban method works gives you some tools to help your product team improve its development predictability and gives you a tool for organizing your discovery work.
You may even create a discovery board to visualize your discovery work and backlog refinement process.
Discovery board applying Kanban approaches to discovery and backlog refinement
Even if you organize your development work in sprints, you can use Kanban practices to visualize and manage your discovery work. As you gradually expand your understanding of backlog items through your discovery process, they work their way across the discovery board, eventually landing in a column such as the “ready to rock” column in the example above.
The ready to rock column serves as the queue of items to consider for inclusion in your next sprint. When those items are brought into a sprint, you then track them on your team’s delivery board.
This approach with a separate discovery board and delivery board works well if your team is using a dual track agile approach. It allows everyone on the team to see what’s currently going on in discovery and delivery regardless which track they spend most of their time in.
Kent McDonald
Read also
Prioritize with confidence
