For teams that use Scrum or Kanban, the transition to Scrumban should be done by iterations. For teams who are not familiar with the agile process, iterative implementation could also be helpful in avoiding wasting time and adopting the process most effectively. Below is a tutorial of adopting Scrumban step by step.
First of all, prepare a simple Kanban board which consists of three columns: “To Do”, “Work in progress” and “Done”.
At this point, you should not think about sprint planning and just put enough items to work on for the whole team, and a few more. One item per team member would probably be best in order to make sure that there is a pipeline until we decide to input the new items. If you use Scrum, you will still be using sprints and will estimate effort on those task cards to keep the sprint intact and predictable.
The next important concept to grasp is the Pull principle. Kanban teams typically know this principle very well. The idea behind the Pull principle is to make sure that the team members can choose the items to work on. Therefore, you put the task cards on the board, but you do not assign them to anybody. The team members pull the tasks which they would like to work on and are capable of working on. For example, in the below examples John C. will try to run the production – he pulls the first item and start working on it.
Next, you need to master the process of item selection and prioritization on demand. You can do small planning meetings, where the team selects the items that have the most value and need to be done next. Planning meetings can be done as soon as the To Do or backlog reaches a certain number of items. In this example, John does planning meetings whenever the backlog contains less than 2 items. This approach keeps the waste away and instead of planning the whole iteration, you plan just a bit. Also, this approach guards from having too many items planned in cases when the unexpected happens.
In this example, John has added three colleagues and now his team can cope with a larger workload. According to Kanban, there needs to be a limit of the WIP (work in progress), keeping people focused on their tasks and forbidding multitasking, which leads to scope switches and wasted time. Let’s put a limit of four on the WIP. It means that not more than four tasks can be done at the same time by the team of a size of four. If a task is blocked and cannot be completed, it should move into backlog and a new one should take its place. Another approach is possible when some multitasking is allowed and cope up with small bugs or similar parallel tasks. WIP limit can be increased by 1 or 2, depending on how loose you are willing to make it. Let’s update our board.
Now we have a basic Kanban board, and we know when to plan, estimate new items and introduce them into backlog. The scope of work and the limits are known. We also know how to work – we pull the tasks and finish them, only then we take new ones.
The goal of this process is to have a continuous improvement. First, we need to learn how to plan a backlog for an iteration and what approach to use when prioritizing. The backlog can be limited in the same way the WIP is limited. But it would mean that we have some number of empty slots for tasks on this iteration and they cannot be exceeded (keep it as small as possible to avoid waste). All the limited columns can be imagined as empty slots like this:
Firstly, we need to run a few iterations in order to see how many average tasks we can handle through the iteration. Then we need to calculate the backlog size. If the team can accomplish ten tasks in a week then its velocity is two tasks per day for current team. If the iteration takes one week, then the backlog size should be 10. In addition, the backlog can be split into few columns in order to enable visual prioritization of the items through columns.
The green arrows illustrate how the tasks should move through the board.
It typically makes sense to plan small, aiming at only a few tasks per iteration. This approach can cut hours and days from the lead time metric – the time taking from the request on a task, feature, bug or similar item until that request is done and delivered to the end customer. The cycle time means the time item had spent in production except queue. If the task is done, it should be put to done – while if it needs additional steps, it has to be queued elsewhere. Experienced teams can run their backlog planning activity to the extent when only one or two items are in the backlog, waiting to be done. If these tasks are taken, a responsive planning team can provide new tasks for the future. But keep in mind, this can work only when planning is fast and responsive to empty backlog trigger. Otherwise, you can run out of work and stall the process.
If you use Scrum, by this time you should have stopped doing sprint planning with early binding and switched to pull principle with plan on demand. In this step we divide our WIP into smaller steps, thus allowing us to discover bottlenecks and keep the process detailed for better limits.
Now the board work in progress (WIP) has a total limit of 5 and the columns are limited to 4. This limit means the WIP allows some multitasking because it can contain five tasks, but the team has only four members. Our team can be fully loaded in one of the columns and reach its limit, but it can have some multitasking in other columns. For example, if the testing phase is blocking the item because there are problems with testing environment, the item can remain in test and a new task can be started until the testing environment is fixed. Also, by using this approach it is possible to finally discover the bottlenecks and see which steps tend to block the process flow.
This board sample is just a simplified approach to show how Scrumban works. In order to have an accurate cycle time calculations, the queue columns, such as Analyse done, Development done and Testing done have to be introduced, where finished items lay until they are pulled to the next column. They do not contain limits and can be thought of as a parking spot for tasks.
If you have your cycle time and lead time under control and you can predict them, then all other metrics are just derivatives of cycle or lead time. By mastering those metrics you will know how long does it take for a task of a certain size to reach the end customer, how long it does it stay in management and release, and how long does it take to develop it. You can view the tasks as a direct value or money boxes. By visualizing them, you can predict how long will it take to provide a certain amount of value or earn some amount of money.
Finally, you might ask what about the utility and maintenance and deployment tasks on time-boxed iterations? There are at least two options:
- Feature freeze and deploy (Scrum approach)
- When you have 10-15% time left untill your iteration deadline, make a feature freeze
- Take tasks that are not going to make it in this iteration and put them into next iteration
- Introduce deployment and release tasks into the board which can be pulled through the pipeline as normal work items
- Continuous deployment during the iteration (Kanban approach)
- Each task must reach the end customer when it is finished
- Fast and cheap deployment process can make this work
- By using this approach, you can continuously work on your tasks without interruptions and you will be sure that you have done everything you could in this release in order to publish as much as possible
By using one of these approaches you should have already realized that planning and releasing are not happening in same intervals like in Scrum, where you plan and release for each sprint. By using Scrumban, you plan more often than you release. Having those two decoupled, you focus on releasing as much as you can, and the planning is done only on demand. In addition, an on-demand Kaizen event is a must. You will need to discover how often you do these events – you can start by having such an event after the iteration is finished, and later on you might discover that you need to make it more often.
Finally, the board is set and ready for using. Every team will add their own interpretation and personal preferences, so please take these recommendations as a basis, not as a full instruction.
There are also several rules and constraints that are followed in Scrumban:
- Keep backlog as small as possible
- Plan only on demand
- Split your backlog into few columns so you can prioritize and decide which tasks are worth doing next
- Leave some space for multitasking – but keep control of it (the limits have to be slightly higher than the number of team members)
- Decouple planning and releasing
- Use only average lead and cycle times to measure your performance
- Specialize your team and let people focus on what they prefer the most
- Allow people to pull the tasks themselves
- Have Kaizen events
- Leave space for deployment in iteration or have continuous deployment for each task
To sum up, the Scrumban approach offers a slightly more flexible process for fast paced production than the other methodologies. It is ideal for startups, where things tend to change a lot, and manufacturing companies, which are willing to control and improve their process by reusing the current resources and focusing on production performance.
While a simple whiteboard with sticky notes is sufficient to implement Scrumban in practice, you can also use electronic agile tools that allow for Scrumban like Teamhood Kanban BoardNext: Learn how to get started with Scrumban.