Book Notes #31: Kanban and Scrum, Making the Most of Both by Mattias Skarin and Henrik Kniberg

Title: Kanban and Scrum, Making the Most of Both
Author: Mattias Skarin and Henrik Kniberg
Year: 2010
Pages: 120

You’ve probably heard of Scrum and Kanban if you’re interested in agile software development.

If you’ve ever led a team, worked in tech, or found yourself drowning in sticky notes and to-do lists, Kanban and Scrum: Making the Most of Both by Henrik Kniberg and Mattias Skarin is a gem.

It doesn’t try to sell you on one “correct” way of working—it helps you understand two of the most popular frameworks in agile and shows how to blend them smartly.

This isn’t a dense, academic read. It’s visual, practical, and based on real experience from teams who’ve actually used these ideas to get better at what they do.

Whether you’re new to agile or deep in the trenches, this book feels like a conversation with a seasoned coach who’s seen it all and still believes in simple, thoughtful improvements.

As a result, I gave this book a rating of 8.5/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, are How to Win Friends and Influence People and Factfulness.

3 Reasons to Read Kanban and Scrum, Making the Most of Both

Book Overview

Have you ever seen two people argue about which is better: Scrum or Kanban? It’s almost like a rivalry between coffee lovers and tea drinkers. Each side claims their method is superior, more efficient, more “agile.” But what if the real magic isn’t in choosing one over the other—but in understanding how they can work together?

That’s the heart of Kanban and Scrum: Making the Most of Both by Henrik Kniberg and Mattias Skarin. This short, illustrated book doesn’t try to crown a winner in the agile arena. Instead, it takes a refreshing approach: what if we stopped treating these two frameworks as competitors and started using them as complementary tools?

Henrik and Mattias do a brilliant job of walking the reader through the basics of both methods without drowning you in jargon. Scrum is introduced as a highly structured, team-based way of working, complete with fixed roles, timeboxed sprints, and regular ceremonies. If you’ve ever felt the comfort of a routine, that’s Scrum. It gives teams a rhythm, a shared understanding of who does what, and a focus on delivering value in small, manageable chunks.

Kanban, on the other hand, is like a whiteboard that’s always alive. It’s about flow. There are no timeboxes, no sprints, no strict roles. Just work moving from “to do” to “done” in a visual and highly flexible way. Kanban encourages teams to limit the number of things they’re working on at once—what’s called WIP (Work In Progress). By doing less, you actually get more done. It’s counterintuitive, but it works.

What’s most fascinating is how the authors show these systems aren’t mutually exclusive. In fact, mixing elements from both can be incredibly powerful. For example, you can run Scrum sprints and still apply WIP limits using Kanban principles. Or you might prefer the continuous flow of Kanban but borrow Scrum’s retrospectives to improve your process. There’s no dogma here—just practical advice shaped by real-world experience.

The book also pulls back the curtain on what happens when teams start applying these ideas. It’s not always pretty. Tasks take longer than expected. Boards get messy. Teams push back against limits. But over time, things start to shift. Teams become more focused. They stop starting and start finishing. Bottlenecks become visible. Conversations get better. People begin to own the process.

One story that stands out is how a team initially struggled to commit to anything in Scrum. Every sprint was a battle with unpredictability. Instead of forcing the process, they leaned into Kanban—mapping their flow, visualizing the real work, and only then reintroducing structure where it helped. It wasn’t about picking the “right” framework. It was about listening to what the team needed and building from there.

That’s the real lesson of the book. It’s not about frameworks, it’s about thinking. It’s about asking better questions: Where is our work getting stuck? Are we trying to do too much at once? Are we actually delivering value, or just staying busy?

Scrum and Kanban aren’t silver bullets. They’re mirrors. They reflect the health of your process and nudge you to improve it. This book reminds us that improvement isn’t about changing everything overnight. It’s about small, consistent adjustments—guided by data, feedback, and trust in the team.

By the end of the book, you’re not left with a prescription. You’re left with permission—to experiment, to combine, to challenge the rules, and to build something that works for your context. That’s what makes Kanban and Scrum: Making the Most of Both such a valuable read. It doesn’t try to convince you of anything. It just opens your eyes to what’s possible when you stop choosing sides and start designing your own way forward.

Some concepts presented in the book are:

Scrum: Scrum is a structured framework for managing work in short, focused cycles called sprints. It prescribes specific roles (Product Owner, Scrum Master, and Development Team), events (such as Sprint Planning, Daily Stand-ups, and Retrospectives), and artifacts (like the Product Backlog and Sprint Backlog). Scrum emphasizes delivering potentially shippable product increments at the end of each sprint and using frequent inspection and adaptation to improve both the product and the team’s way of working.

Kanban: Kanban is a flexible, flow-based method focused on visualizing work and managing it through continuous delivery. Unlike Scrum, Kanban does not prescribe roles, events, or iterations. Instead, it uses a visual board to track work items and emphasizes limiting work in progress (WIP) per stage to improve flow, reduce cycle time, and make the process more predictable. It’s a pull-based system where new tasks are started only when there’s capacity.

