Scrum and Kanban: How to Combine Them for Better Flow

frameworks teams

Points of Clarification

"My team is a Scrum team, we already limit our work in progress."
"Scrum doesn't work for us; Kanban will be much easier because of what we do."
"Software development teams shouldn't use Kanban."
"Scrum won't work on operational teams."
"You're doing it wrong."

If you haven't heard these statements, you probably haven't had a discussion about a team using Scrum or Kanban. The reality is:

Scrum doesn't explicitly define how the team plans and controls the amount of work they do -- just that they get done with what is necessary to achieve their Sprint Goal.
Altering practices where we once delivered every 3-6 months down to a process where we are asked to deliver something every 2 weeks is hard.
Kanban is not easier. "If you cannot do Scrum, you can't do Kanban," Peter Saddington.
All types of teams can benefit from the structure that Scrum provides, especially if the teams are associated with complex and complicated products and services.
We are all doing it wrong until we're not.

Before going further, "Scrum is a lightweight framework." While, "Kanban is not a methodology nor a framework. Rather, it is a management method or approach that should be applied to an existing process or way of working."

As a framework, Scrum is intentionally devoid of practices and protocols that define the ways of working that a team might employ. This is because Scrum aims to define enough "philosophy, theory, and structure help to achieve goals and create value." Although the creators of Scrum describe these things as "immutable," there's plenty of room for teams to experiment with and define how they achieve their goals within their specific context. The creators of Scrum openly encourage teams to embrace practices that enhance their team's ability to achieve business value and customer delight. These include practices from eXtreme Programming and Kanban.

So, there is no Scrum vs. Kanban; there's only Scrum and Kanban [or Kanban and Scrum, depending on your preference].

So Your Team is Looking to Mix Things Up?

There are two things the teams should think about as they seek to change, add, or subtract from the things that define the way they work.

First, principle #10 of the Manifesto for Agile Software Development - "Simplicity--the art of maximizing the amount of work not done--is essential". This manifesto principle reminds us to keep our processes and the way we work lean, do not add steps or activities that may introduce waste or impede the team's ability to learn. Basically, before you add or change something, ask yourselves, "How would the new or updated process enable the improvement we seek? What might be the upstream and downstream impacts of the change?"

Second, consider how the change will be evaluated and how improvements will be measured. Ensure the team has identified the factors that indicate an improvement is needed; based on these, establish a set of measures and the necessary data to assess the team's improvements over time.

Why would a Scrum team consider Kanban?

The team encounters unplanned work on a regular basis; therefore, a significant amount of their work is managed piece-by-piece and not directly aligned with the Sprint Goal. They would look to Kanban to improve the visibility and flow of non-goal-related work.
The team struggles to complete work pulled into a sprint and carries it forward into the next sprint. There are usually a number of causes, but the team cannot isolate and address them. The team would look to Kanban to improve flow and leverage the flow measures to identify areas of improvement.
The team has been using Scrum for some years and is still leveraging the practices they initially implemented when they first learned Scrum. The team would consider leveraging several of the Kanban practices to be disruptive and as a catalyst for improving team performance -- leading to better outcomes.

Why would a Kanban team consider Scrum?

The team is struggling to coordinate and collaborate with customers, stakeholders, and users of the solutions they produce. The team would consider setting a cadence-based, iterative goal and engaging the customers, stakeholders, and users to review goal results and define the next iterative goal -- basically using Sprint Planning and Review.
The team is heads-down working and not aware of the overall flow of work, how their work impacts the big picture, and not taking any strides to solve systemic problems. The team would implement Scrum's cadenced meeting structures to enable team collaboration and improve alignment.
The team has been using Kanban effectively; however, they continue to have difficulty integrating their work with other teams. Dependencies are a regular cause for work being stalled. The team would consider establishing a Scrum structure and cadence aligned with the partner teams. They may also participate in Scrum-of-Scrum sync-ups with partner teams.

