Three ways of telling if you are not problem-oriented

1. You can’t tell why something is under development

…or the reason sounds like “I’ve been told to”, “it makes sense” or similar stuff.

Do, you and your team fail to know why something is important? And why working on that feature is more important than working on some other thing? Don’t you know the expected outcome (outcome - not output) of the current sprint? Smells like software factory to me.

I truly believe that the only way a development team can do a proper job is by knowing what problem is being solved. Working on a list of prescripted features will only get you so far.

And let’s face it - I’m a developer, but technical challenges are not enough. Having a higher purpose and autonomy to work towards it is what fuels motivation in the long run.

2. You “celebrate” the “final delivery” of a product

Well, feels natural, right? You finished a product, you’ve delivered it, you’ve fixed the initial feedback/bugs, so it’s a success. It’s over! Time to celebrate!

What does it mean, though, that you’ve finished a product? What was its goal?

Here’s the difference between outputs and outcomes. An output is a feature: a new form fieldset, a new database schema, a new screen on a mobile app. An outcome is a 25% incoming calls reduction, a 10% bump in online sales YoY.

Put it another way: imagine a client/stakeholder that need to sell something online. You ask a team to increase the revenue of a specific checkout page by 10%. Sounds like a plan, right? You let the team try out things to reach the goal, and after a while, you see that you’ve reached an ROI of 120%. For each euro you invested, you got 1.2€ in return.

Why would you want that “product” to be ended and celebrated? I can only come up with three valid answers (and a shitton of invalid ones) to do so:

1. You ran out of budget. Seems fair.
2. Priorities shifted. Seems fair, too.
3. Scaling up the solution means a lower ROI, so it is not worth the effort.

Why would you “pick up the next item on the list” otherwise?

Doing and delivering more things is not better by default.

Any other reason seems suspicious. If the outcome is positive, why not getting more of it?

3. Feature delivery as a performance metric

Fuck burndown charts, and fuck story points. Well, at least, fuck them when used as a tool to know if “a team works as expected”. If they “deliver”.

If a team delivers crap, and you make that team go faster, you’ll get crap at a higher rate. A fantastic idea.

If you think of products as tools to solve problems while providing business value, well, things start to change. Now you need to create a hypothesis and analyze the outcome. You have a simple idea, you test it out, see if it works, and then start all over again from a different starting point.

The only way to do that is to focus on the outcome, define business-focused metrics, inspect the result, and adapt the following iteration.

Not knowing if feature X has been helpful, or if it’s being used at all, smells like a solution-oriented environment.

I guess what I’m trying to say is that I don’t care if I help to deliver 1, 10, or 100 features in a sprint. What I want is to know that something important improved and that I helped end-users while aligning the effort with business goals.