Boards (Scrum Board vs. Kanban Board): Both Scrum and Kanban use boards to visualize work, but in different ways. A Scrum board resets every sprint and only shows items selected for that iteration. It’s tied to the sprint backlog and represents a fixed commitment. A Kanban board is continuous and does not reset—it represents the team’s workflow stages and tracks tasks moving through them over time. The Kanban board often includes WIP limits and swimlanes for clarity.

Work In Progress (WIP) Limit: WIP limits restrict the number of work items allowed in a given stage of the process. In Kanban, these limits are explicit and visual, preventing teams from starting too much at once. In Scrum, WIP is implicitly limited by the size of the sprint backlog, as the team can only commit to a certain amount of work per iteration. The main purpose of limiting WIP is to focus attention, reduce context-switching, and improve flow efficiency.

Sprint: A sprint is a timeboxed iteration in Scrum, usually 1–4 weeks long. During a sprint, the team commits to delivering a set of tasks (user stories) from the product backlog. The sprint structure provides a regular cadence for planning, delivery, review, and improvement. It also creates stability by resisting changes to scope during the iteration, helping teams focus and deliver on their commitments.

Product Owner: The Product Owner is a key Scrum role responsible for managing the product backlog, setting priorities, and maximizing the value delivered by the team. They represent stakeholder interests and are the voice of the customer within the team. Their role is critical in deciding what the team works on next.

Scrum Master: The Scrum Master is the facilitator of the Scrum process. They ensure the team follows Scrum principles, help remove obstacles, and coach the team on continuous improvement. They are not a manager but a servant-leader who supports both the team and the organization in adopting agile practices.

Cross-Functional Team: Scrum requires teams to be cross-functional—meaning they have all the skills needed to complete the work without relying on external roles or handoffs. This setup reduces delays and dependencies. Kanban, by contrast, allows for both cross-functional and specialized teams, depending on the context.

Lead Time: Lead time in Kanban is the total time it takes for a work item to move from the moment it is committed (added to the board) to the moment it is completed. It’s a key metric used to measure flow efficiency. Reducing lead time makes delivery more predictable and improves responsiveness.

Cycle Time: Cycle time is a subset of lead time that measures how long a task spends in the “active” part of the workflow—typically from the moment work starts until it’s done. It’s an important indicator of team throughput and is used in Kanban to evaluate the speed of specific workflow stages.

Velocity: Velocity is a Scrum-specific metric that tracks how much work (often measured in story points) a team completes in each sprint. It’s used for forecasting how many backlog items a team can handle in future sprints. While helpful, the book reminds us not to use it as a performance metric, but as a planning tool.

Estimation: Estimation is the practice of sizing work items before starting them. In Scrum, teams often use relative estimation (like story points) to gauge effort and plan sprints. Kanban doesn’t require estimation, but some teams still use it to support forecasting. The emphasis in Kanban is more on actual flow data than predicted effort.

Backlog: The backlog is a prioritized list of work to be done. In Scrum, the Product Backlog is curated by the Product Owner and refined regularly. During each sprint, the team pulls work from the backlog into the Sprint Backlog. In Kanban, backlogs are used more loosely and work is pulled in continuously as capacity allows.

Sprint Planning: Sprint Planning is a Scrum event held at the beginning of each sprint where the team selects items from the product backlog to commit to. The team collaborates with the Product Owner to understand priorities and define the sprint goal. It sets the direction for the upcoming iteration.

Daily Stand-up: Also known as the Daily Scrum, this is a short, daily team meeting in Scrum (and sometimes used in Kanban) where team members sync up, share progress, and surface impediments. It helps maintain alignment and keep the team on track.

Retrospective: A retrospective is a Scrum ceremony held at the end of each sprint, where the team reflects on what went well, what didn’t, and how they can improve in the next sprint. Although not mandatory in Kanban, teams using it often adopt retrospectives as a useful tool for continuous improvement.

Continuous Flow: A concept central to Kanban, continuous flow means that work items move independently through the system as capacity becomes available—without waiting for a timeboxed cycle. This allows teams to be more responsive and avoid artificial batching of work.

Pull System: Kanban operates as a pull system, where new work is only started when the team has the capacity to handle it. This contrasts with push systems, where work is assigned regardless of team capacity. Scrum also has a pull element, as teams pull tasks into a sprint rather than being assigned work externally.

Visualizing Work: A core principle in both Scrum and Kanban is making work visible. Boards help teams and stakeholders see what’s being worked on, what’s blocked, and what’s done. This transparency promotes better communication, quicker problem-solving, and clearer prioritization.

Empirical Process Control: Both Scrum and Kanban are grounded in empiricism. That means making decisions based on observation, experimentation, and feedback—not assumptions or rigid plans. Whether through sprint reviews in Scrum or metrics like lead time in Kanban, both encourage learning and adaptation based on real data.

