As you already know I’ve recently attended ACE Conference. By the way, if you missed the message the event was great. Anyway, the interesting thing about industry conferences is you can clearly see some cool phrases, buzzwords or examples. I was once on a conference where like every second presentation cited CHAOS Report to share the news: two third of features aren’t used.
Um, after third time it’s not much of a news anymore.
Anyway, one of few buzzwords I caught in Krakow was limiting Work In Progress. To be honest, I’m confused. Wasn’t it me, who told you to limit WIP in my Kanban presentation? Yup, it’s hard to deny. Am I on this damned limit-WIP-bandwagon then? Yup, it seems so. But why, oh why limiting WIP became a buzzword?
For some reasons we need them. I think we keep attaching those buzzwords to our messages for a very simple reason – they sell. They sell whatever we have for sale. So yes, we’ll be hearing a lot about limiting WIP these days. By the way, another such thing is system thinking which follows exactly the same pattern – every cool kid on the block will tell you about system thinking.
Despite the fact I hate one of my genuine messages became a buzzword, which makes it easier to be depreciated, there are some good points as well. No, I don’t think about being right a couple of years earlier than the rest of crowd. It definitely scratches my ego on the back but, well, my ego feels pretty comfortable anyway.
A good thing of some good concept becoming sort of buzzword is it reaches some ears much easier. There are people who won’t adopt good things unless they’re well-known. There are organizations which hate to experiment. I have a good news for you: now, you have an excuse guys. Everyone tells you that you should limit WIP. Hard to ignore that now, ah?
Unfortunately I know what happens then. The concept is being misused and abused and finally under the buzzword there’s hardly anything coherent. It’s like with agile. What does it mean when someone states they do agile (or are agile, for that matter)?
Basically nothing.
Unless you see how people work you can’t really say whether we discuss hard-core agile team which could serve as Scrum+XP implementation in Sevres or just the good old do-whatever kind of team which just wanted to get agile badge.
It will be the same with limiting WIP at some point of the time. But until then I’m going to enjoy being the part of buzz proponents.
So go, limit your WIP! Use Kanban! It is a goddamn silver bullet! It will make your team hyper-productive and will bring the peace to the world! And of course, in the meantime, it will remove poverty as well!
And if you really think it might be a good idea, let’s talk seriously. Because I know it works, when applied in a reasonable way. Yes, your guess is right “reasonable way” is a key phrase here.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
3 comments… add one
Pawel, my teams have been using kanban for about 9 months now, and we keep evolving our process to get better and better. It’s awesome!
I’d say that limiting WIP is necessary, but not sufficient. Lately I’ve come to realize that also reducing the “batch size” of stories, features, or tasks you are working on is also very important.
Even after we got good at limiting WIP, sometimes the cards on the kanban board were just too damn big.
One of my teams delivered a release a month ahead of schedule just a few weeks ago. Another one of my teams is probably going to be about a month early with a release this summer. And these were real quality releases; we tested more and better than usual and our code peer reviews have been more and more fruitful as we have been reducing the sizes of the cards we flow through the value stream.
I can attribute our success to kanban; the visualization and evolution of our value stream, limiting WIP, reducing batch sizes, and allowing for better prioritization and protecting my team from drive-byes and task-switching.
I’ve learned so much and have so much to share. I started up a new site at http://KanbanSchool.com as a platform from which I can share what my teams and I have learned as practitioners of Kanban.
And you were one of my original sources of knowledge and inspiration after I discovered Kanban, Pawel. So thank you very, very much!
Josh Nankivel
Love the WIP.
Thanks Pawel, you dropped a “game changing synergy of WIP lovers who use Agile methods to leverage low-hanging-fruit to the maximum potential creating paradigm shifts in the way we look outside-the-box of usual high-impact steamlined processes that add holistic secret sauce of value-added visibility to best-of-breed core competency best practices.”
Josh,
The batch size is a tricky thing. There’s a concept of MMF – Minimal Marketable Feature – which gives you sort of kick start here. However many teams I work with evolve to the point where they don’t follow the definition strictly.
When you need to estimate when some project will be done you need reliable historical data and when I think reliable I mean comprehensive as well. If life time of your features is spread like from a couple of days to a couple of months you can’t really prepare reasonable estimates basing on them.
Also, as you mention, huge tasks sucks in terms of blocking the board. If you have a feature which hangs on the board for long weeks it will affect real limits you have on the board.
But then, it all boils down to the good old WBS – the better we split the scope into small batches of work the better we can track how we’re going. In Kanban we have smooth flow as well as a bonus.