Pawel Brodzinski on Leadership in Technology

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

Category: project management

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

  • Portfolio Management: Stop Starting, Start Finishing

    Whenever I end up discussing project portfolios with people representing or knowing specific organizations out of curiosity I ask a couple of questions. How many projects? How many people running those projects?

    Note, most of the time I don’t ask these questions in the context of completely random organizations. The most common case would be asking people who are a part of Agile and Lean community. People who understand the concept of limiting work in progress and its implications.

    Disturbing news is that, even among the most mindful people, the answers I would get are pretty much shocking.

    Kanban Leadership Retreat is an occasion to meet people advancing thinking for a community that painted limiting work in progress prominently on their banners. One would expect that these people, if not anyone else, would be ahead of the rest of the crowd in addressing the issue of too many concurrent projects.

    Well, maybe we are. At the same time the ratio of a number of projects run by an organization to a number of people who work on those projects reported at the last Kanban Leadership Retreat in Cascais is terrifying.

    1.0, 2.1, 4.5 and 6.0. Let me rephrase what this number is. This is how many projects per person an organization runs on average. In fact, it does mean that some people are in a situation that is much worse than that.

    I didn’t gather that data in any consistent manner. I just asked my question any time the context would pop up in a discussion. It isn’t by any means proper research. It shows, however, a very interesting trend. The best result is a project per person, and we are talking here about an organization with a hundred engineers in this case. Few of those projects, if any, require attention of a single person only.

    From that point though we go downhill. I can’t imagine any situation where a single person runs concurrently a few projects and they are at least a tiny bit effective. This means heavy multitasking for those initiatives that get any progress and lots of others where progress is nil. Effectively, they are parked even if management believes that they are active.

    Let me repeat. It wasn’t reported by a random community. It is the community that calls their user group meetings Limited WIP Society. Not Visualization Society or Flow Society. Limited WIP Society. We do care. We do pay attention. Yet still, we do suck at that. Big time.

    Larry Maccherone in his talk at Lean Kanban North America reported that teams that work on a single project are significantly better in terms of defect density. We can use that as a proxy for quality of work. It’s not anecdotal evidence. Larry bases his research on raw data from almost ten thousand agile teams.

    By the way, Larry also reported that team size of 5-9 people is by far the most popular one. In other words, ideally, we should be looking as projects to people ratio of 0.2 and below. Of course it is contextual and shouldn’t be treated as the true north. In organizations that typically run tiny projects that require attention of 2-3 people such ratio may be unachievable. At the same time we do have companies that typically run huge initiatives that involve dozens of people.

    In either case anything above 1 is obviously crazy. In fact 1 is crazy already.

    We can’t make this possibly work.

    The easiest way out is obviously reviewing the portfolio and putting on hold or abandoning a big chunk of ongoing initiatives. This would mean that the active remainder would get more, hopefully enough, attention so that these projects can be completed in reasonable time.

    Sad truth is that I know such an expectation is unrealistic.

    If we understand that potential projects are options that we can execute and once we decide to start them it means commitment we should also understand the consequences. Commitment means that there’s a price to be paid for abandoning an initiative. What’s more that cost isn’t easy to assess. How much would reputation of a company suffer for letting a client down? How much bad word of mouth would be triggered?

    Another way is to go with the theme of Lean Kanban Central Europe conferences: stop starting, start finishing.

    In other words make it hard to start new stuff. Discuss the cost and risks attached to adding one more thing to your plate. I don’t expect an explicit WIP limit. On portfolio level it is rarely a feasible option anyway. The strategy that you can use is WIP limits by conversation.

    There’s not much guidance needed to shift these conversations to a broader context that is frequently ignored. It’s not only how much a new project would cost and how much we are going to get in revenues. It is also about available capabilities: can we staff a project appropriately for its whole lifecycle? What is the cost of delaying the project? What risks are we going to introduce by starting a new initiative both to that initiative and to all ongoing ones? And what is ultimately value of completing the project?

    The value question goes way beyond simple financial outcome. In fact, it is a very deep discussion as one needs to understand the goals of an organization. Otherwise discussion about value is pretty much irrelevant. Also discussion about value doesn’t happen in isolation. Remember how hard it was to let down current clients breaking our commitments to them? Well, that’s clearly negative value for the company. If that’s the cost you pay you better have a damn good reason to do so.

    I do admit that WIP limits by conversation is a concept that seems vague and fuzzy. However, given that people understand what is effect of too much of work in progress I find it a surprisingly powerful tool. It simply shift the focus of a discussion and thus influences how decision making process looks like. It is like a facilitation tool that helps us to use knowledge that we already have.

    Then we stop starting and start finishing.

    If we do that in a continuous manner we evolve toward more effective way of working. Not only does it mean fewer emergencies or better reliability but also choosing the right initiatives to run. It would be a nice situation to be in, wouldn’t it?

  • Evolutionary Change of Portfolio Management

    There’s a fundamental flaw in how we manage project portfolios. What typically happens is we focus on estimated cost of work and expected profit. After all these are parameters that decide whether a project is successful or not.

    Estimated Cost and Expected Profit

    There’s whole ongoing discussion on how to estimate, when estimates give us value and whether we should estimate at all. A bottom line is that getting estimates right is extremely hard.

    A problem is that, even if we got our estimate right, the scope of a project will change anyway thus it will affect the original estimate. Few companies would bother to change the estimates but even for these few there already are some numbers in contracts and budgets that won’t change anyway.

    It seems that one of the critical numbers we use to make decisions about our portfolios is vague.

    By the way if we are in the context of fixed price contracts it automatically means that the other number—expected profit—has changed as well.

    It’s not a rare case to see these values changing drastically. I can come up with examples from my experience when, because of misestimate or increasing costs instead of margin of 30-60% the project ended up costing a few times more than the revenue a company got for doing it. Not only wasn’t it even close to breakeven but the company paid a huge toll in terms of both direct costs and lost opportunities.

    A partial solution to that is transiting to time and material contracts where the revenue is a derivative of effort invested in building a project. While that definitely helps to avoid direct loses it doesn’t really fix the variables. The time span of a project can be changed thus the absolute numbers will be altered.

    What You See Is All There Is

    Even if we potentially could get our number right it wouldn’t really help. A root cause for that is a concept described by Dan Kahneman: What You See Is All There Is (WYSIATI). Human brain doesn’t look for data points other than those readily available. In other words if we define existing and potential projects from a perspective of estimated cost and expected profit these will be the main, or even the only, inputs for decisions on starting new projects.

    This has very sad consequences. In neither case we assume that in normal circumstances we will be working on unprofitable ventures. If we are in the world of fixed price contracts the final price will directly depend on an initial estimate.

    We’ve already discovered one painful dependency between an estimate and a profit. While costs are changing the contract terms remain the same affecting profits. It is even worse than that. The price was calculated based on the same estimate most likely by multiplying it be a factor of expected margin. Unfortunately humans are crappy at estimation.

    And don’t even get me started about all those dysfunctional situations when there’s a pressure to reduce an estimate because a client has a limited budget or something.

    In either case, a picture of all the potential projects will be rosy. We won’t allow it to be different than that. We will tweak the numbers back and forth until they fit the rosiness of the picture.

    The ultimate issue of this is that, because WYSIATI kicks in, our decisions about starting new projects will be overly optimistic and heavily biased toward perceived attractiveness of our endeavors. A simple fact that it has very little to do with the real outcomes of projects or our appalling track record with assessing attractiveness doesn’t change it. What you see is all there is.

    Overcommitment and Multitasking

    The end result of this bias is easy to predict. Since all things seem to be overly attractive we tend to start too many projects. Eventually, and pretty soon, we are overcommitted beyond the point where we can comfortably finish everything before agreed deadlines.

    Even in the cases when a flash of sanity keeps us from jumping off the cliff and stop one step before there’s usually not nearly enough slack in the system to account for any emergency that would happen.

    Of course there’s no plan whatsoever in case our initial estimate was wrong and we need more effort to finish a project, because we’ve proven to be perfect estimators in the past and never got anything wrong. Oh, wait…

    What does happen next? Expediting of course. When heroics within a team is not enough we pull people from other teams just like there was no tomorrow and they weren’t doing meaningful work on other committed projects. Anyone wants to guess what happens in the projects that we cannibalized to save the other one?

    More of the same vicious cycle.

    Not only such work is ultimately inefficient but it also hits sustainability of the business as it damages relationships with clients.

    Informed Decisions

    To reverse that cycle we need to go to the first place, the point of commitment, and change the drivers that influence our decisions. Bearing WYSIATI in mind, what we need is access to meaningful bits of information.

    We need to know how our current commitments affect our capabilities over time. In other words we want to know which teams are working on which projects. Not only now but also in reasonable future. What reasonable future means will of course vary depending on a context.

    How would a new project fit available capabilities? Do we have people with the right skills and knowledge available? When are they available? How much slack do we need to be able to respond to uncertainty in existing endeavors?

    We need to know, at least roughly, what is Cost of Delay for new projects. Is it possible to delay start of this project for a month? How about longer? What kind of costs, or lost future gains will it incur?

    What is value of a new endeavor? Is it money that earn only? How about long-term relationships with a client or bringing more financial safety thanks to a steady flow of work?

    By the way, when we are talking about value, it is crucial to remember that value for our organization doesn’t equal value for a client. Of course, the more aligned these two are the better, but it’s almost never an ideal fit.

    What are the risks attached to a project? How sure can we be about all the assumptions we make?

    These are all crucial factors that we should be taking into consideration when making a decisions about starting any new project. If we don’t have them at hand, as a result of WYSIATI, they will be ignored and we’ll be back to our rosy, overly optimistic and utterly harmful view of portfolio.

    Bad news is that to do better we need pretty broad understanding of the mechanisms that drive us sideways. Good news is that once we know that the change isn’t that painful. Focusing on different kind of data will alter decision making process on a portfolio level.

  • Unscaling Agile

    A theme of scaling Agile, or Lean for that matter, is all hot these days. You will hear it all sorts of contexts: as broad as Agile and as specific as one of the methods we use. No wonder. It sells.

    You can tell that looking at tracks at Agile or Lean conferences. You can tell that looking at a rise of approaches that specifically aim at the big scale as their main target (SAFe, anyone?)

    The interesting part of the whole dispute is how rarely we question scaling up strategy. I mean it seems to be some sort of unquestionable paradigm and when you decide to go against that everyone looks at you as you were an alien. I sometimes feel like rolling out a huge program to introduce Agile or Lean in the whole organization was the only thing there was for big companies.

    How does it work for us so far? Not so well. We don’t have lots of success stories and those few that are available seem to be share at pretty much every Agile or Lean event there is. This tells a story about our success rates with scaling agile too.

    Unscaling strategies are almost never mentioned in the dispute. It is so despite the fact that we actually know at least a couple of different approaches we can use there.

    One is skunk works. The basic idea is to create a group within a company that operates pretty independently on the rest of the organization. This creates an opportunity to try out a lot of stuff that would be hard to implement in a broader context. At the same it creates an environment of much smaller scale.

    Applying Lean Startup within a big organization goes along the same lines. On the top of a product development strategy we create a context of work that is autonomous and that operates in small scale.

    Quite a different approach is when an organization decides to find a partner to outsource some of their work to. With such a situation one thing that is easily done is scaling the context down. A difficult part is to find a partner that would live be the right values and employ the right practices. But then again, it may be used as a viable unscaling strategy too.

    Interestingly enough, such approaches are rare. One exception may be outsourcing. However, outsourcing done in a common way has nothing to do with scaling down and very frequently criteria used to choose an outsourcing partner only make the whole situation worse. Believe me, I’m actually in this business on a receiving end so I’ve heard all the motivations for sending the work near-shore or off-shore.

    If you wonder why unscaling is so unpopular you aren’t going to be surprised with the answers. Either of these scenarios means losing control and that is something that management is generally allergic to. Also to make it work you need trust as high autonomy is one of key parts of the setup. Finally, there’s a risk of doing something not exactly in a standardized way which may produce unpredictable outcomes.

    Have I just said between the lines that one of the main drivers of scaling up Agile and Lean is complacency? Oh well…

    Anyway, unscaling strategy not only makes it much easier to adopt Lean or Agile but at the same time it enables fresh ideas as many constraints are typically relieved. Not to mention that it goes along the lines of autonomy, mastery and purpose which drives individual motivation.

    So the next time you hear about scaling Agile why not consider unscaling it?

  • What Value Is Exactly

    One of arguments that I repeat in different contexts is that our ultimate goal should be delivering value to our customers. At the end of the day it doesn’t matter how many lines of code or features we’ve built. What matters is how much value has been delivered.

    The concept seems to be pretty challenging in software development communities. In Lean or Agile communities it gets closer to stating the obvious. Nevertheless we don’t do that much with the obviousness. Product development, portfolio management or work organization on a team level are oh so often all about efficiency and not much more.

    After all it is way more difficult to assess value we deliver than simply count features. The interesting thing happens when we try to define what value is exactly.

    The question we should hear over and over again but don’t is: value for whom?

    A common setup is: a vendor a.k.a. a software development company, a client paying to have a product built and its users. There are obviously more complicated scenarios as well as simpler, e.g. a company developing their own product. I’ll focus on the scenario with three key groups of interest though.

    Let me give you a few examples.

    The software development company built a product for the client. It is high quality, it does the job and paying users seem to be signing up in big numbers. The only problem is that the client was toxic thus big chunk of people working on the app left the vendor. Despite the fact that value is there for the client and users the balance of value on the software development company is negative.

    If I saw such a project at Lunar Logic I would find our way out of the arrangement. By the way, it basically means that I don’t consider value for a client / users as the ultimate goal we should strive for. There has to be alignment with value on the other end as well.

    There is another product for another client. Again it was delivered with high quality, users really like it except they’re not willing to pay for the service. This time collaboration went exceptionally well. On the top of that the product was fun to build for the team. It seems that the software development company got value on their end. Users, to some point, too. But the client? Not really. This business doesn’t scale.

    Should I as the vendor’s representative reject to build such a project? I mean, a product idea is always a bet so you never quite know how it’s going to play out.

    The value equation is again imbalanced though.

    Yet another product was built in a very collaborative manner with a high quality and both the software development company and the client were happy. Except the users wouldn’t come. Why was the client happy then? They treated the product as an experiment that should verify a hypothesis. Even though the product wasn’t a success the main goal was knowledge discovery and from this perspective value was there.

    Once again one of the parties – users – didn’t get value, yet it doesn’t render the whole endeavor senseless.

    Of course, an ideal case is when not only is it a win-win-win kind of situation but also each win is roughly equally valued by each party. My experience is that it doesn’t happen very often.

    In fact, value for money metric would differ depending on how much one values money. If a few hundred dollars for a day of work of a developer seems to me like a fortune I would expect miracles for my money. If it seems like a decent or even affordable rate my expectations of value I’m going to get are different.

    When you talk about value, make it clear what value you are talking about exactly.

    To make such a clarification you first need to understand that there are different sorts of value and they are driven by different factors. Then a natural next step is to ask what these factors are. Once again it will differ much. It may be profits, employee retention, number of users, knowledge discovery, solving a problem that people have, or hundreds of different things. Only if you are able to tell which factors are important in a given context you can come up with reasonable measures of value.

    Without that value will be an ephemeral concept that we can’t assess in any meaningful way.

    This also means that we can have a discussion on how value differs for all the parties involved and which bits are the most important for us. Because most of the time we have to choose.

  • Portfolio Management: The Search for Value

    I am talking about the cost of multitasking pretty frequently. This discussion gets even more interesting when we are in portfolio management context. Why? It is so because we are dealing with extremes more frequently on that level.

    Cost of Multitasking

    Let’s imagine a situation when a software developer is dealing with three tasks concurrently. We know that it isn’t efficient. It may be based on our knowledge how multitasking affects our work but it may as well be our intuition.

    Now, would we have the same intuition if we changed the context and we were discussing a team working concurrently on three different projects? Interestingly enough, we’d be looking for arguments why in such a context it isn’t that much of a problem. Stuff like: part of the team would work on one project and another part on another project. Sounds familiar, doesn’t it?

    Thing we typically forget about is how team members would interact with each other. They wouldn’t think of themselves as of isolated sub-teams. They will be frequently looking for colleagues’ help thus they will make other people switch projects for a while every now and then. Finally, we have the coordination effort that has to done. Who is working on what, what is the status of everything, etc.

    This gets even worse when the distribution of people across the projects isn’t fixed. Then people would be thrown to one or the other initiative depending on the current situation. Why is it costly? Zeigarnik Effect describes that we, as humans, have intrusive thoughts about stuff that we left unfinished.

    In other words, if I change a project but I haven’t wrapped up my part in the current initiative I will likely be interrupting myself thinking about the old tasks. In fact, I don’t need any external factors to incur the context switching cost to my work.

    There’s more than just efficiency penalty though. The teams that are working on more than one project deliver lower quality results, as Larry Maccherone points in the results of the research run across thousands of agile teams.

    Cluttered Portfolios

    Things get even more interesting when look at the big picture – not a single team but all the teams within one organization. It’s enough to ask two questions. How many teams are there? How many active projects or initiatives are run concurrently?

    The answers with the ratio in a range about 10:1 (ten projects per team on average) aren’t uncommon. It means that our forces are spread very thin, the coordination effort is significant and the frequency of people switching projects is fairly high.

    Another question may be: what is the percentage of people assigned to more than a single project?

    Either way, in some cases we’d find that not only do we have more projects than teams but also we have more projects than people working on them. Some extreme examples I know of would show that there are 4 times more ongoing projects than there are people available to work on these projects.

    How efficient is that?

    No reasonable person would do such a thing on purpose. Yet, this is happening pretty often.

    Project Attractiveness

    If we assume the goodwill of people managing project or product portfolio, there must be something wrong with the approach we typically use to manage the portfolio. Let’s think for a while data we use to inform our decisions on starting new initiatives.

    Obviously we know the client and, at least roughly, the scope of the project. On that basis we come up with the idea how much the project would cost and what revenue we can get out of it. How do we do this? Well, we estimate.

    One problem is that, as Daniel Kahneman points, we are biased toward the most optimistic scenarios. Another one is when we do these estimates. Johanna Rothman phrases it:

    If you fall for estimation as your way of valuing projects in the portfolio, you are doomed to fail. Why? Because you are trying to predict the cost or the date when you know the least about the project.

    Typically, we base on insufficient data and use our flawed estimation skills to come up with the measures that are supposed to help us assess value of projects. That doesn’t sound like an extremely useful approach if you ask me.

    The problem is that pretty frequently that’s all we have in our toolboxes: an unreliable total cost estimate and expected income based on that very estimate. If we are really lucky we can say a bit about high-level risks too. However, if nothing else is in place the only application of risks assessment on this stage would be tweaking the income expectations so it includes potential screw ups.

    All in all we end up looking at projects through attractiveness glasses. It’s all about how much profit we can potentially earn doing this or that project. Given that we model income on expected total cost almost all of the projects will look reasonably profitable, thus all of them will be considered attractive.

    There’s a pattern our brain follows, called What You See Is All There Is (WYSIATI). It basically says that whenever we are judging something we take into consideration only evidence that we have at hand and omit data that we could potentially gather to inform our decisions better. In other words, if what we see is cost and profit we won’t automatically be looking for other data points that can tell us something about value of the project. We will just do our judgment on information we have at hand.

    If we put WYSIATI on the top of our limited and unreliable data almost every initiative would look appealing. It is no surprise that we end up with heavily overloaded portfolios.

    Where Value Is

    The question we should be addressing is not the one about expected profit, but about expected value. The problem is that the latter is more difficult to answer. On different occasions, during my presentations, I’ve had a chance to ask audiences whether they know what the value of features they build for their clients is. Few people do.

    We simply don’t think about our products and projects in such terms. Even when we do though, it solves only a part of the puzzle. One oversimplification I often notice is that we boil down the discussion about value to the users or clients only. The problem is that both parties will define value differently. Let me give you an example.

    At Lunar Logic we build web applications for our clients. We can build a product for a client that delivers valuable features in a predictable fashion. We can even help the client shape the product so we avoid the non-value adding functionality. The client would be happy – they’d got what they define as value. At the same time though, the client may simply be a toxic person who would make the team’s life miserable. Now, on our end, depending on a situation, it means that overall value of such a project may as well be negative: we would have gotten the money (one aspect of value) but lose a part of the team (another aspect of value). It is likely that the former wouldn’t compensate for the latter.

    I don’t have all the answers for the questions about value. The cases when I’d disagree with how our clients define value aren’t rare. On my end, while I can say what we value as the company, sometimes it is very difficult to assess value for initiatives we undertake. It’s not as bad as it looks though.

    We don’t need to define value in absolute numbers. If the goal is to improve the way manage portfolio most of the time we will need to answer only relative questions, e.g. which project is more valuable given the criteria that are important in a given context?

    In fact, the most valuable outcome of the discussion will not be the exact assessment. It will be a discussion itself as it will likely cover the areas we typically ignore, thus will yield in the better understanding of the situation.

    It won’t happen though unless we understand the limitations of our decision-making process on a portfolio level. Otherwise we will keep doing even more of the same thing make our teams even more inefficient and miserable.

  • Multitasking Teams

    There’s one question I ask pretty frequently during my presentations or trainings: do you think that context switching comes for free? I’m yet to see a single hand up after the question.

    Not that I believe that this is universally accepted point of view. In fact, there is a follow-up question which is: who has a boss who thinks that context switching comes for free? I do get positives for the latter.

    I’d also assume that some people, even if they believe in free context switching simply wouldn’t raise their hands. Peer pressure, you know.

    I’m happy with the assumption that awareness of costliness of context switching isn’t ubiquitous and definitely there are different assessments of how costly it is exactly. Still, I’d say that basic understanding that we pay a context switching tax is pretty common.

    Context Switching Cost

    After all, it oh so obvious to predict how texting on the mobile while walking through a crowded street is going to end. Or playing Angry Birds while driving. Or driving, having a call, lighting a cigarette, overtaking another car and shifting gears, all at the same time (a true story; I’m glad that the passengers made it alive).

    It gets a bit less obvious when it comes to our workplaces. On occasions you’d hear things like “do it in the meantime” or “can’t you work on both of these things concurrently?” (Sure, I can. As long as you want both of them to be late, that is.)

    The real fun starts on yet another level though. Concurrent projects. When we aren’t discussing individuals but teams and not atomic tasks but projects, suddenly the assumptions that concurrent work on them doesn’t hurt becomes surprisingly common.

    The reasoning is that one team member will be working on one project and another team member on the other project. I’m always astonished that this thinking pattern is there even when there are more projects than team members… Anyway, let’s assume the situation is not that dramatically bad.

    There is still a problem of multitasking on a few different levels. First, there’s planning and coordination. Who should do what for how long? Even if team members typically do have comfort of being able to focus on a single thing there are people on the team who constantly switch context between all the projects that are run.

    Then, there’s regular communication. Typically ad-hoc communication can be a distraction. We willing pay the price for the distractions because we get value of those discussions. They are relevant for people because they touch the matter of the project they run. Well, as long as it is about the project they run. That isn’t necessarily true if a team run a few projects.

    Finally, there are situations when people would change the context of the project even if we don’t plan they would. What happens when someone is stuck? They’d ask for help. Whom? The person who is likely to help them. Does it mean only people from the same project? Not really.

    Obviously we’d get some of that even if a team works on a single endeavor, but such cross-team interactions are usually way less frequent, thus way less costly, than those within the team.

    This is sort of a gray area that is often forgotten even in organizations that are aware of the cost of multitasking. This is one of the reasons why visualization of project portfolio is so important. Each case where a team is coping with a few different projects or products at the same time should at least spring a discussion, as this is an obvious inefficiency.

    Multitasking on a team level is no less painful than on any other.

  • Estimation Quality

    OK, so I am on yet another agile event. I’m sitting there in the last row and a guy on the stage starts covering estimation. That’s interesting, I think, maybe I’ll learn something. After all estimation is something that bothers me these days.

    Planning poker, here it comes. Yawn. People would pull the card with their estimate, yadda, yadda, yadda, they’d discuss and agree on a story point value. Yawn. The distribution of estimates would be normal.

    Wait, now the guy has my attention.

    So apparently he knows the distribution of the estimates. Good. How about checking what the distribution of lead times for historical data is. Because, you know, there are people who have done that, like Troy Magennis, and it seems that this distribution isn’t normal (Troy proposes Weibull distribution as the closest approximation).

    In short: if your estimates have a different distribution than historical data for the tasks that the team has completed the estimates are crap.

    Back to the presentation. The guy points how estimates for big tasks are useless in his context. Well, yes, they are. All the estimates in his context are crap from what I can tell. Then he points that we should be splitting tasks to smaller ones so planning poker makes sense and produce more reasonable estimates.

    Um, sorry sir, but you got it wrong. If you are using estimates that are distributed differently than historical lead times you are overly optimistic, ignorant, or both.

    How about this: I will not poke you in the eye with my pen but you will check the distribution of the estimates and the past lead times. Then you will recall some basic stuff from statistics course and stop selling crap that we can’t possibly answer the question: “when will it be done?”

    OK, rant aside. I don’t say that coming up with the idea how long it will take to build something is easy. Far from that. I just say that there are pretty simple things that can be done to verify and improve the quality of the estimates.

    Once you got the estimates look at their distribution. If it is different than what you know of historical data (because you’ve checked historical data, haven’t you?) the estimates don’t bear much of value.

    In fact, you can do better. Once you know the distribution of historical lead times you may use that to model estimates for a new project. You don’t really need much more than simply basic work break down. You can take the worst case scenario from the past data and assume the best case scenario is 0 days and let the math do its magic. No guesswork whatsoever needed.

    The credit for this post should go to Troy Magennis, who opened my eyes to how much use we can make out of limited data we have at our hands.

  • 5-Minute Board Test

    I discuss different Kanban boards or task boards with their teams pretty often. It’s not uncommon for me to see a board of a team that I know nothing of. I like these moments. I typically challenge myself to make sense out the visualization as I stare at it.

    Some parts are rather obvious. Typically the process isn’t that difficult to figure out. Usually I can tell who is working on what at a glance too. On the other hand something that should be obvious, but often isn’t, are classes of service – what they are and which items are of which class. And then there are lots of small different artifacts like blockers, comments, subtasks and what have you. Those do require some additional explanations.

    One of common sins of teams adopting Kanban is making visualization too complex. We do say visualize everything, but obviously it means “as long as it adds value.” Boards tend to get more and more complex over time as we typically want to track more information as we understand better how the work gets done. We really don’t need to complicate things more than necessary on the day one.

    So what makes a board a good one? The board is good when it does its job as an information radiator. This happens only when it is easy to comprehend and understand for the team members.

    This is a core of my 5-minute test to verify whether the board is designed well. The test is simple.

    A random team member should describe what is happening on the board to an outsider – someone who neither is a part of the team nor works with it regularly. If the outsider has any questions about specific things in the board they should ask and get the answers from the team member. The whole activity is time boxed to 5 minutes (thus the name).

    The board passes the test if at the end of the task the outsider can tell what exactly is happening in the team: who works on what, what are the problems (if any), what is the progress of work, how the team knows what to do, etc.

    One could argue that for bigger, more complex boards 5 minutes is not enough. I don’t agree. When we are interacting with the boards we rarely have more than just a couple of minutes. Of course team members would know part of the design without any explanation. That is why I’m giving an outsider full 5 minutes.

    The more stuff there is to take into consideration when making routine, atomic, everyday project decisions the bigger the chance someone would misinterpret part of that. That’s the point where understanding the board, and the process, isn’t fully shared across the team anymore. That’s the point where people start acting differently despite identical input.

    This is exactly the problem we tried to address when introducing information radiators in the first place. If the board doesn’t solve that problem it simply doesn’t work.

    Would your Kanban or task board pass the 5-minute test?

  • What Does Project Management Mean to Me

    I was poked to answer the question on meaning of project management by Shim Marom. Since my work, and this blog, evolved away from covering what can be called traditional project management approach long ago I thought it may be a good occasion to restate the purpose of the blog as well.

    Se here it is.

    Getting the stuff done

    The simplest answer, from the top of my head, is that project management is all about making it happen. Of course it’s not a single person’s effort. It’s more orchestration of all the stuff happening around but at end of the day the discussion always starts with what got delivered.

    But wait…

    “There is nothing so useless as doing efficiently that which should not be done at all.”

    ~Peter Drucker

    Getting the right stuff done

    The discussion on the right stuff is primarily product management / product ownership thing but most definitely it’s not beyond the scope of what I consider project management. After all, if you’re doing the wrong thing there’s no credit to anyone. A project manager isn’t an exception here.

    So yes, it starts with grasping the business case, understanding how the project corresponds to it and actively working on that match.

    When we are on the right thing though, it’s inevitable that doing right thing versus doing thing right argument will pop up…

    Getting the right stuff done right

    Getting the thing right is about the quality. If there’s no quality built-in it’s going to come back to you and bite you in the butt. Painfully. While I’m as far as possible from introducing oppression tools like quality procedures and such stuff, quality doesn’t automagically happen. One needs to create environment where high quality thrives and is encouraged.

    What exactly the high quality means is obviously contextual but from my experience it’s not that difficult to describe the quality in any given context.

    If nothing else you can always make the next project better than the last one.

    Getting the right stuff done right and improving

    This brings me to one of the areas I sunk into when I started flirting with Kanban – continuous improvement. There should be no pride in doing same stuff again and again. Unless you’re a freaking genius and know it all about project management, that is.

    Personally, I couldn’t be farther from that. That’s why I have an ambition to improve. Improve the way I work but also improve the way everyone around works. It’s not that easy as it sounds though. The prerequisites are: understanding how the work gets done and learning like hell.

    Without understanding work we are like children in the fog – clueless and lost. Learning means that we broaden our horizons and go beyond that carrot and stick method our first managers were using all the time.

    Getting the right stuff done right, improving and building trust

    This one is a classic last but not least. In fact, I believe that without trust you will struggle across the board. And I mean trust here in a very broad sense. One, it is about building trust within a team. Without that people wouldn’t become vulnerable, thus would restrain to become transparent. Without that a project manager would always have limited information of what’s happening in an endeavor they’re supposed to lead.

    Second, and more importantly, it’s about building trust with a client. That’s where the real fun starts. It’s really rare when a client would take the first step and will start to be open, transparent and vulnerable. The good part is that they will likely do so once they see it on the other side. But this is fear that every project manager, and every team member, has to overcome by themselves.

    The example, as usually, should go from leaders.

    So this is it. I believe this definition works well for me right now and the stuff I deal with fits the picture neatly. It doesn’t matter whether I talk about Kanban, organizational culture or team management. It doesn’t matter whether I deal with a portfolio level, a project level or a task level. It’s all there.

    Project management is about getting the right stuff done right, improving and building trust.