Tag: value

  • Value for Money

    There’s one observation that I pretty much always bring to the table when I discuss the rates for our work at Lunar Logic. The following is true whenever we are buying anything, but when it comes to buying services the effect is magnified. A discussion about the price in isolation is a wrong discussion to have.

    What we should be discussing instead is value for money. How much value I get for what I pay. In a product development context, the discussion is interesting because value is not provided simply by adding more features. If it was true, if the following dynamics worked—the more features the better the product—we could distill the discussion down to efficient development.

    For anyone with just a little bit of experience in product development such an approach would sound utterly dumb.

    Customers who will use a product don’t want to have more features or more lines of code but they want their problem to be solved. The ultimate value is in understanding the problem and providing solutions that effectively address it.

    Less is more mantra has been heard for years. But it’s not necessarily about minimalism, but more about understanding the business hypothesis, the context, the customer and the problem and proposing a solution that works. Sometimes it will be “less is more”. Sometimes the outcome will be quite stuffed. Almost always the best solution will be different that the one envisioned at the beginning.

    I sometimes use a very simple, and not completely made up, example. Let’s assume you talk to a team that is twice as expensive as your reference team. They will, however, guide you through the product development process, so that they’ll end up building only one third of the initial scope. It will be enough to validate, or more likely invalidate, your initial business hypothesis. Which team is ultimately cheaper?

    They first team is not cheaper if you take into account the cost of developing an average feature. Feature development is, however, neither the only nor the most important outcome they produce. Looking from that perspective the whole equation looks very differently, doesn’t it?

    This is a way of showing that in every deal we trade different currencies. Most typically, but not necessarily so, one of these currencies is money. We already touched two more: functionality or features and validation of business hypothesis. We could go further: code quality, maintainability, scalability, and so on and so forth.

    Now, it doesn’t mean that all these currencies are equally important. In fact, to stick with the example I already used, rapid validation of business hypothesis can be of little value for a client who just needs to replace an old app with a new one, that is based on the same, proven business model.

    In other words in different situation different currencies will bear different value for a purchasing party.

    The same is true for the other side of the deal. It may cost us differently to provide a client scalable application than to build a high quality code. This would be a function of skills and experience that we have available at the company.

    The analogy goes even further than that. We can pick any currency and look how much each party values that currency. The perception of value will be different. It will be different even if we are talking about the meta currency—money.

    If you are an unfunded startup money is a scarce resource for you. If at the same time we are close to our ideal utilization (which is between 80% and 90%) additional money we’d get may not even be a good compensation for lost options and thus we’d value money much less than you do.

    On the other hand, if your startup just signed round B funding abundance of available money will make you value it much less. And if we just finished two big projects and have nothing queued up and plenty developers are slacking then we value money more than you do.

    This is obviously related to current availability of money and its reserves (put simply: wealth) in a given context. Dan Kahneman described it with a simple experiment. If you have ten thousand dollars and you get a hundred dollars that’s pretty much meh. If you have a hundred dollars and you get a hundred dollars, well, you value that hundred much, much more.

    Those two situations create a very different perception of the offer one party provides to the other. They also define two very different business environments. In one it is highly unlikely that the collaboration would be satisfying for both parties, even if it happens. In the other, odds are that both sides will be happy.

    This observation creates a very interesting dynamics. The most successful deals will be those when each party trades currency that is low-valued for the one that is valued highly.

    In fact, it makes a lot of sense to be patient and look for the deals where there is a good match on this account than to jump on anything that seems remotely attractive.

    Such an attitude requires a lot of organizational self-consciousness on both sides. At Lunar Logic we think of ourselves as of product developers. It’s not about software development or adding features. It’s about finding ways to build products effectively. It requires broader skills set and different attitude. At the same time we expect at least a bit of Lean Thinking on account of our clients. We want to share understanding that “more code” is pretty much never the answer.

    Only then we will be trading the currencies in a way that makes it a good deal for parties.

    And that’s exactly the pattern that I look for whenever I say “value for money.”

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

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