Good morning. Now, where do I start? I've been involved in Agile development for a long time, since 2000. Within the Agile community I have a little bit of a reputation for being the user experience advocate or the user centered design advocate. My creation story that I tell too much is starting with extreme programming in 2000 and absolutely falling in love with it when finally good software was built, but then I needed to qualify good.
In the first XP project I served, one of the tough things was being asked to either be a customer or be a developer and I had to choose. Prior to that, I had been on the product side, I'd been working directly with users and I had been synthesizing what they did and building prototypes and working with them and taking it back and running a team of developers to get things built and writing code with them and taking teams of developers out to visit users and I had a very organic way of working. We had very good software built, but like a lot of developers, we were hacking a bit.
We could have been doing things a lot better. I fell in love with working in an XP style or an Agile style, but what really threw me was this split, this kind of breaking up of what I thought would have been a really functional relationship for me with users and customers. Then working on a customer team in an XP environment, I saw people doing a lot of arguing and fighting over what should be built. It just seemed like there was a lot of strong practice on the engineering side and not on the XP customer side.
Our customer team at that time was composed of strong industry of domain experts - they knew their stuff. They arguably knew their stuff. If you take 5 people in a room that know their stuff, they all know different stuff and they all think their stuff is right. You think your stuff is right. We can put our stuff in a cage and our stuff can have a cage match and that's what was happening everyday.
Everybody's right stuff was doing that. I said "There has just got to be a better way." My first job I actually abandoned the customer team and just said "OK, the easiest thing to do is to be an engineer and focus on building well what they ask for and let them have those fights about where the product was going". But the inevitable happened - we didn't get a successful product to market. We got a product to market that was built well and it had some popularity, but it wasn't the same as we still went through many rounds of layoffs and the company still imploded.
What I got concerned about was this is a great process, but at the end of the day, if the product we build isn't successful, it doesn't much matter. I often coin in a phrase from a guy that I knew in the Bay area at that time, a guy named John Bruer, who said "It's not my problem, the hole is on their side of the boat." I was seeing a lot of that and I felt a lot of that in the Agile community.
I felt like I had a practice that was working before Agile on at least that side of things, but the other thing you find when you fall into the Agile community is that there are a lot of people that are really reflective, very thinking about the way work and they way things don't work. They have good language to talk about things, they know how to talk about their process and when it came to the customer side of practices.
I knew what I was doing, but I was just going out working and talking with customers and I would say language like I sit down and talk with customers and the XP people would say "We do that." - "No, you're not. These guys are business analysts or proxies or people that work hired by the company. They're not the direct customer. They're not the real customer." Further more, if you work for a product company, customer means person who buys something, user means person who uses something.
In product companies where you are making a product of any suitable size, you know full well that the person who makes buying decisions is not going to be the person who is using the product. The person who uses the product often has it inflicted on them and the customer making buying decisions will often be really focused on their needs, which tend to be reports about what those guys are doing and on the buying side, they often don't worry much about the experience of those guys until the product gets sold and those guys start complaining and then they get worried about those guys.
Anyway, it's a tangled relationship. When you look at a piece of software that's not just one kind of user, what you need to do is understand those people. In an attempt to put language around the space, I started digging and doing research. Being blunt at that time, there were and it seems there still are 2 ways of looking at things.
There is traditional business analysis, where I ask customers what they want and I help to make sense of it and represent it back as use cases or other models and I'm gathering requirements. Then, there was this space called user centered design. In user centered design, I don't ask customers what they want, I seek to understand what makes them tic or what makes them work or what's important to them.
2. You say there are 2 types of what to do approaches, if you will. Tell us a little about that.
In research, if I want to put some practices into the customer space, I found 2 schools of thought. There was what I might call traditional business analysis, which is an approach where I talk to people understand people, I model what I'm understanding that they're asking for and I feed it back to them as uses cases or work flow models or business rules or shall statements, if you are in a government situation. I get them to agree on it.
I can remember going to classes for business analysts and them saying "You write all these things down, then you have business people with different interests and you put it in front of them and you make them argue about what they want". It's a little evil. They don't know what they want, the truth is they can't articulate it well, you write down what they say and give it back to them and you make them fight. It didn’t seem functional.
3. It sounds like a no win situation.
It is a no win situation. At the end, they fight, they come to some tense agreement on what they want and then you build it and any sensible smart thinking person would know "When I build it, they are still going to keep fighting. At the end of the day they are not going to be happy with what they got and I lose and they lose and it isn't helping people." I went to a different direction and found these user centered design people.
User centered design people did something somewhat blasphemous - they wouldn't ask you what you wanted, and if you told them what you wanted, they would listen to you and they wouldn't give it to you. Their goal is to understand what you need, to understand what you are doing, what's important to you and use what they understand about designing software and suggest something or come back with based upon what I'm seeing you do I think this is the thing that would work well for you.
The idea or the hope there is - if you position it darkly - that they can help you think, but if you position it benevolently, that they can really scratch an itch that you can't see. The idea is they focus on you and understanding you and what you need. The term "user centered" gets bandied around a lot and there are a couple of right ways to be user centered and a couple of wrong ways to be user centered. A lot of people think they are user centered because they ask you what you want and you tell them and you do it.
I don't know if that's user centered or order taking. McDonald's asks me what I want and they give it to me, but I don't think they care about me. Maybe they do, but I get a Big Mac in the end and I'm gaining weight and it's not they are really concerned about me. They would give me something healthier, frankly if they were concerned they would take out all the salt and fat out of those things - that would help. People who talk about user centered design, talk about saying "I will talk to the users and then the users will tell me what they want" and a user centered designer will say "I will listen to that, but then I will come back and tell them what they really want" - that sounds really arrogant.
What's behind it is benevolence and if you are a good user experienced person, if somebody says "I want a such and so feature", the next question to ask that I get from my good friend Lane Haley at Cooper that I've worked with before was always asking "If you get that feature, what can you do then? What will you get after that? How does that help?" You ask in a very nice way and you keep asking those questions and you get behind the feature they're asking for and into the benefit that they are seeking.
4. Perhaps, with your experience, you can provide some knowledge that you posses that they don't.
Yes, that's correct. I'm supposed to be the software professional. They are not, if they were the software professionals, I wouldn't be here. I dug into user centered design and to make a long story less long, there is a wealth of practice, a lot better ways to ask questions and talk to people, a lot of great ways to make sense of the weird disparate information I get from people, a lot of good ways to start to separate people not by job title or not to call them users, but to separate people in meaningful ways about the kinds of goals or behaviors they have.
And start to represent that and talk about it and to become user centered by stepping into the shoes of the user and working to make decisions on their behalf. If you are really user centered and you're somewhat empirical you are not going to make decisions and presumptions about what they need, you will take it back to them and vet it with them. You will test it and test for user experienced person doesn't mean it doesn't have bugs, it means I have a guess about what will satisfy you and test means checking if it does satisfy you.
Of course, it should not have bugs and that's an assumption. If you say "test" to a user experience design person they mean you put it in front of users. Coming into Agile development, I heard a lot of discussions about users, but in fact I didn't see a lot of discussions with users. I heard an awful lot about testing, but I didn't hear enough about testing as I thought about what testing meant - I solved a problem you had. To me, the idea that testing meant no bugs was like saying "Water is wet".
Of course it has no bugs! I would be a failure as an engineer and as a software development organization if I really settled for bugs. That's not up for discussion! It was surprising for me that some people felt it was. Not that I haven't really a lot of software with bugs, but I knew it wasn't something good to do. Some people don't quite understand that releasing software doesn't help people, it's not good. Some people fell into the "I built what they asked for, they can't make up their mind, it's not my problem! The hole is on their side of the boat."
To make a long story short, one of the problems with the user centered design community is they developed ways of working in a bit of silo, in a bit of one of the boxes in the waterfall model and they hand over specification. One of the fabulous things about working in an Agile context is we got to start talking with each other. In an Agile context, it doesn't do any good if I understand the user and then I tell you what to build.
Yes, if you are the builder, you have a lot of opportunities - the time you are laying hands on code to make things better for the user, but you have to understand them. Digging into user centered design, digging into Agile who's compelled me to do is say "What are better ways to leverage this style of thinking and that style of thinking and do things that help the whole team understand users?" We started talking about the thing that I call story mapping and can't remember during what conversation with what friend that I was talking with - I want to say this was a coffee shop conversation with Alistair that caused this to start calling it story mapping.
That's what my blog says. Is that what I said? Good! It's true, then. I forget what happens as I get older. It's an approach to working with user stories that I started doing very early on and like all good ideas you have, you think "What a great idea!" Then you see somebody else doing something similar and you say "How did they find and steal my great idea?" The truth is it's a pattern. If you see multiple occurrences of many people doing the same thing, it's a pattern. I was doing something like this and I'd written an article a while ago and then I joined ThoughtWorks as a company and worked with them for a long time. Then, as soon as I joined ThoughtWorks I stumbled into a guy named Luke Barret who was doing almost exactly the same thing.
Just recently been working with a guy named David Hussman who was doing exactly the same thing. All we are doing is trying to understand what's important to users and thinking through the users experience, thinking through what they do. It turns out that when you describe things, sometimes it's helpful to describe things at a coarse grain level and sometimes it's helpful to describe things at a fine grain level. I do an exercise in classes, to get people to start thinking from a user's perspective and I'll ask people to think of all the things they did in order to get ready for work today or "What did you do to get ready for work?" It's an easy thing to do, so I'll ask them to write down everything they did on stickies and write one thing per sticky. I said "Write and scribble for a while".
What comes out of that exercise is these short verb phrases like "Take a shower" and "Brush teeth" and things like that. When you think from a user's perspective and what users are doing, you almost always start with verbs. You find that some people will write down "Take a shower" and some people will write down "Turn on water" or "Wash hair", so you start to see different granularities. What a story map starts to do is capture that decomposition and sometimes it's not helpful to talk at a fine grain level, it's not helpful to say what did you do to get ready for work this morning.
"I turned on the water, I washed my hair, I lathered up, I rinsed, I put toothpaste on the toothbrush" - it is such a fine grain level that people can understand. "I brushed my teeth, take a shower, get dressed" It's helpful to talk at a coarse grain level and sometimes it's helpful to talk at a fine grain level. What I'm trying to do with the story map is capture things at a coarse grain level and at a fine grain level. The other thing is when you are talking about user experience or what people are doing, you often talk in verbs.
The reason I started doing this little exercise is because I wanted people to describe software this way. When people start describing software, they automatically start naming features or things that people use in the software. When I ask people what they did to get ready for work in the morning, they never say "toothbrush", they never say "bed", they never say "closet".
6. There is always a verb in there. You have to do something.
Exactly. But yet when we become software professionals and people ask us to build a backlog, we start naming all the nouns and what people are doing sort of vaporizes and we don't understand it and if you are not seeking to understand users, the backlog becomes no longer a point of conversation, it becomes a description of a thing that we want to build that we presume meets someone's needs and these needs we don't understand. Does that make sense? I saw a look on your face.
Yes. Often times there is a standard template that as a type of user, usually I see the template as I want, and then fill in the blanks, so that. As a user, I want a toothbrush and it presumes the solution is a toothbrush, maybe it's a waterpick.
8. It misses the verb - you are absolutely correct.
It misses what they are doing. There is an old C2 blog entry or not a blog entry a wiki entry. The original C2 wiki, XP was discussed and I think there is an entry for "I want a pony", because a lot of stories are about wanting a pony. What we really need to understand is what's going on behind it. If I'm using the backlog as a conversation to understand users, we end up building a map that deals with the flow of doing something, left or right because a lot of westerners think time moves left or right and we deal with a decomposition from big things, like "take a shower", or bigger things like "get ready for work" and I'm talking about a whole system.
I have to talk at a big level to smaller things underneath it and then to even smaller things underneath that. It's the little things when we're talking about software especially that we want to translate directly into "The software could have this feature or this capability or this thing". Those are things that I can translate into actionable, buildable things. At the outset, my goal is to understand what people are doing, so that I can think holistically about the big thing. What I see happen with user stories, you are starting at the leaf node, you are trying to understand the forest, one tree at a time.
The other thing is when you become user centric, you start to understand that there are different users that have different goals and they think differently and they approach the system differently and you can't just say there is these kinds of users and those kinds of users. I use a design problem in a class sort of an information kiosk that I might put in a music store to look up a CD and then we'll talk about persons like a hairy shopper or somebody who's trying to get in and out quickly and somebody who's a casual browser. When I have a simple function, like search for something by title, which one of these 2 users does that? They both do, but they approach it differently and they think about it differently.
9. Even something as simple as that?
Yes, who logs in. What I see in a lot of people's backlogs is this oversimplification of who the user is or a lot of backlogs or as a user and a lot of people who get bound up with that story format and will use the backlog to say "You know, there is just something I need to do and so, as a developer, I need to do such and so".
You're laughing, you've seen those backlogs and you tried to convince them you are not being user centric, but I'll tell you, you're not being user centric if you are working at the leaf node and if are not considering impact of this functionality on different kinds of users. It's probably a good idea to not write stories as a developer, but it's frankly most the stories I see aren't particularly user centric either. They don't give you deep understanding of the user.
Yes, it's a fuzzy thing and, for some reason that makes me anxious I see too much comfort with not understanding the user. I can't understand then I see statements made like they never make up their mind, the requirements are always changing and blah, blah, blah. To me, it's because they defer figuring out or discovering the solution, they've delegated it to the user or to the customer and it's hard work, and requirements often times change because they start seeing things and figuring it out.
One of the good things about Agile is you see things and you figure it out and you change your mind. One of the bad things about Agile is you see things and change your mind. One of the other things is we don't have practices that help people come more quickly to what they want. The story mapping thing is one thing and there are a couple of concerns I have a way that people work with backlogs. The term "epic" gets popularized to mean a story that's too big. I'll ask you - you are an Agile professional. What does too big mean?
11. Too big to estimate a lot of times. It's a technical term.
It's a technical term. So how meaningful is that to the user?
12. To the user? It's irrelevant.
It's irrelevant. When engineers are working with the user, a business person and no one else, that's an epic.
13. That's too big. Tell me something else.
It gets used to hit them, it gets used to force them to think about building software, which is what they need to, but it also stops the developer or the business analyst or the other folks, the software professional, from understanding the user. Epic often means too big to build or too big to estimate. A good example I remember from talks many times before Lynn Miller who has written some papers on doing user centered work in Agile context. At the time, the company was called Alias, it's now a division of Autodesk and they are writing a product called Sketchbook Pro.
Sketchbook Pro is a simple drawing software that works on a tablet PC or with a tablet and there are menu features - file, save as, Photoshop document. From a user's perspective it's a little thing. On a story map, where I look at working with files and saving files and saving files down to save another copy and save as a different format, one of the options for save is a different format that saves as a Photoshop document. It's a small thing. It's down here.
From a user's perspective it's certainly not epic, it's little. But from a developer's perspective, saving as a Photoshop document, was going to take many weeks to build and it was an epic from their perspective. You get into this tangle of user stories. I first heard the term "boundary object" from Brian Merrick. I'm not sure that in that context of that conversation he was talking specifically about stories, but the idea of a boundary object is a token or a thing that allows 2 people with 2 different interests to talk about the same thing.
An example I've heard before is "10 K run for life" that a cancer study research program might do. If I'm a runner, the "10 K run for life" is an opportunity for me to get out, socialize with neighbors, to give me a reason to train a little bit harder, to do this run, to give me a reason to go out and buy new shoes and to socialize with friends and ask them for donations and things like that. If I'm a cancer institute, it's a fund raising opportunity, it's a visibility for my cause and it's a chance to get more money in the specific areas.
It's a brand building opportunity and a fund raising opportunity. We can both agree that there is this "10 K run for life" and we can talk about it. A mistake might be to say there is a "10 K run" story and we want to manage it as data. We will put some fields into it to hold additional information. You, as the cancer institute, might start to say "Well, this is a fund raising event, so I want to put fund raising targets in there, I want to put the details in there about when the campaign starts and critical dates".
As a runner, I'm going "Nonsense. I don't want to see that information. I want to put in there details about decisions I need to make about what shoes to buy and my running schedule and my target time and the training program that I need to hit." If we argue with each other about saying "A 10 K run is about training!" - "No, a 10 K run is about fund raising!" and we can scrap forth and back about this for a while.
You get people talking about user stories as "No, it's a test! It's something that I need to test in the software!" Then, as a user business person "No, it's something I need in the software! It's a statement of the value I need." Then you get the project manager saying "No, it's something I need to schedule and I need to prioritize and put this one before that one."
It describes the software, describes the value to the business, the value to the user, the place in the schedule, the size so that I can figure out how can I do the cost, the estimate, the specifications for building it, the test for testing it. We try and build systems that put all that stuff in there and it just gets messy. The trick to a boundary object is it stays a conversation.
I was teaching a class recently in mid-rant and he said "Keep your details to yourself. If you are a tester, we agree that there is this thing to test, and we agree that we need to keep track of the test", but you got to look at what data you expose. It's the title we agree on and maybe a little bit of information on what it is, but our concerns or your concerns? We need to let people have concerns. When I ask people what the user story is, often times the thing that comes up or the thing that gets said most often is a token for a conversation. I dug in a little bit. Do you know who first said that?
15. I think it's Ron Jefferies.
I thought it was Ron Jefferies, too, but I hear it was Alistair in the original C2 wiki where they were discussing a lot of this stuff. I believe the last consensus was that it was Alistair before extreme programming was written. But the important point of these things is the conversational point. If we draw back in, we were talking about the story map and the idea is that it becomes a conversation.
These are called user stories and one of the most difficult parts of software development is understanding what users are doing and building an appropriate product in response to that. That's what the map ends up doing for me. I pulled out my little quick reference here that I build to support classes to trying to steal it. I overcomplicated and explained it in a lot of different ways.
16. Is there any place where we can get a copy of that?
It's on my site - www.agileproductdesign.com. By the time this interview is on-line, they'll be able to Google the term "user story map quick reference". But if you go to my site, under "Presentations" there is a user story mapping presentation, where there are lots of slides and links to articles and there will be links to this guide. It talks about what I see - the decomposition levels. I think I told you in the beginning I found a colleague - Luke Barrett - who was doing this thing and I keep trying to tell him that the things at the top I label as user activity.
There are big things people do, like in our conversation, this morning, getting ready for work is one of those big things. I can say it, we know it is and we can talk about it. Activities are where that resonates with the user centered design community and it's a common word that people can understand. My guess is, in getting ready for work this morning, a lot of people have this little ritual they go through with checking their e-mail, and checking their to-do lists and things like that.
We can refer to this as an activity just catching up with what's going on in the morning and it has things inside of it like checking e-mail and checking appointments for the day. If you look at checking e-mail, under that it breaks down to reading mail, responding to a couple of people, maybe flagging a few things for higher priority. It is in some way a simple functional decomposition, but there is a left or right order that helps us understand experience and then, as we get down to the details, now we're in the bowels of things that we can start to say "I could build a feature for this or a piece of functionality for that."
Yes, those are the leaves. And then, frankly, even those leaves break down to the smaller leaves, but our goal is to understand. On the backside, of this thing I talk about the process that has worked for me, initially starting to create the thing and a mantra that focuses on a mile wide/inch deep. We're trying to understand the experience and what I see go wrong in a lot of user story workshops is people grab on to that user story format and they know the good user stories have tests and they go a mile deep/inch wide.
We will work for hours and hours and never understand the whole breath of what people do - oddly, this from a community who abhors big design upfront. So, I see huge big design upfront or short sighted deep design upfront. A mile wide/inch deep filling in and validating. I find that I get these maps up and suddenly, if they are out on the wall and visible, I can bring lots of different users in and we can walk the map and they very quickly understand "I do this, but over here I do this different thing, and now I do this" or "That's not right! I do this after this."
You can tell "That's interesting, I talked to this guy and he does this before that" and he says "Oh, yes, some people do that. That's interesting to know" and we can have conversations like that. When you've got something big on the wall, suddenly you have wonderful nouns like this, that, over here, back there and way down the road. You get these conversations that start being clipped and short and meaningful and include gestures and pointing and suddenly stories become about conversation again.
Then, at some point in time, we need to start actually deciding what to build.
I find that people put things in a column, down at the leaf level, people naturally start putting important things at the top and less important things down below. We started the metaphor with one of the very first articles I wrote and this was called "How you slice it". The metaphor is left or right slicing. You find that at the leaf note, where I want to do some prioritization and release planning, I can just slice things and people will naturally move things up for high priority, down for lower priority, but then we end up prioritizing across the entire breadth of the functionality.
We end up with holistic slices of software that server people. That's the long and the short of it. For me, the story mapping thing is going back to using the story as a genuine conversation to actually drive understanding of the system, not as what I've seen it become - molecular conversation about the details of a particular feature and how we're going to test it.
It starts pulling in all the engineering concerns and testing concerns and we get bound up about estimation, it's the planning concerns and we use terms like "epic" to say "too big" and we mean "too big" from an engineering perspective, not from a user's perspective. We start pulling in the concerns of constructions way too early before understanding. That's what I'm edging at with all this stuff.