Interview: Jeff Patton on Embracing Uncertainty
In this interview with Jeff Patton at Agile 2008, he talks about three strategies that can help product owners do their job more effectively by embracing the inherent uncertainty in all software development.
The first strategy is:
... the first strategy was to focus on goals and outcomes we are trying to achieve and in particular focusing on the goals that motivate us to build the software. If we understand what our business goals are, what’s the outcome we are trying to achieve, not if you ask someone what their goal is and they say that the goal is to build this software, like in this point in time, well that is not the goal, the goal is what you get after you build it. The goal is the benefit the organization receives by having built the software and deployed the software and getting people start to use it.
The second strategy Jeff recommends is:
The second strategy was a strategy about deferring decisions, delaying decisions to the last responsible moment, about what to build.
.... how we could - given some sort of thing that the user is trying to achieve - we can come up with a number of possible product solutions that allow that user to achieve it, and we want to come up with a solution late when we know more about the problem and when we know about our economics and our time concerns, we want to come out with the most economically advantageous solution.
The third strategy Jeff recommends is:
Strategy number three was what I called scaling up or building up quality. Now if we are not sure exactly what we want to build, but we know we got a delivery date and we know we have got a budget, one of the things that we should be doing is focusing on building pulling in the old XP-ism that’s the simplest possible thing and sometimes the simplest possible thing means it’s not really complete, it means it is a screen that doesn’t have validation yet, it means it is a screen that doesn’t have colors, it means it may have a crude layout, it may even mean that it doesn’t persist in a database. But maybe our first stories build out an example of our solution that we can then see and experience and touch and say “Yes, that is going to solve my business problem”. And then we slowly build up quality over time.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015