Introduction
In the agile work context, there are currently 2 major areas of influence with Scrum and Kanban. Both frameworks bring certain advantages and disadvantages with them and have a different focus.
Is it not a good idea to extract the best elements from both worlds and to unite them in a comprehensive methodology? This is where the term “ScrumBan” comes from, first introduced by Corey Ladas in 2009.
To create a better understanding, I would like to present my personal situation and way of thinking. I have been dealing with Business Intelligence topics since 2015 and was able to graduate with a Master’s degree in Data Science in 2021 (see my Master Degree Journey Post).
In 2018, I completed the training to become a Scrum Master and since then I was allowed to accompany several teams during the implementation of Scrum in BI environments. In the last two years, I was also able to significantly support a team in the transition to an agile project methodology. We went through different phases together and started with the classic Scrum approach. Over time, we added or replaced certain artifacts so that the agile methods were an optimal fit for our way of working. At that time, I hadn’t even thought about whether this could be ScrumBan. We optimized what was already working and got rid of things that did not bring significant benefits.
Different kind of ScrumBan
Within this blog post, I want to provide clarity on what things worked well and how you can best use that for yourself.
When deciding on a best practice approach of Scrum and Kanban, the most trivial question is first of all, how many and which elements from which framework should be used? There are different possible solutions for this:
A. Scrum with a Kanban board (It’s more a less just Scrum?)
B. Scrum with a Kanban board and WIP limits on the “doing” column(s) (Scrum with a process improvement?)
C. Scrum with a set number of tasks selected per Sprint rather than using story points (Scrum with NoEstimates?)
D. Scrum without Sprints (That’s no longer Scrum?), or Kanban augmented with the Scrum roles and events (which is the same thing)?
E. Scrum with variable length Sprints (No longer Scrum?)
All these possibilities are understood as ScrumBan and probably there are even more variations. However, I could see that ScrumBan is essentially about the transformation path away from Scrum to a very lean Continuous Delivery process that uses Kanban as a tool for the transition.
Founder Corey Ladas writes about it:
“Scrumban is not a set of practices. Scrumban is not a prescribed process. There is no canonical reference implementation of Scrumban. Scrumban is not an approach to doing Kanban. Scrumban uses kanban in pursuit of continuous delivery and continuous improvement.”
How can you start with ScrumBan ?:
You must first understand that ScrumBan is not a fixed framework, but a very individual transformation process.
- I recommend you to start with Scrum first. Also use all artifacts and especially in the beginning stick quite strictly to the guidelines from the Scrum Guide. Don’t soften the approach too early, but do some sprints very close to the standard approach. This will help you and the team to arrive successfully in the agile world.
- Use technical support, e.g. colors or tags to identify which person is working on which task. This is the first step towards a Kanban board, which allows you to limit the Work in Progress (WIP).
- Conduct regular retros and look together as a team at what is working well and what is not. Take 2 active suggestions for improvement per sprint and also look at the implementation success at the end. Choose one practice that will help you progress toward continuous delivery. You may discover a waste or a bottleneck, such as too much work in progress or work that is behind schedule in some columns.
- Measure the success of each measure taken at the end of the sprint using fixed KPIs.
- Repeat steps 3 and 4 until you are practicing Lean production and working in a continuous flow that is free from waste.
Is ScrumBan the escape route from Scrum?
Yes! — somehow
Scrumban is a method of progressively abandoning Scrum rather than abruptly.
It’s also feasible to begin your journey without Scrum, but preserve some of the Scrum aspects that you find valuable. Some positions or activities (for example, planning or review meetings) are excellent candidates for retention. Of course, you’re no longer using Scrum, according to the Scrum handbook.
But that’s the whole concept of Scrumban!
My recommendation of the artifacts I would definitely keep:
Planning: Gives an overview of the tasks for the next week and enables a commitment from the team.
Sprint goal: Best per user story. This makes it much easier to measure success.
Retro: One of the best events to improve the process and get active feedback from the team. Be careful not to do it too often and it will weaken the impact.
Review: Very helpful event to gather feedback from stakeholders. If there are several different stakeholders, it may also be a good idea to split the event into several smaller meetings.
Sprint Timeboxing: Gives the entire Continuous Process a fixed timeframe. Very useful, since things always take as long as they are allowed to take (Parkinson’s Law). Helps as a fictitious deadline to bring things to completion.
WIP: The best Kanban Feauture, because it avoids too much work at the same time and especially different work. New tasks can only be tackled after the old ones have been completed. Helps for a clear structure.
Have you already applied Scrumban? If so how did it go? Let me know in the comments.
