Less is more

(*)

 Agile is good and has helped a lot, but it doesn't solve it all. "Agilists are killing the planet", said Gabrielle Benefield on a GOTO Conference presentation. I'll share here why.

Some people have assumed that agile is a way to be faster, but it's not, it's just a way to respond faster to change. You won't find in the agile manifesto anything saying we are making software faster.

We've evolved from trying to get the objective with a cannonball with waterfall, spending a lot of resources upfront, fingers crossed that we got the objective, to a machine-gun in agile, getting multiple shots, being able to adjust as we go. It's been a great improvement! 

We are now getting the stuff that stakeholders requested, on time, and on budget, adjusting and through continuous delivery, feedback and continuous improvement.

So, if we now get with the features planned on time and on budget, does it really matter if we are delivering the wrong thing, for the wrong people?

With a machine-gun you might be increasing the odds of getting the target, but also a lot of bystanders on the way, making it difficult to know which was the actual target in the first place, and therefore getting a lot of waste, so output is not necessarily a good thing. 

We've increased the odds of success using a machine-gun, when here what we really want is a targeted sniper gun.

Stop building the wrong thing righter. Build the right thing.
It sounds a lot like waterfall, doesn't it?

At the risk of boarding a subject I've already covered, with the relay race example here, I'll approach it from Gabrielle Benefield's perspective, to make some counterintuitive and polemic asseverations, and give it in a Product Management view.

What they want

Let me ask you something, Why do you go to Ali Express?  Are you going there to check what's the brand new feature they've released on the page?
No! You're going there to make a purchase. 

So, achieving a goal of finishing 35 features shouldn't be what it's applauded by itself alone, but instead, we should ask ourselves, are we making more money? would it have been the same if we delivered just the main 3?
Sometimes adding more features than the ones needed is what actually decreases the user experience, making the product less likable.

Keep the product aligned to its vision, doing more features isn't directly proportional to more money. This isn't something new, Tom Gilb started mentioning this back in the '60s but it took a really long time for people to pay attention to this.
So making the assumption each feature we do is worth X amount of money does not make sense on a planning stage.

Don't ask the users what they want, nor the devs about what they think the users want.

Ask data instead, it lies less than people. 
Onsite customers are usually a particular fraction of the general user population. So they might not see the actual use people will end up giving. Sometimes people don't get what involved customers consider to be simple. Consider as well that if you ask a "1860s chariot user" what they want, they would ask you to build faster horses. 

Observing the users is how you will really learn. Ask yourself, What's the user's goal?: Build personas.
Have a clear idea of where you are, and then where you want to be. Your goal should be to UNDERSTAND users, understand the problem deeply before you aim to solve it.

A nice example of this is one toothbrush manufacturer project idea: 

Let's do a toothbrush for kids, a little toothbrush. Little people, little toothbrushes. Makes sense.

When the product leads ran a user experience analysis, they realized that kids grab the toothbrush with full hand grasp, as they have no fine motor skills, so they changed the product altogether and made big toothbrushes that the kids can grab easily, which actually were a big success in the market. 

How do you know what the right thing is? With agile we've optimized the process to get the most important 20% out to the market in an efficient way, but the important thing to figure out now is which is that precise 20%. 

Set the target outcomes, they are the poka-yoke (a.k.a. APB in Argentina, where I'm from) of product development. Doing this first you'll make it hard for yourself and your team to build the wrong thing. We are so good at building things fast, that it's easy to build the wrong things.

Back to the Ali Express example, if you are a PO for Ali Express if you deliver products in three weeks, and your desired outcome is to deliver products in a single week, all features and enhancements then have to be aligned with this idea.

Aim for outcomes

If you plan based on outputs you will commit to a certain future. Contracts will force you to get those.
Stop pretending you can see the future. Keep options open but be ready to execute quickly.
We should aim to get out with the right product, not survive in the market. Survival is the slowest way to commit suicide in software development, here it's more "arrival of the quickest".

Outcomes set a direction and there are many ways or options to achieve it.

Outcomes and options are fractal, high-level outcomes for the company, and subdivide into options that we think will get there. Build Impact mappings to understand the size of the opportunities.

How do you know what the right thing is?. Truth is you don't know. Prod requirements are more prod guesses. Stop guessing, start testing. Run multiple options fast. Make the unknowns known, highlight risks. Get to the users early and often.

Make outcomes measurable

Measurable things can be quantified. But mind we don't measure to get the precise numbers: we don't do poker planning to get the best estimates, but to share knowledge.

Ignore your mother, be fast, dirty, and cheap.

"Why are you building that way if you don't even know if it works?"

"Well in Q4 we are going into a user testing phase and do all this research on it." 

"Don't you have friends or family to ask them earlier?"

Get fast feedback, reduce the risks of waste.
Always prioritize to get the right product with defects instead of the wrong product with defects. Sometimes telling your team the product is unusable they won't get it, so make the effort to get your team to spend a day closer to real users and their experience. It won't require more than a minimal investment and will get the alignment you need from your teams.

Find ways to get the feedback, look at their usage of your product. Avoid incremental feature farming. Features are not the experience. The game is to hit the target firing as few bullets as possible.

Current legal contracts incentivize building more which is concerning. Velocity and cycling time measurements push developers to build more, rather than stop and deeply think about what should we build.

Aim for the minimum viable, not the maximum possible.
Measure as you go. You need to get to your target as quickly and with as few features as possible.
POs Job is to filter those things out.

Setup automated metric frameworks that collect from your users. If your metrics lag, you lag.

Keep the metrics simple, measure a small number of things, for a start-up company for example revenue is not as important of a metric as virality and you'll have to bring new ones as you move forward.

Research is too important to be left in the hands of a few researchers. Open to the users as early as you can.

Your team also drives success.

Transparency is key, share the data with the entire dev team, not management only. Progress indicators tell you if you are on track, target outcomes validate the investment. If we are not getting there, we adapt.
Does that really work? Well, let's do a reality check:
What's better, our velocity has risen to 49 and we have delivered 100 new features or we just implemented a feature in three days which will save us 15 million dollars over the next year?

Q: How do you measure money being saved?
A: Well, this varies with different products, but in some cases a good example would be, to take a look at the customer conversion funnel.

• Define what customer conversion is. Let's say Ali express has a customer making a purchase and entering a certain amount of times per quarter. 
• Now define what customer conversion is, according to your data: Let's assume for this purpose getting 50 dollars in purchases yearly from that customer. 
• You can see for each customer conversion after the implementation above the conversion rate you had before up to how much your features impacted the product. 
• Now you can measure that money vs the investment made to make that happen.

What industries can do this? 

We can measure products or transformation areas. So any industries having either or both.

Wrapping up

Measuring outcomes then, to my view, is way evolved than measuring outputs. It does not change development, it fundamentally changes the systems and structures around us. Contracts will need to evolve to target outcomes as well.

So, back to "Agilists are killing the planet": (which is a pretty strong statement).
The Machine-gun approach will get you to build features faster. More features built means more resources used, and even more resources to maintain what has been built. So you are actually "helping to kill the planet faster".

"Save the features, save the planet 😊". 

(*=Img source)