Beyond the code … beyond the output

Outcome does not equal output. I hear this statement again and again in Agile world and I must admit that I like it a lot. Between the two concepts there is a significant difference  which is not that easy to digest. Understanding the outcome of what we are doing can have at least two major benefits. Firstly, where there is a why, there is a strong will. We all feel much more motivated when we understand why we are doing what we are doing. Secondly, the value that we add on the table increases significantly when we understand the outcome.


The “revelation”. Lately, I had a “I wish I was 20 again and know as much as I do now” moment. Who hasn’t had moments like that? And it wasn’t one of those when you think “this time I would be cool.” I would probably still be a geek, but a much wiser one I hope. This moment took me back in time and gave me a story which I am using now every time I try  to explain the difference between outcome and output and how the two benefits work. Either it’s an Agile training I’m holding, or I am talking about Product Mindset, this story really seems to help. And I want to share it with you in the hope that it will bring a little more clarity into the matter.


The first company I worked for almost twenty years ago had an integration pattern for newbies which was really cool. I received in my care an ongoing project. It was a desktop application written in C++. Using the application, you could register everything that happened on the desktop and playback it. And if something didn’t happen exactly like it was recorded, the differences were logged. If a button opened a window and the window was not in the same position, or didn’t have the same color or the window was in a different mood (how cool would be if this really exists) an error would be logged. Does it already sound familiar? It was one of the first automated testing tools I had my hands on. Almost twenty years ago. Nowadays this is a must have in every software development team and there are tons of tools for people to play with. Back then, not so much.


My mission was to clear the tools from bugs. And that’s what I’ve done. Windows hooks, low level programming, digging into the roots of the operating system – that’s how passionate people define heaven. Even today, after almost twenty years, I remember one of the most nasty bugs I had ever solved. It took me about three days, but when I solved it, the joy was so high that I could throw a party. And when somebody asked about what I’ve done I started to talk about window hooks and events and keystroke messages that didn’t register. And in my passionate errant speech I always missed the other person’s look. That look that says “duuude shut upppp. When is the food coming?”. Because those were things which were important only for me . For my passion for technology.


The output. What I’ve missed is to understand why I did what I did.  I didn’t care.  So, at the end of the day what I provided was output. Pure output. I fixed bugs. I didn’t add any additional value. I didn’t care why I fixed those bugs. I was so caught in the technology that nothing else mattered. And there is nothing wrong with that. But now I want a little more.


The outcome. Now I am thinking of what would have changed if i haven’t missed all that. I had in my hands an automated testing tool. The outcome was there in front of me. The value of what I was working was huge. Automated testing. Huge time reduction of running repetitive tests. Faster validation of completed work. And much more. But I wasn’t focused on outcome at all. Motivation stopped at the bug fixing level. Value added stopped at solving technical challenges. I wish now I could have come with at least one idea. Or ten. In order to bring my contribution. I cooked an awesome dish but I forgot to add the flavours.


Businesses today don’t allow us to just cook the food without flavours. Adding to our passion for technology the right focus on the outcome and on the business value, will definitely boost our game. And it will definitely move us much closer to the Agile mindset. It took me a while to understand that.

Leave a Reply

Your email address will not be published. Required fields are marked *