Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: portfolio management

Kanban Leadership Retreat: Portfolio Kanban

This year’s Kanban Leadership Retreat (KLRAT), as always, was awesome. In fact, despite sharing some critical feedback during retro session at the very end of the event, I still consider it the best event of the year, hands down. This year I’ve come back home with the biggest homework ever: experiments to try out, ideas to play with, concepts to write down, etc. It means that coming back next year is a no-brainer to me.

One area that you’ll hear a lot about here is Portfolio Kanban. And this was also the subject of my session at the retreat.

The Goal

One of my goals for KLRAT this year was pushing forward the discussion on Portfolio Kanban. Answering questions like: what are the boundaries of the method? What are the gaps we still need to cover to make Portfolio Kanban thorough? How the implementations on portfolio level are aligned with the method as we know it?

During the session I wanted to talk about all these things. My expectation wasn’t to rule out all the doubts. I assumed that the outcome would include some answers as well as some new questions but overall would bring us to better understanding what Portfolio Kanban is.

The Hypothesis

I hypothesized that Kanban method with its principles and practices define well the approach we can use on portfolio level. In other words that we don’t need any other definition for Portfolio Kanban than the one we already have for Kanban. This is where we started.

The Process

I didn’t want to start with the Kanban definition and look for its possible applications (we would find those, wouldn’t we?). I asked participants for a brain dump practices, actions and techniques that we use manage portfolio. Then we sorted them into six buckets of Kanban practices. For example portfolio overview would be covered by visualization so it went to the visualize bucket, limiting number of ongoing projects would obviously go to the limit WIP bucket, etc.

Of course there were odd balls too. These went to the side as another group. Actually, this one was the most interesting one for me as they pointed us to possible gaps.

Everyone had a chance to briefly explain what they put on the wall and why it went to a specific bucket. Then we used the remaining time to discuss the challenges we see – which questions weren’t addressed and need further work.

The Outcomes

There are a few lessons learned from the exercise. I think the most important bit is that the hypothesis was confirmed. I am convinced that using constraints of Kanban method we can neatly define Portfolio Kanban.

Of course the specific techniques will be different. Interpretation of practices will vary too. But the same is true with team level Kanban applications in different contexts.

Things get more interesting once we go deeper into the details. Let’s look at the wall which is the documentation of the session (click for a larger version).

After a glimpse you can see that one bucket is almost empty. Surprisingly enough is the improvement / evolution bucket. Does it mean that we don’t see a match between Kanban method and portfolio management in this aspect? Personally, I think that it would be too quick to draw such conclusions.

An observation made by Klaus Leopold was that quite a bunch of the stickies on the wall that could be placed not only in their original place but also in the improvement / evolution bucket. That’s obviously true. But then I can’t help but thinking that if we were doing the very same exercise with Kanban on team or service level the end result would look different.

I think that the answer is that evolution on a portfolio level involves different behaviors and different tools than on a team level. How exactly? Well, this is one of these loose strings we have after the session, so I don’t have an answer for this. Yet.

Finally, pretty obvious outcome of the session is the list of the challenges we will have to address (or explicitly leave unaddressed) to finalize definition of Portfolio Kanban

Although we aren’t there yet in terms of defining what Portfolio Kanban is going to be, we made a big step forward. And this was exactly what I wanted to achieve. I didn’t want more divergence as I believe we’ve had enough of that so far. I didn’t expect more convergence either. Not just yet. Also I think that the time at KLRAT is just too scarce to spend it discussing the exact definition.

And that is how the end result of our work looked like.

All in all there are going to be follow-up steps – those that will bring convergence. If you are interested in further work on the subject stay tuned.

July 3, 2013
WIP Limits by Conversation

The biggest challenge when applying Kanban on portfolio level is how to introduce WIP limits. Kanban without limiting work in progress will always be shallow. In fact, many would argue (me included) that it is not Kanban at all.