Practices and Rules Shared by Scrum and Kanban

Focus on Customer Needs and Value. At the end of the day, great teams aim to deliver high value to their customers and make sure their needs are being met. There's no greater feeling than being on a team, overcoming a complex challenge, and seeing a customer use and benefit from a solution the team built together. Thus, it's no wonder that at its core -- Scrum and Kanban assume the team is hyper-focused on delivering value and delighting customers. This is done through whole-team discovery practices, leveraging Human-Centered design, product and big-picture alignment, frequent customer engagement, and relentless backlog management and prioritization.
Make Work Visible. The starting point for the Empirical Process is Transparency. All team-level frameworks/methodologies/management practices require that all team members share and make transparent the work they are doing so that the rest of the team can self-organize and work together to achieve team goals. Making work visible should be easy -- if it's worth doing and you're doing it, then put a card on the board and manage it through agreed-upon visual protocols. The fact is, making work visible is challenging in environments where work gets done through back channels via rank-level coercion or heroism that disrespects the team constructs.
Self-organizing Teams. In today's workplace, teams are assembled with all the necessary skills and capabilities to fulfill the team's charter and purpose. Teams are presented with missions or projects; it is up to the team to determine the best way to accomplish the goals and how to do the work necessary to deliver. If there are skill or capability gaps, the team is responsible for identifying the gap and coming up with how to overcome it. If teams are held responsible and accountable for the mission or project results, then they make the decision on how to get stuff done.
Manage Flow. All team-level frameworks/methodologies/management practices are built on the back of Lean principles. The first pillar of the House of Lean is Flow, and the goal of the team, management, and organization is to optimize the flow of value. This means the Team Members and management/stakeholders work together to ensure the constraints of the organization's operating systems are addressed. Teams avoid local optimization that impacts upstream and downstream areas; thus, teams will adapt how they get their work done to integrate smoothly with dependent teams -- either suppliers or consumers.
Feedback. Building on the point above and the influence of Lean on team-level ways of working, the PDCA (Plan > Do > Check > Act) Cycle, which was defined to explain how to gain knowledge while on the job, is the nucleus of Lean. Thus, it's the nucleus and, quite frankly, the key to all processes that are aimed at solving complex and complicated work. The most important part of the cycle is Check -- where we observe, listen, and seek to understand the effectiveness of our product or solution. From this feedback, we shape our next steps -- including what we create and how we might do it. All teams should create the environment and establish the practices to ensure rapid feedback loops, powering the PDCA flywheel.
Continuous Improvement. The twelfth principle of the Manifesto for Agile Software Development is "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." The right-most pillar of The House of Lean is Kaizen or Continuous Improvement, sometimes identified as Relentless Improvement. The one thing that is constant is change; with change usually comes the need to adjust our product or solution, alter the way the team gets stuff done, and or learn new skills. Teams should always seek to get better and be ready for the challenges of tomorrow. Being resilient isn't a nice-to-have trait of a team; it's required, and teams become resilient through the growth that results from continuous improvement efforts.

What aspects of Kanban should a Scrum team consider?

