Hi Craig, good to talk to you again. I talk to you a lot.
Craig: Well we tend to catch up at conferences all over the place, and I tend to stalk you out like a bit of a groupie that I am. But it wouldn’t be an Agile conference without Jeff Patton there, I think I saw you at my first Agile conference in 2008 I think it was, I think I clambered to sit in the back of the room where you were talking about user product design or something along those lines.
Yes, it’s funny, this year at this conference I was in the stalwart track. I had to look up the word stalwart to figure out exactly what it meant.
Craig: Doesn’t that mean old guy?
I think it means old guy but it kind of means staunch supporter and there is a bunch of different variations, I’m thinking I don’t think I’ve been a staunch Agile supporter, I think I have been grumpy about it for a long time, I’ve been talking about what’s missing, but the truth is I’ve been here always, the first named Agile conference was in 2003, and I’ve been to every single one since 2003, it’s now 2015 so that’s a while. And then before that there were the XP conferences and I’ve been to them and before the conferences merged I was going to those since 2001. So yes I am a stalwart now because the trick is to just not go away.
Craig: SO you would be up for a gold watch before long wouldn’t you?.
Actually yes I am ready for a gold watch. Another ten years.
Yes, first I am very pleased to get it done, a lot of people will make comparisons to writing a book like carrying a baby, it takes a long time, and certainly I know nothing about that but I know it took a lot longer than none months. And there were a lot of failed attempts in-between. So I am glad to finally get something out, most people, quite a few people said “Didn’t you already have a book out?” so yes, I finally got something out and shipped.
Well, the truth is if you were to read my book all the way to the very end, I put all the acknowledgements at the end so I’ll tell you what I’ve told other people before, I can write short articles and small things but whenever I sit down to write a book it became too serious, I explain that my writing was a lot like taxidermy where you take something living and beautiful, you kill it and you stuff it and the best you can hope for is that it’s kind of life like. What I wrote up until then was sort of dead, it took something that was interesting and made it boring. What helped with this particular book was finding throughout the years I’ve had so many people that have helped and tried to help and thrown up their hands and given up, and offer to co-author, started to co-author, gave up. Finally the secret for me ongetting this thing done was finding an editor, the guy whose name is on the cover that did not come from software development, he came in, he is a writer for Ink Magazine, and for a lot of other business magazines and has edited and helped co-author a lot of books, but he knows good writing, he doesn’t know software, he knows good writing and we focused on that and he quickly identified that when you speak about things that’s good, when you write about things what you write is kind of boring so here’s a way we are going to do this, we will talk together every morning for an hour, I will send out the audio and get it transcribed and then I’ll edit the transcriptions and people would tell me that the book reads a lot like you speak and that’s because it was all spoken, a lot of it was spoken at least.
Craig: That’s also, what you’re really saying, what we can learn from that is, when you are setting up your team get the people with the right skills on the team.
You can learn that but maybe the pithy way I will end up saying that is to come in the Agile world and what is that first Agile manifesto value that it’s individuals and interactions over process and tools. A lot of people think if they follow the right process that things will go well, process is not skill, and when it comes to writing a book that’s different than being good at building software. It took me a while to figure out how to find my voice writing, and it was finding the person with the right skill that helped.
Yes, the German and Japanese editions were released last month, and last conversations with O’Reilly, Korean and Chinese versions are in translation and then French, Spanish and Portuguese editions they are talking to translators about those. Demand is good, InfoQ has a big audience, Craig you’re from Australia but oddly when I look at Amazon sales the country that sells the most on Amazon at least is Germany. More people buy the book in Germany. The cool thing for me is the practice, it went global fast.
The big problem with stories - I started with Extreme Programming in 2000 before the term Agile was coined, and then at that point the thing that Extreme Programming described was stories. We will be sharp about this, they weren’t originally called user stories, they were called stories, and if you buy the XP Explained book now they are still called stories not user stories. But they are called stories because we were meant to be talking with each other, it’s a story not because of how we wrote it down, but because I carry whatever I wrote down to you and we talk together about it.
During that conversation we are focusing on not just what to build but why, who it is for and why? That’s why people started calling them user stories to remind us we should be talking about the users of the system, but then things emerged, the template that a lot of people live by emerged, the “As a type of user I want so that”. And then I get people saying: “Oh I can’t use user stories because I am writing an API, I am writing something deep in the bowels of the system, there is no user here”, or not everything fits into that template and I have to remind people that they get their name from how we are supposed to be using them. Now, gosh, it’s been fifteen years since stories and Agile started to take root and by now they have gone a little bit sideways, people have thought user stories, people hammering about are they writing them correctly, when the goal wasn’t writing them at all, for if your writing just enough, and not correctly certainly, the correction comes in the discussion, and the other thing is when you name something of value that you want it’s often way too big, there’s the aspiration that we build lots of these stories in a sprint or iteration, or a short time box, and one of the problems we run into is an idea that has any sort of value is a lot bigger than fits into a sprint or iteration. So story maps are a way to start talking about a big thing and break it down into a small thing.
You use story mapping to explain a big product idea, and at its dead simple idea – look we’re at this conference, we’re at Agile 2015 and there is a conference app and if I were to open up the conference app I can see there’s a lot of features in it, but if I were to tell you how this works I would say first I open up the app, and then I log in but unless you log in the first time, because then it remembers, then I can see all the sessions, I can look at my schedule, I can search for a session or I can search for speakers and whenever I find sessions or speakers I can add it to my schedule and then when I look at my schedule I see what’s in there. And if you see I’m telling a story step by step by step by step.
6. And they’re the activities that someone would do?
Yes, the big things are the big steps, and everyone of them can break down further. A story map is a simple two dimensional model that left to right tells a story, and top to bottom breaks it down into parts and they are not organized by priority left to right, they are organized in a story, or a narrative and they are broken down top to bottom, there is that logging in step; the logging in, the details inside that, creating a user name and password if I don’t already have one, entering a user name and password if I do, and recovering a lost password, there is a lot of things that are underneath that login step. So It gives us a simple structure to talk about the big picture and not lose sight of the big picture, helps us tell the big story to get to the little stories.
Craig: And I think that’s one of the things that you certainly extrapolate in the book is the conversation and standing around that wall or that artifact and having a real conversation is the real output from that not the map itself.
My aspiration with the book is to remind people of the promise of stories, to remind people why they work in the first place, and in software development and the building of anything, people have struggled for years, everybody is trying to find a better way to document and communicate requirements because if you document enough so that people absolutely get it, it’s way too much and then people still don’t get it, if you document too little people don’t get it, and the real promise of stories is that you’ll get it if you talk to each other regardless of how much you document. I want to remind people that’s what they are about.
7. [...] Is that something that you see in your travels?
Craig's full question: One of the things now, this process has been around longer than the book obviously, it’s something you have been talking about for a number of years now, it’s got now to one of those things where you see lots of teams doing it and then you see lots of implementations and people trying to take a lot of it literally, so one of the things that I wanted to ask you about was I see people have lots of discussions or even arguments about “The way I look at the order of things for example you might login first but I might login later, or you might go and look at sessions whereas I might go look at this” and they have discussions or an argument about the order the activities occur in. Is that something that you see in your travels?
Yes, constantly. What do you do about that? If you are trying the story mapping stuff… In teaching story mapping and I will do this at a workshop tomorrow, I try and get people to learn how to map using something other than software. And I’ll ask people, you’ve been there when I’ve done this, I’ll ask people to sit down and write down on sticky notes everything they did from the moment they woke up until the moment they left their house or basically how did you get ready this morning? And they write down all the steps and then I will ask them, first off they learn from that to write down short verb phrases, the steps are what people do, they’re not features. Then I’ll get them to arrange them in a left to right flow, if they arrange them by themselves they would come out in a perfect order, but if you think about it, you don’t get ready in the same order every morning, you change steps some mornings, things happen, so you can’t even map the way you get ready in the morning, there’s not one fixed way but I do this with a group of people, have them merge it together on a table top and they learn that they don’t all get ready the same way in the morning. But the sad part is that this is reality, you don’t use your software the same way every time, people are not the same, they use software differently and these are the kinds of discussions we need to really have. I’ll tell people that the discussion about order is the discussion we wanted to have but whatever order you put things in is the order that allows you to tell the story, it’s that typically people do this and this and this and this, and the way you take care of the branches, and what abouts and it might happens other way, is in the discussions or in notes or other things.
Craig: Yes the branching one is another one I get quite a bit is what if I am branching, what do I do if another persona - I want to portray them on the board and again people get hung up on that sometimes when creating a story map.
People will say “Jeff I’ve got this map and people do step one, and then there’s a branch here, where they might do A or they might do B, how would you map that?” and I would say “Well there is step one and then here is A and then there is B”. “So why did you put B next to A, why did you put them in that order?” And I will say “I didn’t, you did, it’s the order you just told me the story, you didn’t say B then A, you said A then B”. What I find is that there is kind of a natural order the way we tell stories, we know that we could do one or the other, sometimes we do things concurrently, but we can only say one thing at a time, we can only speak synchronously, and if you organize them in an order that supports story telling it seems to work out well enough.
First thing that comes to mind is that I sort of suck because I quickly see other cool things that people are doing, I quickly adjust them and try them out and when they work I sometimes forget exactly where I got it. I know that when I built maps I usually built them in small teams, just a few people doing it, but then I learnt from somebody else a long time ago that she would orchestrate big workshops where she’d get the map on the wall, and she’d do work ahead of time to prepare the map, or get all the stories there, but whole groups would organize it on the wall and they would work together to plan, I learnt from her how well mapping scaled, I’ve seen people do cool things with tagging, with marking things on maps, or illustrating concerns and architectural dependencies, I am trying to think of other things.
9. Can you elaborate on that one, the tagging and the dependencies one?
When you organize a map the map ends up being in a workflow order, and this is where things get a little freaky, people often times think in terms of features. In the context of teaching sometimes I will use an application that has sharing as a feature, but when you look at sharing, elements of sharing in an area upstream where you configure things, there is elements of sharing, when you are making a list of things, and you make changes to get shared with other and then downstream in the map there’s elements of sharing where when I did something that was shared a notification gets sent to somebody else. So features get spread out, when you look at a feature like sharing it’s split all across the map, so if I want to see where sharing is in the map I have to tag it or people use from a stationary store or office supply store they get colored flags where they will flag something, or mark things with colored markers, I see people doing things with different colored sticky notes to change things, so that’s what I mean by tagging, but people will go through, architects will look at a map and will say “Ok, we’ve got this dependency on this external system we are integrating, let’s go through and look at the whole map and let’s mark all the things where we’ve got architectural dependencies on this thing. People will build maps for a product that cross cuts multiple teams, and so we’ll go through and tag all the things, for which team needs to work on which piece. People figure out all sorts of clever ways to do this.
Craig: There are certainly a number of talks here at the conference where people are explaining it in different ways, which is really interesting to see. You are obviously more than story mapping though.
No, that’s pretty much all am, it’s just that one thing.
It’s funny I am known for this practice story mapping, and story mapping is cool, it’s seen as a bridging practice between product thinking people and development where we need to think of the parts we need to build but we need to think holistically about the product, it’s a good bridge between user experience people and product people and developers, because we are very experience centric, we are thinking about the product from an experience perspective, so that’s a nice practice but it kind of fits in a bigger soup of what motivates me to be in software development is building good products so it’s this world of product management that I am interested in. It’s interesting that I am starting to see that Agile has become a fairly mature thing, lots of Agile conferences, lots of people involved in it, but I am starting to see the rise of product management as a concern, I am seeing more and more frequently product management conferences, there’s a product management conference that started in the UK an organization called “Mind the Product”. “Mind the Product” launched regular meet-ups they referred to as a product tank, and when I look at “Mind the Product” I can see product tanks certainly in the UK, other countries and a lot of big cities in the US. They have a “Mind the Product” conference, the conference just launched in the US and when the conference came up they announced the conference and very quickly sold out. It’s becoming a strong community. And one of the bigger concepts that lurks in product thinking is this big concern that we’ve always known about, it’s the we might be building the wrong thing concept. And the way we learn if we are building the wrong thing is not by building it, in fact that’s the anti pattern, it’s if the only way you could figure out if you were doing the wrong thing was to do it and then see if that was wrong, that’s not so cool. If the only way you could figure out whether that knife was sharp was by cutting yourself with it, you’d think of a better way. So this is where Lean Startup thinking comes in, this is where a lot of other thinking comes in and this is where deliberate experimenting comes in. In the product world there is a stronger acknowledgement that we were doing things the wrong way, we used to work hard to figure out what to build and then build it and then figure out later if it was the wrong thing to build, in spite of our best research and best guessing, we were still wrong, now we are using things like rapid experimentation to validate our product ideas before we build, we validate with prototypes, we validate with simpler things, and the interesting thing for me is this is at odds with Agile thinking. Craig do you know the first principle in the Agile Manifesto? This is your quiz. The twelve principles.
Craig: First principle in the Agile Manifesto, number one.
Ok, I don’t mean to put you on the spot.
Craig: I can’t think of them in order.
I know this because I reference it a lot, it’s the working side, I can’t quote it exactly but it’s that working software is the primary measure of progress.
Craig: I’m not sure that’s number one.
It is.
Craig: Really? Ok.
Look it up, I am going to be in trouble if it’s not Craig, you should look it up. It’s this we value working software, and it’s the primary measure of progress. Product people are thinking “Woah, that’s too much, in fact the progress we need to make first is validating that we should be building working software, because working software is kind of expensive, especially if it’s potentially shippable, if it’s high enough quality to ship. In fact the first stuff we need to do is learn as fast as we can.” What is interesting me is trying to figure out how do we reconcile good Agile thinking which of course we need with good product thinking which of course we need and in the product world in Agile thinking we talk about working software, and we talk about velocity of Agile teams, and velocity means how fast can we build working software? But it’s learning velocity that matters more from a product world: How fast can we learn? And how cheaply can we learn and sometimes learning cheap means not building software, so how does a process or way of thinking work when our highest we value working software and we value learning fast, what happens when those two things come into conflict. When learning fast doesn’t mean building working software is that not velocity, does that not count?
Craig: I think wouldn’t you say though, and actually it’s number seven “Working software is the primary measure of success”.
What’s number one?
Craig: So I think we are both right here because number one is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.
Valuable software, ok, and number seven is the working software.
Craig: And I think those two go hand in hand a little bit because valuable software is what you are talking to whereas the working software is to make sure that when we do build something that it’s not something sitting in inventory or a pile in the corner somewhere, it’s something that actually works.
That’s right, the value there is the first and sometimes to figure out the way to deliver something valuable is to not build software first it’s to better understand what’s valuable and sometimes the best thing to do is to deliver a simple prototype first and check it for value and then adjust it and then take it to software.
Craig: That’s still working, correct? The prototype is still working in some way.
It’s just not software. And it’s definitely not shippable, potentially shippable means it’s good enough to release to the market it’s not that either. That’s the part.
Craig: And do you think this – are you seeing with these product management conferences, are those people coming from the Agile way of working or is this like some of the other movements that are coming through now where they’ve commonly been infected a little bit just because of the wayssoftware development has been working and they have gone “you know we have to do things differently”. Have you got a sense of where it’s coming from? Is it being pushed by Agile or is it just being pushed by the fact that that skillset is saying we have to find a better way of doing this?
It’s partly the skill set and if there is any one catalyst that has caused a lot more focus on this stuff it is probably the Lean Startup community. For better or worse the Lean Startup community has inspired a lot of focus on startups and startup thinking, at least in the States I am seeing the rise of accelerators or places where I might get help in starting a business and you get state and local governments that are helping to fund accelerators because they recognize that having technology startups in our city, helps the city thrive, there is a lot of emphasis on startups, Lean Startup thinking contributes to this, and boy if you were going to build a startup that people would recognize the old failure mode, the build it and they will come mode, that process doesn’t work and this is where there is a lot more of an emphasis on validated learning. What’s interesting is that that’s been a catalyst more than anything, what’s interesting and sort of concerning for me is when I show up within a product world there is an acknowledgment that we need Agile software development but there is this element of learning that Agile people just don’t get. Boy if I’ve got something that I would like to help the Agile community get a hold of over the coming years it’s to try and bring these communities a little closer together, to help Agile people recognize that they can be seen as just not getting it by product people and really start getting it.
For my money, what’s in the manifesto is a real emphasis on our role as people who build software. You have to look at the manifesto as a historical document, this was written in 2001, and in the decade prior to that we had been losing more and more money on big project failures, projects that would go through old traditional requirements processes and then never get anything built or go through a long multi month to a year or more of requirements only to figure out that we can’t afford to build this or start to build it and then cancel it.
In the early 2000’s our biggest challenge was just getting anything built at all. Happily,fourteen-fifteen years later after the Agile Manifesto, we are getting a lot better at building things. And now the bottleneck has moved, now it’s not about can we just get something built; it’s about validating whether we are building the right thing. Your original question is what’s getting in the way here, I think the Agile community is still – and certainly not everybody – but the Agile community is still focused on executing and building software. I’m involved with the Scrum community on re-evaluating what the learning objectives are for Scrum Product Ownership.
The primary source of what Scrum means, is by looking at the Scrum Guide, and the Scrum Guide is authored by Schwaber and Sutherland. If you look in the Scrum Guide, what goes in a product backlog are features or capabilities or enhancements or bugs or requirements, and it’s sort of not clear that you would put anything in the backlog that wasn’t software. And it sort of looks like it’s left out. That’s where we are now, it’s starting to acknowledge and change the discussion and maybe go back and rethink some of the frameworks, some of the basic frameworks we teach people.
Craig: I think it’s one of the things where we know the terminology and we can see how it could apply to other things but our terminology almost lets us down in that respect.
That’s right, and for people that are learning and take it very literally, you and I have been at this for a long time and we know what people meant when they said it, and we can see that we’ve evolved and we can do things a little bit differently, and we can be Agile in spirit but sometimes what gets in the way is the language we’ve used, in some cases the ten and fifteen years old language that we used. For people that are learning new they interpret it very literally.
If people want to find the book, where would they go? You’d go to the O’Reilly website, you go to an Amazon website, they type in user story mapping, and then a long subtitle that kind of ends in “Building the right product,” but user story mapping is easy to find.
13. And if they want to find more about you or engage you Jeff, how do they find you?
They would google Jeff Patton and my website now, my web presence has always been a little tangled, is now at jpattonassociates.com and just look for me on Twitter that’s the easiest way, it’s just Jeff Patton on Twitter.
Craig: Ok great to see you again Jeff and enjoy the rest of the conference.
Thanks Craig.