The problem is that typical methods we use to limit work in progress on a portfolio level simply don’t work. Well, of course you can try to limit the number of concurrent projects, but if you’re like a vast majority of companies your projects will vary in their size very, very much. I find 1:200 difference in size between the smallest and the biggest project run by an organization pretty common.

If we wanted to translate this to work we do on a team level we would be talking about having tasks that we finish in anything between half a day and half a year.

It means that you could substitute one of your big ongoing projects with a dozen concurrent small ones and that’s still fine. Except that using a number of projects as a WIP limit doesn’t seem like a good idea anymore.

Limiting work in progress in such an environment has to be contextual. One has to take into consideration size and length of projects, dependencies between them, etc. A different WIP limits will be applicable when portfolio is dominated by medium-to-big endeavors and different will make sense when you’re coping mainly with small projects. In short, to say anything more about sensible WIP limits we have to know the context.

If we discuss the current context, everything that is happening right now, estimated effort needed to complete the new project, available and required capabilities and any other potential projects we can likely say whether we should or should not start the project. This is basically the core of idea called WIP limits by conversation (I credit Klaus Leopold who I learn the term from). With each new project in a backlog we discuss to say whether it fits the implicit WIP limits or not.

It may sound like it’s a lot of work but it isn’t. The most difficult discussions will be around relatively big projects but then, you don’t start such projects every other week, do you? Discussions about small projects may be more frequent but they will be way easier to decide on too. And they won’t be happening so very often either.

A tool that is very handy to support WIP limits by conversation is good visualization. Unless everyone involved has a general idea which teams work on what, what capabilities free teams can offer, what are other commitments, etc. the discussion will be basing on gut feelings. And a gut feel of most CEOs is that the company will cope with every single project… somehow. This is how you end up having 30 people involved in 100+ projects. Not the most effective way of working, right?

I am perfectly aware that the approach seems to be vague, but the general rule is that the more variable the work is the less explicit WIP limits can be.

WIP limits by conversation may also seem fragile. If there is a person who pushes more and more projects into the system lack of explicit rules for limiting work in progress may seem like a weakness. Not necessarily so. Usually visualization is enough to show risks attached to a project that doesn’t fit available capabilities. After all, no wants to start a project that is doomed for failure and will hurt the organization’s reputation.

Of course the conclusion of discussion may be that not starting the project is not an option because of, e.g. relationship with the customer, but then you simply start talking about costs. What other work won’t be done or will be delayed, etc. A format of conversation proves to be very useful on such occasions.

One nice side effect of introducing WIP limits by conversation is that you are encouraged to talk about thing like expected value, cost of delay, estimated effort and probabilities of all of these numbers for all the projects that you start. It usually helps to refrain from projects that don’t make much sense but unless you’d started asking such questions no one would have been aware of the fact.

Another gain is slack time generated on a team level. If you care about not overloading the teams, occasionally they won’t have an ongoing project. This is perfect moment to all sorts of improvement work as well as learning or helping other teams.

My experience is that, despite its vague nature, limiting WIP by conversation works surprisingly well. After all, I don’t know many people that want to make their teams miserable and hurt their organization on purpose.

March 25, 2013
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.

March 15, 2013
The Project Portfolio Kanban Story: Better Board

When applying Kanban on project portfolio level you’re dealing with different challenges than in case of standard Kanban implementation on a team level (if there even is such a thing). Both the flow dynamics and task granularity is very different, thus you need to focus on different aspects when designing Kanban board.

This is basically why typical Kanban board design will often be suboptimal.

At the same time the biggest challenge you face on project portfolio level is defining and applying WIP limits. For the time being my thoughts on a subject are that depending on a specific environment teams would be choosing very different measures to manage WIP on portfolio level. However, as we as a community still lack experience from addressing different scenarios I’ll focus on the path I’m following. After all the story format I chose requires that.

In my case the most reasonable thing I was able to come up with was a number of people involved in project work. Unfortunately the scale of the team (more than 130 people) didn’t allow me to use straightforward approach and scale up WIP limits with numbers.

