Noodling on Kanban… Part Four
Okay… time to wrap this thing up. If you missed any of the first three ‘Noodling on Kanban‘ posts… I included links at the bottom of this one… just to make it easy on you guys ;-)
There is clearly much more to this topic than I wanted to try and address in this tiny little series. We could talk about how Kanban drives culture… how it gives managers a role… how it is more inclusive. Karl Scotland and I debated over Drum-Buffer-Rope and how it applied to Goldratt’s Boy Scout story over drinks at Agile 2009. We agreed we were splitting hairs. I tried to get David Anderson to admit that Kanban was just a visual way of managing and elevating constraints… he didn’t agree.
There is lots more to say… but for the general agilist or newbie… this should be enough to start. For this post we’ll wrap with some of my thoughts on what situations a Kanban might be particularly useful and what I see for Kanban outside the team. To me that is the much more interesting problem.
Time to Use Kanban?
My personal take is that Kanban… even Kanban with a capital ‘K’… is not a development methodology. It is not a replacement for Scrum or XP or AUP or DSDM. I do think that Kanban is a powerful tool that can be used when some of our more common agile practices stop making sense. Consider these examples:
Have you ever tried to talk about planning in two week iterations with a team that is responsible for production support? The idea that you can’t add anything to the sprint once it is started is going to fail… we’d probably abort every sprint. How about a mature product team that is iterating an existing product? Does it necessarily make sense to stop every two weeks for a few hours to plan… to retrospect? If requirements are generally understood… the team talks over lunch… and they just know how to get things done… probably not.
How about a team that suffers from late delivery in the sprint? A Kanban board can keep them focused on continuously delivering value… even if they don’t do away with the iteration boundaries. What about a new team that isn’t ready to self-organize or self-manage? A Kanban can give the manager a tool to help the team learn how to self-organize and self-manage. We can use Kanban as a replacement for stuff we don’t need or as an addition when we need a little bit more control. Something to consider, huh?
Kanban in the Enterprise
Personally, I find most problems at the team level pretty uninteresting. It’s not that team level practices aren’t important… they are incredibly important… it’s just that most of the teams I work with have environmental problems. If the organization would just create the team… leave the team together… let them stabilize… let them establish a pattern of delivery… most of the coaching stuff we do could work itself out. Coaches could focus on helping competent teams become excellent.
Similarly… at the team level… Scrum… Kanban… who really cares… let the team decide what works for them and go for it.
For me… Kanban gets really interesting at the portfolio level and across the enterprise value stream. Most organizations really struggle to get value flowing in a predicable way out of their enterprise project portfolios. What if we could have an enterprise Kanban… a portfolio Kanban… a project Kanban… and a team Kanban. As you go deeper into the organizational hierarchy… the work in process limits at the enterprise level force value from the portfolio… portfolio limits force value from the projects… and projects force value from the teams. Imagine a system with enterprise cycle time all the way down to team level cycle time.
Thinking about the enterprise as a series of capabilities… capabilities that together form a system… a system that can be managed and subordinated to the constraint… now that is exciting. Now we can focus our enterprise agile adoption dollars at the constrained teams and resource groups to get maximum value from our investment dollars. That is where I’d like to see us to start talking about Kanban.
Hope you enjoyed this series of posts. Make sure to comment if you think I’ve got this all wrong… I am open to your feedback. Oh… and here are the links for your reference:
Noodling on Kanban… Part 1
Noodling on Kanban… Part 2
Noodling on Kanban… Part 3
I like the idea of implementing Kanban at different altitudes. Viewing the organization as a manufacturer of value puts the focus on doing what's necessary to maintain the delivery of value. At the other extreme, it can be used at the individual level to bring focus on maintaining one's own delivery of value. Sorry, must go – I have too much inventory of value and need to get it delivered! :D