how to take your team from scrum to kanban
TRANSCRIPT
FROM SCRUM TO KANBANLearn why and how your team can progress to implementing Kanban after using Scrum.
Why move to Kanban in the first place?
What can remain intact?
What needs to change?
What tools are there to support the transition?
When will Kanban work better than Scrum?
What is the expected benefit?
Is there any proof that all this works?
ABOUT
Why move to Kanban in the first place?
What can remain intact?
What needs to change?
What tools are there to support the transition?
When will Kanban work better than Scrum?
What is the expected benefit?
Is there any proof that all this works?
ABOUT
WHY MOVE TO KANBAN IN THE FIRST PLACE?A project team can have many wrong motivations and only one right one to undertake the move from Scrum to Kanban.
THE WRONG MOTIVATION FACTORS TO MOVE FROM SCRUM TO KANBAN...
While this argument could theoretically be true (given the context), it can only be valid if you know precisely why Scrum does not work for you.
Scrum is somewhat easier to implement than Kanban. If you cannot make it work due to the lack of discipline, chances are that you will fail with Kanban too.
Trying out Kanban only makes sense if your team has the necessary discipline (or a really good Flow Manager) to go to a more advanced delivery method.
Scrum does not work for us(AKA. we can’t make scrum work)
Scrum was never meant to cope with organizational structures. It was meant to impose new structure and you shouldn't expect it to fit the current boundaries.
If you are facing “political” problems in your organization, they will likely replicate to the Kanban world too.
Kanban might ease the tension generated by the “corporate culture” but is likely to expose many other issues. The entire organization should be prepared to face them, otherwise you will be doomed to fail.
Scrum roles do not fit our organizational structure(AKA. we don’t know what to do with management)
Planning is a non-value adding activity and it should be minimized as much as possible. However, if an experienced team cannot plan two-weeks worth of work, this might be a false argument.
If your environment makes it impossible to follow at least a basic plan, Kanban might help, but not a lot.
If you switch to Kanban with the mindset that you will never ever have to plan anything, you might be getting yourself into big trouble.
We don’t want to waste time planning (AKA. we can’t plan properly)
Self-organization and proactivity are important for Scrum and Agile, but they are even more important for Kanban.
If the people in your organization are passive and unmotivated, switching to a new delivery method is not likely to improve the situation dramatically. On the contrary, Kanban will expose a lot of issues, which are likely to worsen the situation.
Kanban is a less prescriptive method and it heavily relies on the culture of the company and the motivation of the people in it. Kanban cannot create the culture and the motivation for you, it can only help you build them.
We don't have a dedicated product owner (AKA. we don’t have anyone to tell us what to do)
If you switch to Kanban, you will still be a distributed team and you will still have similar problems. Kanban will only help with some of the rituals, but won’t magically solve all issues for you.
In certain situations, Kanban might be even harder to implement with a distributed team, as it requires much more dynamic team collaboration (to keep the WIP limits under control).
There are many examples of decent Scrum implementations in a distributed environment. This is not a good enough reason to abandon Scrum.
We are a distributed team(AKA. we don’t want to depend on the guys overseas)
THE RIGHT MOTIVATION FACTOR TO MOVE FROM SCRUM TO KANBAN...
Optimizing your current workforce is the only constructive argument that you can and should use to switch to Kanban.
Anything else would be wishful thinking and beating around the bush.
We want to improve our efficiency and deliver more(AKA. we’ve got hell of a lot to do, but we can’t afford to hire all the people we need)
WHAT CHANGES DOES KANBAN REQUIRE?
One of the fundamental changes that comes with Kanban is the absence of iterations. With Kanban, you take care to work on as few things as possible, drive them to completion and then start new ones.
There is no final goal or final deadline. People constantly produce goods and then through a certain period of time (Takt) the customer gets what has been produced.
A typical example is a SaaS company. Engineering works on many features in parallel and, at the end of the week/month, the features that have been completed are deployed on production.
Takt is defined as the rate at which customers accept the goods you create for them.
Replace Sprints with Takt
Instead of planning the entire release, plan just as much work, as is needed to keep people working and not being idle.
This approach can be labeled as Just In Time Planning. Only plan when someone is available to work on a given task.
This approach gives you the flexibility to change priorities as you go and not waste the time you’ve used to plan, estimate and refine the features that got dropped off.
This approach can generate significant economic benefit, because the organization is much quicker to respond to the actual customer demand.
Plan and refine as few work items as possible
If you ask people to commit to a whole sprint, this means that the entire sprint has to be estimated and all details have to be known.
Unless people know all the details, they will not be willing to commit to a sprint, or quite often, they will under-commit.
Only ask people to commit that they will finish what they start, as quickly as possible. That’s all you need.
Do not ask people to commit to more than one thing
Unless you have a really disciplined team, quite often some of the items on the Kanban Board will get stuck. Also, sometimes people won’t be working on the right priority task. That is why you need someone to take care of the Flow.
The Flow Manager is a person with a lot of experience in Lean and Kanban. His/Her responsibilities include asking the right questions and making sure that the process associated with the Kanban Board is strictly kept.
The Flow Manager is there to make sure that work “FLOWS” through the system as smoothly as possible, whatever that means in a given context.
Replace the Scrum Master with a Flow Manager
One of the things that does not work as well in Scrum is the retrospective meeting after each sprint. Quite often, people are not interested in participating and only wait for the meeting to end.
Having a meeting at the end of the sprint somehow creates the mentality that improvements should be an afterthought. Also, any inefficiencies that might have been made apparent are not addressed right away, because people know that the retrospective is after the sprint.
Improvements and inefficiencies should be reported and tackled on the spot. That’s how you can create the culture of continuous improvement, which is one of the fundamentals in Lean/Kanban.
Replace the retrospective meeting with many frequent smaller meetings
The first practice in Kanban is to visualize your workflow and the work flowing through it.
Many Scrum teams are already doing this, but many are still not there.
Visualization allows teams to constantly monitor where things are and pay attention to the right items at the right time.
Visualize your workflow
Limiting the work in progress is a crucial element of implementing Kanban. Unless you are limiting the amount of work being tackled, you are missing a great improvement opportunity.
The sprints in Scrum naturally limit the work in progress, because you are not allowed to work on anything outside the sprint plan, but you can apply WIP limits on the workflow level too.
Implement WIP Limits
Applying WIP limits on the workflow level prevents the team from starting too many things at the same time and ensures less context-switching, which naturally leads to higher efficiency.
Implement WIP Limits
Queues are states in your workflow in which the work items “wait” for something. Between 50% and 90% of the time items spend “In Progress” is a result of their waiting in queues.
Map queues and activities
Visualizing queues on the Kanban Board and managing their WIP limits strictly make it possible to shorten the cycle time dramatically.
Paying attention to queues educates people that waiting states are extremely damaging to your process and they should gradually start depleting the queues with higher priority.
Map queues and activities
One of the most important metrics in Scrum is velocity. However, velocity is really hard to improve, because it reflects the capacity of the team and nobody has a recipe for how to improve a team’s capacity directly.
One metric that can be improved by decreasing the time spent in queues is “Lead time” or, also referred to as, “Cycle time”. This is easily achievable when strict WIP limits are configured for all queues in the workflow.
In other words, by measuring and improving the Lead and Cycle times in our systems, we can easily affect its throughput. This relationship has mathematical proof (known as Little’s Law):
Avg. Cycle Time = Avg. Work in Progress / Avg. Throughput
Measure Lead/Cycle time and not velocity
The most popular analytical artifact from Scrum is the burndown chart. While it helps to demonstrate the current sprint progress, it is of questionable value for each consecutive sprint.
Replace burndown charts with cumulative flow and cycle time charts.
With the cumulative flow diagram in Kanban you can track how your progress changes historically and you can quickly spot deviations or negative trends.
WHICH SCRUM RITUALS ARE A GOOD IDEA TO KEEP?
This is by far the best ritual coming from Scrum. The daily stand-up is a great way to keep everyone in the team up to date with the latest news and exchange information.
A nice trick to having everyone appear on time is to set the meeting for a somewhat odd time, e.g. 09:03 or 10:08.
Daily stand-up meetings
If you happen to have a really long Takt time (more than a month) then it is still a good idea to demonstrate your work to others as frequently as possible.
If possible, schedule unofficial, intermediary deliveries, so that your customers can provide feedback before it’s too late to implement changes.
Regular demos or deliveries
WHAT TOOLS EXIST TO SUPPORT THE TRANSITION?
Perhaps the best way to start your Kanban implementation is to use a physical Kanban Board. This is how you can visualize all work and see if something gets stuck.
The physical board is also a great tool in front of which to host your stand-up meetings. That’s how you make sure that the team will update the board at least once a day, which should be more than enough in the beginning.
Physical Kanban Boards
Mature teams quickly outgrow the physical Kanban Board and eventually need a more automated way to manage their work and collect metrics without too much manual work.
In the past couple of years, a few Kanban Software Tools have evolved to address all these needs in a flexible and effective way.
The three best Kanban Software Tools on the market today are:Kanbanize, LeanKit, SwiftKanban
There are many other visual management tools such as Trello, but they lack the sophistication required by a high-performance team truly embracing the principles of Kanban.
Kanban Software Tools
WHAT IS THE EXPECTED BENEFIT WHEN GOING TO KANBAN?
Implementing Kanban can quickly gain you over a 30% improvement in your cycle time metrics.
It is quite common to see improvements of 200% - 300% and sometimes even 700%.
Such improvements in cycle times result in increased capacity and throughput, which can easily double.
At least 30% shorter cycle times, but improvements may go as high as 600-700%
Sometimes, teams that work on Scrum will refuse to take any new assignments during the sprint. This may result in business losses or broken plans.
In Kanban, you can reprioritize any time, as long as you keep one simple rule:- What goes into In Progress must get to Done. Only then can you take on a new task.
This flexibility is extremely valuable in dynamic contexts with low predictability.
No Broken Plans and Greater Flexibility
In Scrum, it is easy to see the principle that “Work expands so as to fill the time available for its completion”. This hurts productivity.
In Kanban, there is no time allocated for a given task or a given sprint, which makes it impossible for work to expand. If it does, the cycle time metrics will show it and measures can be taken.
No Instances of Parkinson's Law
