Portfolio Kanban: Why Should I Care?

It’s an interesting observation for me: people keep asking me to speak about Portfolio Kanban. London, Krakow, Chicago… it seems that for me Portfolio Kanban is going to be the topic to speak about this year.

When I started with Portfolio Kanban it was an experiment – a tool I wanted to play with to see whether it is useful at all. When you start speaking publicly about such things though, there is one important question you have to answer: why should anyone care?

After all, unless the question is answered Portfolio Kanban is just a toy.

So… why?

When I look at work that is happening in lean and agile communities I see a lot happening on a team level. Scrum is a framework designed for a team level. When you look at Kanban implementations, vast majority of them are on the same level too. Now, should we be worried? Is it wrong? No! It’s perfectly OK. Well, sort of.

Let me start with this:

A system of local optima is not an optimal system at all; it is a very suboptimal system

Eli Goldratt

Focusing on a team level and a team level only we are optimizing parts as rarely a single team is a whole. I’m far from the orthodox view that we should focus on optimizing the whole and the whole only, as most of us don’t have enough influence to work on such a level.

It doesn’t mean though that we should cease any responsibility for optimizing the whole system, no matter what sphere of influence we have.

This is basically why improvements on a portfolio level are so crucial. They don’t have to be done instead of improvements of a team level or prior to them. In fact, a holistic approach is probably the best option.

If you aim your efforts on a team level only you likely become more efficient, but the question is: efficient at building what?

Processing the waste more effectively is cheaper, neater, faster waste.

Stephen Parry

If the wrong decisions are made on a portfolio level, efficiency on a team level doesn’t really help. What’s more, it can even be harmful because we just produce waste more efficiently. I can think about a number of wasteful activities imposed on teams on a portfolio level, but two are the biggest pains in the neck.

One is starting projects or products that shouldn’t be started at all in the first place. There is dumb notion that people shouldn’t be idle, so whenever individuals or teams have some spare time it is tightly filled with all sorts of crazy ideas that simply aim at keeping people 100% utilized. That’s just plain stupid.

Usually, even when people are busy, they get this kind of work anyway, as “they will cope with that somehow.” After some time not only do we run lots of projects or initiatives of questionable value but we have to spend additional effort to finish and maintain them.

Another pain point is multitasking. All these filler projects are obviously of lower priority than regular work. So what people end up with is they keep switching between projects whenever higher priority tasks calls. The problem is that a context switch between two projects is even more painful than a context switch between two similar tasks within the same general context. Oh, and have I already mentioned that once you’ve finished those filler projects you keep switching back to them to do maintenance?

So basically what you get is very low value work at cost of huge context switching tax. Congratulations!

Oh, is it that bad? It’s even worse.

If you are doing the wrong thing you can’t learn, you will only be trying to do the wrong thing righter.

John Seddon

If the organization starts all the fires on a portfolio level, teams end up trying to cope with that mess. If they care, they will make the wrong thing a bit better. Does it help? Not at all. The sad thing is realization what could have been happening instead, which is basically learning.

The organization could have been learning what work really adds value. The teams could have been learning how to work better. On all levels there would have been opportunities to improve thanks to occasional slack time.

And, by the way, the organization would have been operating more efficiently too, thanks to less context switching.

This is basically why you should focus more on organizing your project / product portfolio.

Why Kanban in this application then?

I guess I already gave the answer between lines. Visualization, as always, enables harvesting low-hanging fruits. I mean, unless we see how screwed up we are, we often don’t even realize the fact. Visualization also helps to substitute everyday project-related wild-ass guesses with everyday project-related informed decisions. Sounds better, doesn’t it?

Then there are WIP limits that enable conversations about what projects get started, how we staff the teams and how we react in all sorts of special case situations. In fact, without that bit changes introduced by Portfolio Kanban will be rather shallow.

Finally, if you are aiming for improvements, Portfolio Kanban gives you a change mechanism that is very similar to what you know from team level Kanban implementations.

The best part though, is how easily you can start your journey with Portfolio Kanban. Even though it tackles the part of the organization that is usually highly formalized and full of politics, Portfolio Kanban doesn’t require, at least at the beginning, to have everyone signed up for the idea. A single person can use Portfolio Kanban as a disruptive weapon and see what it brings.

Seriously, it’s enough to have only one person willing to work consistently on Portfolio Kanban board to see the first yield of the improvements. And one doesn’t have to wait very long until the first meaningful discussions around projects start. Then you know something has already changed.

Even when no one really realized you used Kanban to achieve that.

If you liked the article you may like my Portfolio Kanban Story too.