Outcomes not outputs
One of the key takeaways I got from reading the excellent book Lean Enterprise is the idea that you should focus on outcomes not outputs. This is a powerful idea for strong agile teams, and ties in well with the Agile Manifesto. If you understand this concept, you can make a lot of the annoying conversations around “velocity” and “efficiency” go away. But what does that actually mean?
Traditional management focuses on outputs, not outcomes
Traditional management theory comes from manufacturing and has an emphasis on outputs. You should aim to optimise a system to produce more outputs at less cost. You measure the efficiency of a system by how many outputs it makes for given inputs (costs). So if you have a factory that makes widgets, then widgets are your outputs, and your inputs are people (workers who make widgets) and probably raw materials.
The job of the manager is to:
- define the best and most efficient system for producing these outputs
- make sure everybody follows that system
- measure how effective the system is (defined by outputs vs inputs).
This thinking has two problems. First, it assumes the manager knows the best way to make the outputs. Lean manufacturing says it is the job of the workers to come up with the best system and to keep improving it. That is the concept of Kaizen (continuous improvement). It comes from the workers, not the management. The second problem is that it doesn’t even make sense when you are not doing manufacturing work (repeating the production of many discrete identical things), but knowledge work (continuous iterative collaboration work, i.e. software development).
Software development is knowledge work, not manufacturing work
Knowledge work doesn’t involve spitting out of many identical widgets. It involves a bunch of people coming together, brainstorming, coming up with something, changing it. Maybe starting again. Maybe throwing it away and going with something quite different. Then working on it some more and eventually releasing it in some form. Think of people making a movie, putting on a play, doing a music tour, organising a festival. Software is much more like that than it is like manufacturing widgets in a factory.
Nobody would try to measure the “efficiency” of the “outputs” of people putting on a play, so why do we do it for software development? We should focus on the outcomes, the results, instead. How many people come to the play. How many good reviews and ticket sales the movie gets. Or how successful your festival is. Not how many minutes long the movie is. Or how many stages and bands you have at your festival.
Traditional management thinks outcomes are for the business, not for IT
If you can convince your managers of this, they might say “fine, it’s about outcomes, not outputs. We get that. We’re “the business”! But you let us worry about the outcomes, that’s our job. That’s our responsibility. You’re building the things, you focus on the outputs, that’s your job”. This is a total fallacy. Agile encourages us to break down this split. Business and IT should work together, as one team. The whole team is responsible for the success or the failure. The whole team is responsible for the product. And the whole team is responsible for the outcomes.
This is why it is hard to do Agile if you have outsourced your IT. Everybody has to be on the same team. And if you have product owners and UX people working for one company, who is paying a fixed price contract to a different company for the development and testing, it’s hard to all be on the “one team”.
We can’t measure outputs anyway
People have been trying for decades to find ways to measure the outputs of software work. What metrics do you use?
Function points – these are the WORST, yes, the ACTUAL WORST
People initially tried using “function points”. Every “function” that you build and test is one “point”. But what the hell is a function? Is Login a function? Happy path? What about unhappy paths? Are they one function, or one for each? Including forgotten password or not? You can go around in circles trying to define this a hundred different ways. It can be gamed easily too (adding redundant paths to increase point count). It encourages poor behaviour (spewing out features, even low-value ones, at the cost of improving the quality and test coverage of important features). And it assumes that “more functions is better”. Who says it is?
Remember, around 80% of software never gets used. That’s the metric you should be worried about. And you don’t improve that number by adding more functions. you improve it by taking away functions that nobody cares about.
There is also valuable work that will be badly measured by this terrible metric. For a while, I worked with a team that spent two years and millions of dollars and did not build one single function point. And their work was probably the most valuable of all the many teams working on their platform. They were doing a major architecture rebuild. They were moving from a shabby old monolithic legacy application to a lighter, faster, more resilient microservices architecture.
Not one new function point, but it improved the scalability, testability and resilience of the platform hugely. Which was a great outcome. So don’t use function points, ever. If someone talks about function points, slap them, or sack them.
What about velocity?
So we can measure outputs with velocity, right? How many “points” we are doing? We could try, but we really shouldn’t measure our “performance” with velocity.
There are many reasons why you shouldn’t use velocity to compare teams. But to summarise:
- velocity is difficult or impossible to baseline and compare
- it is based on a team’s context and every context is unique
- if you use it to “measure” a team, they will freak out and get upset, or game the metric, or likely both.
Velocity should be used by a team to estimate their progress towards a release goal, and that’s it.
Maximise outcomes and minimise outputs
Teams should focus on outcomes, not outputs. Management should focus on outcomes, not outputs. Product owners and their stakeholders should focus on outcomes, not outputs. Why? Because of two reasons. Firstly, outcomes are what counts, because outcomes are customer outcomes. Secondly, outputs don’t really matter. In fact, if you are achieving outcomes, then less outputs are better than more.
Outcomes are what matter
We’re all in this to deliver outcomes. Those outcomes will vary depending on what you’re doing. For a business, that will probably be business outcomes: more sales, or more customers, or more sales per customer, longer customer retention, and so on. Or they could be more general like customer satisfaction or market penetration. For a non-profit, they could be things like awareness or reputation. Make sure you know what outcomes you are trying to achieve before you build anything. Don’t build anything unless it delivers outcomes. The extent to which you achieve outcomes is how successful your work is. Not the extent to which you produce lots of output or deliver lots of “stuff” on time and on budget.
The best outputs are no outputs
Here’s a crazy idea to get you thinking. First off: we all want better velocity, right? The team with the higher velocity is the “better” team? Or is working “better”? Maybe. Try thinking about this, though. If we actually want outcomes, not outputs, and I hopefully have convinced you of that, then we should actually be trying to minimise outputs for the same outcomes. Huh? Confusing? Try thinking about it this way.
A thought experiment
A product owner says “our conversions for this sales form are down. We need more sales so more conversions. There has to be a way to increase them. Go!” And three teams step up to the plate to solve this.
The first team after a month says “we’ve built an analytics engine that plugs into our data warehouse and can deliver targeted sales messages based on multi-variate segments. Results so far are great. We nearly killed ourselves to deliver it and had to cut a lot of corners but we got there. We did 100 points.” The second team after two weeks says “we figured webchat could probably solve this, and there was an off-the-shelf solution that we could pretty easily plug it in, so we did. Works well. Results so far are great. We did 40 points”.
The third team after one day says “um this isn’t a software problem. We checked the instruction copy and it’s terrible, full of mistakes. We just wrote new copy and put it into the CMS and the results so far are great. This took 10 minutes of text editing. Then we went to the beach. Points? Zero.”
Each team delivered the same outcome. One team delivered 100 points, another did 40, and the last team did none. Who got the best result? Which team gets the medal? The third team. They delivered the best outcome with the least amount of outputs. That’s the objective. They achieved outcomes while creating no technical debt, no fragility, no complexity, no defects, no cost, and no waste. That’s winning. Zero velocity. Not one hundred. Zero.
Remember the Agile Manifesto, especially the part about Simplicity
Remember the Agile manifesto? My favourite principle is this one:
Simplicity–the art of maximizing the amount of work not done –is essential.
This is a big “A-ha!” moment that a lot of people don’t understand. Even some people who’ve been doing Agile for a while. It is “Ha” if not “Ri” level thinking (if you don’t know what that means, I’ll explain it later, or do a search if you’re really curious). But think about this: the objective is not to maximise the amount of work done, it is to minimise the amount of work done. To maximise the outcomes, while minimising the outputs.