Improvement Through Constraints: One of the book’s key insights is that constraints (like WIP limits or fixed sprint lengths) aren’t meant to restrict creativity—they’re meant to create focus. By limiting how much work is in progress or when changes can be made, teams are forced to finish what they start and improve how they work.

Chapter by Chapter

Chapter 1 – What is Scrum and Kanban anyway?

The book kicks off with a quick, down-to-earth explanation of what Scrum and Kanban are. It’s not trying to be overly detailed—just enough so you can get a feel for what each one is about.

Scrum, in a nutshell, is about breaking big teams into small, cross-functional groups that work in short, fixed-length timeboxes (called iterations or sprints). These teams pick a handful of high-priority items from a product backlog, estimate how much effort each one will take, and aim to deliver a potentially shippable product at the end of each sprint. After every iteration, they regroup, inspect what worked and what didn’t, and adjust their process. So rather than doing everything at once, they deliver small chunks frequently and learn as they go.

Kanban, on the other hand, is more about visualizing the flow of work. You break your work into pieces, write each item on a card, and track them across columns on a board that shows where each item is in the process. The key idea here is limiting how many items are in progress at any time—this is called limiting Work In Progress (WIP). The goal is to reduce how long it takes to complete things (lead time) and make that time more predictable.

The author doesn’t try to say one is better than the other. Instead, he keeps things neutral and focused on understanding. This chapter is more of a gentle setup, getting you familiar with the basics of both approaches before diving into comparisons. It’s like learning the rules of a game before figuring out which strategy fits best.

Chapter 2 – How do Scrum and Kanban relate to each other?

This chapter dives into the relationship between Scrum and Kanban, shedding light on how the two can complement each other rather than compete. The author starts by clarifying that both are tools, and like any tool, their effectiveness depends on the context in which you use them.

The main idea here is that Scrum is more prescriptive, providing clear rules and structure for how to organize and run teams. Kanban, on the other hand, is much more flexible—focusing on flow and continuous improvement, with fewer constraints. So, they are both process tools but work in different ways to help you get better at managing work.

One fascinating insight the author shares is that while both tools limit work in progress (WIP), they do so in different ways. In Scrum, WIP is indirectly limited because each sprint has a fixed scope. You can’t start more work than what fits into the sprint. But Kanban goes further, explicitly limiting how many items can be in progress at each workflow stage, creating smoother flow.

The author uses a metaphor to help you understand: Think of a fork and a knife. There’s no clear answer to which is better—each serves a different purpose. Similarly, Scrum and Kanban are just tools for different purposes. It’s not about which one is superior, but about using them where they make the most sense. Sometimes, you might even use them together.

The key takeaway from this chapter is that Scrum and Kanban can coexist. You don’t need to choose one over the other. Instead, use both, adapt them to fit your needs, and experiment with them to see which parts work best in your context.

Chapter 3 – Scrum prescribes roles

In this chapter, the author explains how Scrum prescribes specific roles for a team: Product Owner, Scrum Master, and Team. Each role comes with a clear set of responsibilities to ensure the team functions effectively.

The Product Owner is responsible for setting the product vision and priorities. They manage the product backlog, ensuring that the team works on the highest-value items first. The Scrum Master serves as the process guardian, helping the team stay true to Scrum principles, remove impediments, and ensure smooth collaboration. The Team is made up of self-organizing members who collaborate to get the work done.

The key idea here is that these roles are defined with a purpose. Scrum relies on these roles to keep the team organized and focused on delivering value. Unlike Kanban, which doesn’t prescribe specific roles, Scrum uses these positions to maintain structure and clarity in how the team operates.

Chapter 4 – Scrum prescribes timeboxed iterations

This chapter focuses on one of the defining characteristics of Scrum—timeboxed iterations (sprints). The main idea is that Scrum organizes work into fixed-length iterations, usually lasting 1 to 4 weeks.

Each sprint has a clear beginning and end, and during that time, the team works on a set of tasks from the product backlog. The goal is to deliver a potentially shippable product increment by the end of the sprint. The timeboxing creates a predictable rhythm, where teams plan, execute, review, and improve their processes in a short, regular cycle.

One interesting point the author makes is that the timeboxed nature of Scrum helps keep teams focused. They know exactly what to expect and when, which helps in managing expectations and avoiding overcommitment. By the end of each sprint, the team reflects on what worked well and what didn’t during a retrospective, which encourages continuous improvement.

Chapter 5 – Kanban limits WIP per workflow state, Scrum limits WIP per iteration

Here, the author compares how Scrum and Kanban limit Work In Progress (WIP), a key feature in both methods.

In Scrum, WIP is limited by the sprint backlog. Each sprint has a fixed set of tasks, so the work for the iteration is already defined at the start. The team can’t pull in new work until the sprint is completed, indirectly limiting WIP.

Kanban, on the other hand, limits WIP per workflow state. For example, in the “Ongoing” column, you might set a limit of two tasks, meaning no more than two items can be worked on simultaneously in that stage. This direct limitation helps create a smoother flow by preventing bottlenecks and ensuring that teams don’t overload themselves with too many tasks at once.

