Adapting Scrum with Kanban

Adapting Values

• Successful use of Scrum depends on people becoming proficient in living according to these five Scrum Values:
  • Commitment
  • Courage
  • Focus
  • Openness
  • Respect
• These values build a foundation of trust, which is required to bring the Scrum three pillars, 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.
  • 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.

Adapting Roles and accountabilities

• 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 (DoD)
    • 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 Product Owner is 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 Developers, 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 Scrum Master is 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.

Adapting Events

• 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.
• 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 Scrum, 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.
• 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 (DoD).
    • 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.

Adapting Artefacts

• How do Scrum’s artifacts apply in a Kanban environment?
• 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 priorIncrements 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 (DoD).
    • 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 (CI) and Continuous Deployment (CD) capabilities.
        • This is harder but enables smoother flow throughout the Sprint boundaries.
• Commitment: Definition of Done (DoD)
  • The Definition of Done (DoD) 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.

More at Scrum and Kanban

Scrum PSK exam flashcards

PMI-ACP exam