Instead of continuing my struggle to find a perfect measure that suits the current board I decided to redesign it completely.

Whenever you read about Kanban you learn that it is an evolutionary approach. Kaizen and all the stuff. However one advice I have on designing a Kanban board in general is that when you start running circles with board evolution and see little or no improvements throw the whole board out and start from scratch. From one point of view it can be considered a revolution (kaikaku) but from another: you don’t really change your way of working, you just try to visualize it differently.

Either way I took my own advice and started from a clean whiteboard. I also remembered another advice: not to stick to standard board designs. This is what I ended up with.

First, there is no value stream or process in a way we understand it on a team level. Since the flow of index cards wasn’t dynamic I decided this isn’t information I should focus on that much.

Second, on horizontal axis, instead of process there is a time line (monthly granularity). As variability of project sizes is huge I decided I need some sort of time boxes which I measure WIP against. With very few small engagements, ones that take us less than a few weeks, monthly time boxes looked reasonable.

Third, I created swim lanes for teams. We don’t have 130 generic engineers, or Average Full-Time Equivalents, or whatever other inhumane label you can think of. We have teams that we strive to protect and teams do have specializations. It means the context of a team is very important and if it is important it goes to the board, thus swim lanes.

Fourth, having such board construction I had to change my approach to index cards. Instead of having a single index card representing single project I ended up with territory-driven approach. A project covers a territory both in terms of team(s) and time. Looking at index cards with a project name you can instantly guess which team is working on the project and how long it’s going to take them. And the best part: a size of index card in any given month represents roughly how big part of a team would be involved in work on a project. This way we can easily show a few smaller projects as well as on big or any combination of those two.

Fifth, as one of Kanban base concepts is pull it is represented by backlog area – green cards on the left side of the board. These are projects that aren’t yet started. The specific swim lane they are neighboring show preferable team to work on a project. However, it rarely is such a direct dependency: this team will do the project as there is no other one suitable to do the job. Most of the time we assume that another team can build the project too. Each time a project goes into development we decide, at last responsible moment, which team will take it.

Of course there are some nice additional flavors here as well. Violet and yellow index cards differentiate maintenance projects from new ones. Green card are for projects that aren’t yet started and once they are we switch to yellow. Red index cards represent overrun in projects that are late. As we work on fixed price, fixed time projects we roughly know up front how much time and people we want to invest into a project. When something bad happens and this plan changes we show that. After all we put more attention to challenged projects.

A simple fact that we are working on fixed time, fixed price projects doesn’t mean our arrangements never change. They do. Any time something changes we just update it on the board, same as we’d do with any other board. We just keep the board updated as other way its value would diminish.

This Kanban board design definitely tells more than the initial one but I started this whole revolution to deal with WIP limits. What with them?

Well, there still aren’t explicit WIP limits. However at this moment there are implicit WIP limits and information about them can be pretty easily extracted. Considering that I use territory-driven approach to index cards WIP limit is show by vertical axis of the board. Each team has a limit of one full-sized sticky note (representing whole team) per month which can be split in any way.

In other words we won’t start another project unless there’s some white space that this project would fit into as white space represents our spare capabilities. Actually, it may be a bit of simplification as on rare occasions there are project we just start, no matter what. But even then we either can make such project fit the white space in a reasonable way or we need to make some more white space for it.

Even though such WIP limits aren’t explicit, after some time of working with the board I can tell you they do the job. They do, not only in pulling new projects into development but also, and more importantly, in long-term planning as we have visibility a year ahead and can confront our capabilities with planned sales etc.

With this board, for the first time from the beginning of my journey with project portfolio Kanban I felt satisfied.

See how we come up to this point – read the whole story.

Advertisement: Infragistics® NetAdvantage® for Windows Phone gives you rich, innovative mobile UI controls to build high-end mobile user experiences for Microsoft® Windows Phone®. Their high performance, eye-catching data visualizations, mobile form factor optimization, touch gesture support, and alignment with Metro usability guidelines take your social media connected mobile applications to the next level.