The author explains that these differences shape the way teams approach work. Scrum controls WIP through timeboxes, while Kanban does so through continuous flow. Both methods help teams avoid overburdening themselves, but the approach is different.

Chapter 6 – Both are empirical

This chapter highlights the empirical nature of both Scrum and Kanban. Both frameworks emphasize experimenting and adapting based on feedback. The key takeaway here is that neither Scrum nor Kanban provides a one-size-fits-all solution. Instead, both encourage teams to continuously assess their processes and tweak them as needed.

The author draws attention to the concept of feedback loops in both methods. In Scrum, feedback comes after each sprint, allowing teams to inspect their progress and adjust their approach in the next iteration. In Kanban, feedback is real-time, based on metrics like lead time and WIP limits. Teams can adjust on the fly, allowing them to react quickly to changing conditions.

The author emphasizes that this empirical approach—experimenting, observing, and adjusting—is at the core of both frameworks. It’s not about following a rigid set of rules; it’s about finding what works best for your team through constant experimentation.

Chapter 7 – Scrum resists change within an iteration

The author explains that Scrum is designed to resist change within a sprint. Once a sprint begins, the team is expected to stay focused on the work they committed to, without adding new tasks or changing priorities. If a new, urgent request comes in during the sprint, it is usually deferred to the next sprint.

This rule ensures that teams can complete their work within the defined iteration, without disruptions. While this can be frustrating at times, especially in fast-moving environments, the idea is to provide stability and a clear focus for the team during each sprint.

In contrast, Kanban allows for changes to be made as soon as capacity becomes available. When something new comes in, it can be added to the board immediately, as long as the WIP limits are respected. This flexibility is one of the key differences between the two approaches.

Chapter 8 – Scrum board is reset between each iteration

The author compares how Scrum and Kanban boards work. In Scrum, the board is reset at the beginning of each sprint. All tasks from the previous sprint are cleared, and the board is filled with new tasks that the team will focus on during the current iteration.

This reset creates a clean slate and a sense of closure, allowing teams to reflect on what they accomplished before starting fresh. The reset is part of Scrum’s timeboxed nature, reinforcing the cycle of planning, executing, reviewing, and improving.

In Kanban, the board is persistent, meaning it’s always in use. Tasks are added or moved as work progresses, without the need to reset the board at regular intervals. This provides a continuous flow of work, with a focus on optimizing the process over time.

Chapter 9 – Scrum prescribes cross-functional teams

In this chapter, the author explains that Scrum prescribes the use of cross-functional teams, meaning each team should have all the necessary skills to complete the work within the sprint. These teams are self-organizing and collaborate closely, with no reliance on external resources or specialized teams to finish tasks.

The idea is that having a cross-functional team helps eliminate bottlenecks and delays because the team can handle every aspect of the task from start to finish. This structure is designed to maximize efficiency and agility, as the team members work together without waiting for input from outside departments.

In Kanban, cross-functional teams are optional. You can have specialized teams that focus on specific parts of the process. For example, one team might focus on development, while another handles testing. Kanban allows teams to set up their workflow however it makes the most sense for their specific situation.

Chapter 10 – Scrum backlog items must fit in a sprint

This chapter focuses on how Scrum requires that each backlog item be small enough to fit within the duration of a sprint. If an item is too large, it must be broken down into smaller, more manageable pieces before the team commits to it in a sprint. This helps ensure that the team can finish the item within the sprint timeframe, providing clear and achievable goals for each iteration.

In Kanban, there is no explicit rule about item size. The items can vary in size, and Kanban teams focus on maintaining a steady flow of work rather than strictly fitting items into a set time period. This gives Kanban teams more flexibility, but it also requires good tracking to avoid long tasks from causing delays in the overall process.

The main takeaway here is that Scrum forces teams to make items smaller and more manageable, while Kanban allows teams to work with items of varying sizes and manage them based on workflow constraints.

Chapter 11 – Scrum prescribes estimation and velocity

In Scrum, teams are expected to estimate the effort required for each backlog item, which is then used to calculate velocity. Velocity measures how much work a team can complete in a sprint, based on past performance. This allows teams to make predictions about how much work they can commit to in future sprints.

The author points out that this emphasis on estimation and velocity is part of Scrum’s structured approach to managing work. It helps teams stay on track, make realistic commitments, and measure progress.

In Kanban, there is no prescribed estimation process. Some Kanban teams may estimate work, but it’s not a requirement. Instead, Kanban focuses on tracking lead time—the time it takes for an item to move through the entire process. This allows teams to focus more on the flow of work and less on detailed predictions about effort.

One of the key insights here is that Scrum is more focused on planning and forecasting, while Kanban emphasizes real-time tracking and process optimization.

Chapter 12 – Both allow working on multiple products simultaneously

This chapter explains that both Scrum and Kanban can handle multiple products or projects at the same time, though they approach it differently. In Scrum, teams usually work on one product per sprint, but in environments where multiple products are involved, teams may merge different product backlogs into a single backlog and prioritize items across products. This helps manage resources and ensure that the team focuses on the most critical tasks for each product.

