A Scrum primer for Kanban teams

July 12, 2017

All you need to know to improve your Kanban using Scrum

Continuing to Build Bridges

Continuing our series about the bridge connecting the Scrum and Kanban world, today Yuval Yeret is joining us again. As a reminder, Yuval is known as “Mr Kanban Israel” for his work helping establish a strong Kanban community with several enterprise product developments in the “Startup Nation.” Today, he leads the Scaled Agile practice and North America consulting services at AgileSparks, a global Agile consulting firm. Yuval and AgileSparks have been bridging Scrum and Kanban in the trenches for several years.

Yuval Yeret

The view from the Kanban side of the bridge

Picture yourself on the Kanban side of the shore looking at the Scrum world across the bay. What is actually going on there on the other side and how can you take advantage of some of it to improve your world? What is more or less the same, but just spoken in different terms/language? And, are there real unbridgeable differences?

As you review the list of Scrum practices, you will probably recognize areas of alignment, practices that are complementary, and practices that feel unnatural in a Kanban context:

Areas of Alignment - Some Scrum aspects align fairly closely with Kanban principles, even if they are slightly different in the way they are practiced.
Complementary - Some Scrum aspects are complementary to a Kanban environment. Some of you are already using many of those aspects because they are a natural fit and have become part of de-facto Kanban practice.
Unnatural Aspects - A few Scrum principles/practices may not feel natural to Kanban practitioners.

Definition of Scrum

Let’s start with a high-level definition of Scrum before we dive into the specifics of how to apply it on top of your Kanban. The Scrum Guide defines Scrum as a framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value. I highly recommend reading the entire Scrum Guide whether you intend to implement Scrum or not.

Values

Successful use of Scrum depends on people becoming proficient in living according to these five values:

Commitment
Courage
Focus
Openness
Respect

These values build a foundation of trust, which is required to bring the Scrum pillars of transparency, inspection, and adaptation to life. The Scrum values are beneficial to have in most contexts, including when practicing Kanban. Let’s take a concrete, grounded look at following Scrum values in the context of using Kanban.

Scrum Aspect	Short Description	How to apply to Kanban
Commitment	People personally commit to doing their best to achieve the goals of the Scrum Team.	Be committed to using Kanban to improve your performance towards delivering a continuous flow of value in a way that is sustainable.
Courage	The Scrum Team members have the courage to do the right thing and work on tough problems.	You might say Kanban isn’t about courage because it is evolutionary and doesn’t require many changes. However, if you have tried Limiting Work In Process, collaborating across the value stream, or moving from utilization thinking to flow thinking, you will agree that courage is crucial for succeeding with Kanban.
Focus	Everyone focuses on the work of the Sprint and the goals of the Scrum Team.	Having focus is natural to Kanban practitioners. Limiting Work In Process is all about the whole group working on the value stream by focusing on a few things instead of spreading the group too thinly. Another connection is that Kanban helps you to focus on the important constraints, bottlenecks, and other flow problems.
Openness	As we work together, we agree to be open about the work and the challenges with performing the work.	Being open with others within the same value stream about where things are, what we need, and our ideas for improvement is crucial if we genuinely want Kanban to improve how we’re doing. Otherwise, it is just a fancy visualization system. In fact, if we're not open, Kanban won't even be useful as just that. Using Kanban, we are also open to many options for how to do things and the improvement models to use.
Respect	Scrum Team members respect each other as capable, independent people.	People working in a Kanban system should see themselves as a community of people respecting each other as capable and independent. Kanban also reflects the value of respect for our humanness by seeking a sustainable, healthy flow, by recognizing the perspective of others, and by looking for ways to continuously find better, fitter ways of doing things.

See more at: http://www.scrumguides.org/scrum-guide.html#values and https://guntherverheyen.com/2013/05/03/theres-value-in-the-scrum-values/

As a Kanban practitioner reviewing these values, I invite you to consider whether they resonate? Do you need to strengthen these values in your Kanban community/system? And if so, do you feel that Kanban on its own is enough to support these values or would it help to add Scrum to your practices.

Accountabilities

Every self-respecting agilist knows the accountabilities central to Scrum---the Scrum Team, Developers, Product Owner, and the Scrum Master. Are those accountabilities useful for Kanban practitioners? Let’s examine that question, accountability by accountability.

