A Scrum Primer for Kanban Teams

If your Kanban team is interested in implementing Scrum, or even just a few Scrum-related practices, read on to get the opinions of a Kanban thought leader.

Steve Porter

Jul. 24, 17 · Analysis

Like (4)

Save

6.41K Views

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 in helping to 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.

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 about 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 the 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. 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 ScrumGuides.org and GuntherVerheyen.com.

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?

Roles

Every self-respecting Agilist knows the roles central to Scrum---the Scrum Master, Product Owner, and the Development Team. Are those roles useful for Kanban practitioners? Let’s examine that question role by role.

Scrum Aspect	Short Description (According to the Scrum Guide)	How to apply to Kanban
Development Team	A cross-functional, self-organizing team of professionals who work together to deliver an increment of value. Team members may have specialized skills and areas of focus, but they share accountability for delivering a high-quality increment.	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.
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 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 Development Team understands and enacts the Scrum framework. The Scrum Master also works to remove any impediments the Development Team 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	A one-month or less interval in which the Scrum Team works to create an increment and achieve a goal. The Sprint contains all the development work: Sprint Planning, Daily Scrums, the Sprint Review, and the Sprint Retrospective. To help the Scrum Team focus, no changes are made during the Sprint that would endanger the Sprint Goal. However, the scope may change as the Product Owner and Development Team learn more.	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	During Sprint Planning, the entire Scrum Team collaboratively decides the work it will perform in the Sprint. Once the Product Owner discusses with the Development Team the objective that the Sprint should achieve, the Development Team forecasts the functionality that it will develop during the Sprint. The number of items it selects from the Product Backlog for the Sprint is solely the Development Team’s decision. After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.	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. 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.
Sprint Goal	The Scrum Team sets an objective for the Sprint that can be met through the implementation of Product Backlog items. It provides guidance to the Development Team as to why it is building the Increment. The Sprint Goal gives the Development Team some flexibility regarding the functionality it implements within the Sprint.	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.
Daily Scrum	The Daily Scrum is a 15-minute or less meeting for the Development Team to synchronize activities, create a plan for the next 24 hours, and to identify any impediments. How to accomplish this is up to the Development Team providing it inspects progress toward the Sprint Goal and inspects how progress is trending toward completing the work in the Sprint Backlog.	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. The Scrum Guide suggests that the Development Team members explain what they did yesterday, what they are are focusing on today, and what their impediments are. 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 entire Scrum Team and the stakeholders carry out the Sprint Review. Its purpose is to inspect the Increment and adapt the Product Backlog if needed. The informal meeting is intended to elicit feedback and foster collaboration. The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.	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 Sprint Retrospective is an opportunity for the entire Scrum Team to inspect itself and create a plan for improvements to enact during the next Sprint. Although the Scrum Team may discuss improvements at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.	Most Kanban teams run retrospectives as well. Again, some teams do them on demand, but most teams benefit from doing 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	An ordered list of everything that the Development Team may eventually work on for a given product. As it learns more about the product, the Development Team may change, add, or remove items in the list via the act of Product Backlog refinement. It is important that the Product Backlog is visible, transparent, and clear to all.	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 adding detail, estimates, and order to items in the Product Backlog. Refinement is an optional practice and is not a formal event. If needed, it can be an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.	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.
Sprint Backlog	A set of Product Backlog items the Development Team forecasts it will deliver in the Sprint, plus a plan for delivering the increment and realizing the Sprint Goal. The plan has just enough detail so that changes in progress can be communicated daily. The Sprint Backlog emerges during the Sprint and the Sprint Backlog is modified throughout the Sprint by the Development Team as they learn more about the work needed.	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.
Increment	The Increment is the sum of all the Product Backlog items that the Scrum Team completes during a Sprint and the value of the Increments of all previous Sprints. At any time during the Sprint, the Scrum Team may decide to release Product Backlog items. By the end of a Sprint, the Increment must be in useable condition and potentially releasable, regardless of whether the Product Owner decides to actually release it. It is important that the Increment is transparent to allow for its inspection and adaptation (via changes to the Product Backlog). Increment transparency is accomplished via its 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 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 a smoother flow throughout the Sprint boundaries.
Definition of "Done"	The definition of "Done" is a shared understanding of what it means for work to be complete. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.” The definition of "Done" is not an artifact, but a technique to ensure that the Increment is transparent.	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.

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 suboptimal 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!

scrum agile Kanban (development) Sprint (software development)

Published at DZone with permission of Steve Porter, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Comments

Related

Trending