Kanban, on the other hand, naturally supports working on multiple products at once because the board can represent multiple workflows, each for a different product. Tasks from different products can be managed on the same board, and teams can use visual cues like swimlanes or colored cards to differentiate between them. This makes it easy for teams to see progress across multiple products at a glance.

Chapter 13 – Both are Lean and Agile

The author emphasizes that both Scrum and Kanban are rooted in Lean and Agile principles. Agile focuses on flexibility, customer collaboration, and delivering value in incremental steps, while Lean is about minimizing waste and continuously improving processes. Both frameworks aim to deliver value quickly and efficiently while staying adaptable to change.

The key commonality is that both Scrum and Kanban are designed to help teams become more efficient, improve flow, and continuously refine their processes based on feedback. Scrum achieves this through iterative cycles and fixed roles, while Kanban uses visual management and flow control to keep work moving smoothly.

Chapter 14 – Minor differences

This chapter touches on a few minor differences between Scrum and Kanban that may not be as central but still worth noting.

One difference is that Scrum prescribes a prioritized product backlog, whereas in Kanban, prioritization is optional and may be handled in various ways. Kanban also does not prescribe daily standups or burndown charts, which are typical in Scrum. Additionally, Scrum teams usually reset their boards at the start of each sprint, while Kanban boards are persistent and evolve over time.

While these differences are small, they are important when deciding which approach to use. The author encourages you to experiment with both frameworks and adapt them to your team’s needs.

Chapter 15 – Scrum board vs Kanban board – a less trivial example

In this chapter, the author contrasts how the Scrum board and Kanban board operate, highlighting the practical differences between them.

A Scrum board is typically reset at the beginning of each sprint. It’s used to track the tasks that the team commits to completing within that sprint. The board often has columns like To Do, In Progress, and Done, and it’s focused on visualizing the sprint’s work. The key point is that each task or story on the board is directly tied to a specific sprint.

On the other hand, the Kanban board is persistent. The board isn’t reset—it keeps evolving as tasks flow through the process. It’s more focused on managing the flow of work over time, with columns representing stages in the workflow, such as To Do, In Progress, and Done. Tasks can stay on the board for as long as necessary, and new work can be added continuously as long as it respects the WIP limits.

A fascinating part of this chapter is how the author demonstrates that while the boards may look similar at a glance, the Scrum board is typically for short-term, timeboxed work, and the Kanban board supports a more fluid, continuous flow of tasks.

Chapter 16 – Summary of Scrum vs Kanban

Here, the author offers a quick recap of the major differences between Scrum and Kanban. They are both methods designed to help teams organize and manage work more effectively, but they approach this goal in different ways.

Scrum is prescriptive, offering clear rules, defined roles, and timeboxed iterations. It’s built around the idea of delivering work in short bursts, learning from each iteration, and improving the process along the way. Scrum has a strong focus on roles (like the Scrum Master and Product Owner) and ceremonies (like sprint planning and retrospectives).

Kanban, in contrast, is more flexible. It doesn’t define roles or prescribe timeboxes. Instead, it focuses on improving the flow of work by limiting WIP (Work in Progress), visualizing the process, and ensuring a steady stream of tasks through each stage of the workflow. Kanban is less about structure and more about continual flow and improvement.

The author suggests that neither method is inherently superior—it all depends on the context and what the team needs. Some teams might find Scrum’s structure and timeboxes more helpful, while others may prefer Kanban’s flexibility.

Chapter 17 – The nature of technical operations

This chapter explores how technical operations are impacted by Scrum and Kanban. The author explains that both methods can work in technical environments, but each has its strengths depending on the nature of the work.

For example, in technical operations, tasks often have different levels of complexity. Scrum can be helpful in these situations because its timeboxed iterations help provide structure. Teams know they need to finish a certain amount of work within each sprint, which can drive focus and discipline.

On the other hand, Kanban can work well when tasks are highly variable and need flexibility. Since Kanban doesn’t have timeboxes, it allows teams to handle work that requires more time or ongoing adjustment, like operations or support tickets, without being confined to a set sprint schedule.

The key insight is that the choice between Scrum and Kanban depends on the type of work and how much flexibility or structure is needed. Both methods can be adapted to work for technical operations, but understanding the specific demands of your tasks will help guide the decision.

Chapter 18 – Why on earth change?

The author addresses the question of why organizations should consider adopting Scrum or Kanban in the first place. The core argument is that traditional management practices often don’t support modern, flexible work environments. Teams today face a range of challenges—complexity, uncertainty, and the need for fast delivery—things that traditional project management techniques can’t always handle effectively.

Scrum and Kanban are solutions to these challenges. Both methods bring the benefits of continuous improvement, adaptability, and focus on value delivery. The author argues that adopting these frameworks is a response to a rapidly changing business environment, where teams need to be able to respond to customer needs and market changes quickly.

