This is Deborah Hartman at Agile 2008 and I am here with Jeff Patton. Welcome!

Thank you, it's good to be here.

Jeff, you are, I just want to let people know that you are one of last year's winners of the Gordon Pask Award which is offered by the Agile alliance to recognize contribution to Agile practice, congratulations.

Thank you.

And thank you for your contribution to the community. And I would like to know, and some of our viewers maybe don't know who you are, what do you do and how did you get to where you are now.

That is a good question. In the Agile community I am famous for being the user experience guy which is for me just a little bit odd but let's see if I can rewind and tell a story about how I got here. I have been in software development for a very long time. I started in college actually as a graphic designer and it turns out that doing graphic design was harder than doing programming so I started doing more programming and if you show up and do programming and you got a graphic design background you are the UI guy and everybody probably knows that. I got started with Extreme Programming in 2000 and I was lucky enough to work on a great first one of the first XP projects in this particular case Kent Beck was the consultant hired to get the practice started.

So I got a very pure beginning and I fell in love with the way Agile practices work and especially when it comes to engineering practices I fell in love with the confidence and certainty I felt about the code that I was getting out and the quality of the product that I was building. But I just struggled with the decisions that were being made with what to build. We built a fabulously high quality product that didn't sell well and the company ultimately didn't do well and a lot of people that I worked with and liked working with didn't end up staying working with that company. So, if I could draw back in, I went looking for a better way other than user stories, to describe what we wanted to build and user stories are still a good thing to describe it ultimately but what comes before that?

How do we decide what we want to build? How do we know it's the right thing to build? How do we know who is going to use it and how they are going to use it and make sensible choices about what their life is going to be like once the software is delivered and then ultimately how does it look and behave and then the user stories can take care of it from there. But there are all those questions up front that if they answered correctly lead us to build the wrong thing the right way. And I found the most practice to learn from this to the user experience community from disciplines like interaction design and user centered design and I found a lot less help from the traditional requirements help gathering business analysis community. So the expertise in user experience had caused me to be known as the UX Agile guy, that's a long answer.

So you come from the XP community and embrace change is not new to you and yet your talk this year at Agile 2008 was entitled "Embrace Uncertainty". What is the difference?

What is with that? So embrace change seems like a response to the assumption that we will never really know what we want so let's build something and see if it is the right thing and then we will embrace change and then there is a lot of change and it is correct to do that but one of the things I see on the product owner role is as soon as an Agile person starts collaborating with them they will ask them what kinds of things they like build and we want to trap these on story cards and we are even giving some looseness in the forma by saying "As a kind of user I want to be able to do something so that I will be able to get some sort of value". But even that's a little difficult but when pressed people can hypothesize about what they want built. And as soon as they start to hypothesizing about what they want built, they get kind of a clear idea of what they would like to see and they start to become certain about what they want.

I think they are being certain about what they think they want. Is that where you are heading?

Yes, certain about what they think they want. And for them it's certain no matter how you describe it and they press on and start building that thing they are fairly certain about and that is one of the scary things for me, is that when I run into someone that says "We know exactly what we want, how fast can we get it?" And that is the scary thing. Agile development works best when we are clear about what we are trying to get from an outcome prospective, when we are clear about what our goals are that we are trying to achieve and we allow what we are building that will get us there to float, to respond to change at every iteration and every sprint to look at what we have built and say "How is this helping us rich our goals, not how is this not like the mental picture that I wanted built?".

I unfortunately didn't make it at your talk. Can you tell us what did you do in your talk?

And you should be very sad. The talk came about as a result of having one of those bleary-eyed waking up moments and suddenly hearing a song lyric on your head and realizing suddenly it is very wise advise. And that the wise advice came to me by way of Johnny Rotten from the Sex Pistols, and the second phrase in the song Anarchy in the UK is "Don't know what I want but I know how to get it" and I always think "That's what Agile is to me". I don't have to know what I want but I could get it still. So my talk uses those, that song and those song lyrics not just the lyrics but you got to play Anarchy in the UK loud. It's not just that, I got to play other things.

I want to start by phrasing the problem so I chose the problem for me is when people are clear about what they want and they think the are just going to build it one chunk at a time and then they will be done, that's it, I know what it is, I'll just build it one chunk at a time so I chose Pink Floyd's "Another brick in the wall" for that one so I described the problem of knowing what you want and then used to burn down chart creative the bricks and then we sort of burnt down the bricks, and low and behold change starts to happen and the plan starts getting busted up and our velocity isn't good because change starts to happen. We start to realize we weren't actually sure about what we wanted and we fooled ourselves so I phrase the problem by showing someone failing.

You had a scenario that you set up. A company with all kinds of entertaining music but which ended in failure. And?

