Month: August 2016

In my last post I made a point that Scrum contains Kanban. So let’s look at it from another angle. Let’s see what is the most important aspect Scrum provides and which is missing in Kanban. It’s not about specific roles or meetings. It’s not even about iterations. It’s the purpose driven aspect. In Scrum, we build a Product Backlog, which shall be ordered by business value. It is not meant to be any todo requirement list. It’s a tool which allows us to split the tiny most important vertical slice of functionality, deliver it and get fast feedback from customers.

Product Backlog needs very strong foundation, otherwise the prioritization gets hard or even impossible and you are back at reactive mode we tried to avoid. In Scrum, we want to form a strong clear product vision, and then talk about what we shall deliver next Sprint and form it as a Sprint vision called ‘Sprint Goal’. Only after that we can talk about which items we shall have in our Sprint Backlog.

Kanban, on the other hand, is great for reactive type of work like call center for example. In call center we don’t prioritize up front, we don’t plan big. We only need to visualize our process and improve its overall quality. For such environments Kanban is great match and it is a good idea to use it.

I often get question what is Kanban and if it is better than Scrum. So let us start with explanation of what Kanban is. It’s a very light method coming from ancient Japan and then popularized by Toyota. It has three rules:

• Limit work in progress (WIP)
• Visualize
• Minimize lead time

That’s all. You can start with any process, visualize it and based on what you see improve the throughput and bottlenecks. It’s simple, it works. But you have to be really improving based on what you see. Companies are often going to Kanban because the change required by real Scrum is too painful. So they do some board (you can’t usually see much from it), and say we are done.

Because Kanban doesn’t really help you with implementation and mindset change, Scrum is so successful comparing to Kanban (I’m not saying that Scrum is simple, but the opposite). So if you truly think about the three above principles, you find out that Scrum actually embraces Kanban at many levels. So let’s go one by one.

Limit work in progress (WIP)

In Scrum we have Sprint backlog to fix number of backlog items / User Stories in Sprint.

It’s a common practice to say that each person can work at one task at a time. Once it’s done they can take another one. Two (and more) people can work on one task to make it done faster.

Successful teams work one UserStory at a time. As a team, they take one Backlog Item and finish it. Once it’s done, they take another one and collaborate on it.

Visualize

Sprint backlog is visible, defined, well understood.

Common practice is to have Scrum board to visualize sprint progress and help team members collaborate.

We make our backlog and priorities visible to everyone.

Sprint review shows the done functionality every Sprint.

Minimize Lead time

Sprint Backlog and Definition of Done is here to make sure teams finish working software each Sprint.

Scrum says the shorter Sprint, the better. So most of the teams now have two weeks Sprints and there is strong trend to one week Sprint.

Common Kanban/Scrum misunderstanding

One of the most common misunderstandings and reasons why people choose Kanban and leaving Scrum is that we can’t deliver working software any time during the Sprint in Scrum. We have to wait to the end of Sprint they say. But there is nothing in Scrum which would prevent you from continuous delivery. The only changes you need to do regarding team practices (note it has nothing to do with Scrum itself) is to adjust your definition of done (DoD) by adding “running on production server” and let team to work ‘one Story at a time’ so they deliver done functional stories one by one. Any time during the Sprint they are done with that story (done means it’s according to the DoD) the functionality is already at the production. Simple and straightforward 🙂 right?

So all around, there is no reason to leave Scrum. By the way, if it’s not fun to be Scrum, it’s most likely not Scrum, so inspect and adapt the way you work. If you are looking for some useful tools how to make it working and how to make it more fun, you can check my new book The Great ScrumMaster.