In my previous post I have discussed estimates and its value when planning our work. In that same post I have mentioned that it should be about the combination of creating value (effectiveness) against reducing costs (efficiency), the so-called return-on-invest.
There are different ways to define the value of a product. Sometimes it can be straightforward that a certain investment in a product leads to a higher revenue because people tend to buy more or pay a higher price. In this case you can conclude in hindsight that if you earn more than you have invested, it was the right choice to invest. Unfortunately in reality it is not that simple to do that math, since typically more than one action/change is done and it typically takes some time to observe the outcome of that action or change. Additionally, many other factors, quite often from outside, could have influenced the outcome as well. So you are never sure that both are fully corelated.
Let me take a simple example. You are selling product X and you have decided to automate all your tests, so that your customers are much more happy about the product. Of course you measure your current market share and the number of products returned due to defects. After some substantial time, you have automated all tests and again you run the same measurement. You noticed that your market share has increased with 10% and the number of products returned has been reduced with 10%. So you conclude that you followed the right strategy by automating all tests.
In the meantime, your only competitor decided to focus more on a different set of products and therefore decided not to sell their likewise product anymore. Are you now quite sure that the mentioned success was really a (big) success because of the test automation?
Therefore in the agile world it is quite often stressed that creating short feedback loops are important. It will at least reduce the number of external or additional factors that could have influenced the results as well. It might be a good practice to keep the time between collecting the problem you want to solve until the moment that you actually deliver a solution to the end user as short as possible. Furthermore, within a complex environment, we are quite sure that we are not going to find the golden goose in one run, so it is even a great idea to iterate multiple times while making small improvement steps.
Apart from companies, even companies that feel that they are agile, who still are not collecting and checking with (real) end users, I have noticed some elements in the chains between problem collected and solution delivered that are common practise and not helping us in becoming more agile and delivering the most valuable products.
The first element is about the length of the chain: how much time is spent on simply waiting, so doing nothing, creating no value and just burning costs. This good old waiting time sometimes quite exceeds the time being really busy with creating the value. It can be waiting on many different things, like another party who needs to do something before you can continue, specialists waiting for another specialist finishing their part (typical for the waterfall approach), waiting for someone higher in the food chain to give approval, et cetera, et cetera.
The second element is about losing information when transferring information, which is worsened if it is connected to decision making as well. There is a lot of research that shows how much information is not known of lost when decisions are made, specifically in bigger organizations with multiple management layers. One of the key aspects of “good agility” is to push down decision making towards teams as much as possible, thus looking for as much autonomy as possible. In practice, multiple management layers and the need to keep control of decision making within these layers are actually obstructing autonomy. Having decisions to flow through the hierarchy both lead to poorer decisions because of loss of information accuracy as well as a longer waiting time as indicated in the previous paragraph.
In practice I notice that companies in their transformation to agility (or their interpretation of agility to be more precise) typically create a kind of hybrid structure, so e.g. have kind of agile teams that are free to do a lot of effective things within the own agile team bubble, preceded by a long multi-entity problem definition and long multi-entity solution delivery process. The latter harms effectiveness much more compared to the locally-optimized gains.
By simply counting the number of (waiting) steps and measuring the number of handovers before the solution to a specific problem is delivered, will give you some insights on this topic. And next by removing one of two of these obstacles at the time, you will enhance your agility and with that the chance to quickly relate the value of your product to the costs, because you are then working towards shorter feedback loops.
