Hmm, where do I start? I’ll give you the intro that I give to other people. I’ve been in software development for over 20 years now. I was lucky enough to get started on this on the ground floor of the Agile ponzi scheme. I started with a XP project in 2000, that had hired Kent Beck to coach it and right away I fell in love, well I simultaneously fell in love with working this way and just hated it. And I loved the intention paid to process, and the discipline around it, but I had come from a world where I had moved through the ranks as a developer, to UI-developer, to UI-designer, to a product manager and I was focussed on building good products and I saw a lot of missing practice around products. So I’ve been in every role in software development. For the last chunk of years I have been working as a consultant. My area focus is on Agile practice plus good product management, plus good user experience practice and today that’s a blend of Lean user experience and Lean Startup thinking, things like that.
It’s funny. I can remember an old mentor of mine and me, trying the make the case that Agile practices were really missing something, that they really dropped the ball. And he kept telling me that: No, not that they dropped the ball, that’s not what Agile process is for. So in defence of Agile process, they do a lot of right things, but the Agile process certainly the way they are traditionally used, they are focussed around delivery. A traditional Agile process starts with somebody who wants something, describing it, a lot of emphasis on communication and then how well people work together. Than we focus on using a lot of good practice for building things and at the end of the cycle, we look at what we have built and we inspect it. But these days I focus on good product practice, where we try really hard to make sure we’re building something that someone wants from the outset. See if I can more concisely answer this. Agile process is built around what might be an IT model, where someone has requirements and gives them. I work with a lot of product companies, where the hardest thing is figuring out, what we should build at all. And there is a lot of work we can do, short of building working software isn’t always the cheapest, fastest way to figure out if we should build software. And, that’s what is missing for me in Agile practice. And what’s cool to see is the evolution of this stuff and again the threat of Lean Startup is inside the Agile community and inside a lot of other places and that’s both attention to that concern and a sensible faster attention to that concern.
Todd: And you mentioned the word requirements, that was something you kind of talked about in your talk and that stories and requirements are different.
Yeah, this particular conference I have been asked to deliver a talk in the Agile boot camp track, a talk about requirements and planning and product management in Agile. And I said, well, I am only going to talk about that, if I can start with that Kent Beck quote, that – from the extreme programming explained – don’t remember it exactly, but something to the effect of: the word requirements is causing more damage to the software development industry than any other. He explains that you call things requirements, but the truth is that they are not required. The majority of requirements aren’t actually required to really deliver a value or a benefit and than, when you call things a requirement – Gosh, it has been my experience, that when you say that this is a requirement, it’s kind of a conversation killer. You say it’s a requirement, people say: Ok, great, it’s required and just tell me the details of how it should go and I will build it. But the idea behind user stories, is the reason they're called stories, as we are supposed to be talking to each other. They’ve got their name from the idea, that you and I should get together and you should tell me your story. And it’s during this story, you will talk about … paint your vision for this product or this thing or this software functionality. Who is using it and what they will do and why they are using it and together we figure out, what is the best solution to this. What’s the most cost effective thing we could build for someone. It’s a very different thinking and working style to me guessing it what I want and describing it to you as a requirement and you building it. At the end of the day you don’t understand what my real problem is and I may understand my problem, but I am not the software expert and I gave you my guess at the solution. The requirements model is a bit dysfunctional and stories try to fix it, so that’s what we are trying to correct.
Todd: You also mentioned, aside from not being a big fan of Agile development at least for a lot of product stuff, you also mentioned, you were not a huge fan of epics and themes.
Ah, I just … The word story gets its name from how it is supposed to be used. You are supposed to tell me your story. Calling something an epic, kind of breaks it down. It doesn’t, … I guess we mean epic as a big story and “telling me your epic” no longer means something and I too often see the word epic used, first off the word: epic refers to a story that is really big and when we say big, we mean, takes a long time to develop. Now, if we are really talking about a user’s story, the story I tell it is based upon what I need, not how long it takes to develop. You know, one example I remember from a company building something, they are building a product that allows for drawing and there is a simple menu choice, where you say: File – Save As – Photoshop document. Sounds kind of small, I just want to save it as a Photoshop document. How big could that be? As it turns out, that’s something that took multiple developer’s months to build. That’s an epic. How would I possibly know that, if I was a user. So, I often times hear engineers say: Well, that’s an epic. As a way of saying to people, you haven’t broken down your stories small enough and it starts to smack of you haven’t broken down your requirements small enough and it’s no longer a conversation, no longer us working together. So, not a fan of the term. I didn’t hit the themes, but theme is not so bad. But theme just means a bunch of things that work together.
I’ll ask people first off to think of stories as rocks, if you take a big rock an put it on the floor and hit it with a mallet and it breaks up to a lot of pieces. And what do you call those pieces? They are rocks. So a rock is a rock, all the way through and stories are too. You can break them down that way. And than there is the Asteroids’ metaphor. I got this metaphor from, oh, I am going to be in trouble for not mentioning his name, it will come to me just in a minute. I can picture his face, but can’t remember his name. Sorry. The old Atari game Asteroids, you are a little space ship in the middle and there are these big slow moving rocks flying through space and your job is to shoot this big asteroids and well, blow them up. But if you shoot a big asteroid it breaks down to a few faster moving smaller asteroids. They go in every which direction. You shoot one of those and they brake into even smaller rocks, moving even faster, going in every which direction. And it’s a really crap Asteroids strategy to take all your big rocks and brake them down into small rocks really quickly. You’ll die. And so I tell people to do this with their backlogs. Don’t take all your big stories and break them down into a lot of small little stories. You’ll have hundreds of them and you’ll die. It’s a loosing strategy for managing backlogs. The cool thing about stories in backlogs is, you can put them back together. You can roll up lots of small stories into bigger stories and you can’t do that in Asteroids. So, think Asteroids when you are working with backlogs!
Grooming is another word to rant about. I remembered taking some original Scrum training from Ken Schwaber in the early 2000s. And I remember, him using the term grooming the same way you use grooming for beard or your hair. It means: Man, you are looking shaggy or dishevelled and grooming means to cut away, to remove things. And grooming your backlog back than I understood it to mean, stop using your backlog as a trash can. Stop throwing any old thing in there! Cut away the stuff you don’t need. Keep it tight. And referring to the Asteroids as a metaphor, take a lot of the little junk and roll it back up, so convert a lots of little stories into boulders at least. Keep it tight, keep it orderly. That’s what grooming means. But one of the other things that has to happen, the stories, well we need to get clear about what our story is, before we go into a planning meeting. It just makes them go better. And we need to have lots of conversations with team members about them. We really need to imagine the details of how they work, understand the business rules behind them, understand what UI would or could or should look like. I mean, we may need to do UI design and we eventually need to arrive at an agreement of what we’ll build, the acceptance criteria stuff. So all that work to go to deeper understand and elaborate them gets called backlog grooming now.
Ah, ok, a word is … there is an old Lewis Carroll quote from Alice in Wonderland that Humpty Dumpty had said: “When I say a word it means precisely what I want it to mean.” So grooming means precisely what its people want it to mean. So that’s ok, that it means that. But now to the question that you have asked. The antipattern I see on grooming, is lots of people show up in a room, we project your favourite Agile life cycle management tool, JIRA, or Rally or VersionOne at the wall, and someone mans the keyboard and we all type in acceptance criteria. And, lots of people try and ask, typing acceptance criteria and lots of people monkey wiith their smartphones under the desks. Everybody complains that it is too long. And that is not the conversation that Kent Beck imagined when he describes stories. The conversations we should be having are animated, they’re impassioned, they are in front of white boards, they are drawings, words and pictures, they are discussing alternatives, they are trying to imagine what’s the most cost effective way to solve this problem. There are not these boring things. So I think, what I might have said is, that when a bunch of people get together and it sucks, we call that a meeting. When a bunch of people get together and work effectively together, we might call that a workshop or collaboration. So backlog grooming meetings are that sucky version, the conversation that needs to happen in stories was the one people were originally going for, the one where we work together to try and solve problems.
Todd: So now one of the other things that you are better known for, that kind of can help us facilitates that, is story mapping.
Yeah, so I am known for story mapping, which is another thing that I am embarrassed to take credit for. I coined the term and actually it's something I've been doing since 2001. I didn’t coin the term, I called it something else in the 2000s, but after calling it story mapping it kind of took off. It’s a simple concept. Back to the Astroids metaphor: If you have got a big rock and you need to break down, and you want to keep telling stories, if the big rock is about what somebody does, tell me what you imagine. Well, I imagine first the user opens the app and than does this and than they do this and they do this and they do this. And if I tell the story and write down the steps as they do them, from left to right, because that’s the way stories flow: first step, second step, third step, forth step. Than I go back to the first step and I say: Ok, if they were going to do this, what are the details of how that might look on screens? What about when things go wrong? What about kind of other boundary things? There are other concerns here, but what we end up with, there is a simple two-dimensional model, left to right it tells a story and top to bottom it kind of breaks down an decomposes the story. I call that a story map, because it has a latitude and longitude and it tells a story and it is a really useful tool for helping to facilitate these conversations. And then the cool thing is, if you are trying to do some planning work and you have got a left to right flow, you know, the users need to get from the beginning to the end of the flow, but the question isn’t, you know, if I have to do a three step process and I don’t have enough time, which step do I remove, that usually is not an option.
What you cut away are the details, maybe some of the options in every step you can avoid, things like that. So the top to bottom axis we use to prioritize and we use to slice away things that we don’t need. So yeah. I’ve been known for that, but I didn’t invent story maps, I gave it a name, because I have seen other people create similar things. And there is an old definition for a pattern, if you tell somebody about a great idea and they say: Wow, that’s a great idea. That’s not a pattern. But if you tell somebody about your great idea and they say: Well, we do something like that too. That’s a pattern. Story maps are a pattern. I have seen multiple people do stuff like this. If they have got a name for it, it might have been something else, but a name is a powerful thing. Once it started, we all call it by common name, now we can build up a community around that thinking.
5. Usually this kind of happens in workshops, so who would be involved in these workshops
Ah, it’s a good question. If I think back to the dysfunctional backlog grooming session, there is everybody involved. That’s another characteristic of a meeting, that you are invited and invited is kind of a euphemism for “you have to go there!”, you are commanded. It’s like being invited to jury duty. You know, if you don’t show up, you will be arrested. So when you are invited to a backlog grooming session, that’s not so good. But if it is a workshop, you are invited and if you don’t want to come, don’t! But who should be there is someone who understands the product from the user’s perspective, someone who understands how to code the product and someone who understands, usually a tester, someone who is going to understand how to test this product. So you usually look for someone who is part of the product ownership team and often when you get down to the detail level, it is either a business analyst or a user experience designer, a UI designer, an engineer and a tester. And you know, that is the – a few people refer to that group as the three amigos, those are the people that need to work together. And than other people who are interested. But yeah man, it’s going to be a crap conversation if the people there don’t want to be there, don’t want to be talking about it. But it is also going to be a bad conversation if it is not balanced, if you have these concerns of representatives. So often you have a Scrum Master or coach to make sure we have got the right people in the conversation, so that it is productive.
I can remember Ken Schwaber once saying – one of the creators of Scrum – that the Sprint Zero term, there's no such thing. There is not a thing. The reason I don’t like the term is, it sort of implies that there is a sprint zero and than I start building. It sort of implies a phase as kind of thinking. First thing I do is a big requirements thing and than phase two is building. I use the term product discovery. I borrowed it. First the term has been used by a lot of other people. I follow a lot of practice and thinking from a guy named Marty Cagan, who has written a book called “Inspired”. It is the best book on product management, software product management, that’s out there right now. Discovery is the work we do to figure out if we are building the right thing, to figure out what problems are we solving, what’s a valuable solution, what can people use and what’s feasible to build, given the tools and time that we’ve got. Discovery is a continuous activity that runs in parallel with delivery work. And yeah, it has to run ahead a little bit, but sometimes the work that kicks out of discovery, is to build a high fidelity prototype, something that we might AB test or split test in our environment or other things like that. And sometimes the discovery is not done and we are putting things in to sprints and the minute you ship something, you start learning things and discovery starts again. So discovery runs continuously and delivery runs continuously and that gets referred to as dual track development, is the term that gets used for that. So yeah, don’t like the term sprint zero, like the term discovery and both discovery and delivery are continuous activities.
Ah, I hate answering questions with it depends. No, the whole team is not doing both, part of the reason I just said in the story workshop you don’t want the whole team there. There is sort of natural size limitations to effective collaboration. You don’t pair program with the whole team, it takes a pair, at most three people can sit together at the computer and any more than that is just too much, nothing happens. When you are working together to do something collaborative, but to move fast and make decisions fast, three or five people is the most. Discovery work is usually lead by a product owner, a product manager, same person, by someone who understands users, an analyst in an IT context, an interaction designer, a UX person in more of a producty context and a lead engineer. These people steer discovery and discovery involves business stakeholders, involves lots of users, it may involve the whole team at times. But it is usually that smaller group that steers it and pulls in people as needed. Now a work with organizations, where the whole team is five people: product owner, UX person, two developers and a tester.
And it is done to pull off three people and leave one developer and one tester, that do other stuff. So the whole team does go through discovery together. And you see kind of these ebbs and flows, where we do a lot of discovery and not so much delivery and than we are really confident, that we are building the right thing. Subsequent sprints where more focussed on delivery and a little less discovery. And than with bigger teams, I might see a continuous thread of discovery and a continuous high volume thread of delivery, with people jumping back and forth between.
8. So it would not be so much like a separate discovery team?
No, there will not be a separate discovery team. The people doing discovery have to be there to watch the thing being delivered. The engineer, the lead engineer that is helping with discovery, actually isn’t helping with discovery full time. They are helping with discovery some fraction of their time and the other fraction of their time they are working on the team delivery, building things. It’s a bad idea to have one group that would figure out things. In the presentation yesterday I used a lot the term “shared understanding”, that the problem with requirements documents is, that you only get so much out of them, people read them and interpret different things. What happens from conversation and other things is, we build a shared understanding, a mental model. We make the mistake believing we can write it down in a documentation and people will get the same mental model. The team that does discovery may have a really clear picture in their heads, but if they hand it of to another group that does not have that clear mental picture, stuff goes wrong. And, anybody that has been in software development long enough knows, that even if you build very high fidelity mock-ups, even if you build a good functional prototype, that when you actually put it in code something weird always goes wrong. It never quite turns out the way it should, so the people who did the discovery have to be there to help massage it back into a shape that feels like it would work. Did I get there to the answer of that?
Todd: Yeah, absolutely. Thank you. One other thing you kind of touched on was a kind of a shift for development teams. That’s a shift from outputs to outcomes.
Yes, it goes over and over. I have heard the language used a lot. Years ago at a conference a speaker talked about the difference between output and outcome. Output is what you build and outcome is what happens when things come out. That’s why it is called that. If I build a piece of software, it is not the software that I want, it’s people to use it, more people to buy it or to use it and for those people who use it to be happier, than they were before. You measure output in terms of how much you build, in Agile that’s story points that you delivered in your velocity. You measure outcome using metrics or KPIs like, you know, conversion rate on a website. How many more people buy, or how many more people register, or how many more people like it on Facebook. How much they buy, how much they put into the shopping carts. All those things you measure are actions that people are taking. Outcome is that. That’s the real benefit. And so much, that if you are focussed on requirements and details, you are paying attention to the output not the outcome. We want everybody to start to … maybe one more rant. I hate the term product owner sometimes. I wished it was product leader, but that doesn’t ring true. You want, I want to see everybody in the team to take ownership of how well this product is doing and not just ownership, real pride in it doing well. You hope that the person who is the product owner is a strong leader and helps set direction and vision, but if everybody is focused on outcome, that’s the side effect of everybody taking ownership.
Todd: Definitely. One thing you mentioned was Lean Startup a little bit earlier. And you also in your talk mentioned minimum viable product. Now, there is a little bit of a difference between how you refer to a minimum viable product and say, Eric Ries refers to a minimum viable product.
Oh, you know talking about the talk I gave yesterday, that had cut a lot on the fly. There are two definitions of minimum viable product and as there are with most words in the dictionary, so don’t get confused by that. I guarantee you that if you look up almost any common word in the dictionary, you will find one, two, three definitions for it. Hey, the original term minimum viable product came out of product management and in fact it was Eric Ries and a lot of his ideas were driven by Steve Blank and his book “Four steps to epiphany”, and even Steve Blank described minimum viable product in his book as the smallest product that we can ship, that is viable in the market place. Viable doesn’t mean crappiest product I could ship, viable for a product means, well viable for a living organism means, you can put it into the wild and it won’t die. Viable for a product means, you can put it into the market and it won’t die. So the minimum viable product is not crappy. It is the good one for the target market that we have got. So that was the original definition. But Eric Ries used it in “Lean Startup” and the book sold so many copies and now in the software community his term, he redefined it not minimum viable product, but he redefined it to mean an experiment. Your products are experiments. We build as many experiments as we can and you build the smallest thing you can build to learn something. And the smallest thing might be a landing page, the smallest thing might be a paper prototype, or some other prototype. But at the end of the day, to make it kind of clear here, we are not in the experiment building business, we are building experiments, so that we can figure out what the product is. So you build minimum viable product experiments, so that you can learn what the minimum viable product in the market place is. So I’ll define MVPEs as the thing we build to figure out what MVP is.
You know, there is a lot of a legacy and hold over. We just, in this conference an old guy that has been around a long time, Tim Lister, spoke, and he said something pithy and funny, that test, is the phase that we go into, that kicks us back to those other phases, that we thought we were done with. In traditional process thinking, when we start testing something or evaluating something and we decide it should be different, well, in traditional product thinking where we are concerned, in traditional project thinking – it’s another thing I mentioned – projects end when we deliver, products’ life start when we deliver. In traditional project thinking anything that delays delivery is bad and if we build something and we realize it’s wrong, that’s bad and that’s referred to as a bad requirements or as scope creep or as other sorts of derogatory terms, but in Agile development it should be called learning, that’s what it is. As a consequence of building it, we have learned that, that’s not going to work. And the truth is, everything that we build in software, we are manifesting our ideas that are intangible, software is not tangible anyway, but we are imagining it, we might dial up our imagination with prototypes and actually make it really feel like it is right, but until we start using it and working with it and actually solving problems with it, we can’t be sure it’s right. And correcting our bad imagination, that comes out of the learning thing.
Ah, what I am working on. Let me see, list a couple of things here. Hey, I am trying to move past Agile. I am trying to look at moving, I don’t know what the next thing is going to be called, but I know it ends up having to be a blend of the good sensible things that are in Agile, I want to jettison some of the bad thinking that are in Agile, the product owner decides what to build and the team builds what they are told to. No, I want everyone to own and I am looking at processes that blend Agile with design thinking, with good user experience thinking, with Lean Startup thinking, with good solid product thinking. And trying to build a group of people that do that and build common language around that and … You grabbed me, just after I finished a demo of a little tool that myself and David Hussman, of DevJam that we are working on. I am a tool hater, I don’t like a lot of the tools out there, because one of the things I get concerned about is collaboration, so we have been building a little product called Cardboard. It’s a virtual board that you put cards on, that’s all. That’s it. I'd love to work with people on a wall with sticky notes, or a table top with cards, but if you and I are separated by dozens, hundreds, thousands of miles, we can’t do that. So this is, well we describe it as if Google Docs and sticky notes had a child, this would be it. Our emphasis is on just simple card modelling remotely. And the thing that makes me exited is, it is actually starting. More important to me is not the list of features, it’s that when I am sitting working with somebody, it feels like I am working with them face to face. And it is starting to feel like that. So.
Todd: Excellent. Well, thank you for joining us.
Thank you. Pleasure to be here as always.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
Community comments