Kanban - Daily Standup's and Other Meetings?
Hi, I know i am posting a questions which might be discussed before so apologies. Please do guide me to the right discussion in that situation.
I read this in the ProKanban, that Daily Standup and other events are not required / Mandatory in Kanban. "There are no required meetings/cadences in Kanban, There are no mandatory cadences in Kanban"
However the Kanban Guide states that :
1. " The Kanban complementary practices don’t invalidate the need for Scrum’s Sprint. The Sprint and its events provide opportunities for inspection and adaptation of both product and process."
2. "The flow-based perspective of Kanban can enhance and complement the Scrum framework and its implementation".
I cannot imagine Kanban's implementation without having the Scrum Roles and Scrum Events in place. Agreed that "Kanban practices can help Scrum Teams improve flow and create an environment where decisions are made just-in-time throughout the Sprint based on inspection and adaptation" but that does not take away from the fact that the team should have Scrum events. Please help me understand this better.
Scrum is intended for use in complex environments; this is not necessarily the case with Kanban. However, if a Kanban strategy is to be applied in a complex situation, then the Scrum Framework may be of benefit. Its various events, cadences, and other elements will help complexity to be brought under control.
Kanban is a very overloaded term. In its original use, Kanban isn't a product development framework or methodology, but a tool that can be incorporated to help with just-in-time flow. From its use in manufacturing, it's expanded to a more generic way to visualize the state of work within a workflow. Much later, David Anderson created the Kanban Method, which is a set of principles and practices for helping organizations understand and improve their way of working. Even more recently, Scrum.org created and continues to maintain the Kanban Guide for Scrum Team, which introduces some additional strategies for flow of work on top of the Scrum framework. Given all of these uses of the word "kanban", it's important to understand what you mean.
Prior to this post, I wasn't familiar with ProKanban. I took a quick look, it seems like it's closer to techniques for visualizing, monitoring, and managing workflow than a framework or practices for developing practices. I also see that Daniel Vacanti is involved in ProKanban, and he is also an author of the Kanban Guide for Scrum Teams. It looks like the Kanban Guide for Scrum Teams takes the approaches supported by ProKanban and layers them over the Scrum framework. This makes it true that, in Kanban as defined by ProKanban, there are no specified meetings or cadences, but this becomes false when Kanban is layered on top of Scrum.
I'm not sure why you can't imagine Kanban without the Scrum Events. There are plenty of processes and methods that don't have the Scrum Roles and Scrum Events. But consider that Kanban is, at its heart, a just-in-time and continuous flow approach to work. Instead of having a Sprint cadence that starts with a Sprint Planning, has a Daily Scrum every day, and ends with a Sprint Review and Sprint Retrospective, consider a process where you plan when you need to, meet when you need to, collaborate with key stakeholders when you need to, and inspect and improve your way of working when you need to. The same things probably happen, but at different regularities or schedules that may or may not be consistent over time.
I cannot imagine Kanban's implementation without having the Scrum Roles and Scrum Events in place.
A good example of where Kanban is used without some of the Scrum events is with a production support team, working on triaging and fixing issues. Imagine trying to have Sprint Planning without knowing what problems will surface each day?
Thank you so much for the explanation Thomas!!. Thank you Chris and Ian!. This i think should go in the Kanban Guide. :)
"This makes it true that, in Kanban as defined by ProKanban, there are no specified meetings or cadences, but this becomes false when Kanban is layered on top of Scrum.
I'm not sure why you can't imagine Kanban without the Scrum Events. There are plenty of processes and methods that don't have the Scrum Roles and Scrum Events. But consider that Kanban is, at its heart, a just-in-time and continuous flow approach to work. Instead of having a Sprint cadence that starts with a Sprint Planning, has a Daily Scrum every day, and ends with a Sprint Review and Sprint Retrospective, consider a process where you plan when you need to, meet when you need to, collaborate with key stakeholders when you need to, and inspect and improve your way of working when you need to. The same things probably happen, but at different regularities or schedules that may or may not be consistent over time."
Sidharth, I think Chris, Ian and Thomas provided ample explanations I fully agree with.
All I'll say is that these two guides take two different stances on purpose:
- The Kanban Guide over at ProKanban aims to focus purely on Kanban. It doesn't limit nor specify what complementary practices (such as Scrum roles, events, artifacts) a practitioner might use together with Kanban. This is a similar stance to the one taken by the Scrum Guide that doesn't include complimentary practices just the core framework.
- The Kanban Guide for Scrum Teams gives guidance for how to combine Scrum and Kanban effectively so of course in this sort of context Scrum applies in its entirety including the Daily Scrums.
HTH
Yuval
Thank you so much for the explanation Thomas!!. Thank you Chris and Ian!. This i think should go in the Kanban Guide. :)
This is in the Kanban Guide.
There are two "Kanban Guides". There's the ProKanban Kanban Guide, which just describes Kanban. Then, there's the Kanban Guide for Scrum Teams. The Kanban Guide describes Kanban outside of the context of Scrum (or any other methodology), which does not require anything to happen at a particular cadence. When you layer Kanban on Scrum, you would refer to the Kanban Guide for Scrum Teams, which does not change Scrum. The cadences for events are derived from Scrum, not Kanban.
Although I haven't thought about it, you could probably make a Kanban Guide for XYZ Teams, where XYZ is a different methodology, like DSDM or Extreme Programming. The roles, events, and cadences would be inherited from these other methodologies, with the visualization of the workflow, management of the workflow, and metrics coming from Kanban.
Thank you so much Yuval and Thomas! Your explanations will go a long way for all of us!