Continuing with our theme of facilitating Scrum and Kanban, we’re honored to publish another guest blog post by Dave White on ‘Kanban and Scrum Together – Not So Fast’. In this blog post, Dave has shared his thoughts on the article ‘Kanban and Scrum Together’ written by Steve Porter. Hope you enjoy reading it!
KANBAN AND SCRUM TOGETHER – NOT SO FAST
A colleague of mine who works at Scrum.org now posted a blog about how Kanban and Scrum are stronger together. Steve Porter had this to say in his blog post…
Kanban and Scrum – Stronger Together
You might find my comment there, here it is again…
I’ve been sitting with this tab open for a month, trying to decide what to say. I felt like it was time to close the tab by providing my thoughts. To be clear, I’m speaking about The Kanban Method when I use the word kanban and I believe that is what this article is talking about when it says Kanban and Scrum are stronger together.
Part of me is disappointed with the misconceptions of what Kanban is and how it can be applied as demonstrated by the comments.
1) Hiren Pandya: … the requirements needed to transition to kanban.
Dave: Anyone can begin transitioning to kanban at any time because of the lack of prescription of “the one” kanban approach. Kanban has a natural and specific mindset that accommodates the current state and an evolutionary path to maturity, of which we are all at different points in our journey. Honestly, transitioning to kanban is as simple as changing the label we use to describe our mindset and values.
Dave: The problem with this statement is that any approach that is open to adding/removing practices as their value to the team changes will create a hybrid solution. Kanban by its very nature creates hybrid solutions as teams take tactical practices from anywhere they choose to enhance the way they deliver value to their customers. The kanban value system openly embraces the concept of taking practices from anywhere that might improve your team/organizations ability to deliver value to customers. It has to accept all practices with respect.
Regarding cadences not being constraints, I would posit that a Replenishment meeting with a cadence of 2 weeks is exactly the same kind of a time-bound constraint as a Sprint Planning meeting that happens every 2 weeks. Practically, they are equivalent constraints.
Dave: This seems to be a reinforcement of the myth that Kanban is for Type A teams and Type B teams shouldn’t use it. Which is a myth.
After reading your article, and the comments, it makes me wonder why people think that a team couldn’t implement a fully “Scrum” set of practices and processes and name it Kanban. It is 100% possible to do that. I don’t know that the opposite is true, in that a team would fully implement a kanban system and call it Scrum. Kanban allows for far more variation than the Scrum guide does.
Thank you and Dan for stepping forward and taking on this challenge.
Steve kindly responded with some questions..
if you can truly transition to a Kanban system as easily as you described
and
if you’re not limiting WIP, you’re not implementing a Kanban system
I responded with this –
Dan and I have had great conversations about WIP limits. Last time might have been in Germany over cocktails, but it was a great conversation.
There are many ways to limit WIP. I, and probably Dan too, would actually probably prefer to call it an optimal WIP policy, but if we are speaking only about limiting WIP, there are different kinds of policies along the maturity curve that we can use to limit WIP, all with different pros and cons that are discovered as we go. We choose which of those policies to start with based on organization emotional resistance and education/experience, all the while understanding that we are using this first policy as a starting point and we expect it to change, sometimes frequently, as information about team workflow evolves. Some possible policies include…
- A Sprint backlog is a WIP limiting policy.
- Stating everyone can work on 2 things at a time is a WIP limit policy.
- Keeping a flow efficiency number high is a WIP limiting policy.
- Canonically, a number at the top of a column on a kanban board is a visualization of an explicit WIP limit policy.
So while I speak about limiting WIP, I don’t necessarily write a # on the kanban board until the team discovers the problem with the # not being on the board, then we decide what to do about it. If I recall correctly, Dan always puts a # on the board, but makes it high enough that there should be no emotional resistance to it, and then he starts talking about lowering it. I think both approaches have merit.
About ‘no WIP limit == no kanban system’, generally speaking, I’d state that you have an immature virtual kanban system if you don’t have pull-based work scheduling mechanics in play to manage the flow of work. This is subtly different than saying if your not limiting WIP, you’re not implementing Kanban.
I’m presenting all of this for a couple of reasons.
- I don’t like being censored
- It is, imho, really important for the community to get access to all of the information
If someone is going to present two competitive concepts and state that they shouldn’t be competitive, that is great. And I’ve stated that Kanban and Scrum should not be seen as competitive and incompatible.
But if you are going to explore the merits of each concept and allow for the continued misunderstanding of an either of those concepts in your dialog, you’re biased and doing a disservice to the community.
Please check back soon for my exploration of each comparison that arises as we follow Steve’s series of posts.
This article was originally published on western devs blog and can be found here– https://westerndevs.com/Kanban/Kanban_and_Scrum_Together/
Read the next Post in the series: Nothing in Kanban Prevents Scrum
