January 2015 Archives

How Scrum team benefits from Kanban practices

While discussing some struggles of Scrum team with my friend He Mian during his Kanban course recently, i realize that Scrum team can benefit from many Kanban practices.


There are 6 core practices defined in Kanban method. They are:


  1. Visualize
  2. Limit Work-in-progress
  3. Manage Flow
  4. Make Policies Explicit
  5. Implement Feedback Loops
  6. Improve Collaboratively, Evolve Experimentally

Let's look through them to see how Scrum team or any team doing iterations can benefit from those Kanban practices.


  • Visualize

Scrum team usually adopts some form of task boards to help coordinate their work in sprint. The key is to effectively inspect where we are so as to adapt accordingly. Visualization in Kanban goes deeper than usual task board. When the cycle time of your stories is still long (e.g. a week or more), the additional details expose problems earlier and help us adapt faster. Kanban uses more elements when visualizing, such as area, color, shape, number, etc. For example, the impediment could be visualized as attached note with different color on the story. This brings everybody's attention immediately.


  • Limit Work-in-progress

Scrum limits WIP indirectly by iteration. It's recommended to work on one story at a time, however, it may not be viable with small size story (e.g. 2-3 days, 2-3 people) and big size team (e.g. 7-9 people). It is good practice to limit WIP further inside sprint, and visualize that by limiting the number of lanes for example. One argument against doing that may be the risks involved in not starting the work, considering that the goal is to complete them all by the end of the sprint. We shall take risk factors into account when prioritizing stories. By limiting WIP, we actually improve the chance of completing them all by the end of sprint.


  • Manage flow

When managing the progress, reminder of sprint goal is a good step forward, while focusing on flow provides more clear guidance. Anything that prevents flow becomes impediment.


Bottleneck is one common reason that prevents flow. In Kanban, a few ways are suggested to address those both in the short term and in the long term. For example, when testing becomes bottleneck, you may first consider removing any non-bottleneck work from those people who are testing; then, you may consider improving quality of the work flowing there by doing more developer tests; then, you may consider having developers help testing. Scrum team benefits from ideas of flow management.


By measuring cycle time - the time you start working on a story till the time you get the story done, you get insights from control chart and distribution chart on how to improve the flow in the long term.


The focus on managing flow is also reflected in the way that daily standup is done in Kanban. We walk through the board from right to left, story by story. This helps making more effective inspection and adaptation.


  • Make Policies Explicit

The Definition of Done (DoD) is one of the most important policies in Scrum. The Definition of Ready (DoR) gets popular in Scrum community, which is another policy. BTW, in practice those may lead to the wrong focus on handover from one group to another, but those could be and are achieved collaboratively in many contexts.


Many Scrum teams create and evolve their working agreement, which forms a dynamic set of processes and policies. Kanban points out more opportunities to make policies explicit, and they become areas for improvement. This fits well with the inspection and adaptation on process. Only when you understand how you do things now, can you improve further. The improvement involves the update of policies, which becomes the baseline of next improvement. Scrum teams benefit from treating working agreement as the carrier of continuous improvement. And the working agreement is visualized in the board.


  • Implement Feedback Loops

There are 3 practices defined as feedback loops - daily standup, improvement kata and operational review. We have talked about daily standup in managing flow, and let's look at the other two.


Improvement kata is the daily improvement activity. I have been promoting the paring of manager and ScrumMaster on process improvement. Usually, they work together on removing impediments. The impediments may come from daily scrum or retrospective. Kanban measures flow, and provides the feedback with data. The data is systematic, and supplements well for the impediments. Operational review acts as feedback loop in large scale. The key again lies at the analysis of data.


In Scrum, two levels of feedback are built-in, daily and sprint. Daily feedback is provided through status sharing in daily scrum and sprint burndown. Sprint feedback is provided through conversation in sprint review and release burndown, as well as sprint retrospective. Comparing to metrics defined in Kanban, such as cycle time control chart and distribution chart, CFD, etc., those feedback in Scrum is more subjective. Scrum team benefits from integrating more data in the feedback loop. In particular, we shall consider gathering objective data in sprint retrospective to achieve more balanced view and better insights.


  • Improve Collaboratively, Evolve Experimentally

The improvement practice in Kanban emphasizes using models and the scientific method. The requires more rigidity in our improvement activities. While it is one direction to improve retrospective through more effective facilitation so as to increase team engagement and promote ownership, it is another direction to improve retrospective through more rigid analysis and followup. I have seen teams applying PDCA in their retrospective and reaping solid benefits.


Summary


Even though flow and iteration are different concepts and practices, when we dive deep, we find that Scrum teams benefit from doing some Kanban practices.


  • use visualization to help inspection
  • limit WIP for flow
  • use flow to guide adaptation
  • improve on DoD, DoR and working agreement
  • create feedback from data
  • retrospective with data

About this Archive

This page is an archive of entries from January 2015 listed from newest to oldest.

December 2014 is the previous archive.

February 2015 is the next archive.

Find recent content on the main index or look in the archives to find all content.