The short strokes, the lead character which was a picture of Roger Waters the lead singer from Pink Floyd, set up a project and we started to start the burn down chart, but the change started to happen it became clear that he wasn't going to hit everything he wanted in time as a result of having to accommodate the change as planned and account for that. And Roger became a little afraid of Agile processes after that. What we needed to do from there on in the talk was teach Roger to embrace uncertainty by giving him some strategy, some things, he as a product owner could do to figure out how to deal with the uncertainty of not knowing exactly what he is going to get.

This is great, we are getting practical, will you share with us some strategies that product owners can use to embrace uncertainty?

The strategies I described, complete with music and lyrics, and I chose a song and an artist to describe each one of them, but I discussed three basic strategies: 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.

Basically I describe this kind of dependency between the stories we write and the people that end up using this software for some purpose and then the business goal at the top that says "If we are going to get this goal these people are going to use or buy this software and they are going to use this software to do this and then their stories are about that". But if we are clear about what our goal is and in fact if we find out while we are still talking about goals we might want to find out we have many, and if we can winnow that down and choose one focused goal, that winnows down the users we have to worry about and the stories we have to build so the first strategy was focusing on what your goal is and be clear about that. The second strategy was a strategy about deferring decisions, delaying decisions to the last responsible moment, about what to build. For that one I used Paul Simon and the Fifty ways to leave your lover. As a disgruntled boyfriend I want to leave my lover so I can have a better lifestyle.

That is going to be the best user story that I have ever heard.

So, given Paul's problem we know that in that song at least we have at least fifty ways so as long as we don't decide on the way let's put the "leave lover" in the backlog instead of "slip out back jack" or "make new plans stan". We are going to leave the fifty ways and we will defer the decision about what to do, or how to make that story true or what exactly to build to the last responsible moment. That was strategy two and then I gave some concrete examples about 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. So, that was strategy number two.

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.

So I gave a strategy for building necessities first and then adding sophistication later and then finally capping off with the quality of experience later. But the goal with that heuristic for breaking up or splitting up stories, was to split up stories into what is essential first. Now one of the things that I poked up a little bit is the original Scrum model where at the tail-end of that Scrum model at the far right hand is this phrase "Potentially Shippable Software". And I would submit that the strategy is at odds with what we are trying to achieve here, it forces you to know what you want. It is potentially shippable, for me I hear in my head "Don't make a mistake, get it right the first time". But you got to know what you want, especially if it is going to be potentially shippable. It implies some culpability if I make a mistake and I build the wrong thing well it is not potentially shippable, it is not about the quality of the thing that was built it's about having something shippable because I chose the wrong thing. So I want to push a little bit harder on building things that maybe aren't potentially shippable but that iterate us towards proving that we are building the right thing, and then once we are confident we're building the right thing, building the thing right.

What kind of response did you get from the people who attended your presentation?

Generally pretty good and when the talk ends with the Sex Pistols song you can usually expect a reasonable response but it did give people a lot of pause for questioning and concern. And when I underline and question the phrase potentially shippable software, that is going to make a lot of Agile people concerned because they have been focusing so hard on building complete pieces of stuff and I seem to leave people with the idea that we couldn't tell people when the release date was and we couldn't predict when we are going to be done. Or if I did things like deferring deciding what to build we couldn't estimate accurately so yes there are questions that concern those things and they were right.

You can't estimate accurately, the only way to estimate accurately is to decide precisely what you are going to build up front and I think by now we know we are fooling ourselves when we do that so I think those questions for me came out of still fighting that urge to really be predictive about what we want to build and really be predictive of really make assumptions that we know what we want or we know what will solve our problems or we know what will achieve our goals. So generally good, and some questions about some fears and concerns.

I hear clients "We want to go Agile but we need to know exactly when we are going to deliver and exactly what". It's an oxymoron.

It is an oxymoron. And what is odd is that I find that people are very sure what they want almost always finish their projects late. And I find that by embracing uncertainty, I started with Agile in 2000 and we had this problem that I described early in the interview were we effectively built something that people didn't want, but from then I moved forward to working in a fixed price fixed scope environment I had to deliver on time, it had to be high quality, it was commercial, it wasn't for internal use, so we had competitors, so if our customers didn't like it they go elsewhere and we were contractually bound to delivering modifications to point to sales systems for these customers.

I can't claim a hundred percent success, because I suspect I was a little bit late here and there, but in general I was on time with a product that customers loved and I found that by embracing uncertainty I could almost always finish on time as opposed to being sure what they wanted or when I ran into customers that were sure what they wanted it was pretty easy to punch holes in it as soon as I figured out what their goals were and I could pretty easily convince them that what they were asking for wasn't going to get them what they wanted and helping them be clear about what they were trying to achieve or what their outcome was, for me it was a way for me to help them embrace uncertainty and then by proceeding forward for there we were able to almost always deliver on time something that people liked.

