Frugal production
Let’s think about this enterprise philosophy hit song:
- I want to satisfy the needs of users, buyers, managers, stakeholders.
- Therefore I want features.
- Therefore I want to optimize the production of features.
- In other words I want to maximize the production of features.
Imagine that big bank. It wants to solve problems for its advisors, or even its customers. With some help from specialists at every step, the bank formalized requirements in a backlog, organized RFI and RFP, selected a software package, started a project, set up constraints to make sure everything is delivered on time and budget, mounted and unmounted every corresponding team.
At every step, the bank relied on the result of previous investments, results of which were validated, and thus considered right. If everything done before is right, we only have one thing to measure when developing: the speed of production according to specifications. I may be user stories, man.days, lines of code, green tests in a campaign, whatever.
We maximize production of features because we don’t want to come back to what was already validated, and because we don’t know how to do all the steps at the same time. In other words, because it is easy. As a consequence, we measure the accumulation of things on top of accumulated things. This logic is the cause many a failed project.
Jeff Patton teaches us that the goal is to optimize outcome (i.e. changing behavior) to improve impact (i.e. consequences for our organization), while minimizing output (i.e. production).
How to do that concretely? As said earlier, we maximize output because it is easy. Therefore solutions will be hard. This is good news: it is an occasion to take some advantage over your competitors.
Validation
We must move quietly. Take the time to verify that what we throw out the door is useful. Consolidate fundations before adding new floors.
As Jim Benson says, “Software being ‘Done’ is like lawn being ‘Mowed”. Software gets interesting when it gets into users hands. It is finished when it is decommissionned. Make this official, by adding a validation/understanding/learning/feedback step at the end of the value stream.
A feature to release is not code to produce. It is an outcome hypothesis. John Cutler insist on talking about bets. Once the code is released, we need to evaluate its consequences, and decide where to go from there:
- It’s perfect we can stop iterating.
- We should try modifying this or that.
- We need more info.
- Let’s deactivate or remove it.
- And so on.
By the way, if you doubt, like you should, of features usefulness, you should limit the number of experiments you run in parallel. An experiment takes time to reveal its secrets. This delay is actually an interesting topic to think about. Among other things, it helps understanding why our so-called experiments are not scientific. Cynefin rather talks about probes.
Pull system
Limit your WIP (Work In Progress, i.e. the number of things being worked on), in all steps of the stream, including studying/prioritizing. By doing so, you will avoid preparing items when the next step is not ready to take it. Your backlog will thus remain under a reasonable limit.
- The first step of the stream is a prioritized list of problems to solve, ideas, wishes, unverified asumptions. You study these topics by priority, when you have the capacity to take them. That is to say, when it’s useful to think about them.
- Then you can think further about them: “what for”, split, explicit the goal and constraints, share understanding…
- Then development if needed, test, deployment, and so on.
- And then, validate the need, gather feedback to iterate.
So, step by step, you push features from the last step: impacting the world.
Of course, it only works if items are small. How small? If you’re beginning, it’s never small enough. If you have more experience about flow, and you know why it’s too small, then improve your process to decrease the transaction cost, and then make items smaller.
Wrapping up
Let’s fix the logic described above. Instead of:
- Users have needs.
- So we must produce features.
- So we must optimize feature production.
- I.e. we must maximize feature production.
Let’s try:
- Users have needs.
- We might satisfy those needs with features.
- So we must optimize feature production and impact.
- I.e. we must minimize feature production while maximizing impact.
When you use a product, you are delighted when you can see right away the feature you need. It’s a nice surprise to use it feature fluidly, the way you expected. It’s a change, compared to those products crawling under menus of sub-menus to propose all potential options, endless forms to support every possibility, just in case.
Propose the product you love using:
- Verify features usefulness.
- Do less things in parallel, and finish them.
- Focus on users.
It’s never too late to do things properly. It’s always time to validate the hypotheses induced by upfront investments, however huge they are.
AAAgile 
3 comments