POST

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 first comment there if someone at Scrum.org approves it in the pursuit of open and shared discussions.

Update The comments have finally been approved.

Since it hasn't been approved at the time of me writing this blog post, here it is again...

Hey Steve,

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.

Let me start out stating that I believe that teams and organizations need to be better at addressing customer demand. That pressure is what drives organizations and teams to adopt a 'process' that they think will help. We would call those processes Scrum and Kanban and that is probably the first point of failure. It is unfortunate that these processes are seen as incompatible and I applaud your decision to try and change that thinking. It isn't the practices that are incompatible, but the religions that sprout up around the organizations that evangelize the processes.

Part of me is disappointed with the misconceptions of what kanban is and how it can be applied as demonstrated by the comments. Going through some of the the comments, I see...

Hiren Pandya ... the requirements needed to transition to kanban.

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 describe our mindset and values.

Bruno Baketarić Create hybrids: Beware! --and-- along with an absence of time-boxes or any other time-bound constraint (the Kanban cadences are not constraints).

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 it's very nature creates hybrid solutions as teams take tactical practices from anywhere they choose to enhance they 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 time-bound constraint as a Sprint Planning meeting that happens every 2 weeks. Practically, they are equivalent constraints.

Mark Chapman I don't quite get what the point is here, they have different uses for different teams.

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.

Final Thoughts...

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.

I guess in the long run, we are trying to foster collaboration and enhance the strength of our professions by bringing these two communities together, which I think is very noble and the right thing to do. What I would like to see though is a properly educated discussion about where and how they (Kanban and Scrum) are different (or not) so that people can make decisions from how to describe what they are doing.

Thank you and Dan for stepping forward and taking on this challenge.

(I added some Markdown to simulate the Disqus formatting)

Steve kindly responded (without approving the original comment) 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 still considered spam and unapproved comment. Update - The comments have finally been approved.

First of all, I spoke of transitioning to The Kanban Method as being very easy. I didn't discuss the implementation of a virtual kanban system as easy, although in truth, most Scrum teams are already using a virtual kanban system.

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, sometime frequently, as information about team workflow evolves. Some possible policies include...

• A Sprint backlog is a WIP limiting policy.
• A policy of not starting anything new until your current work is done, is a WIP limit.
• Stating everyone can work on 2 things at a time is a WIP limit policy.
• A visual token indicating there is capacity to pull is the visualization of 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.

The problem with WIP policies (and this certainly applies to many Scrum teams I've seen) is that there is usually no penalty for breaking the policy. It is an indicator of bad behaviour if the team violates a WIP limit, but it isn't a law and we acknowledge that sometimes we have to violate our WIP limits due to unforeseen events.

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 reasons.

1. I don't like being censored
2. 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 and incompatible.

But if you are going to explore the merits of each concept and allow for the continued misunderstanding of a 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.