CultureTechnology

Output Vs. Outcome

By October 7, 2012 No Comments

One of the questions at last week’s monthly engineering meeting was something like, “How can we be successful when we seem to be striving to do more with less?” I’m paraphrasing, but I think that was the gist of the question. It is a great question actually, because we do have a LOT of important projects underway and we have chosen to move people around such that some teams are now smaller.

Personally, I think the answer to that question depends on what you mean by “more“. Yes, there will always be tweaks and improvements that we can make in order to improve the overall efficiency of our software development process—that is what continuous improvement is all about, and it is a fundamental principle of our agile development process.

But I think we need to dig a little deeper in order to really answer this question.

Output != Outcomes

I know many of us look at the big numbers put in front of us and sort of shrug. “How can we, as an individual contributor, really contribute towards hitting those numbers? What can we do to help close a deal or help increase profitability?” One of the ways I think we can work together to make an impact is to focus on improving the ratio of output to value on our projects, like Jeff Patton talked about when he was at Daxko last year.

We naturally tend think of our work mostly in terms of development effort or output. How many new features are in the release? How many story points did we complete in the sprint? We talk about our work in the ways that are easy to quantify and measure.

The outcome of our work isn’t as easy to measure, but it’s what really matters. We all intuitively know that our goal isn’t to release 10 new features this year, but to improve the lives of our customers as best we possibly can. To do that, we must always focus on the outcome or impact our work will have on the users of our products.

We can’t stop at thinking about outcome, though. To be as successful as we can be at having significant impact on our customers’ lives, we have to actively work to minimize the output while also maximizing the outcome or value, of our products. This is counter-intuitive at first because as engineers, we are always focused on how to increase the output of our teams. Jeff Patton created this great illustration to emphasize the point.

 

That sounds great – how do we do this?

I think we do this in several ways.

  • We must strive to understand the value we are trying to provide with each of our stories. If we ALL understand the value, then we can work together to build the best possible solution for the least amount of output. BTW, this is also the fundamental principle behind the concept of minimum viable product (MVP).
  • We must choose the “right” stories to build. Asking ourselves, “Are we choosing to work on stories that balance effort and value so that we can have the most impact possible on our customers’ lives?” This is largely the responsibility of the Product Owner teams at Daxko but I think every team member should be thinking about this as well.
  • We have to be realistic about what we can do well. If given the choice of doing ten things crudely or doing five things brilliantly, I’ll take those five brilliant things, thank you very much. They need to be the “right” five things though! Pick the 5 things that will have the most impact to our customers and knock em’ out of the park.

As you are working on your projects, look for opportunities to minimize output while maximizing outcome. If we can do that, we’ll be a long way toward doing our part to help Daxko grow.

Jason B. is a software testing professional that loves a good challenge. When he’s not running waterfalls in his kayak, he’s working to make the world a more “agile” place.

Leave a Reply