≡ Menu
Pawel Brodzinski on Software Project Management

Portfolio Kanban: Why Should I Care?

Portfolio Kanban: Why Should I Care? post image

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.

in: kanban, project management

8 comments… add one

  • Lech Ambrzykowski March 16, 2013, 12:18 am

    Thanks for sharing. Great piece!

    This could actually work even in large scale (e.g. > 100 projects) by using intermediary levels, ie. domain portfolios.

  • Alex March 18, 2013, 7:00 am

    I just read your Portfolio Kanban Story posts very interesting! The last post was one year ago… a new entries coming? Looking forward to see your latest board design…


  • Pawel Brodzinski March 18, 2013, 10:18 am

    @Lech – There is a limited number of items on the board that can be comprehended by a single person and this is sort of a limit. Your observation, however, is spot on. You can freely scale up and down this approach as long as the typical size of work represented by a single sticky scales up or down accordingly.

    In fact, I’ve had great discussions in London (during London Lean Kanban Day) about applying the approach even in very big organizations where the atomic item wasn’t a project but rather the whole product line.

  • Pawel Brodzinski March 18, 2013, 10:22 am

    @Alex – Yes, there are new entries coming soon. They won’t be the following chapter of the story but rather results of more conceptual work around the subject and conclusions for further implementations of Portfolio Kanban.

    You may hear me speaking about Portfolio Kanban too. Next occasions will be ACE! Conference and Lean Kanban North America.

  • Matthias Jouan May 23, 2013, 1:19 pm

    Hi Pawel,

    I had not read the Portfolio Kanban Story up to now, but I just watched the video of your speech at LLKD13 and I can’t help thinking that the current result of your portfolio-level kanban experiment is nothing but a portfolio-level Gantt chart.
    Could you please enlighten me about the key differences you see between the two?


  • Pawel Brodzinski June 3, 2013, 11:00 am

    @Matthias – Sometimes I say that this design of Portfolio Kanban board is a sort of Gantt chart. And I’m only half-joking. Anyway, the clue here is that this is only one of possible approaches to design the board and most definitely not the only one. The board is only a tool you use. The method is way more than that. It’s about the way you act on the data you get from the board.

    But even if we stick to this design one important bit is different. In Gantt charts we set a plan and then track progress. So when we have a project that was supposed to take a month but it already took two and we’re only halfway there what we’d typically see is a month-long bar with 25% progress shown there. On portfolio board you’d change the area covered by stickies to show that now you expect the project to take 4 months, not 1.

    The difference may seem tiny, but the effect is that in the latter case you don’t plan anything for the following months while in the former there is such a temptation. This is basically how limiting WIP on this level works.

    On a side note, I can imagine portfolio board mapped in Gantt chart and it can even work, although it would be pain in the neck as it wouldn’t be a default way of using Gantt charts.

  • Matthias Jouan June 5, 2013, 8:33 am

    Thank you Pawel

    I am not a big fan of Gantt charts. Nevertheless I must say that I disagree with you : when you write that Gantt charts set a plan, you seem to mean it like written-in-stone plan. This is wrong. IMO it would be a real project management suicide to consider a Gantt chart as unchangeable. If we have a project that was supposed to take a month but it already took two and we’re only halfway there, we definitely have to update the chart the way you’d do in your implementation. I would add that I don’t think progress in a Gantt chart should represent time, or even effort. It should IMO represent some sort of risk mitigation, but that’s another story.

    Anyway, what made me think about a Gantt chart here is the resource-based WIP limits instead of “traditional” stage-based WIP limits. It has been one year since you first wrote about this board design for the first time : did you experience any problem with not having explicit stage-based WIP?

  • Pawel Brodzinski June 10, 2013, 1:33 am

    @Matthias – I don’t say the plan is, or should be, written in stone. I merely point the most typical usage of Gantt charts. Note that even when you don’t change the initial baseline Gantt chart still can be useful in some way as you still track the progress.

    My problem with this approach is that is lies when it comes to long term planning. And again I’m talking about the most typical usage of Gantt charts.

    Anyway, the important part here is about WIP limits. Not answering directly – I still don’t know a neat way to limit work with stage-based approach on portfolio level in vast majority of cases. For me it’s not the question which approach to choose, but which one is merely feasible.

    I don’t say that vague WIP limits by conversation are applicable as easily as typical stage-based WIP limits, because they’re not. They require more discipline and more understanding of how the work gets done. On the other hand I found that it is surprisingly easy to start these meaningful discussions.

    The discussions are driven by visualization. Having all the data on a single physical board that you can quickly comprehend in seconds to get the big picture and then get into details wherever needed is the early game changer.

    While I don’t think WIP limits by conversation is an ideal solution, counterintuitively, there’s little resistance even without the clear rules whether the org can or can not start a new project.

Leave a Comment