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!
