Scrum and Kanban are both agile process optimisation methods. ScrumBan combines the workflow-improving principles of Kanban with some of the roles and rituals (Product Owner, Sprint, Daily, …) that Scrum provides. This results in a working mode that affords continuous flow with clear roles, quick learnings integration, daily prioritisation, as well as regular and structured customer interaction.
To provide a working model that caters to the continuously learning nature of a e.g. a startup-like project while ensuring that priorities are continuously updated and development results regularly reviewed with customers.
Outcome / Deliverables
A continuous workflow with fast and regular prioritisation and customer feedback events that optimally matches a team‘s learning and delivery capacity.
Scrum is a self-organised “process” with the purpose to predictably deliver comparably small increments of a bigger project in fixed time boxes. An increment is to-be-reviewed at the end of the sprint and priorities are re-set after the review. Kanban provides a lightweight way to manage a workflow by limiting and visualising work in progress. An item is done, when it’s done and the resources can reassign themselves according to the priorities valid at this exact point in time. Scrum provides clear role definitions with the PO at the center of the project where Kanban basically is organised by the sequence of sub-tasks to be performed. Scrum also prescribes the regular review of realised work increments with customers.
Consider the following project example:
Within the Vmax Team we set out with Scrum as our operating mode. The idea was, that we would build the foundations from a comparably stable and continuously evolving backlog and that the creation of e.g. the various items that made up the envisioned product would be a pretty straightforward implementation effort. Hence we assumed that a sprint-based bi-weekly reprioritisation of our backlog would be sufficient.
Over time it turned out that the Vmax project behaved much more like a “startup” than we expected. Backlog and priorities changed more quickly than the bi-weekly sprints we had defined. On top, we found ourselves often “learning and adapting” more than “creating”. So we decided to change mode to be able to adjust to our reality.
After some internal discussions we opted for a ScrumBan model (with some Lean Startup elements added). We had come to value the clear Scrum role structure, in particular the smart guidance by a PO. And we also liked the structured and regular customer feedback rounds via the reviews that helped us put our achievements and learnings into a perspective. Also, we stuck to and actually extended the Dailies as they help us to update and share priorities based on learnings and “customer” feedback.
At the same time we introduced a “virtual sprint” of a week’s length with a mini-review every Thursday to be able to look at our learnings and achievements on a more frequent basis, while keeping the bi-weekly customer review cycle. The hardest part of the new setup was to structure stories in such a form that they created minimal dependencies which have a potential to slow our progress down. Still, after two weeks, we added an “on hold” column to our KanBan board to be able to free up Dev Team member’s WIP limits when dependencies bogged the resources down.
All in all ScrumBan furnishes us with with a lightweight workflow management that accommodates our continuous project development while keeping and enhancing the benefits of Scrum roles and regular meetings.
Dos & Dont’s
- Visualize the workflow
- Limit WIP
- Manage the workflow
- Ensure collaboration across workflow steps
- Improve process and board over time
- Don’t start with a board that’s too complex
- Reddy, A. (2016): The Scrumban [R]Evolution