A quick perspective on Kanban and SCRUM (by Pedro Talaia)

In this article I’ll analyze the similarities and differences that both Scrum and Kanban have.

There is a main similarity between Scrum and Kanban, which is that they are both used to product development. And the real difference is the way that you work with them for a final goal.

Every time that we’ve been trying to get our job done, we try to do it well and quick, but 90% of the times we lose track in the middle of it or we have to start from the beginning to understand what we’ve been doing.

It is common knowledge that visualizing the work it is a really good step forward that helps to understand what has been done. But the two better ways to do it effectively are Scrum and Kanban.

First of all, Scrum is way more aggressive than Kanban, mainly, because you have to fragment everything to a sprint backlog (we will learn about this forward), and in Kanban you have to first visualize the workflow and then control the WIP (work-in-progress). This Kanban process happens in a smoother way. The goal is the same but you do it in a different path.

There are 4 key principles for each.

Scrum: Product Backlog; Sprints; Burndown charts; Retrospective;

Kanban: Visualize Work; Limit the WIP; Focus on Flow; Improvement;

As you can see the last and final key principle can be always related with Feedback. Feedback is the best and ultimately better way to improve every job and company. For me it is the best key attribute and it is really simple to apply.

Quickly we’ll go through the 4 key principles of each, just to understand the main idea.

Scrum

Product Backlog

It is where you’ll get everything that you need to get the job done. Mainly where you’ll get the list of desire features and the time that you need to do it.

Sprints

Before each sprint usually it’s held a sprint meeting to see the overall progress of each or to pick the sprint with a deadline that suits better for the work that comes ahead.

Burndown Charts

This is not usually talked about when doing scrum, but for me it is really important to keep track of how the work is going to be done.

The burndown chart is the chart that brings the working hours until the end of a task. This can be seen in the Daily Scrum meetings that will be held before starting the day.

Retrospective

Being able to recognize where the sprint can be improved and how well the scrum is working is a really important key feature that can get the team better and better.

More about Scrum here:

https://www.mountaingoatsoftware.com/agile/scrum/overview

Kanban

Visualize Work

This is a tricky one. There is no key word to this one. Everyone can have a different way of tracking down the processes.

In my table I can just do a To-do and Done list for each of the development processes, and on yours you can add a To-do, Doing and Done. That will change everything. The big thing surrounding this is that you have to visualize it, first because it looks more real if you see it, and second you can better memorize it.

Limit the WIP

The WIP is the key to limit the work that is getting done just like a pipeline. Just keep track of what is being done and if the work is not moving just re-adjust so you don’t stall it anymore.

Flow

First of all you need to understand that you need to collect data to improve the flow of the work. To be smoother and to be more effective.

Improvement

This is a principle that goes hands in hands with the 3rd principle “Flow”. But the final goal is that everyone needs to understand what your KANBAN is and what are you trying to do, what are the main goals that you pretend to achieve, so you can move in to a positive direction and to continue improving this system.

If you want to know more about Kanban you can find it here:

http://www.everydaykanban.com/what-is-kanban/

http://kanbanblog.com/explained/GettingStarted.html

My last thought about this two systems is that both are based mainly on empirical work.

Finally I would like to mention that you can challenge yourself and try to merge both Scrum and Kanban into one. Mainly by using Kanban over Scrum, it works better.

Use it and abuse it, and only that way you’ll see any feedback on your improvement.

Pedro Talaia