Skip to main content
03 Jan 2018

Outcomes not output - how to deliver the right thing

I recall one day being super proud of my agile teams, we’d finally got the secret sauce right – we were, as Jeff Sutherland’s masterful book stated achieving, “The Art of Doing Twice the Work in Half the Time”. This is what we were striving for, BEING AGILE. The high performing, self-organising, co-located teams delivering with cadence.

We had a single master branch with continuous integration and were well on our way to true continuous delivery of being able to release our microservice architecture on demand. Don’t get me wrong, there was still some legacy around that could only be released once every few weeks but for the most part, we were right there.

The biggest thing that bothered me all those years ago and at most places I’ve worked at since that time, was that although we were delivering all this stuff, neither the total transaction value nor profit was increasing based on what was getting delivered. We had put so much emphasis on delivering everything right – at the right time, the right quality, building in automation, building incrementally with continuous delivery etc. that we had not put the same level of efforts into delivering the right thing.  The technical team were just building what was asked for. We might have been building it one hell of a lot faster, but a “crap feature” is still a “crap feature” no matter how fast you build it.

So how you do deliver the right thing?

Think about when you’re trying to solve a problem in your everyday life. Take this user story for example – “As a busy technologist I need to relax so I book myself a holiday”. Sure, there are other ways to relax, so I might weigh up my options and hypotheses and the associated costs of each one, before I decide what action to take. I can relax by having holiday on the beach, I could book a spa or massage, I could take a tablet, read a book, listen to music, have a coffee or whatever might relax me.

As humans we are constantly jumping in head first to try and solve the problem, always, time after time we do this, - it’s in our nature, it’s our instinct….  but we’re not even taking the time to understand the problem and the root cause of the problem in the first place.

By NOT understanding the problem, you’re going to spend a lot of money going on holiday only to find that as soon as you get back, the root cause of the problem is still there – so WHY do you need to relax. By delving deeper, you might find that you need to relax because you’re stressed - due to family, a friend, work… it could be anything but you’ve got to take the time to understand the problem enough first, as unless you do, you won’t be solving anything.

We do this too in technology… every day we spend too much time and money building something that does not solve the root cause of the problem, because we have not taken the time to understand the real problem. Spend the time! There are many lean techniques such as the 5 why’s, the fish bone diagram, interviews etc that will help you understand the root cause and then you can find some REAL options available to you to resolve the problem. This is the starting point on being outcome driven, understanding the problem and opportunity first before spending a penny on building code that will never be used.