What Scrum Gets Wrong about Kanban and What Kanban Gets Wrong About Scrum

Great article! But I have some thoughts..
1) Kanban for software as a framework does not exist. at least there is no authentic source like the Scrum Guide which I know of.
2) Evolutionary means believing in incremental improvement, Kanban does try to preserve the existing structure by making a value chain and make change in the workflow.
3) Kanban does not promote 'teaming'. It is task oriented.
4) WIP makes sense when you have small tasks of more or less similar sizes. For innovative software development implementing WIP amounts to making software development a routine, predictable, mundane task.
5) Innovation in Kanban takes a backseat because time-boxing, teaming, creativity do no exist.
6) Continuous improvement, and visualization of work are well covered under transparency, inspect/adapt in any empirical process.
In short, Kanban has become an easy way to keep doing waterfall in disguise because it is politically suicidal to say we do waterfall in many organization.

Ashok, I think you have repeated a few of the myths that Steve tried to debunk here. The primary being that Kanban does not encourage 'teaming'. It is quite the opposite. I would highly encourage reading and watching the work Dan and Steve have done together to see if it changes your understanding of Kanban. You will, hopefully, quickly realize that Kanban is not waterfall in disguise and can greatly help Scrum teams reach the next level in their agile journey.
Cheers!

Ashok, thanks for your comments.

I'm sorry to hear that you've had some bad experiences with Kanban. I have seen some of what you've listed in your comment, but in my case, it was by teams doing a poor job of implementing Kanban. Scrum can be implemented poorly as well.

I will 100% agree that there is no authoritative guide to Kanban. In some ways that's a strength. How Kanban is implemented is very context specific and much looser than Scrum. Without a context, it would be difficult to tell people exactly how to implement Kanban.

My concern is not as much with Kanban as with the people misusing the word 'Kanban' to run waterfall. No metrics, no pressure valves, just free for all development. If there is no authentic guide obviously people will devise their own framework, and mostly they will devise a framework that suits their convenience rather than what is right for the next gen software development.

They don't like Scrum not because of 'meetings', (in fact waterfall was full of meetings) but simply because they don't want time-constraints or commitments. They feel it fails them. Again it is just my observation in last 10 years. Finally it really does not matter if you implement Kanban or Scrum, what matters is how effectively you translate those 12 agile principles into practice.

I agree some people are realizing the importance of team and trying to introduce in their writings. I am not doubting their brilliance but calling that an authentic guide may not be acceptable to everyone. But like I said above agile is not about Kanban or Scrum. It is about implementing those 12 agile principles.

I totally share your concern. People throw stickies up on the wall and say their doing Kanban. It's the same when people hold a standup every day and say they're doing Scrum. I think that's part of the reason I'm been working on building this bridge with experienced Kanban professionals. I want Scrum teams to learn Kanban the right way, so they can maximize its potential beneifts.

These are some great points; it's too bad that they haven't been directly addressed.

Scrum is also often misunderstood and implemented as waterfall with new titles. Fully utilizing the Scrum framework is also an evolutionary process. Introducing Work in Progress limits is certainly revolutionary to many, but not as revolutionary as the paradigm and behavioral changes that truly embracing Scrum requires.

Kanban requires a system with flow. Once that flow is removed with a collaborative, cross-functional, empowered, self-organizing team the benefits are limited. A hardware quality inspection group could benefit from flow-focus in kanban and Scrum would be less effective from them. There are grounds for the "____ is for ____" argument generalities then, as always, it is important to look at context.

As for teamwork, "if done incorrectly" is challenging to accept because, as stated by Mr. Porter, there is no definitive guide. In most organizations, a "focus on the activity/action/work" directly translates to roles. Work in Progress limits only encourage swarming if there is a team mentality, especially from the organization above. That is similar to Scrum challenges.

Sprint Planning can also be a waste of time in Scrum. It can be a challenging mental shift to loosely forecast work with some details for the first bit of it instead of bulk planning or no/weak planning. In a flow based system with specialized roles, it would most likely be a waste unless there were downstream considerations that need coordination or preparation.

Sprints do constrain flow; that is part of the intent: creating a rhythm. It's true that additional items may be added to the Sprint, but it's certainly not flow in the kanban sense.

"Combine actively managing flow with the practice of improving collaboratively, and you naturally end up with cross-functional, self-organizing teams of people working together to deliver value." If a group of individuals can become such a team, the next step is truly collaborating which often reduces the kanban columns to three: To Do, Doing, and Done. This is a goal for high-performance Development Teams using Scrum.

Perhaps one might consider "Essential Kanban Condensed" ( http://leankanban.com/guide/ ) a manual or guide. Though considering almost 100 pages essential and condensed does not seem not so Lean. Condensed review: https://theagileist.wordpre...

Sorry that you feel I didn't address his comments directly. I thought the major points had been covered. A point by point reply can be seen as a bit confrontational, and I'm looking to build bridges. But I think this should summarize things.

1. I agree

2. Just because you start with your existing workflow doesn't mean that the changes being introduced by Kanban aren't revolutionary.

3. I think there are many Kanban practitioners that would disagree. This certainly hasn't been my personal experience, but I'm not trying to discount what you've seen.

4. Same as above. WIP limits provide you focus, which is critical when doing innovative software development.

5. Same as #3. The assumption that Kanban doesn't lead to time-boxing, teaming, and creativity is not one I'd share. Again, I don't want to discount other people's experience with Kanban.

6. Agreed. Both Kanban and Scrum share a lot. Kanban is just more specific in some areas.

I don't want to discount that Ashok has seen Kanban be used in a way to keep doing waterfall. Any process can be done poorly. I would suggest that that's not inherent in Kanban but may be more around the implementations he's seen.

On Kanban not allowing team behavior is a sign of not understanding the purpose of Kanban. The focus is on the card and not the columns. If people stay in their columns, yes that's anti-agile behavior and can be seen in even scrum. Kanban actually exposes that behavior and helps teams retrospect and make decisions to address that.

So if we remember the purpose of Kanban is to visually show the flow and help team talk and address what's constraining the flow and help swarm, we are using Kanban as intended.

Thanks for the article. I agree that both practices can complement each other. However, to make the best use of them, it's necessary to get to know them well. I found an article in which the two methods are compared, check it out: https://kanbantool.com/kanb...

You don't understand Kanban at all.

1. Wrong. Kanban was developed as a pull system with JIT (Just-In-Time) in mind by Toyota. It was written by Taiichi Ohno, and you should look there.
2. No it doesn't. Continuous improvement is the core essence of Kanban and Lean. That you have something like that in Agile now is the result of Kanban (and Lean) revolution.
3. Kanban does promote teaming, it is about cross functionality and different experts being involved at every step of the processing (of anything). That is the main distinction between Taylorism and the Toyota model–cross-functional involvement in each process step of an item.
4. Scrum is already a WIP model. Sprints and estimates per Sprint are typically the WIP limit in Scrum. As you probably guessed it, this approach was also inspired by Kanban, historically.
5. Nope. In Kanban innovation tasks (i.e. SPIKE) are raised by the team and broken down like normal items. Meaning, they are accounted for as a regular item in the WIP, even though each one of these Specification tasks might spit more tasks than one.
6. Word salad.

"In short, Kanban has become an easy way to keep doing waterfall in disguise because it is politically suicidal to say we do waterfall in many organization."

And Scrum became what in most of organisations, I am sorry?

If you don't implement a Pull System (customer pulls Backlog items to progress) and WIP limits , then you can't do Kanban right.