When flow gets interrupted or gets a hiccup and it stops. It just seems like it never gets going again. But part of that, I always think about has got to do with having it ready in the queue, and having it ready to be processed. You talked about managing the queue. Is that similar to… to a scrum backlog?
Related Podcast and Transcription: Kanban Lessons from Anderson
Excerpt from the Podcast:
Joe: I think it definitely could. There’s one other item that I would like to address. It’s something that I’ve always struggled with and I’ve read different things on it. It’s really about when you manage the work and process, it’s about flow, and flow is about having everything in place and being able to do it. Once you start it, then you can finish it.
When flow gets interrupted or gets a hiccup and it stops. It just seems like it never gets going again. But part of that, I always think about has got to do with having it ready in the queue, and having it ready to be processed. You talked about managing the queue. Is that similar to… to a scrum backlog?
David: Oh, for sure, yeah. There’s whatever is off to the left hand side of the board that you don’t see. And in general, we try and discourage putting a lot of energy onto the backlog. There’s maybe a couple of things that I talked about in the book, the idea of going through the backlog and deleting items which are considered no longer relevant; we see some companies adopt policies that if something stays in the backlog for a period of time, in some cases as little as two months. If it hasn’t been selected and brought onto the Kanban board within two months then it gets deleted.
Some other places have longer policies, maybe six months. But the idea is that the backlog is just a large collection of options. Sometimes there needs to be more sophistication, and my colleague Corey Ladas talked about this in his Scrumban book that was published perhaps a year or so ago and the idea that there’s a certain number of things on deck, to use the aircraft carrier metaphor. Then there are some other things which are inside the hull of the ship in different states of readiness. And it’s possible to put some Kanban limits on those different states of readiness.
So if you think specifically about an aircraft carrier, there may be two aircraft on deck with the fuel dock, and the pilots are sitting in the aircraft, and they are ready to take off at a moment’s notice. So that’s completely ready to fly, and the work in progress limit is two. That’s perhaps constrained by the physical size of the deck on the carrier, but nevertheless it’s a work in progress limit of two.
Inside the hull of the aircraft, they might keep a half a dozen aircraft which are sight ready and perhaps fueled up, but there are no pilots. The pilots are off in the mess room, playing cards or something. They’re not sitting there in the aircraft.
There’ll be some other ones that will be under repair, or that have just come back from a mission and need to be cleaned and serviced and refueled. So, we can have those same concepts in software development.
We’ve seen some people divide the backlog up into three different states of readiness, where they might have anything from two to 10 items which are ready to go, in terms of their analysis and the understanding and any proprietary work that may have been needed for them, research or sub?party products that need to be integrated, or environment set up for installation.
Further back in a lower state of readiness, perhaps where the requirements are not fully elaborated, there may be a larger number of those; 10, 20, 30, 40, depending. Further back there’s just a list of ideas or outlines, and there may be a much larger list of those. And that stuff sometimes gets referred to as Top Stream Kanban. That may be a topic for a future book for me. Not just that one thing, but it’s likely to feature as a chapter in a future book.
Lean Sales and Marketing: Lean Engagement Team
More Explanation on SDCA, PDCA, EDCA
Special Marketing with Lean Book and Program offers on Facebook