Pawel Brodzinski on Leadership in Technology

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

Tag: product portfolio

  • Portfolio Kanban and Doing the Right Thing

    There’s an ongoing discussion that I occasionally refresh with Markus Andrezak on usefulness of applying Kanban to manage portfolio and generally to the process of figuring out which products should be built.

    What is Portfolio

    One obvious thing that we can start with is focusing on a specific context. After all portfolio is a pretty loaded word and it is used in all sorts of situations. While my goal isn’t to boil down portfolio discussion to only few available options I see at least three distinctively different cases.

    There are organizations that ore focused on project work. A typical gig they run would be a distinct initiative that is different form all the other initiatives they run. What’s even more important the revenue from that work would be connected to delivering work. This would be a project portfolio case. A classic example would be an offshore web software shop.

    Then we have organizations that, similarly to the previous example, focus on building multiple concurrent and independent initiatives yet they would operate them as products by themselves. In other words they earn money by directly selling their software, or services provided by that software, to the end users. There’s no simple definition when the work is done. This would be a product portfolio case. A classic example would be a game development studio.

    Then there is an alternative version of product portfolio where the whole company is focused on building a single product. In such a case the overarching initiative that everyone contributes to is obvious as there is only a single one. The discussion would happen between either specific goals to achieve or specific big scale functionalities to build. This would frequently be labeled a product portfolio too although for the sake of this discussion I’d go with a feature portfolio label, even if it isn’t precise especially for big organizations. A classic example would be a startup building what they believe is the next world-changing product.

    Of course we can think of a mix of any of these scenarios and rarely only one of them will be pursued by an organization exclusively. What’s more we could go further with a differentiation within these scenarios. We’d see a completely different dynamics of project portfolio in a company that works under time and material terms than from one that build fixed price projects. A very different feature portfolio will be in a startup at an early phase which is still figuring out product-market fit that in an established company focusing on leveraging their user base or staying ahead of competition.

    Where is the Problem

    The discussion about applicability of Portfolio Kanban boils down to defining what is the most painful problem on a portfolio level in a given context. From that perspective there is a clear distinction between project portfolios and the other two scenarios. The difference is in the way revenues are generated.

    In project work the more projects we finish the more revenues we can expect. With product or feature portfolio building software is only an intermediate step in order to generate revenues. In other words we know much more up front about return on investment in project portfolio scenario than we do in other two.

    That doesn’t completely change the bottom line. In each case the choice on endeavors an organization works on is crucial for its long-term health. In each case overcommitment and too much work in progress on portfolio level can decimate the value of any ongoing work, no matter how carefully chosen. There are commonly mentioned reasons for that: long lead times mean long feedback loops and a lot of work in progress results in inefficient work.

    There’s one more dimension that from my experience is at least equally, if not more, important. The constraints provided by work in progress limits change the dynamics of the discussion about starting new stuff, be it projects, products or major features.

    Typically the discussion about economic feasibility of starting a new product or a project happens in isolation. If the ultimate problem that we are trying to solve is choosing the right initiatives to work on it should never happen in isolation. After all most of ideas we come up with make sense… in some context. An interesting question would be whether we are in such a context.

    We may have a bunch of projects that we expect to be profitable. But which of them provide us most monetary and non-monetary value? How starting another one affects the ones that are already ongoing? Given a business hypothesis which we want to validate, which out of all possible experiments would generate most valuable information? Would starting another concurrent experiment obfuscate the outcomes of ongoing ones?

    Of course we can say that each project will provide some value and each experiment will provide some learning opportunities. We don’t have infinite capabilities thus we need to choose.

    Role of Portfolio Kanban

    The way I look at Portfolio Kanban is that is addresses a very common issue of overburden at portfolio level and as a result it drives the discussion about what are the right endeavors to pursue. The latter starts happening when, thanks to WIP limits, we start saying no to new initiatives. What WIP limits create is they underscore available capabilities as a scarce resource. The next step typically is more careful consideration how these capabilities are put in the best use, which ultimately means a discussion about what is the right thing to build.

    Obviously this dynamics is not true in all environments. Startups, especially at the early stages, will likely focus on figuring out what is the right thing to build without any external incentive. Organizations built around a single product, at least to a certain size, will naturally maintain discipline in strategy planning that will provide an answer what are the crucial product goals for them.

    Beyond that it all gets fuzzy. If an organization gets big enough it has capacity to build multiple initiatives concurrently. Each product that grew far enough has a number of potential development paths it can follow and each of them can be promising on its own. If we talk about multiple product organization a temptation to follow a bunch of new goals at the same time is even stronger. And with projects it’s like an everyday issue.

    Of course I don’t say that it’s not possible to start the other way around: nailing down the ultimate purpose, which may mean answering the Spice Girls question, and following up with defining what are the right features, products or projects that serve the purpose. This would likely mean that the number of concurrent initiatives will be limited as majority of activities would be optimized toward pursuing the purpose.

    The problem is few organizations are ready to make this step just like that. And even when they are, there are still a lot of risks along the way. First, depending on how the ultimate goal is defined it doesn’t have to limit the options for what constitutes an attractive endeavor and we’re back to the square one. Second, even if the purpose provides enough focus there’s typically still plenty of options how to pursue the goal and thus overburdening portfolio is still a viable option. Third, and most importantly, in bigger organizations defining a single purpose may be impossible because office politics kicks in or there isn’t enough strategic leadership present.

    In either of these cases as well as in the most common situation where there isn’t enough awareness to even start the discussion about the purpose Portfolio Kanban may serve as a facilitation tool. On the top of efficiency gains, similar to those seen in other applications of Kanban, it would catalyze the discussion about what is the right thing.

    This is, in fact, the most important outcome of introducing Portfolio Kanban that I’ve seen.

    What Portfolio Kanban Is Not

    An argument I’ve heard a couple of times is that Portfolio Kanban doesn’t help to define what is the right thing to build or what is the ultimate purpose. I completely agree with this one. That answer simply isn’t there. Portfolio Kanban, pretty much alike any Kanban application, is a meta method. One shouldn’t expect to get context-specific answers.

    If an organization is ready to look for these answers that’s great. Depending on specific context Lean Startup, Lean UX or other modern product management approaches may be relevant. That’s where awesome guys like Will Evans or Markus Andrezak kicks in with their expertise. That’s where Stephen Bungay’s work will prove invaluable, which Jimdo guys will happily confirm. That’s where Don Reinertsen would provide outstanding guidance for decision making.

    In such cases, usefulness of Portfolio Kanban will indeed be limited. It will be mostly process improvement and efficiency stuff.

    A common case wouldn’t be even remotely as rosy though. That’s why value provided by Portfolio Kanban typically go beyond the process stuff. It would still stop at introducing pressure to start important and difficult discussions. It wouldn’t provide guidance for that conversation. A good thing is that there would be more pressure the more screwed up the situation is. We can expect this catalyzing mechanism to exist continuously till we either solve the problem or give up on limiting work in progress on portfolio level.

    If someone claims that Portfolio Kanban is supposed to provide more than that in terms of defining what is the right thing, well, we may be talking about different things.

  • 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).

    KLRAT Portfolio KanbanKLRAT Portfolio KanbanKLRAT Portfolio Kanban

    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

    KLRAT Portfolio Kanban Challenges

    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.

    KLRAT Portfolio Kanban

    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.

  • 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.