Kanban Ideas

We have been talking about Kanban a bit lately in other venues.

Let’s talk about some key Kanban ideas in Scrum.

1. Do the most important thing first.

In Scrum, we want the Product Owner to order the work (the PBIs or User Stories) mainly by Business Value.  (Yes, I talk about ‘ordered’, but this is mainly Business Value looked at from the ‘right’ time dimension, not, ‘do the low BV things first.’)

2. Pull

In Scrum, work on things that the Team has ‘pulled’ into the Sprint.  Also, we don’t do what we want, and hope it will sell.  We don’t create ‘excess’ inventory.

Is this perfect?  Well, no. The ideal is the PO has received an order from ‘the customer.’  This varies by business and  product.

At least the PO, on behalf of the customer, says he wants it.

3. Flow

When played well, Scrum has flow for each story. Anytime flow is stopped, as shown by the Scrum Board, then that impediment (lack of single piece continuous flow) should be fixed.

It is true that flow stops for the 15 minute stand-up each day.

How does Toyota do it?  Toyota (Taiichi Ohno) says that the Team must be in sync. As in crew, they must row in sync. That’s his metaphor.  Scrum has the same concept, in part, as shown in the Daily Scrum.  Toyota does not have ‘every single minute’ flow. In fact, Toyota is famous for ‘stop the line’, to fix a defect.

Note that sometimes in ‘software Kanban’ there is no Team. This is quite contrary to what Taiichi Ohno taught.

So, Toyota and Lean are very mindful about when to have flow, and when to sacrifice flow for other values.

Using a Team that is in sync also enables greater flow. Example: If one person is stuck in any way, the other teammates are there to help. They have every incentive to help, since they want the team to ‘win’ or be successful.  The team concept increases the flow.

4. Minimize WIP

It is good for everything and everyone to minimize Work In Process (WIP).

Scrum does this first by saying, one product backlog to one Team.  The Team should choose what goes in the Sprint; the top items from the Product Backlog. Choose items  that can be confidently completed in a Sprint, whatever the Sprint length might be.

Some of the reasons for using a Sprint Planning Meeting are…
(a) to minimize disruptions during the Sprint,
(b) to see the inter-connectedness of pieces of work, so the Team can choose stuff that is reasonably inter-connected, to maximize the feedback at the end of the Sprint in the Sprint Review (demo). (We always get feedback…many reasons), and
(c) to allow ‘chaos’ in the beginning of the Sprint, with a possible change of direction

This last one allows and encourages a serious re-think about the whole direction of the product. We want significant mid-course corrections.  In part, based upon the feedback at the Sprint Review.

In addition, Scrum uses the Scrum Board to minimize WIP. Only the top story (PBI) or two should be in progress (WIP) at any one time. If a story gets stuck, we can put it down, and pick up the next most valuable story.  In any case, we minimize WIP.

***
I am quite impressed with all these Kanban ideas already in Scrum.  I will try to explain them more later.

Also, we can discuss how we might change the Scrum Board to be a slightly different Kanban board. (The standard Scrum Board is a kind of Kanban board.)

 

« « Waterfall meets Disciplined Agile || The ScrumButt Test » »