A Quick Comparison of Scrum-ban, Kanban, and Scrum

scrum agile kanban tips scrumban

As we discussed last time, Scrum-ban is ideally suited for tasks that are roughly equally-sized and that are focused on continuous development.   Scrum-ban takes some of the concepts of scrum and melds them with Kanban.   Here’s a quick comparison between the three methods:

Kanban Scrum Scrum-Ban
Daily Stand-ups No Yes Yes
Artifacts None Backlog, Current Work, Burndown Charts Current Work
Metrics Lead Time/Cycle Time Velocity Lead Time/Cycle Time
Demo Not used Required Optional
Skill Sets Specialized Cross-Functional Either Specialized or Cross-Functional
Iterations No Yes No
New Work Prioritized Immediately Prioritized at Sprint Planning Meeting Prioritized Immediately
Retrospective Not used Required Optional
Defined Roles None Product Owner, Scrum Master, Scrum Team Product Owner, Scrum Master, Scrum Team

Kanban is focused on continual delivery of fixed size pieces of work.  In Kanban, priorities immediately shift as new tasks come into the queue.   The team measures how long it takes tasks to be handled from the time they enter the queue to the time they are completed (lead time), and how long they are in process from start of work to end of active work (cycle time).    Kanban teams are focused on individual work, and may swarm tasks and work together, but typically do not meet daily to discuss progress.

Scrum teams are cross-functional.  They track team velocity, burndown charts, etc.  They use fixed-length iterations and take on work based on the team velocity, but work items can be a variety of sizes.   Agile scrum teams communicate in daily standups, hold a planning session to commit to work at the beginning of an iteration and do a demonstration and retrospective at the end of the iteration.

Scrum-ban uses fixed-size pieces of work for development  and tracks work that is in queue, ready to be processed, and in process.   It focuses on cycle time and lead time to determine how much work to take on, as in Kanban.   Scrum-ban brings in the communication elements of scrum, adding a daily standup to discuss progress and optionally holding retrospectives periodically to discuss possible process improvements.  Teams doing scrum-ban may be either cross-functional or specialized.

Here are a few tips for using Scrum-Ban and Kanban with your agile teams:

1.  Do not marry your method.   Agile is about people over process.   As a scrum-master or agile team manager, it is important to be flexible in techniques.   Sometimes teams will switch techniques depending on the phase they are in during development.   For example, while researching a new feature, the team could use Scrum-ban to conduct a series of fixed-length research spikes that look at individual aspects of the feature’s design, etc.   As they are developing the feature, they could switch to pure scrum to work through initial development and test.   After the feature is in maintenance mode, they could hand the team off to a support team that uses Kanban or Scrum-ban to tackle customer issues.

2.  Do not force it.  Scrum-ban is not necessarily meant to be an introductory technique.  If an agile team is highly-functioning, and their workload is not already equally-sized, it might be best to keep them running in pure scrum.   If a team is highly functioning as a scrum-ban or Kanban team, only introduce the aspects of scrum that can benefit them (i.e. For a Kanban team, it might be good to not force fixed length iterations, but instead only introduce the concept of a daily standup at first).

3.  Encourage team ownership.  Agile teams that are working well typically work with a high degree of autonomy.   When introducing new techniques, offer the ideas as suggestions.   Do not dictate, “Now we will start working in Scrum-ban.”   Allow team members to first learn about the techniques and interact with team members to see how they are receiving these ideas.   You may be very excited about making a process improvement or trying out a new idea, but remember people over process.   It takes time to adapt and be efficient, help the teams decide whether they need the change and when the best time to introduce new method might be.

Good luck in exploring Scrum-ban, Kanban, and Scrum.  If you have specific questions or need help implementing any of these concepts, contact us, or leave a comment below!


Comments are closed.