Kanban as a tool

Myths and facts about using it.

So many times I’ve heard that Kanban is a framework or that if you are working with Agile teams you either use Scrum or Kanban. Now, I cannot be happier to say that both statements are more than wrong.

So let me clarify something, the meaning of the word Kanban is “signboard.” And yes, of course, the signboard (Kanban board) and the method (Kanban method) were created at Toyota and within the Lean parents.

Now you might be thinking, “why the title says Kanban as a tool?”. Well, throughout my experience working in the Agile world with different kinds of teams (IT, Marketing, HR,etc) I realized that the Kanban board (as a tool) helps visualize your current state, thus making it easier to find a way to improve it. You don’t need to modify anything or start adding weird words or strange ceremonies for people that are not familiar at all with Agile.

The second question you might have at this point is… and what does Scrum have to do with Kanban? Well, as I was saying, Kanban in its literal translation means signboard, and Scrum is an agile framework that adopted the best practices from different frameworks like user stories, code review, pair programming, and even the board. You will not even find in the ScrumGuide how to set your board.

Signboards

During our baby steps through Scrum we all might have seen and used the common (and basic) board with only 3 columns: “ToDo”, “Doing/InProgress” and “Done” (Fig 1). But let me say something, if you want to take a step forward with your team, it’s time to refine that board in order to track the current states/phases your team’s work goes through so everybody can properly suggest the best way to improve the workflow or how to resolve any bottlenecks you might have.

Most dev teams usually go through these states: “ToDo, In Progress, Code Review, Merge, Ready for test, In Testing, PO Review, Done”

In this example we can see that most of the work is already in the “In Testing” phase. So one suggestion (and the main reason why we have cross-role teams) that your team would make should be, “Let’s help our QA guys so we can close most of the user stories before the sprint or iteration ends”.

We need to explain to our teams that instead of opening more user stories, it’s much better to start closing what we already have on the way.  A half finished story is not finished at all.