You give me a good reminder that we really need to replace our craze for full scope for happy customers.

Yes, that full scope thing is tough. When I look at user story writing practice, folks like Mike Cohn are preaching good practice. They show us user stories backlog that has really big undefined epics at the bottom and as we get close to building it we winnow those down into little more precise pieces and I am sure Mike would agree we kinda want to let that uncertainty live for the things we intend to build in the future. I find in practice people want that scope they are not willing to embrace that uncertainty they decompose their epics into small estimable stories, and we end up with backlogs filled with hundred of stories, over a thousand stories and we begin to swim in the stories and we come into work and we play planning poker every day and we get lost in what we intend to build.

We actually created an inventory of stories that have to be maintained during the whole project.

Yes, we could create a full time job for backlog management, our product ownership team is staffed with backlog managers that shuffle and compare is that and ask which one is high priority, this one or that one? And it becomes a pretty devious thing.

Does user experience and interaction design work belong with the team member behind the sprint or with somebody working before the sprint?

That's a great question. So when most people think of user experience they think of user interface design. What they don't realize is that people who do user experience work spend this much of their time doing user interface design and this much of the time understanding what the problem is, who the users are and sketching and iterating over possible ways to solve it. And once they are fairly sure they start doing detailed user interface design. So user experience people belong squarely on the product owner team. They advise, they help interpret the problem, and they help phrase it back, they have lots of techniques, including facilitating techniques, and modeling techniques that help describe their problem and help make backlog decisions about what we should be building. Subsequently they move on to sketch what the user experience looks like and then harden that into user interface design.

And where user interface design goes precisely kind of varies on the organization some organizations put user interface design just in time but before the sprint, and some organizations put user interface design inside the sprit and it really depends on where your skills are, but you will find it in that big user experience community, which is pretty big, you'll find that there are people who have a lot of skills revolving around understanding the problem and modeling it and figuring out what to build. But you'll find that the best detailed user interface designers, and interaction designers and visual designers and these are the people that pick the nits over what the UI looks like, can do it very well, they tend to live closer to the iteration. It's a big community but you need them on the product owner to make decisions, otherwise they end up being in the role of pig lip-sticking, and the term to lipstick the pig and putting a great UI on a crappie product, doesn't make it a great product.

That is the problem of narrow perfectionism right? My UI is great they failed.

What is an interesting thing is we are here at the Agile conference and that the closing key note speaker was Alan Cooper who is very famous in the interaction design community has written a couple of books on the subject and is famous for ranting and saying big things about how important this is. Somebody asked him at the tail-end of this conversation if we want to get these kinds of people on the team how do we find and hire a good interaction designer? And his response was: "Just ask them if they like talking to users, do they want to talk to users?" and if their answer is "Yes, I love talking to users", that is an interaction designer.

You'll find that people who do a lot of visual design and graphic sorts of things would say "Maybe I would rather not talk to the user, I just want to do this kind of work". And then I am guilty of stereotyping here because there are people that are great at visual design and they do like to talk to users but the people that are just great at graphic design then they certainly have a place but don't want to talk to users are probably not the people that should be doing interaction design not doing the choosing about what they want to build.

What about small teams that don't have budget for or perhaps enough work to keep a usability person busy. You say there is a big community, are there reading materials, are there courses, are there books?

I am going to take your question slightly sideways. This is one of the things I discovered when talking to good people like Cooper that were here this week, at the conference. Interaction design and doing this work isn't a job title, isn't a kind of person, these are skills that people can use. There are great professional interaction designers that are specialists and do a great job at this but what my role in life has been since my inception or the thing that I am most passion about is training everybody to be part interaction designer. So yes, there are people that we can get and bring in but I guess I would encourage everybody to start and learn what interaction designers are and do and how they think this way and be this way.

To tell a story, one of the applications I built early on, it's not sexy but we were designing an application that would receive stuff that came into the back door of a grocery store and my response to that was "Gosh I can't design an application that helps people receive stuff at the back of a grocery store without going there, I have to see what it looks like". And it wasn't just me, I had a team of developers and I said "Let's go down to the grocery store and let's see people receive stuff at the grocery store". And we went back and we sat with the guy that receives carrots at the back door of the grocery store, we saw what his life was like, we snapped a few pictures we talked we watched him do his work and we came back and received stuff at the grocery store. That is talking to users and that is what interaction design is it doesn't take going finding a specialist to do it, it takes doing it.