It’s a call to action for teams to embrace change, experiment with new approaches, and not be afraid to leave behind old ways of working if they’re no longer effective. The chapter stresses that change is necessary for growth, and Scrum and Kanban are tools that support continuous evolution.

Chapter 19 – Where do we start?

This chapter gives practical advice on where to start when introducing Scrum or Kanban into an organization. The author suggests that the first step is to understand the current processes and workflows. This will help you identify areas where improvement is needed and figure out which method—Scrum or Kanban—might be the best fit.

The author emphasizes that starting small is key. Don’t try to overhaul everything at once. Instead, experiment with a small team or project and learn from the experience. This approach will allow you to gather insights and adjust the process before rolling it out to a larger team or the whole organization.

One helpful tip is to involve everyone in the process, as both Scrum and Kanban work best when teams are actively engaged in decision-making and improvement.

Chapter 20 – Getting going

Once you’ve decided where to start, the next step is getting going. The author suggests beginning with simple steps: pick a team, explain the basics of Scrum or Kanban, and set up a board (physical or digital). For Scrum, this means creating a backlog and planning your first sprint. For Kanban, it’s about visualizing your workflow and setting WIP limits.

The goal in this chapter is to make sure that the initial setup doesn’t overwhelm the team. Start with the basics, and as you gain confidence and experience, you can refine and expand the approach.

Chapter 21 – Starting up the teams

This chapter focuses on setting up teams for success when implementing Scrum or Kanban. The author highlights that the way teams are structured and introduced to these frameworks can significantly impact their effectiveness.

For Scrum, it’s essential to make sure that team members understand their roles from the start. Each team needs to know what’s expected of them, whether they are the Product Owner, the Scrum Master, or part of the Development Team. Clear communication and alignment are vital in creating a collaborative and efficient environment.

When setting up teams for Kanban, the emphasis is on ensuring that the team understands the concept of flow and the importance of limiting work in progress (WIP). The team should also be trained to visualize their work on the board and continuously improve their processes. The key to success with Kanban is fostering a mindset of continuous improvement and optimization of the flow, rather than focusing solely on achieving sprint goals.

The chapter emphasizes that whether you’re working with Scrum or Kanban, getting the team to buy into the process and understand the purpose behind it is crucial for long-term success.

Chapter 22 – Addressing stakeholders

This chapter shifts focus to the importance of managing stakeholders when implementing Scrum or Kanban. The author explains that stakeholders play a vital role in both frameworks, but they need to be informed and aligned with the process.

In Scrum, the Product Owner is the primary liaison between the team and the stakeholders. They are responsible for managing stakeholder expectations, ensuring that the team works on the right priorities, and keeping stakeholders updated on progress. Regular Sprint Reviews allow stakeholders to see what has been completed and provide feedback, ensuring that the team is building what the stakeholders truly need.

For Kanban, stakeholder involvement is a bit more flexible. Since Kanban focuses on continuous flow and doesn’t have specific timeboxed iterations like Scrum, the stakeholder relationship is managed through regular check-ins and clear visibility of the workflow on the Kanban board. This helps stakeholders see where work is in progress and where there might be delays, leading to more proactive decision-making.

The key takeaway is that both frameworks require active stakeholder management, but the approach differs. In Scrum, this happens within defined sprints, while in Kanban, the relationship is more dynamic and ongoing.

Chapter 23 – Constructing the first board

The author walks through how to construct the first board, whether you are implementing Scrum or Kanban. For both frameworks, the board is a crucial tool for visualizing work, tracking progress, and ensuring the team is focused on the right tasks.

In Scrum, the board is usually simple, with columns like To Do, In Progress, and Done, and each item on the board is linked to a backlog item for the sprint. The board helps the team track the progress of tasks during the sprint, providing a clear view of what’s left to be done.

For Kanban, the board can be a bit more complex, depending on the workflow. You’ll need to define the stages of the process and create columns to represent each stage, like To Do, In Progress, Testing, and Done. Additionally, you’ll need to set WIP limits for each stage to ensure that the team isn’t overwhelmed with too many tasks at once.

The chapter provides detailed guidance on setting up the board in a way that supports visual management and promotes smooth flow. It emphasizes that the board should evolve over time, as you refine your process and learn more about how your team works.

Chapter 24 – Setting the first Work In Progress (WIP) limit

This chapter introduces the idea of Work In Progress (WIP) limits and explains how to set them up, especially for teams using Kanban. WIP limits are crucial for preventing overburdening the team and ensuring that work flows smoothly from one stage to the next.

In Kanban, WIP limits are explicitly defined for each column on the board (e.g., no more than three tasks in the “In Progress” column). This creates a flow control system where the team can only focus on a limited number of tasks at a time, helping to prevent bottlenecks and inefficiencies. The chapter emphasizes that setting WIP limits requires an understanding of your team’s capacity and workflow, so it’s important to start with a manageable number and adjust over time.