Scrum Aspect	Short Description (According to the Scrum Guide)	How to apply to Kanban
Scrum Team	The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.	Self-organization is visible in Kanban in a couple of ways. Work in Kanban is pulled rather than pushed. A group of people using Kanban agree on explicit policies that enable members to make decentralized, self-organized decisions around the work. They also self-organize to improve collaboratively rather than having somebody “manage the improvement” for them. Each person/team working in a Kanban system is held accountable for contributing to great flow and high-quality value delivery not just in their area of the Kanban but from a whole value stream perspective. Kanban doesn’t prescribe restructuring to cross-functional teams spanning the value stream. Having said that, many organizations implementing Kanban realize that creating an autonomous cross-functional team is better for work/value flow. Most organizations lean towards creating a set of smaller, simpler, and relatively autonomous Kanban systems rather than a large Kanban network spanning multiple traditional component/subsystem teams
Developers	Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. Developers select items from the Product Backlog to include in the current Sprint. Developers plan the work necessary to create an Increment that meets the Definition of Done	It is useful to clarify in Kanban who are the people actually pulling work in the Kanban system and empowering them to figure out when/how to pull the work and accomplish it. Using the “Developers” role can provide clarity and ensure Pull vs Push
Product Owner	A sole individual who is accountable for maximizing the value delivered by the increment. They do this by managing the Product Backlog. Product Backlog management includes many activities that the Product Owner may delegate to the Development Team, but the Product Owner remains accountable.	Are you seeing any of these symptoms? Struggling to shape the demands/needs of multiple stakeholders Feeling the team is stuck in analysis paralysis trying to figure out what to pull next An inability to say “No” or “Not now” to a certain idea A lack of accountability and product direction If so, you should seriously consider assigning a Product Owner.
Scrum Master	The individual responsible for making sure the Scrum Team understands and enacts the Scrum framework. The Scrum Master also works to remove any impediments the Developers may encounter.	From a Kanban perspective, identifying a “process coach” for the team is a useful practice whether you call that person a Scrum Master, Kanban Flow Manager, or Agile Coach. In Lean, managers are expected to be process leaders. Although not prescribed in Kanban, many managers/leaders take on the “process leader” role. Scrum is officially neutral on the role managers should take.

Events

The Sprint includes the following events: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. These events are examples of cadence and feedback loops, which are key Kanban practices that many “shallow” Kanban practitioners diminish.

Let’s look at Scrum’s events in more depth:

Scrum Aspect	Short Description (According to the Scrum Guide)	How to apply to Kanban
Sprint	Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint. All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.	Kanban recommends most teams carry out planning/replenishment, delivery, and process retrospectives on a cadence. This cadence isn’t mandatory and it is possible to carry out these activities “on demand." However, most teams simply do better on a cadence. The Sprint is a specific sort of cadence where the aim is to have a cross-functional team work together to complete the forecasted work. They focus on completing the work before taking on new work that will put the team’s goal at risk---in essence, "cleaning the table" at the end of each Sprint. This encourages collaboration but can feel unnatural and wasteful to Kanban teams, especially if they already get the collaboration and swarming effects through their focus on flow and continuously working under a WIP limit.
Sprint Planning	Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. Sprint Planning addresses the following topics: Why is this Sprint valuable? What can be Done this Sprint? How will the chosen work get done?	Kanban teams that have already established an effective flow of work should carefully consider how Scrum Sprint Planning might be of benefit. Typically, Kanban teams don’t invest much in estimating, preferring to break work down just in time. Therefore these teams would focus on Why the Sprint is valuable and What can be Done, and evolve the “How” throughout the Sprint. One of the key benefits of Sprint Planning is that it identifies a reasonable amount of work thus avoiding spreading ourselves too thinly. In other words, it is a form of limiting WIP. Good Kanban teams limit WIP already albeit in a different way. The other benefit a team gets from holding a Sprint Planning event is to come together as a team to craft a Sprint Goal. See below.
Daily Scrum	The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.	Good Kanban teams have a daily planning meeting in front of the Kanban board as their first-level feedback loop. Scrum and Kanban aren’t that different in the high-level goal/purpose of this meeting. When it comes to running the meeting, there may be some differences. Kanban teams typically focus on the flow of work instead of the people doing the work. They work the board right to left focusing on flow problems. One Daily Scrum aspect that the Scrum Guide emphasizes is the focus on the Sprint Goal to make sure that tactical decisions are best aligned with the overall mission. Kanban teams would benefit from this higher-level focus beyond the immediate flow of specific work.
Sprint Review	The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.	The Sprint Review is essentially an example of a feedback loop. Kanban teams could potentially just do this on demand whenever some deliverable is ready for review. However, experience shows that having a cadence typically makes it easier to get the right stakeholders in the room and is overall more efficient and effective.
Sprint Retrospective	The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.	Most Kanban teams run retrospectives as well. Again, some teams do them on demand, but most teams would benefit from the discipline, simplicity and predictability of having them on a cadence.