I guess I would say "Yes, you can find interaction designers" but I might suggest that it might be a mistake to say that this is a specialist role that we get into the team part time. This is a way we are, just like Agile is a way we are, it's not something you pull in when you need it, I will worry about users one day a week or a week a month and rest of the time I will focus on building things.

But what about developers who want to learn to be that way? Where do they start?

It isn't just the mindset, it's a skill set. I wrote an article that appeared in IEEE Software which you can get from my website somewhere in there, but there is this term user centered deign and a lot of people like to say I am a user centered I really care about users and a couple common failure modes are say you care a lot about users, and you are thinking about the users, and then look at the software and say that is not usable and make decisions based upon what you would like. You are a user so if you are user centric then you make decisions based on what you would like and that is not user centric.

Another way to claim to be user centric is to ask users what they want, bring them in into say "What would you like?" and then to build what they would like. What they said they wanted and show it to them and then when they say "Well it is what I said I wanted but it is not quite it, it's not going to help me" and to say "Well that's what you said and it is going to cost extra to change" and both of those examples we actually never got to know what our users were, and what their goals were and what their problems are. So it is a skill and there is a skill for first figuring out who your users are, figuring out how to talk to them, how to ask leading questions without asking them to supply you with what they want, asking them the types of questions that really get into what they want and then taking that info and making decisions and it's a skill set to model what you understood about users and it's a skill set to build a hypothetical design for a system a user interface design a user interactions, so yes those are all the skills that you need to learn. Certainly there are a large number of books to read and gosh I would hesitate to recommend any one.

Is there a website that people could go to start looking for resources? A writer that talks about these a lot?

It should be my website. But it is not.

So your book is in progress, right?

Yes my book is in progress. To answer your question there is a wide variety of resources in a way of study I could point to the things I did. I took classes and read books from Constantine and Lockwood from Cooper interactive, and took classes from Cooper, and took classes from Holtzblatt and Meyer who published a process called "Contextual design" if you look at this big user centered deign world, it is richer than the Agile world is in Agile development we have common processes like XP and Scrum, and in User Centric Design there are processes like goal design, contextual design, usage centered design and lots of others and all of those are worthy of study and taking classes on and reading books on, and there are books that cap things off.

A popular book that is always a good read is "Don't make me think" from Steve Krug And Alan Cooper and the inmates are running the Asylum, Alan in that book is going to make the point about you not being the user and he will poke at developers to make decisions on behalf of the user because they think that users are just like them, which I made the point before. The book I am working on tries to distill all that stuff into practice we can do. I want to make it simple and simple enough that we can start and incorporate practices specifically into an Agile context.

What can I do in practice to understand what my business goals are, understand who my users are, model their use and then make decisions about what stories go into the release plan based upon that and how do we shave those off into stories that go into each sprint and then how do we evaluate that what we are getting out of the process is really something that is meeting goals because traditional testing doesn't do that, all it does is verify that we got what we intended to build but we need to get it back in front of users and evaluate how effectively they can use it and get their evaluation and is this going to meet their goals. That kind of testing which is more alike traditional usability testing that will actually tell us if we are getting what we want. And in Agile context especially we need to b doing that kind of testing every iteration and every sprint. It isn't just seeing that there are no bugs, it's seeing that it is effectively meeting goals and those are the kind of practices that I am describing in the book.

So I understand you are writing with Alistair Cockburn?

Yes, if everybody who knows me I am so sick of hearing the question: how is the book going Jeff? And I have been struggling with it because what I want to do is just vast but what I can do I don't practice what I preach by the way.

You too?

I do not. So I didn't focus on what the goals are that I am always trying to achieve, I didn't use that to limit my scope, I just wanted to say and write everything. And the book was signed originally under the Cockburn and Highsmith Agile series, from Madison Wesley and my friend Alistair Cockburn said "If you are going to get this book done Jeff, you are going to need my help" and he graciously agreed to step up and as my co-author Alistair and I am getting this work finished and off, so with luck we'll get the draft done shortly and have a book early next year, that is canned and ready to go.

Well I hope you enjoy the writing process.

I hate the writing process.

Well thank you for doing it anyway because I am looking forward to the book, so keep it up.

Thank you.

And parting words: what would you encourage the community to be looking at these days?

I hope getting the chance to listen to me you heard this term user experience, interaction design and a few other terms, I hope you see it not as a group of people who are trying to get in Agile's way but somebody who is trying to help people in this product owner and customer role, really get a better grasp on really understanding what the problem is. For a lot of projects user experience and interaction design are blind spots, and user interface is the thing we attach at the end and usability test is something we do after the product has gone awry. My parting words are if you didn't understand form listening to me what an interaction designer is, or what user experience really means, dig in a little bit more and if you can't start involving either those people in your project or do some research and start to pull in some practice into your project, you don't need people you need to do what those people do.