For Scrum, while there isn’t a formal WIP limit in the same sense as Kanban, the sprint backlog itself acts as a de facto limit. The team can only work on the tasks that fit within the sprint’s capacity. However, the idea of WIP limits can still be useful for Scrum teams to help them focus on completing work rather than starting too many things at once.

The chapter stresses that WIP limits are not meant to restrict work but to create more focus and improve the flow of tasks. They help teams avoid the trap of starting many tasks without completing them.

Chapter 25 – Honoring the Work In Progress (WIP) limit

This chapter builds on the idea of WIP limits and focuses on the importance of honoring them. Once WIP limits are set, the team must stick to them. If a stage on the board reaches its WIP limit, no new tasks can be started in that stage until a task moves to the next column.

The author explains that this discipline encourages focus and completion. When teams respect WIP limits, they avoid multitasking, which often leads to reduced productivity and quality. Instead, teams are encouraged to finish what they started before moving on to new tasks. This creates a smoother flow of work and ensures that items are completed before more are added to the queue.

By sticking to WIP limits, teams can improve their cycle time (how long it takes for an item to go from start to finish) and ensure a steady, predictable flow of work. The chapter emphasizes that this approach helps avoid bottlenecks and increases overall team efficiency.

Chapter 26 – Which tasks get on the board?

In this chapter, the author explores the question of which tasks should go on the board, whether you’re working with Scrum or Kanban. The key focus is on ensuring that the work selected is valuable and manageable, and that the team is aligned on priorities.

In Scrum, tasks are selected from the product backlog during sprint planning. The Product Owner typically prioritizes the backlog, and the team pulls items into the sprint based on capacity. The challenge is ensuring that the tasks selected for the sprint are appropriately sized and deliverable within the timebox.

For Kanban, tasks are selected based on the work that needs to flow through the system. Unlike Scrum, there is no set sprint. Instead, tasks are pulled from the backlog as capacity allows, respecting the WIP limits to avoid overloading any one stage of the process. The important thing in Kanban is that tasks are clearly defined and prioritized, and that the team understands what needs to be done at each stage of the workflow.

The author emphasizes that regardless of the method, it’s essential to have clear criteria for what makes a task “ready” to be pulled into the workflow. Tasks should be well-defined, small enough to complete within the time constraints, and aligned with the team’s goals.

Chapter 27 – How to estimate?

This chapter is dedicated to the process of estimating work, a critical part of Scrum and an optional practice in Kanban. The author explains that estimating is a tool for helping teams plan and understand how much work can be accomplished in a sprint or over a given time period.

In Scrum, estimation is typically done using methods like story points or ideal hours, where the team assigns relative effort estimates to backlog items. These estimates help the team understand how much work can fit into a sprint, and they are used to calculate the team’s velocity (how much work the team can complete per sprint). The challenge, however, is that estimates are not always accurate. The author points out that estimation is just a tool to help guide decision-making, but it’s important not to be overly attached to the numbers.

In Kanban, estimation is less emphasized. Since Kanban is about continuous flow, the focus is more on tracking lead time (the time it takes for a task to move from start to finish) rather than predicting how much work will be done. However, some Kanban teams might still choose to estimate work to get a sense of effort or complexity, especially when managing more unpredictable or complex tasks.

The takeaway here is that estimation is useful but imperfect. Whether using Scrum or Kanban, the goal is not to get perfect estimates but to use them as a guide and learn from the data over time.

Chapter 28 – So how did we work, really?

This chapter provides a reflection on how teams typically end up working in practice, beyond the theory of Scrum and Kanban. The author shares insights based on real-world experience, showing that the process of working within Scrum or Kanban is often messier than it looks in textbooks.

In Scrum, teams can struggle with sticking to the strict rules of timeboxes and sprint commitments. The pressure to deliver by the end of each sprint can sometimes lead to rushing or cutting corners. However, the framework does offer opportunities for teams to reflect and adjust their practices at the end of each sprint, which helps drive continuous improvement.

In Kanban, the flexibility of the flow can be both a strength and a challenge. While it allows teams to adapt quickly to changing priorities, it can also lead to lack of focus or overwhelming workloads if the WIP limits aren’t properly respected. Without clear timeboxes or strict iterations, teams may find themselves working on tasks for too long or constantly juggling multiple things.

The author emphasizes that both frameworks are designed to improve work, but real-world application requires constant tweaking. Teams must actively manage their processes and adjust practices as they learn more about what works and what doesn’t.

Chapter 29 – Finding a planning concept that worked

In this chapter, the author focuses on finding a planning concept that aligns with the realities of the team and the work. While Scrum requires structured sprint planning, the author suggests that finding a planning approach that works for the team is crucial for success.

The key message is that planning in Scrum shouldn’t be about creating rigid plans that can’t adapt to change. Instead, teams should focus on planning just enough to get started and leave room for adjustments during the sprint. Kanban, meanwhile, doesn’t prescribe any formal planning sessions, but it’s still important for the team to have a shared understanding of the work in the system and what needs to be prioritized.

