Indeed Kanban also has a focus on predictability and planning. During Kaizen meetings (the equivalent of Scrum's Sprint Retrospective) predictability is one of the key metrics to analyse.
Since both are Agile methodologies, both have these characteristics.
Kanban gets a lot of material from Lean methods. I agree with you that Kanban has a strong focus on the workflow due to the Lean background.
Scrum is great when a team has a product and is discovering as it goes. Due to the built-in feedback loops (sprints).
However in more political environments, in contexts where the team loses autonomy and there are more bottlenecks in the process, scrum starts to fall behind. Kanban here does better (in my opinion).
Oh, in many companies, Scrum seems to be the standard choice. But Kanban has many benefits. I have switched teams from Scrum to Kanban and they were quicker, more adaptable and happier. It all depends on the circumstances.
Nice piece! I like how you are transparent about the possible advantages and challenges with Kanban.
I'm definitely more experienced in Scrum so I might have a bias for that, but I once made the mistake of letting go Kanban for too long (as I inherited a team) when the project needs (and the team maturity at the moment) were a better match for Scrum.
I guess it's a matter of understanding your team and the project you are working on. When that's clear, being flexible about what methodology can be a better fit becomes much easier.
I agree with you since choosing the methodology is very much context-dependent. I was introduced to Kanban in an environment where the company was struggling to implement Scrum on several teams. Funny enough I am now biased towards implementing Kanban, especially on established teams. Kanban has proven to have more successful implementations, however, Scrum is still the kind for prototypes and making way for new products.
This is a great post Arthur thank you so much for sharing. I am a big fan of Kanban as I have found it more practical to implement vs Scrum and we remove the carry over non sense Sprint by Sprint, caused by incorrect Scrum implementations, multiple work injects, severity 1's or priority changes during the sprint which is what a team faces the time and here Kanban does way better.
A couple of questions, how do you calculate and adjust WIP limits over time?
I start with 1.5 times the size of the team and distribute it across the columns based on lead time but is there a tip that you could provide?
On the Kaizen ( Retro calls) how frequently you have them? Is there a particular format you follow ?
I typically define WIPs on columns where the team is completely autonomous. The famous ones are "Doing" (or Development) and "Code Review". For the Doing, it starts the same as your example (1.5x team size). With time, the sweet spot becomes around 1.2x. But this only happens with time, when our workflow is improved and streamlined. The "Code Review" tends to be half (or even less) to make sure there is no bottleneck here. The goal is to teach the team when pushing a story for code review, to check the board and advance other stories, or even perform a colleague's code review. This last part took months to streamline for several reasons (Deadline rush, colleagues having different levels of code reviewing and feedback, colleagues wanting to become more expert in some areas than others, etc.). For testing columns, typically the E2E (End to End) doesn't have WIPs due limitation of dependency on external teams, but if the team is performing their own UATs, WIP is typically the number of testers plus an extra (this depends on the product and the testing complexity).
For the Kaizen meetings, the bare minimum I set is one per quarter. But this depends on the team and product. If I were to start a new team with Kanban I would implement each every 1.5 months and pass to each 2 months, and then each quarter. Depending on the cadency of delivery and how fast the team learns and implements the improvement actions.
For the format, I typically start with the control chart, where we analyze swimlane by swimlane on several metrics: threshold vs rolling average; average time per story, and the std deviation (which indicates the practicability). Then we go for the outliers (good and bad). The majority of the meeting is discussing these outliers and what we could have done better, or what happened that worked so well.
The throughput is also very interesting to see, but I only introduce it to more mature teams. Where the stories are stable in size, and we can compare apples with apples. Otherwise, it will only add frustration to the analysis.
One key rule I have on Kaizen is to identify max 3 action points as a team. And even it's OK to identify 1. Is better to identify a few of them and implement them, than to identify 10 actions and have little to no improvement over time.
How was your introduction to Kaban? What made you curious about the methodology?
Hi Artur Thank you so much for your detailed answer. It is really helpful to me.
I started my journey on Kanban when I randomly watched this video from Eric Brechner https://youtu.be/CD0y-aU1sXo?si=dopOtNCbFwGYRQmT and later I read his book and took two certification classes fromt the Kanban University.
I found Kanban much more flexible, practical and easier to adopt by the teams than Scrum. I have never seen a Scrum implementation as described by the guide, there are too many variables that make this more difficult to implement correctly but I have used Kanban on the other side on multiple projects already with successful results and it is much more accepted by the teams.
I had just been assigned to a new team and some colleagues were saying how bad Scrum was for them and how I could help to bring real improvements.
By coincidence, a new Agile Coach had been hired and we randomly had a conversation by the coffee machine (pre-covid era when everybody was at the office 5 days\week).
He was a strong advocate of Kanban and he explained the methodology. I was intrigued and we scheduled a few more serious meetings later. In a matter of weeks, we decided to go forward with Kanban. It took a few months to realize this was the best decision for the reality of that team.
One additional difference is that Scrum optimizes for predictability and planning, while Kanban optimizes for workflow duration.
Hello Benedikt,
Indeed Kanban also has a focus on predictability and planning. During Kaizen meetings (the equivalent of Scrum's Sprint Retrospective) predictability is one of the key metrics to analyse.
Since both are Agile methodologies, both have these characteristics.
Kanban gets a lot of material from Lean methods. I agree with you that Kanban has a strong focus on the workflow due to the Lean background.
Scrum is great when a team has a product and is discovering as it goes. Due to the built-in feedback loops (sprints).
However in more political environments, in contexts where the team loses autonomy and there are more bottlenecks in the process, scrum starts to fall behind. Kanban here does better (in my opinion).
Artur
Oh, in many companies, Scrum seems to be the standard choice. But Kanban has many benefits. I have switched teams from Scrum to Kanban and they were quicker, more adaptable and happier. It all depends on the circumstances.
Indeed. The context is key.
Nice piece! I like how you are transparent about the possible advantages and challenges with Kanban.
I'm definitely more experienced in Scrum so I might have a bias for that, but I once made the mistake of letting go Kanban for too long (as I inherited a team) when the project needs (and the team maturity at the moment) were a better match for Scrum.
I guess it's a matter of understanding your team and the project you are working on. When that's clear, being flexible about what methodology can be a better fit becomes much easier.
Hello Veronica,
Thank you for your kind words.
I agree with you since choosing the methodology is very much context-dependent. I was introduced to Kanban in an environment where the company was struggling to implement Scrum on several teams. Funny enough I am now biased towards implementing Kanban, especially on established teams. Kanban has proven to have more successful implementations, however, Scrum is still the kind for prototypes and making way for new products.
This is a great post Arthur thank you so much for sharing. I am a big fan of Kanban as I have found it more practical to implement vs Scrum and we remove the carry over non sense Sprint by Sprint, caused by incorrect Scrum implementations, multiple work injects, severity 1's or priority changes during the sprint which is what a team faces the time and here Kanban does way better.
A couple of questions, how do you calculate and adjust WIP limits over time?
I start with 1.5 times the size of the team and distribute it across the columns based on lead time but is there a tip that you could provide?
On the Kaizen ( Retro calls) how frequently you have them? Is there a particular format you follow ?
Thanks!
Hello Edgar,
Thank you for your kind words!
I typically define WIPs on columns where the team is completely autonomous. The famous ones are "Doing" (or Development) and "Code Review". For the Doing, it starts the same as your example (1.5x team size). With time, the sweet spot becomes around 1.2x. But this only happens with time, when our workflow is improved and streamlined. The "Code Review" tends to be half (or even less) to make sure there is no bottleneck here. The goal is to teach the team when pushing a story for code review, to check the board and advance other stories, or even perform a colleague's code review. This last part took months to streamline for several reasons (Deadline rush, colleagues having different levels of code reviewing and feedback, colleagues wanting to become more expert in some areas than others, etc.). For testing columns, typically the E2E (End to End) doesn't have WIPs due limitation of dependency on external teams, but if the team is performing their own UATs, WIP is typically the number of testers plus an extra (this depends on the product and the testing complexity).
For the Kaizen meetings, the bare minimum I set is one per quarter. But this depends on the team and product. If I were to start a new team with Kanban I would implement each every 1.5 months and pass to each 2 months, and then each quarter. Depending on the cadency of delivery and how fast the team learns and implements the improvement actions.
For the format, I typically start with the control chart, where we analyze swimlane by swimlane on several metrics: threshold vs rolling average; average time per story, and the std deviation (which indicates the practicability). Then we go for the outliers (good and bad). The majority of the meeting is discussing these outliers and what we could have done better, or what happened that worked so well.
The throughput is also very interesting to see, but I only introduce it to more mature teams. Where the stories are stable in size, and we can compare apples with apples. Otherwise, it will only add frustration to the analysis.
One key rule I have on Kaizen is to identify max 3 action points as a team. And even it's OK to identify 1. Is better to identify a few of them and implement them, than to identify 10 actions and have little to no improvement over time.
How was your introduction to Kaban? What made you curious about the methodology?
Artur
Hi Artur Thank you so much for your detailed answer. It is really helpful to me.
I started my journey on Kanban when I randomly watched this video from Eric Brechner https://youtu.be/CD0y-aU1sXo?si=dopOtNCbFwGYRQmT and later I read his book and took two certification classes fromt the Kanban University.
I found Kanban much more flexible, practical and easier to adopt by the teams than Scrum. I have never seen a Scrum implementation as described by the guide, there are too many variables that make this more difficult to implement correctly but I have used Kanban on the other side on multiple projects already with successful results and it is much more accepted by the teams.
Whenever I can I recommend to try Kanban.
Do you have a similar experience?
I have a completely different experience.
I had just been assigned to a new team and some colleagues were saying how bad Scrum was for them and how I could help to bring real improvements.
By coincidence, a new Agile Coach had been hired and we randomly had a conversation by the coffee machine (pre-covid era when everybody was at the office 5 days\week).
He was a strong advocate of Kanban and he explained the methodology. I was intrigued and we scheduled a few more serious meetings later. In a matter of weeks, we decided to go forward with Kanban. It took a few months to realize this was the best decision for the reality of that team.