Enhance Scrum With Kanban Practices
Are your teams having some success with Scrum? Want to up your game? Read on to learn how to incorporate the 6 Practices of Kanban to elevate your Scrum team’s delivery.
Kanban General Practices
- Visualize
- Limit Work in Progress (WIP)
- Manage Flow
- Make Policies Explicit
- Implement Feedback Loops
- Improve Collaboratively, Evolve Experimentally
Visualize
Most Scrum teams will likely be visualizing their work to some degree. Their board might be pretty high level though with process states that are very generalized. This can be a good thing if the team is continually pairing and/or mobbing. Then all skills are brought together at a single time.
If teams are not actively mobbing, waste and delays may be hidden within those general states. Work maybe sitting at rest, or in hidden queues, waiting for a specialist, an approval or the “one person who knows this code”. Remember, every handoff involves a queue. Break apart states where handoffs happen to be able to better measure, and then work to reduce, the time spent waiting.
By redesigning the workflow with more discreet process steps/states, perhaps even with buffer states before specialized work steps, you will be better able to identify and measure delays in the flow.
Team members should be reviewing the board often — what is it telling us?
Limit Work in Progress (WIP)
Scrum teams are already limiting WIP by selecting a small set of work items for the Sprint Backlog. Applying Kanban WIP practices would go beyond that method.
A first place to start would be to apply an overall WIP limit to the entire workflow, something that is less than “1 story per person” and less than the average number of work items selected for the Sprint.
Why less? To reduce context switching. Many teams will start every work item the first day of the Sprint in the belief that everything must be in motion to get everything done by the end of the Sprint. This is harmful thinking because it leads to time loss due to context switching. People cannot multitask though many believe they can.
Having a WIP limit less than the number of people on the team will also promote teamwork. Likely in the form of pair programming and/or mobbing. These are good things for many reasons such as learning, quality improvement and flow improvement.
Beyond an overall process level WIP, experiment with adding WIP limits to buffer states to limit the size of those queues.
Manage Flow
A primary goal of Kanban is to smooth out the flow of value. Teams with high WIP will experience frequent start/stop conditions on individual work items. This leads to unpredictable work item completion rate results.
Teams with smoother process flow ensure higher levels of predictability which can be used to set customer expectations, create forecasts and accurately measuring improvement efforts.
A smooth flow of value can help ensure teams are working at a sustainable pace. Unstable flows often lead to teams working many additional hours to “make their numbers” when work items are frequently becoming blocked or delayed.
Scrum teams should adopt Kanban metrics such as Cycle Time and Throughput per time period. These metrics will be used to provide customer expectations, forecasts and evaluate process improvement changes.
Make Policies Explicit
Consider adding a mini-DoD (Definition of Done) to every process state, known as a “policy”. This will let the team define what it means for a work item to be done during each process step. Work cannot be pulled (a key concept!) further downstream from its current state before the policy is satisfied. Another name for a policy is “exit criteria”, further describing its usage.
Initially the policies might be less restrictive. Over time, teams will typically tighten down policies, perhaps to improve quality. By adding quality policy measures “further left” in the process flow defects and other incorrect decisions can be caught sooner.
Policy items can also arise from “collapsing” or removing process steps because the team has changed their ways of working. An example could be initially a team has a separate peer review state but, because the team has adopted pair programming or mobbing, that separate state is no longer needed. To ensure quality remains high, a policy statement on the remaining process step is updated to include “peer review completed”. These type policies are good selling points to auditors — we’re working to “mistake proof” (poka-yoke) our processes by using explicit policies.
But don’t stop at just adding policies at process states. If the team is using something like swim lanes for Work Item Types or Classes of Services, add a policy for each of those. Define what customers can expect, perhaps similar to an SLA, for the processing of the various work item types or classes of service. What is the expected turn-around time? What sort of notifications happen as the work items complete?
Other types of policies would include WIP Limits and information typically defined in a team level working agreement.
Write the policies down to make them explicit. That way the team and your customers know what to expect.
Implement Feedback Loops
Scrum teams should be very familiar with several feedback loops:
- Daily Scrum
- Sprint Retrospective
- Sprint Review (not just a demo!)
Kanban doesn’t add any prescriptive feedback loops. Recommended feedback loops would include:
- Frequent review of metrics (ideally Lean metrics)
- Meetings, known as cadences in Kanban, for Replenishment, Process Review and Customer/Stakeholder Review
- Anything else needed based on your context
Improve Collaboratively, Evolve Experimentally
Kanban teams learn continuous improvement. Teams adopting Kanban “start with what you do today” and then agree to frequently inspect and adapt their ways of working. This leads to evolutionary change rather than “big bang” highly disruptive infrequent change.
Kanban teams adopt scientific thinking/methods by using experimentation based change efforts. Teams will create safe-to-fail experiments. If the hypothesis proves true, they keep the change being proposed. If the hypothesis fails they do not adopt the proposed changes (roll back).
The Toyota Kata, also known as the Improvement Kata, is a highly recommended method to use to implement the Scientific Method and evolve to a continuous improvement mindset.
Wrapping Up
Scrum is, by design, incomplete. Many teams successfully implement eXtreme Programming (XP) practices to improve their software delivery. By adding Kanban practices teams can improve their process flow which has several benefits such as increasing predictability by stabilizing the flow of value.
If you found this article helpful, please click on 👏 and follow me for more valuable information on Agile, Lean and Book Reviews.
Until next time!
