Kanban vs Scrum Myths and Hype– Guest Post

by Michael DePaoli

It is my pleasure to have Michael DePaoli contribute articles to my Agile blog.  Michael comes with rich experience in IT  and the detailed bio is at the end of this article. Happy reading.

Recently, I heard folks at a few of my clients and at a couple conferences talking about why they are considering moving to using Kanban vs. Scrum. I have no preference to either method other than choosing the right agile development tool for the job.

My concern derived from what I have heard identifies the beginnings of some myths and also demonstrates some of the hype around Kanban. 

First, a clarification;
>> Kanban with a capital (K) is the term David Anderson coined with respect to an agile development approach to driving change based on lean principles.

>> Kanban with a little (k) represents the idea of the “sign” or “billboard” that provides the signal/visibility in a production line for additional demand for service of a particular station.

It is one of the tools that enables just-in-time (JIT) action as described in the Toyota Production System.

Kanban, as Anderson explains in his book, relies on change occurring in more of an optimizing manner (see kaizen culture).

David Anderson's Kanban book

This is the significant difference between Kanban and Scrum. In a Kanban approach, an organization can begin with their current practices with a few exceptions.

Kanban requires:

A high degree of visibility into the state of all work queued and in progress

Absolute respect for WIP limits

A commitment to execution in a ‘pull-based’ manner from the prioritized work queue

Kanban also demands a focus on quality. In fact, this is Anderson’s first step in his six-step recipe for Kanban. Quality comes first primarily because of the obvious cause-and-effect relationship to waste — and because it’s generally more in the direct control of technical management. Working down his recipe, there tends to be less control and influence over the changes by technical management.

Now for the Myths and Hype

Myth: 
>> Scrum has work pushed onto the team while in Kanban work is pulled into the system. This is incorrect. Scrum does not have work “pushed through the system.” It is a pull-based agile development system with work pulled in larger batches (the Sprint Backlog).

>> A Scrum implementation (as well as Kanban) becomes a ‘push-based’ system when the business doesn’t respect the current proven capability of its teams to produce value and just continues to push demands for service into the system.

Doesn't just apply to

>> Kanban

Hype: Kanban at its core is summarized by the premise: ’Stop Starting, Start Finishing’. The entire team’s focus is on ‘getting to done’ for the tasks in progress. This statement is certainly true of Kanban, but the implication that Scrum does not have this focus is not true. Scrum done right has the same focus, delivering software sooner and doing so in priority order to maximize the value delivered to the customer. I’ve coached to Scrum teams for years that, wherever possible, everyone on the team should work on the highest priority item and get it done first before starting on the next item in the Sprint Backlog. This implies limiting WIP, as well as focusing on delivering the Backlog in rank order.

If the focus of a Scrum team is to just get everything in a Sprint Backlog into an in-progress state, regardless of priority, then you have a dysfunctional team that’s most likely not working cross-functionally and certainly not focused on delivering the highest-value items first.

Hype: The statement, “The Kanban method is intuitive and is quickly and easily adopted by teams,” to me is a statement that’s used irresponsibly. It is too often a battle cry of those trying to sell Kanban as a product. It is the cop-out reason used by many organizations who are failing at Scrum and looking at Kanban.

Author Bio :

Over his 26 years in IT, Michael DePaoli’s experienced has included serving in different traditional roles in highly respected companies. The roles have included analyst, software engineer, quality engineer, development manager, project manager, Director of Engineering, VP of R&D, CTO and Consultant in companies, such as American Express, Sprint, Deloitte Consulting, Sapient, Knowledgepoint, Adobe Systems, AOL, NetApp and VersionOne. Michael works as an agile / lean coach and product consultant with the VersionOne services group.

Scrum Smells - Rarely Quoted

We  know the popular Scrum Smells  like

1. Scrum meeting with a  large team
2. Scrum Master assigning tasks to the team members
3. Velocity being used to measure the productivity of team, etc

However, following 4 are rarely called out in open forums even though they are like elephant in the room.   

They are
1. Hierarchy: Product Owners considering superior to the team (specifically Business Analysts). Consider the existence of a hierarchy here.
2. Business Analysts mostly being used for  typing User Stories
3. Agile coaches considering them as superior human beings as compared to the rest of the team. Basically, dictating terms and reserving the right to answer questions from team members. 
4. Software Services vendor continuing to call “Customer as King” but not directing the King in the right direction by pointing mistakes.

Even though 3 and 4 are not specific to Scrum, they still are relevant.

Productivity is not equal to increased Profit

Have you ever been part of a tool selection team ?   Have you proposed procuring any new tool to your supervisors ?


Image: John Kasawa / FreeDigitalPhotos.net

I have done this many times. I have been part of  such tool selection committees.  Most of  the times we as developers are impressed with the new tools for many reasons.  The reason for falling in love with a tool could be because of :
1. Ease of use,
2. Stability,
3. More features,
4. Better communication, etc

All the above reasons are valuable, and in addition I have seen most commonly quoted reason being "Improved Productivity".

Let us discuss more on this subject. If the tools getting procured are going to have an impact on multiple groups, one should look at impact of productivity in one group on the other.
Let us take a fictitious  example of Product owners procuring a tool that can generate User Stories with a click of a button.  Product Owners are now productive, and they have increased generating User stories by >20%.   What if we don't have similar tools at developers end to churn out these stories ?
These generated user stories would go and sit in the backlog  as inventories, which are wastes.


One should be cognizant of the fact that Improved productivity may not  increase in the bottom line. In fact, it might cause bottlenecks and increase in inventory.


One of the key things to ensure improved productivity is by limiting the work in progress (WIP).  If a tool that is getting procured is going to affect WIP, it has negative consequences on the system.

Whether the tool is a high resolution communication device or a simple document repository one, the stakeholders shouldn't get carried away only looking at productivity.   If the stakeholders intent is long term investments, they should look at the impact on their bottom line.  Tool selection might increase productivity in one corner of the organization but might impact the bottom-line at the other corner.

Summary: Tools are important for the organization. During tool selection process, improved productivity shouldn't be the driver for new investments.

Agile Teams to Avoid

Recently  received a request from  SmartBear  representative to share  one of  Infotoons created by their team with the Agile World blog readers. 

Here you go..