Leverage Class of Service. Understanding the work is a starting point for Kanban and should be a starting point in Scrum. Categorizing the backlog items and then aligning these to a Class of Service does two things for a Scrum team: (1) helps to assess the impact of new requests on the team's commitments and (2) establishes a measured way that teams can set expectations. Although it should be applied to all backlog items, Class of Service is especially useful as it relates to unplanned work -- it helps to understand how to plan the work and execution steps and can be helpful to analyze the impact of unplanned work.
Refining the team's board. The starting point for most teams' Scrum board or Storyboard is very simple -- not started, ready, in progress, done, and accepted. Keeping the states simple helps to drive whole-team ownership of the work so that the states represent the activity state of the work -- not the specific person or work center. Having the teams add states that impact flow and understand the time work spent in these states may lead to opportunities for improvement, as well as highlight the constraints in the system.
Adding an Expedite lane. This is another board modification teams can make to enhance the ability to create visibility and manage urgent, unplanned work. Most teams respond to customer support requests, including application configuration updates, bug triage and fixes, and minor urgent feature enhancements. This work often gets blended into the planned work; thus, it becomes hard to manage until it's too late, impacting the team's ability to hit their sprint goal.
Establishing WIP limits. It is argued that Scrum teams limit work-in-progress (WIP) based on the items pulled during Sprint Planning. The problem teams run into is that everything goes into progress and stays there until close to the end of the sprint, making it difficult for team members to support and rally around the work that might require additional brain power or support to complete in the sprint. To overcome this, teams can implement WIP limits that help the team self-organize around the activities that need swarming or focus. WIP limits can be applied on the state (column), across multiple states, a row/work-item grouping (e.g., Expedite lane), or the whole board.
Make Policies Explicit. Although a team might have working agreements, they may not have clear, agreed-upon protocols and policies for dealing with challenges and situations that arise during a sprint. Kanban teams make the protocols and policies explicit -- written, visible, and understood -- so that the team can better self-organize and drive accountability. Establishing explicit policies does two things -- (1) aligns team members on practices and ways to work and (2) fosters conversations around how work is completed within the context of the solution being built.
Leverage Flow Metrics. Flow Metrics are Throughput, Efficiency, Cycle Time, Distribution, WIP, and work-item state aging. These metrics help assess process efficiencies and the impact of process improvements. Please note that teams should consider quality, product value, and people metrics in addition to the flow metrics.

What aspects of Scrum should a Kanban team consider?

Establishing a Cadence. A key element of Scrum is creating focus by constraining the working window and controlling the chaos by establishing "Doing" and "Thinking" time habits. This is done by time boxing -- setting the maximum duration of an event. By doing this, teams create a schedule and or agenda that allows them to plan their work and life, knowing what to expect -- as well as engage with customers and stakeholders to set predictable expectations.
Events. Scrum defines five events, including the Sprint itself. While the Sprint is aligned to "Doing" time, Sprint Planning, Daily Scrum (standup), Sprint Review, and Retrospective are all aligned to "Thinking" time. "Doing" time is the time the team spends creating the increment. "Thinking" time is when a team reflects and collaborates. During this time, the team will review what has been created, assess against our goals and or strategy, identify opportunities for improvement, and plan what to do during the next "Doing" cycle. Whether a team follows the exact Scrum events or something similar as laid out in the Essential Kanban Condensed book, slowing down or stopping what you are doing and taking time to reflect, introspect, and plan is a core part of the PDCA loop -- the way we learn and get better on the job.
Role Clarity. Scrum establishes three roles that help distinguish who is focused on the three aspects of creating a product or solution. The roles are not titles, but they describe key elements of the Scrum Framework that each role is responsible for. The Product Owner is focused on identifying the right thing to build and ensuring the value delivered by the team is optimized. The Developers are focused on building the product or solution right -- ultimately responsible for creating a working increment at the end of each Sprint (or "Doing" cycle). The Scrum Master is focused on building the product or solution efficiently and effectively by knocking down impediments and coaching the team and organization on the processes. Having role clarity helps a team to self-organize and, in Scrum's case, establishes boundaries of accountability. All teams can benefit from role clarity, whether it's adopting Scrum's role definitions or not. In the latest version of Essential Kanban Condensed by David Anderson, there are two roles -- a Service Request Manager, who does similar duties as the Product Owner, and a Service Delivery Manager, who performs duties similar to a Scrum Master and a Delivery Lead combined.
Customer and Stakeholder Engagement. Throughout the Scrum Framework, customer and stakeholder involvement is paramount to success. Without it, the feedback loop will be confined to delivery touch points, which leads to rework and frustration. Finding ways to ensure the customers and stakeholders are connected to the work as it progresses will reduce risks during the creation and increase the value gained.