Are pizzas and hamburgers in Peru the same?

Are pizzas and hamburgers in Peru the same?

Scrumban is a hybridization that results from a team’s, or organization’s need to address specific process or organizational constraints. We’ve examined a Scrum-y Scrumban instantiation.  Kanban-y Scrumban, on the other hand, is usually a reflection of a high degree of specialization of personnel (e.g. developers, business analyst, testers, DBAs . . .). Work is done by one specialist and then handed to the next specialist.  Kanban-y Scrumban helps improve communication and identify unbalanced processes that constrain the flow of work. A Kanban-y version of Scrumban would include the following features:

  1. Release Cadence: Scrumban that is more Kanban than Scrum will generate a continuous flow of work for some period of time. At some point the software will be released into production (or to the customers).  An explicit release cadence is generally a feature of this version of Scrumban.  It should be noted that a continuous delivery cadence is possible, but is very rare. Monthly, quarterly or semi-annual releases are very common.  There is no requirement for any other time-box.
  2. 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.   This is a common feature of all forms of Scrumban.  Unlike the Scrum-y version of Scrumban, unless you just beginning a project or completing a project there is no requirement that the Kanban board be cleared of in-progress work.
  3. 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 any form of Scrumban, I find it beneficial to have team members move work from column to column on the Kanban board during the stand-up meeting.  Seeing progress reinforces motivation.
  4. Backlog Grooming: Backlog grooming and prioritization occurs as work is pulled onto the active portion of the board. The Product Owner (or proxy) should ensure that the backlog is continually prioritized, as backlog items will be addressed as capacity becomes available.  I recommend sizing backlog items small enough that they can move through tasks on the board in one to two days.  In Kanban-y Scrumban, there is no other requirement for estimation.
  5. Attack Bottlenecks:  If bottlenecks, steps in the process where WIP starts to build up, occur, you need to fix the problem. This might mean making process changes or reallocating team members. If this version of Scrumban is being used, swarming rarely occurs because the organization is highly structured with specialists in each development role.
  6. Release Demonstration/Review:  Prior to release, the team (lead by the Product Owner) will demonstrate and facilitate interaction with the software that has been completed for the release.  Many organizations couple the Demo/Review with a more formal user acceptance test (UAT) step, doing the demonstration then UAT. If you wait until just prior to a release to generate feedback, there is a substantial risk of rework.  One organization I recently observed uses a continuous approach to the review step, demonstrating as each unit of work is complete.

A Kanban-y version of Scrumban differs from a pure Kanban process predominately thought use of the daily stand-up meetings, backlog grooming and demonstrations.  The focus on flow will tend, over time, to put pressure on the organization to align the people into teams, and blur the lines of around specialties due to improved visualization of hand-offs and bottlenecks.  The use of teams will make tactics like swarming to problems easier to accomplish and will lead to increased flow.