Artifacts

And finally, How do Scrum’s artifacts apply in a Kanban environment?

Scrum Aspect	Short Description (According to the Scrum Guide)	How to apply to Kanban
Product Backlog	The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.	The different queues Kanban teams maintain to the left of their boards can be seen as a visualization of a Product Backlog. Kanban teams limit the Product Backlog size and depth. Having a limited Product Backlog shouldn’t mean maintaining another backlog of the backlog items that don’t fit the Product Backlog. It means actively ensuring the Product Backlog is relevant and actionable and not a complete list of everything ever asked for.
Product Backlog refinement	Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.	Kanban teams decide how to refine the backlog. They may do this just in time when the inventory of ready stories goes below a threshold, or they can use a cadence.
Commitment: Product Goal	The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.	Kanban can help teams achieve good flow. This flow is useless if not directed towards the right goal. The Scrum Product Goal can provide such clarity that transcends the short term objective of specific tickets/items flowing on the Kanban board.
Sprint Backlog	The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how). The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.	Kanban teams might have a content-based backlog for the entire goal they are focusing on, or a timebox-oriented backlog similar to Scrum. Kanban and Scrum are very similar in that the actual day-to-day plan emerges during work rather than in detailed up-front planning. Both approaches embrace uncertainty and continuous learning and feedback.
Commitment: Sprint Goal	The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.	Commitment to a Sprint Goal provides alignment, focus, and constancy of purpose that will steer the team when they’re facing “shifting winds” that make many of the Product Backlog Items (PBIs) irrelevant or add new PBIs to consider. Many Kanban teams use the completion of an epic or feature as the “goal,” but there is a further advantage to aligning completion of the goal to a cadence. Defining a more granular goal that is timeboxed to the Sprint is going to increase focus and alignment. This alignment can shift a team member’s focus on efficiently accomplishing just their own work to being part of a team that produces something of significant value at least once every month.
Increment	An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable. Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value. Work cannot be considered part of an Increment unless it meets the Definition of Done.	Kanban doesn’t explicitly mention having a potentially shippable Increment. Kanban teams have several options here: Use a Scrum-like Sprint Increment Have an increment upon completion of a higher level item that is marketable e.g. at the “feature” level. Have an increment upon completion of every product backlog item/card. Have a continuously available increment based on highly mature continuous integration/continuous deployment capabilities. This is harder but enables smoother flow throughout the Sprint boundaries.
Commitment: Definition of Done	The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.	The Definition of Done is an example of an explicit process policy. Kanban teams make their current process policies explicit and they evolve over time. This aligns perfectly with the Scrum perspective. Definition of Workflow for a Kanban system should include a clear definition of what Done looks like.

Conclusion

One of Kanban’s core practices is “Improve Collaboratively (using models and the scientific method).” The Scrum framework is one of the models to look at if you’re trying to improve how you do knowledge work especially in the context of product development.

To explore whether adding Scrum practices to your Kanban process will work for your team, go over this list with your group and consider your team’s stance towards each of these items - using a continuum between “Makes total sense; let’s go for it” and “When hell freezes over.”

Then, based on the outcome as well as your general hunger/interest in change, consider one of two main approaches towards experimenting with Scrum in your Kanban context:

1. Take Scrum as a whole and try it on top of your Kanban for a while. If you like what you see here and most of the items are on the “Makes total sense; let’s go for it” side this is probably the right approach for you. This is how Steve and other Scrum experts would recommend you go about it. Steve’s rationale is, “Each component within the Scrum framework serves a specific purpose and is essential to Scrum’s success and usage. As with Kanban, picking and choosing what practices you follow can have sub-optimal results without a deep understanding of what makes Scrum work.” He has a point!

But if you look at the list and it’s dotted with “When hell freezes over,” this is where the alternative comes into play.

2. Take the aspects from Scrum that you DO like and use them as "design patterns" or "good practices.” Note that if you do this you aren't actually doing "Scrum.” You’re just using some Scrum-related patterns. This will be a more evolutionary, experimental, and cautious approach. If you take this approach, frequently consider whether any of the other Scrum patterns are missing and are worth adding to your team’s process. Looking at these two very different approaches to adding Scrum to your Kanban we see Scrum and Kanban's different mindsets towards change at play. Scrum offers relatively revolutionary/prescriptive/shu-level guidance: take it all and experiment with adding practices. Kanban takes a more evolutionary stance that allows you to pick and choose.

If you’re still not sure which approach to take when starting your journey or when looking at Scrum as a seasoned Kanban team, Share your context in the comments and let’s try to figure it out together!

What did you think about this post?

Share with your network

Blog Comments