Hamburgers and hotdogs in China are they the same?

Hamburgers and hotdogs in China are they the same?

Not all instantiations of Scrumban look alike.  Scrumban reflects the team and time box philosophies of Scrum and the flow philosophy of Kanban, combined. Teams hybridize Kanban and Scrum in various ways to address specific needs. A more Scrum-y version of Scrumban will have more of the team philosophies and techniques of Scrum and would include the following features:

  • An Abridged Planning Session: The team will need to select the appropriate number of stories that can be completed during the sprint.  The selection process will require some form of story-level sizing and estimation.  As in Scrum, the team’s goal is to clear the board by the end of the sprint.  Generally the team generally will not need to plan the stories at a granular level (tasks) because the Kanban board will reflect the steps required to perform the work.
  • Pull and Work-in-Progress Limits: Each step in the process will have explicit WIP limits and work on new items will only started if the step has capacity.   The Kanban board would begin looking approximately like the example below:

Kanban board when you begin scrum-y Scrumban.

Kanban board when you begin scrum-y Scrumban.

  • Stand-up or Scrum Meetings:  The team holds a daily planning meeting in which team members address what has been completed, blockers and what is to be done next and by whom.  When using Scrumban I find it beneficial to have team members move work from column to column on the board during the stand-up meeting.  Seeing progress reinforces motivation.
  • Swarm!: As noted in step one, the team’s goal is to clear the board.  Swarming behavior occurs when more than one team member gets involved in a piece of work or task so that it can be completed. If you have ever seen a bunch of ants take care of grasshopper, you have seen nature’s version of swarming.  What one ant can’t accomplish quickly, a coordinated swarm certainly can.  Swarming behavior reflects true team behavior rather than a group of unrelated individuals.
  • Attack Bottlenecks:  If bottlenecks, steps in the process where WIP starts to build up, occur as work flows through the process, the process must be fixed. This might mean making process changes or reallocating team members during the sprint. Swarming (above) is used if the problem is a temporary constraint and does not require a permanent process change.
  • Demonstrations/Reviews:  At the end of the sprint or time-box, the team (lead by the Product Owner) will demonstrate and facilitate interaction with the software that has been completed during the iteration.  The resulting feedback provides the team and organization with the information needed to make sure they stay on track. At the completion of the sprint the Kanban board should look approximately like the following example:
Kanban board when you end scrum-y Scrumban.

Kanban board when you end scrum-y Scrumban.

  • Retrospectives: At the completion of the sprint, the team should reflect on their performance and make adjustments to improve.  This is in addition to any process changes that were made to address bottlenecks.  A retrospective provides time for the team to reflect without an impending deadline.

A Scrum-y version of Scrumban may be confused with a visualized version of Scrum.  The primary differences from pure Scrum are 1) abridged sprint planning (less granular), 2) explicit WIP limits for each step in the process, and 3) a kaizen philosophy in which all bottlenecks are attacked and resolved as discovered.  The goal of Scrum-y Scrumban is that all the work that begins on the left hand side of the Kanban board will flow to the completed column by the end of the iteration, which is not necessarily the goal of kanban-y version of Scrumban.