May 1, 2012
The Project Portfolio Kanban Story: Why Standard Board Design Is Not a Good Choice

When I was starting my journey with Kanban on project portfolio level I based on a classic board design I knew from my work with Kanban within project teams. I basically tried to map value stream to the board but on a different level.

The effect was sort of predictable.

It was also naive.

The basic strength of such design is it’s very intuitive. Well, at least for these parts of the world that read from left to right. The same way we read the board: whatever is closer to the right edge of the board is closer to completion. The value stream we map may be a bit simplified (as me make it linear) but then it isn’t that much of a problem – after all index cards are flowing through the board pretty smoothly.

Unless you put on single index cards “tasks” that last a year or more, which is exactly what I have done.

When you’re looking at very long lasting projects you look for different information than in case of several hour long tasks. It isn’t that important how an index card is flowing through the board. After all you expect it to sit in one place for months. If you find out that the status of the index card has changed a few days late it likely isn’t a problem at all.

It is way more important, and interesting at the same time, to see teams’ capabilities in terms of undertaking new projects, i.e. how much more we can commit to our clients. Note: we aren’t talking about a single team of 7 (plus or minus 2). What we have here is 100+ people working on a couple dozen different projects concurrently. At this level capabilities are pretty damn difficult to estimate, especially given ever-changing business surroundings.

This is a huge weakness of the common board design: it doesn’t really help you with estimating free capabilities. It would help if we were able to set reasonable WIP limits on such board. Unfortunately, it is (close to) impossible.

A number of projects isn’t a good candidate to measure WIP, as projects differ in size hugely. If you use time-boxing you could try using a number of time-boxes as a measure. However in this case you don’t want to have a random team working on thirteenth iteration of a project that was build so far by the other team. With WIP limits measured by the number of iterations you would likely end up this way. Another idea was using money-related measures. This brings a question whether you sell all your work for the same prices. I guess that is true in very few cases and definitely mine is not one of them.

The longer I thought about it the more often I was coming back to people. I mean a team could start another project if they had some free people who could deal with it in planned/expected time frame. I even thought for a moment of setting base WIP limit around 130 (roughly a number of people working on projects represented on the board) and having each index card to weigh as much as there were people involved in a project at the time. The problem was the hassle needed to manage such board would be horrifying.

On the other hand measuring WIP in number of teams was way too coarse-grained as we had anything from multiple projects covered by a single team to multiple teams working on a single project.

All in all I ended up with a belief that, in terms of project portfolio Kanban, standard board design isn’t a good choice. I was ready to redesign the board completely.

If I piqued your interest read the whole project portfolio Kanban story.

April 20, 2012
The Project Portfolio Kanban Story
The Kanban Story was the idea which came to my mind soon after we I started playing with Kanban with my team back then in early 2009. I thought that sort of live journal of our Kanban adventure can be an interesting thing to read. I knew that we probably got some things wrong initially but after all Kanban encourages you to have experimentation mindset and also I’m a strong believer that failure is actually a good thing.

By the way: now that I read my story, sometimes I deeply disagree with the way we approached Kanban, yet still it was a valuable experience and hell of a lesson.

The Kanban Story ended up as the most popular series of posts on this blog of all time and a few chapters are also high on the top 20 list. Sort of success I’d say. So when I started playing with portfolio level Kanban I decided to go the same way. I let myself a few months of experience just to have some content for the beginning and here it is: the very first post of The Project Portfolio Kanban Story.

It will follow similar pattern as The Kanban Story which means I won’t try to address all the problems of the world but will rather focus on the specific situation and explain what we did and why. Expect much of the context and much of experimenting to find the right solution. Expect wrong decisions and changes. It’s going to be some sort of experience report. In chapters. I hope you will enjoy it as much as its predecessor.

Here’s the list of all posts of The Project Portfolio Kanban Story:
November 30, 2011