Agile Culture Part 3 - Learning Organisation
Last time, we looked at Striving for Quality and how that means not just ensuring that what you produce isn't simply defect free, but also the right thing, and produced in the right way. To do that, an organisation needs to be able to learn. This is a problem for many organisations. In many organisations, learning is not only not encouraged but is often unofficially discouraged, or worse, it's officially and actively discouraged. I don't mean training budgets getting reduced here. Learning new skills is an important part of organisational learning and people should be given the opportunity to do so, but I'm talking about something different. I'm talking about an organisation learning whether what they are building is the right thing or not. And whether the way they are building it is the right way to build it Or whether the organisational structure they have is the right structure. What I'm really talking about is organisations learning how to become better at everything they do.
Most organisations are afraid of learning. Why? It seems like such an obvious question - is what we are building, what people want? Organisations will say they are interested. They will quote sales figures and user numbers and so on, but dig a little deeper and they shy away. Did that particular feature meet its goals? Don't want to know. Did that project succeed in the market? Don't want to know. Why? Because if it isn't performing, someone in the organisation was wrong. And they might be important. So it's best not to find out. I have asked about whether a particular feature that a team worked on was meeting its user uptake goals and been told "We don't measure that because that way no-one gets fired for telling the product director that they picked the wrong thing to build". Organisations are afraid of learning because they are afraid of failure.
If you want to do learning properly, there is a cycle you need to run through - hypotheses, measurement, learning. We have a hypothesis - we think that if we do X then Y will happen. As part of the hypothesis we define what measurements we need to perform in order to prove or disprove the hypothesis. We then perform the experiment - we do whatever X is and perform the measurements to see whether Y did or did not happen. Then the important bit - we check the result against our expectations and we learn from that. We adjust our assumptions. We take a different path if necessary. We create another hypothesis and go around the cycle again.
Most organisations do not do this. They have a poorly defined idea rather than a testable hypothesis. They don't define measurements up front. They don't perform a real experiment, instead coming up with measurements on the fly that are intended to justify the initial position rather than really see whether it was correct or not, and they almost never, ever learn. They don't go back and see whether their initial assumptions were correct. That would be dangerous.
I worked for an organisation where every project that came through the online channel claimed as their success criteria a 2% uplift in customer usage. Why? Because 2% was the organic growth in customer numbers year on year. So when 2% was announced at the end of the year, every project could turn around, pat themselves on the back and claim success. The dev team suggested enhancing the analytics so they could track usage feature by feature and that was knocked back. Why? Because that claimed success was tied directly to people's bonuses for the year. If they started to measure the real figures, a lot of people had their bonuses at risk. Real data was very dangerous.
In order to embrace learning, organisations need to decouple the success or failure of experiments from the success or failure of people. Experiments will fail. Assumptions will be wrong. Markets will not react the way you though they would. The success or failure of an individual feature should not determine the success or failure of the team that produced it. They did the best they could using assumptions they thought were correct at the time. The important thing, the thing to really reward, is how much they learned from that failure and how quickly they learned it.
If the team spent a year building a product, spent all of their budged, launched it and it failed, that's not a great outcome. The best we can do is learn not to do projects like that again. If, however, the team spent the first month identifying assumptions and doing small experiments to test them, then learned after that first month that the product would fail, that's a much better result. I worked with a team that was considering a new product. The time-frame to build it was 9 months with an $8 million dollar budget. The plan was to build, release and then learn whether it would succeed. Instead, the team identified a key assumption - a particular percentage of people who were offered the product would need to take it up to make it viable. So they went to the call centre, gave them a list of 1000 potential customers and asked them to call up and make an offer. The call centre charged the project $2 per call. So for $2000 and 2 day's effort, they could prove or disprove that key assumption. What they actually did was try 5 different offers on 1000 people each. So $10,000 and 1 week later they had their answer - none of the offers were popular. No one wanted it. The project was cancelled. The organisation saved $8 million and 9 months of a team's time. That's what learning is about.
The faster we can identify and test assumptions, the faster we can go through the learning cycle - hypothesis, measurement, learning, and the better the result will be. Organisations that really want to be agile must embrace this learning cycle as they way they operate. Everything should be an experiment, with a defined and agreed set of measurements up front. Setting up a new team - experiment. Launching a new product or feature - experiment. Changing a process - experiment. Hiring new staff - experiment. New executive remuneration scheme - experiment. Anything and everything the organisation does - experiment.
The better they get at doing small experiments, the faster they will learn and the better they will become. In changing markets, learning isn't just about being better. It's about survival. As Darwin wrote in On the Origin of Species - "It is not the strongest of species that survive, or the most intelligent, but the ones most adaptable to change". W Edwards Deming said it too - "It is not necessary to change. Survival is not mandatory".
The biggest obstacle to embracing a learning organisation is fear. To overcome that fear, we need to decouple the results of experiments from the success or failure of people. We need to reward learning. In doing that, we take the next step - enabling people to be the best that they can be. And we will look at that next time.