The thing I’m pondering a lot right now is what exactly Agile means or is suppose to mean. As I was telling you before we started talking, that I woke up this morning and I reached into my closet and we’re in an Agile conference, (can I say that), and I dug out my old XP Universe t-shirt from July of 2001, which was the first XP conference. And this was in July and the term "Agile" was coined in February of that year. It’s ten years later now and I’m thinking a lot about what Agile means now and what Agile meant then. I come from the product world where successful software development meant that when you shipped the product it was successful in the market. And now ten years later the thing that’s on my mind is that for a great number of people successful software development means it’s on time and under budget. It was never enough for me in the 90’s and it’s almost taken me 10 years to figure out that a product is successful in the market isn’t what everybody else wants. And for the many, many people involved in Agile development now I find myself pondering "Am I thinking about something else other than Agile development?"
Lean Startup sprung out of a book on product management in a startup context, the product management book was "Four Steps To Epiphany". The Four Steps To Epiphany talked a lot about customer development cycle. The idea that before we develop a product we need to develop a market for the product, or customers for that product. And to understand those customers we need to do things, we have ideas, we execute those ideas, we build a little bit of something, we learn something and then we adjust our ideas. And the cycle that seems to drive Lean Startup is an outward focus on customers and users and it’s built around a learning cycle, how fast we learn. The behavior that shakes out of Lean Startup is... I went to a First Lean Startup conference where Kent Beck was a speaker and Kent had modified the Agile manifesto to add additional statements to everything, and I’m at a Lean Startup conference and I see people that aren’t user experience or user centered design people talking with pride about how many customers and users they’ve talked to every single week, how often they’ve put software in front of customers and users and I’m here at an Agile conference and I have a hard time convincing people to do it all.
They’re happy doing script demo to a business stakeholder every once in a couple of weeks, but there are very few people beaming with pride about how much genuine user customer feedback they’re getting. I think I tweeted the only thing I didn’t like about Lean Startup was the name. It’s not just for startups, a lot of very big companies I spent a lot of time working with, need to behave a lot more startups and it’s not necessarily just a lean-ish thing, it’s a sensible thing.
Well candidly, I don’t think Agile ever had its focus on the customer. When the manifesto was first written and we started with extreme programming, the word customer was commonly used - but it commonly referred to the person on the other side of the conversation with the developer, which often times meant business stakeholder, which often times meant business analyst, and it rarely meant end user. One of the other things that’s always thrown me is I came from an organization that builds software that was used by people outside of our building. We were very aware that there was a difference between customers and users: customers buy things, users use things. And we were building software for enterprise class people; we know that the buyers aren’t the users. In the words of Lou Coleman, he’ll use the words users and choosers. The people who choose the software make decisions on what it should be are not the ones who use it on a daily basis. The world is more soupy than that.
The old XP concept of there’s a customer, and it’s a single customer and/or the customer speaks with one voice and the new Scrum concept that there is one product owner... none of it ever really dealt with actually getting out to the market and out to the public. So the original question is "Am I worried Agile is not dealing with the customer", I’m not sure it ever did.
4. So, how can it start, I guess is the follow up?
The interview is turning into an interesting reflection. I’m not sure if it should start. I’m not sure if it needs to. If you remember in 2000 when I started with extreme programming and I started with a company that was using XP, I kind of fell in love with its engineering practices but I didn’t see the same types of practices that I had used. There was a lot things wrong about me in 2000, 2001 and I apologize to all my coworkers back then, but I kept feeling that there was something fundamentally broken about XP, it wasn’t working. A person who was my XP coach at that time was a guy named Rob Me. Rob owns a company called Pipital which is a cool company that does some great things, but Rob was saying at the time that it’s not XP, it’s not broken, it’s not what it’s there to do. Agile development seems to me very focused on delivery and this strong collaboration between the people who want software built and the people who build it and focusing on those people collaborating effectively and building the software effectively and incrementally so that we can see it, we get visibility. And Agile development affords really good behavior, but Agile development is about fast effective delivery.
Agile development isn’t about the work we do to figure out whether we’re delivering the right thing, Agile development turns on the person who asks for something, getting it and getting it frequently enough to be able to reflect on it and do something to determine if it’s the right thing. Agile development isn’t directed at helping that person, giving that person specific tactics to figure out if it’s the right thing. Am I making sense?
Yeah, they need to change a lot. There’s an old convention and you get to hear a lot of talks and we were talking about Lean Startup, you’ll hear this in Lean Startup quite a bit. The old convention is owner, founder, smart business stakeholder gets great idea, works with some people to elaborate that great idea well enough in an Agile context to build a backlog, we build a backlog and we start iteratively and incrementally building software, we look at that software internally, somebody in a product owner role, or customers, or stakeholders look at that product and we may or may not put it in front of people but in the end there is a big bang, there’s a release, and that’s the time we learn. Very often exactly what we plan to build although it’s exactly what we said we needed, it’s we got what we want but it’s not what we need, and we find out too late. For me Agile development is a learning process, not a delivery process, and I want to leverage those cycles to learn as quickly as possible. And waiting until after a long, many-month development cycle to learn is too long.
So, from a business perspective, for organizations to really leverage Agile they’ve got to plan and think differently about their products. They have to plan to learn, they have to plan to fail, nobody wants to fail, but they have to deliberately get products in front of people so that they can learn if they were the right products to get to people. Does that make sense?
This is what’s interesting, I’ve met you a couple of times and we’ve talked about this and you’ve been around in this Agile space for a little while and we’re at an Agile conference and there’s a bazillion techniques in the Agile community to support delivery. There is at least that many - that wealth of techniques that support... the complementary term I use for delivery is discovery – the work we do to understand what we should be delivering. There’s discovery stuff and delivery stuff. A lot of people use the term discovery, but in conversations with my friend David Hussmann, we’ve decided that those are nice complementary terms. What product owners learn to do is discover and learn to learn about their customers. I won’t enumerate all the techniques, but the fundamental thing that product owners learn is that they’re responsible for the outcome. People have heard me talk before so this is a bit of a broken record, but output is what we build, outcome is what happens after that. I’ll tell people your job in software development isn’t to build software, your job is to change the world.
Then I wait for a bit of a pregnant pause there, because that sounds lofty, but the point is we wouldn’t build software unless we wanted some pain or something that is not correct in the world to be fixed or changed or repaired or better. And the only way you know if your software is working is not if it’s built on time, not if it has all the features you asked for, but if when it’s delivered, people use those features and behave differently and are satisfied by the product or all those things. Product owners are responsible for that and I think your original question is "How do they be better representatives of the customer?". There’s lots of very specific techniques and tactics but maybe this is where Lean applies. What is the Japanese for "How’s your Lean?", I forgot my Japanese for this, but there is a Lean concept that talks about going there, being there. Gemba is the scene of the crime, the place, and I think it’s the heijunka box, I don’t remember saying it right, but it’s the go and be there.
Now, if you are product owner and you’re representing your customers, no one builds software for one dude. It’s very rare that there is one customer that you’re representing or one end user that you’re representing, you’ve got to go there, don’t bring them on site, don’t bring them to your location and talk to, go to where they are, go to Gemba, go to the scene of the crime and see them work. I was talking with a guy that I worked with years ago, a guy named Don, and I had worked with Don early on and together we learned a lot of the things a product owner practices. He had moved on to taking over a product management role at a company and by all accounts was really wildly successful, and I asked him the same question "What’s your secret? If you were giving advice to someone else who is a product manager to do as well as you have, what would it be?" and he said "Go there". You can’t fake it, you can’t fake empathy, you can’t gather enough requirements, you have to genuinely have empathy. You have to genuinely know them and see them and to be able to think from their perspective.
I’ve been stewing an awful lot about stories lately, because again I started with XP in 2000 and stories these days, user stories or stories are used commonly in Scrum and a lot of people who learn Scrum now think stories are part of Scrum. Well stories came from extreme programming and not Scrum. They’ve been around for a very long time, they are not the only way to handle requirements but they are a fabulously super simple idea. I’m going to get to the story-mapping thing in a minute. I’ll give Kent Beck credit for inventing stories but I know there were a lot of people and a lot of conversations over time that did this, but stories are meant to be heard and not seen. The question I am so sick of is "How do I write good stories?". The point isn’t to write good stories, they were called stories because you’re supposed to tell stories. What you write on a card isn’t important, what you talk about is.
The original concept was I write something, and I write a bunch of things, we can arrange the bunch of cards and we can say: "This one is the most important to me to talk about... now let’s talk." You tell me a story about what you want and out of that story we come to some common shared understanding, or shared mental model of what should be built. And at the time we do that, we make a bunch of notes about what to build and then we have some shared understanding about what to build and we can move forward. The story, or what was written on it, doesn’t much matter, the conversation that shakes out of it that is. So, the original naming of the thing was about "I’d like to hear your story". Now that’s all well and good and we’re going to execute and work with development and this is why I say that Agile development is very much directed at this relationship between the person who wants something built and the builder, the maker, the person who will make it. But, now when we switch our perspective to the product owner, the person who is got to figure out what to build, it’s not that obvious, they don’t know exactly what to build. It’s complicated and nobody is building software for themselves.
I would assert that nobody in an Agile customer product owner role is building software that they themselves will be the sole user of. They’re always representative or other people that aren’t themselves, and they have to understand those other people. So a story map is a simple concept. It’s a map because it has latitude and longitude. And the left to right axis is just a big story, a flow, it’s a work flow, it’s a narrative flow, the steps a human takes to do something when they’re using a product. It’s the experience of somebody doing something. And then top to bottom is the decomposition of all the bits that we might use to build it. So when I’m talking to somebody in front of the story map I can talk trough things in terms of this simple narrative flow and then when I’m moving from that conversation about who the people are and what they do to the tactics of what I built first, I can then move down the stack to talk about the bits that I need to build and in what order I need to build it. So the left to right shape is from a user’s perspective, the top to bottom is from priority sequence that I construct in perspective.
From a conversation with a friend that lives close by me, Alistair Coburn here came up with the name story map and it’s something that I’ve been doing for a very long time and it’s a longer story behind how I did this. I’m adapting stuff I learnt from Larry Constantine and Lucy Lockwood, I thought I was super smart inventing this simple variation of what they do with task analysis and task modeling. And I thought I had this simple square shape and I thought I was super smart until I started running into other people that without knowing me and knowing this came up with exactly the same shape, exactly the same structure. I’m name dropping a lot, but a definition of a pattern that I heard from Linda Rising before is that if you tell people about a great idea and they say "Wow, what a great idea" that’s not a pattern, but if you tell somebody and they say "Yeah, we do something like that too", that’s a pattern. While I was lucky enough to come up with a sticky enough term for a story map, it’s a pattern, there a lot of people that end up doing the same thing. And it’s a simple pattern to help us look holistically at a product, to represent what we’ve learned, and what we understood about users and tactically, top to bottom about the development of that product.
The odd thing is I don’t think I ever once considered using user stories as they were. There was no motivation to ever use them off the shelf as.... I’ll rewind. What I was doing in the 90’s... I worked for a company that was smallish initially and then grew a bit larger, and the company was either smart enough or stupid enough to let people who were developers talk directly to customers. And our customers were larger chain retailers so I knew that my customers were outside my building. I knew that when I was talking to one that the companies were large enough that I knew that many of them had different opinions, and I knew that if I was talking to one chain retailer I was responsible for building features that would be used by a lot of them. So I knew never to take what one of my customers said as a requirement, I was always responsible and always had to do the work of understanding my customers and what they needed.
And when I came across the idea of user stories I understood them as focus for conversation, which is a common mantra, and a mechanism to get things into development. And I thought that’s a great idea. I still had to understand these customers and what they need. So the logical assumption was to say it’s simple to take these user stories and arrange them into a shape that helps me to explain to other people what’s going on with the customer. And I’m lazy, I don’t want to write use cases and construct work flow models and do lots of other types of models to figure out what users do and represent to other people and then turn around and from that extract user stories. I’m lazy; I just want to build this model out of user stories. And that’s it. I guess possibly the first time I would’ve used them is after working with a startup in San Francisco were I learned extreme programming and I’ll tell people that’s were a I fell in love with Agile processes and extreme programming but I also learned to really get bugged because the company didn’t make a successful product. The product did not do well in the market and they didn’t do a lot of things I thought were necessary to do that.
So I went back to product managing and managing teams in the organization I’d come from and of course I’m going to use Agile processes and immediately the first project I started with I started building these simple maps. It just was an obvious thing to do.
10. I did. I don’t know if the audience will have.
I’m lucky I live in Salt Lake and that’s where the manifesto was signed. So I got to be at the party - this ten year reunion, sort of pulling a lot of the original manifesto signers plus a few other thought leaders in there. The original manifesto meeting had seventeen people and we had thirty something people at this. Partly because I live here and nobody wanted to not invite me to the party I got to be there. And David Anders said something interesting during the facilitated part that there are a lot of elephants in the room, a lot of things that the Agile community says but won’t go into details about or subjects they avoid, and he said for instance business value. And that conversation went by but then we a large break in the afternoon and I was able so sit down at a table with David and a bunch of other people and said "David, I want to hear more about elephants in the room, let’s start with business value". And out of that good rousing conversation that went on a couple of hours, we made a long list of things that were problems.
Business value is a big one for me because we say it over and over and over. You asked earlier in this conversation what I teach product owners. One of the first things I teach product owners is you can not say that anymore. You can say business value, but it is your job to be very specific about exactly what is valuable and what isn’t. You can’t say business value. That’s vague. That’s ambiguous. You have to be able to tell people what is valuable and what isn’t. So talk about that elephant in the room. And going back to something that I said earlier, business value or what’s valuable, ultimately what we are striving for is this positive outcome, the result of building the software. Not the software but the benefit we get after we deliver it. And, I’m working with a lot of different companies. The companies that mostly call me in are companies that are product companies, that are using Agile development and realize that Agile is great for delivery but there’s this big hole in here between all the stuff that happens to figure out what to build and all the stuff - everything that happens outside the Sprint - this sort of blank spot.
And we talk a lot about focusing on outcomes and one of the things that companies that are more mature doing this are realizing that there is no simple correlation between the amount of software we build and the amount of benefit we get. Outcome is always speculative. I can build a little software and get a lot of benefit, I can build a lot of software and get a little benefit or no benefit or I can suffer a loss. Software is speculative. Every piece of software that we build is a hypothesis about something we can put into the market, something that we put in the world that would make things better. The value comes from that better part. The thing that will rile me sometimes is the overly simplistic discussion about business value in the Agile community. The idea that we can put the business value on story cards, the idea that we can prioritize by it, the idea that we know what it is. The mature companies I’m working with know that there is no direct correlation between the amount of software we ship and the amount of benefit we get. I run into companies that are very depressed that their productivity looks low, because they are not seeing a lot of benefit. But in fact they are building just as much as they ever have, they are maybe even more efficient then they were before, but the stuff they’re building just isn’t working in the market, and now that they’re paying close attention to outcomes they see it.
The real conundrum that we’re left with is how much we build doesn’t necessarily... there’s no linear or simple correlation between it and how much benefit we get. That it is really speculative. That at the end of the day, we’re coming all the way back to something we’ve always known, this stuff is hard. And while it is really hard to get software built, it’s really hard to get good quality in that software, it’s super, super hard to make decisions about what we should be building and this isn’t easy stuff.