Kanban vs Scrum or...?

If you spend any time on the Internet at all you'll see something that goes like this-

Kanban vs. or Kanban Against or Kanban After…

kanban-board@2x.png

I feel like all these are just variations of

“how does Kanban compare to what I do already?”

Okay so remember one of the principles is: Start with what you do now.

  • If you're doing Scrum right now that would work just fine.

  • If you're doing Waterfall that would work just fine.

  • If you're doing sAFE that would be just fine.  

The idea isn't in the How, the idea is are we watching our work in such a way to cause us to improve? How many people have gone to a Sprint Retrospective and it's some variation on:

  • What went well?

  • What didn't go well?

  • What do we want to do differently?

Very very traditional approach, right? Now how many teams that you have you seen actually Implement those changes?

Scrum urges us to look for challenges and label them impediments. Stuff that would prevent us from getting our Sprint Goal done. Now the underlying idea here I think is that what we're supposed to be doing in the course of doing our work is to constantly be looking at the ways that our work is challenged or why we can't do something and it's interesting because a lot of times scrum talks about how to identify those Implement but not necessarily how to fix them. Kanban on the other hand says let's look at the work that we're doing and find the areas of opportunity that let us improve using whatever tools or approaches we want to.

240_F_229541131_zxWwrt14vZl8F7vhHdJyD3ncII391PCr.jpg

One way I like to approach this uses an approach taken from Improv. “Yes, And”

“Yes, And” is a positive way to include in a conversation. In this frame we do Scrum...and. We do Waterfall...and. Kanban provides the model and the ability to predict the effects of change. It shows the areas of opportunity but leaves the type of change to the team.  

So if you'd like to know more we have some upcoming training around Kanban and I'm sure we'll talk about scrum a little bit too check it out here.

How to "DeScale" Scrum- it's not what you think.

How to "DeScale" Scrum- it's not what you think.

This post is the first in a series highlighting the steps that organizations skip when they rush to adopt Scrum. Yet they are critical to “scale” Scrum. The first step skipped, of course, is realizing that the organization doesn’t get bigger- it "descales." A framework for descaling the organization with Scrum described in this series is Large Scale Scrum (LeSS): https://less.works/

Why do so many Scrum Teams “carry over” work from Sprint to Sprint?

Why do so many Scrum Teams “carry over” work from Sprint to Sprint?

What’s intended at Sprint Planning is the break down or decomposition of items pulled from the Product Backlog that the Development Team believes can be completed (that can get to done) during the Sprint. This is called “Topic One” in Sprint Planning or “What can be done this Sprint”?