The author suggests adopting a planning mindset that balances the need for structure with flexibility. The right approach depends on the team’s context, the nature of the work, and the challenges they face. Flexibility is key in both methods, even though Scrum is often perceived as more rigid.

Chapter 30 – What to measure?

Here, the author dives into the idea of measuring performance and the metrics that are most useful for improving processes in Scrum and Kanban.

In Scrum, key metrics include velocity, sprint burndown charts, and release burnup charts. These metrics help teams measure how much work they’re completing in each sprint and whether they’re on track to meet their long-term goals. However, the author cautions that while these metrics are helpful, they shouldn’t be used in isolation. Teams should focus on delivering value, not just hitting velocity targets.

In Kanban, metrics are centered around lead time, cycle time, and throughput. These metrics help teams understand how long it takes for work to flow through the system, identify bottlenecks, and optimize the process. The author notes that Kanban teams should focus on optimizing the flow and removing any delays in the system.

The key takeaway here is that the right metrics depend on the team’s goals. Whether you’re in Scrum or Kanban, the aim is to focus on value delivery and continuously improve the process, using metrics as a tool to guide decisions.

Chapter 31 – How things started to change

In this chapter, the author explores how the implementation of Scrum and Kanban begins to drive real changes within teams and organizations. The process of adopting these frameworks leads to cultural shifts, new ways of thinking, and a fresh approach to work management.

With Scrum, teams often experience a sense of accountability and ownership of their work. The regular sprint cycles force the team to focus on delivering small chunks of value in each iteration, making it easier to track progress and learn from mistakes. Over time, teams become better at estimating their work, managing their time, and improving their processes during retrospectives.

For Kanban, the main change is in how teams view and manage their workflow. By visualizing tasks and setting WIP limits, teams start to realize where bottlenecks occur and work to smooth out the process. The constant flow and emphasis on managing cycle time help teams become more responsive and adaptable to changing demands.

The author points out that change isn’t always easy. In both frameworks, teams can encounter resistance or frustration as they adapt to the new ways of working. However, the chapter emphasizes that the changes ultimately result in improved productivity, more engaged teams, and better value delivery.

Chapter 32 – General lessons learned

This chapter wraps up the journey with some general lessons learned from the experience of using Scrum and Kanban in practice. The author reflects on the key takeaways that can help teams succeed with these frameworks.

The first lesson is that Scrum and Kanban are not one-size-fits-all solutions. What works for one team might not work for another. Teams should be open to experimentation and adapt the frameworks to fit their specific context.

Another critical lesson is the importance of visualizing work. Whether through the Scrum board or Kanban board, seeing the flow of tasks helps the team stay aligned, identify bottlenecks, and make adjustments quickly. The visual aspect makes it easier to track progress and understand the status of work at any given time.

The author also emphasizes the importance of continuous improvement. Both Scrum and Kanban encourage teams to inspect and adapt regularly, which fosters a culture of growth. Teams that take the time to reflect, learn, and iterate on their processes are more likely to improve and become more efficient over time.

Finally, the author notes that communication and collaboration are key to the success of both frameworks. Whether you’re working in a Scrum team with defined roles or in a Kanban flow with flexible roles, fostering strong collaboration ensures that everyone is on the same page and working toward common goals.

In conclusion, the chapter stresses that while Scrum and Kanban are powerful tools, their true success lies in how teams embrace the principles behind them—flexibility, collaboration, and continuous improvement.

4 Key Ideas from Kanban and Scrum, Making the Most of Both

6 Main Lessons from Kanban and Scrum, Making the Most of Both

My Book Highlights & Quotes

Scrum and Kanban are process tools in that they help you work more effectively by, to a certain extent, telling you what to do. Java is also a tool, it gives you a simpler way to program a computer. A toothbrush is also a tool, it helps you reach your teeth so you can clean them

Knife or fork – which tool is better? Pretty meaningless question right? Because the answer depends on your context. For eating meatballs the fork is probably best. For chopping mushrooms the knife is probably best. For drumming on the table either will do fine. For eating a steak you probably want to use both tools together. For eating rice… well… some prefer a fork while others prefer chopsticks. So when we compare tools we should be careful. Compare for understanding, not for judgment

Conclusion

In the end, this book isn’t about choosing the “right” way to work—it’s about learning to think about work differently. It encourages you to step back, see how your team functions, and try smarter ways of getting things done.

Whether you’re managing projects, building products, or just trying to bring more sanity into your daily workflow, Kanban and Scrum: Making the Most of Both is a practical, no-nonsense guide to working with more clarity, flow, and purpose. And that’s something every team—agile or not—can benefit from.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

• Book Notes
• Career Development
• Essays
• Explaining
• Leadership
• Lean and Agile
• Management
• Personal Development
• Project Management
• Reading Insights
• Technology

Navigate between the many topics covered in this website:

Agile Agile Coaching Agile Transformation Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

• Book Notes #127: The Laws of Simplicity by John Maeda2025-04-04
• Book Notes #126: Inevitable by Mike Colias2025-03-24
• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: