Steve Adolph on Product Management, Product Ownership and Business Agility

Transcript

• 00:21 Shane: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. I'm at Agile 2019 in Washington, DC. and I'm sitting down with Steve Adolph, Steve, Welcome.
• 00:31 Steve: Thank you, Shane.
• 00:32 Shane: Good to see you again. It's been awhile.
• 00:34 Steve: It is always good to see you Shane and welcome to our side of the pond.
• 00:37 Shane: Thank you. You and I know each other well but I suspect our audience probably haven't heard much from you and about you. So, do you want to give us the two-minute intro? Who's Steve Adolph?
• 00:47 Steve: Who's Steve Adolph. Well from probably what the audience would be interested in is who's this guy and why does he think he knows something about agile and engineering?
• 00:55 Background is, I've been an engineer longer than I care to remember for those of you who can remember, like PDP-8, eight bit computing and Fortran you're in my age demographic.  I used to design telephone switches, railway signalling systems, printer systems, about, oh my God, 20 years ago, I started crossing over to the dark side and became a management consultant.
• 01:19 I've long been interested in the agile movement. In fact, long before there was even a manifesto, I started getting interested in iterative development, spiral development, and just, how do we make better software? And so I was actually quite involved in the Patterns community knew quite a few people in the agile community from there, Alistair Colburn, for example, and I were writing a book at the time of the manifesto and I  kinda remember Allister phoning me up after the great Snowbird meeting and saying, see Steve, Steve, guess what we did?
• 01:50 And he goes on to describe the whole Snowbird meeting. And I just gave a big shrug because I was going well, of course, that's the way we would want to develop software. That was sort of how I officially got started into the agile world, but I've been doing a lot of work over this time. Even picked up a PhD on the topic, really trying to understand agility in software development, organizational theory, and applying that with my clients.
• 02:16 Shane: What is special about agile? And agile in software development?
• 02:21 Steve: I think what is special about agile is it's a mindset, you know, all of us go say that and go, of course, agile is a mindset, even though most people try to sell it as a collection of practices. 
• 02:32 It really is about rapid learning.  With saying that, all right, we're living in a world where we can not accurately predict the future, and we're going to be committing a lot of people and money to create products and services. And it's an acknowledgement that because the world is changing around us, what we may think is valuable today may not be actually what the clients find valuable.
• 03:01 I think there's two parts of it. There's a technical part of it, you know, that goes back to, you know, iterative development, quick integration showing off what we have. That's what actually drew me in, in the first place.
• 03:11 But there is also a business aspect. Are we actually building the right thing? And it's the mindset of how to organize people that we can make decisions very quickly and learn very quickly to understand are we actually building the right things?
• 03:26 Shane: I'd call that maybe product management, we hear in the Scrum about the product owner - isn't that all we need?
• 03:34 Steve: No, because that's always a problem I've had with Scrum. I mean, I really love Scrum, but what I all too often see is that we obligate, this person we've designated as the Product Owner as to be the big start and the end of the process.
• 03:53 Clearly all our items in the backlog come from this omnipotent omniscient Product Owner who knows everything about the product, and I, as an agile team member, I just work with them and take my stories, develop my increment, and then the world ends with that Product Owner. I just give them my work.
• 04:10 What we fail to realize is that there is a whole mechanism, usually, behind that product owner, it's like going back to Wizard of Oz, where they're told, please don't pay any attention to the man behind the curtain.
• 04:26 Like I said, we have this almost like dirty little secret where, no, of course there's not anything upstream or we've decided to explicitly ignore it. And yet to be straightforward, that's where the value is getting created. That's where people are working and trying to think, what is it that we really need to put in that backlog?
• 04:43 Now, some teams maybe the Product Owner is a subject matter expert. Maybe it's a small startup. Maybe it's a small team with an organization that has that entrepreneurial knowledge, but there really is a large process upstream from the team that's trying to figure it out what is the actual right thing for us to build.
• 05:02 Let's face it with most software teams, if they know what to build, they can build it  right. Most of our engineers are pretty sharp people.
• 05:09 Shane: How do we figure out, where do we start? If it's not this omniscient Product Owner? Certainly there's been a number of articles and a fair amount of movement talking about product management and how going so far as to say that Product Owner is an anti-pattern for product management. So, what is this good product management? Where do we find out what is the right thing to build?
• 05:38 Steve: 05:38 Well, that is of course the classic consultant's answer is "it depends". And the reason that we have to start off with that prefix of "it depends" is because the context of each organization is different. And the volatility of the marketplace is different.
• 05:55 There are some organizations, they do have some ability to protect the future. They have to operate to specific standards, but there's others that operate in very, very fast moving or they're working into green fields, but still I disagree that the Product Owner is necessarily an anti-pattern.
• 06:14 What I would say is that the Product Owner has to be involved and understand what we are building, have an interest in it and be willing to learn.
• 06:24 Now if a Product Owner is strictly, what I've seen in a lot of organizations where I think the roots of the anti-pattern can come from, is that the product owner almost seems to be some kind of ceremonial role, where that's the person who we can shift blame to, but the work, the stories that are in the backlog, it's locked and loaded. There is really no learning , no reprioritization. It's simply we go through the motions. That's where I think the Product Owner has become an anti-pattern; the disengaged Product Owner.
• 06:55 But realistically at the end, someone needs to really champion that process of alright, what is the idea that we have. What's the fastest test, the minimum viable product, we can put out there to learn? How do we use that feedback? What new stories come out of that? What stories come out of the backlog?
• 07:12 We call the Product Owner, you know, Buck stops with them. We used to refer to them as a single wringable neck, but who's that person who pulls all of that machinery together to make those decisions : that this, we do this rather than this, or what we've learned from the field. This is how it's going to change.
• 07:29 Shane: You use the term minimum viable product. So, so often I see that as an excuse for doing something really crappy. So what is a good minimum viable product?
• 07:45 Steve: Good minimum viable product answers a question. It's an experiment. So with the team what we have to be very clear on is what do we want to learn? We want to learn are we building a good product? And by that, I mean, building something that's actually going to create value.
• 08:02 Now, I agree with you. I think minimum viable product and lean startup, unfortunately, has become a very ugly excuse for teams to put crap out there. And we are seeing that, and I have a huge concern that we're starting to develop an attitude in many domains, even to the potential of effecting safety, where we're putting out poorly thought out products and it's having a significant impact on the lives of people.
• 08:29 I think there's a huge misunderstanding of what an MVP is. First of all, a lot of people confuse minimum viable product with the concept of a minimum marketable feature set. In my view, they're two very different things. Minimum viable product is something that we use to learn about what is the right product, what is the right way to deliver? What is actually valuable? We're trying to set up leading indicators that are going to tell us that quickly.
• 08:56 Minimum marketable feature set is what is the minimum set of features that we can put out there that people will actually buy and use. And I think, unfortunately we've developed a culture, especially that may have come from the gaming world and encouraged by many authors where yes, let's put things out there very quickly and get feedback, is actually permeating and making its way into other domains of software with some undesirable consequences.
• 09:22 Shane: So, minimum marketable feature set, let's explore that. What would an example be maybe of an MMF and an MVP? What would the MVP be that would lead us towards, or maybe there would be a number of MVPs?
• 09:39 Steve: There might be a number of minimum MVPs.
• 09:41 So a simple example from a client of mine, which I use a lot about sort of highlighting what an MVP is:
• 09:48 they wanted to put a automated assistant on their website. So, could they reduce the workload on the call centre by actually using an AI to help them understand? So, you've seen some of these on some of the airline websites, different airlines have, can I help you then they give them a name. So this one company wanted to see if is that something they could use?
• 10:10 Now, these things are expensive to set up, like actually building these things and putting them out there is a fairly involved effort? So, what they decided to do was just put the icon on the webpage and said, ask here, so just click here. And then it just took to a page and said to be coming soon.
• 10:29 And that was their MVP - cause they just wanted to see what people actually click through. Would this be something that people would actually be used?  That now told them, should we proceed with this or did anyone actually click through? So that was like an MVP. Something to help them learn.
• 10:45 Is this valuable? Is it going to be worth putting resources behind? Is this going to work in the way that we forecast it will?
• 10:51 The minimum marketable feature set is going to be all right, if we do decide that people are clicking through on this, then what is the minimum set of features that's actually going to make this useful? Perhaps we would start off with being able to write answers for only one set of questions, a set of frequently asked questions and then progressively build it out.
• 11:11 The main success scenarios might be a guide for building a minimum marketable feature set.
• 11:17 Shane: Main success scenario. You have written a book about use cases.
• 11:21 Steve: Yes, I have. In fact, that was the book that Alistair was co-authoring with us. I wrote that with Andy Pols and Alistair and Paul.  What's really kind of fun, I'm still getting the occasional royalty check on that. So, the book has had some pretty good, strong legs.  Use cases are still pretty hip. People are still interested in that.
• 11:40 Shane: How does that relate to user stories? You've written a blog recently about ending the tyranny of user stories.
• 11:46 Steve: The tyranny of user stories is that, what I'm seeing in  far too many organizations, is an obsession with the user story and that everything in the backlog must be a user story and expressed in the as a -  I want  -such that, and there's huge value in that because the intention behind it is very, very good. But not everything is conveniently expressed as a user story and not everything needs to be expressed as a user story.
• 12:14 And interestingly enough, if you look at, for example, The Scrum Guide, user stories are never mentioned. It's just backlog items. All that the Scrum Guide says is that, hey - the backlog items should represent something valuable and that should be verifiable.
• 12:31 Now the user story satisfies that really well, but I think we have become so obsessed with user stories we've pushed aside many, many other tools and practices and ways of capturing value that may be much more convenient for other teams. I've seen lots and lots of teams, they will have issues and problems with the quality of their backlog and the usual automatic coach response is to say, Oh, they were writing badly formatted user stories.
• 12:59 And so we put them through a user story writing course, and we drill into the team what good user stories look like and we castigate those who write less than good quality user stories. And all we've ended up doing really is not fixing the problem, we've just made ourselves feel good. That we actually did an intervention we got these better-quality user stories, but we really didn't solve the issue. Do people really understand what we're building?
• 13:24 Shane: Yes. I've seen a backlog with a thousand uses stories.
• 13:26 Steve: Yes. And that's a major problem right there. Now I've gone into so many clients and say, Oh yeah, we've already got 200 stories in our backlog.
• 13:33 It's like, you haven't even started yet. You know? So that's another problem in itself.
• 13:38 Shane: You coined the metaphor, the rock crusher for user stories. Tell us about that.
• 13:43 Steve: The rock crusher, you know, I'd like to maybe say a coined it, but the rock crusher is you see in a lot of organizations. So it really comes down to this where it comes from is I don't like the way we normally represent a backlog in the textbooks and you see every agile coach it's I call it the stack plates model. So, you know, there'll be a sort of a straight pipeline with little blocks in it, you know, like imagine like plates stacked on each other and all the plates were about the same size.
• 14:12 And so it automatically implies that everything in the backlog is prioritized, everything is fine grained. And that's not what a backlog looks like at all.
• 14:23 Realistically, you know, work that you have a couple months out in the future is going to be very large in scope, likely abstract, because you're still thinking about it. And then as its priority starts to increase, or is that you start what I say, crushing it, you start splitting it, you start splitting the stories or these items - I shouldn't just automatically call them stories - you start splitting these big rocks, or big items in the backlog into smaller.
• 14:51 You know, I like to think of it as much more conical. And when I started talking about it to a couple of friends, one of my friends worked in materials handling, in other words, construction aggregates, where they actually really do crush rocks.
• 15:05 And he says, you know what, you're talking about's a lot like a rock crusher. And that's sort of what we thought yeah, that makes a good metaphor for a backlog. So you have these big ideas entering at the top and they progressively get crushed into smaller and smaller, fine grain stories that are ready for a team to take.
• 15:22 While  I'd like to maybe claim that we coined the term I've been on actual clients where they did call their backlog, the rock crusher. So  it is a common pattern you see that some people adopt, that there are work in the backlog that's at varying degrees of abstraction, varying degrees of scope and we're progressively elaborating these as we move through.
• 15:43 I think the big mistake I see with a lot of organizations is they're representing their backlog exactly like what you were saying before. Hey, we've got a thousand user stories in here. Hey, we've got 200 user stories in here. This is not agile. In most cases, what they're doing is just doing fine grain requirements all upfront and then iterating through it.
• 16:01 We're just going into an old-fashioned waterfall except we're iterating the implementation.
• 16:06 Shane: How do we prevent that from happening?
• 16:08 Steve: That's where kind of like we're promoting on the rock crusher idea. That the one thing that we don't want is to have a large number of fine grain, very precise user stories until we need them.
• 16:22 One of the great expressions, you know, if you want to really describe what agile is about, it's leaving things to the last responsible moment. So don't start writing detailed user stories or detailed backlog items until you know that we really need those. Now we're maybe progressively refining.
• 16:37 I mean, in, in some ways that's what we used to do - right. We used to have a far out there idea. Then we would do some modeling of it. We might do some tests. So, agility is saying, look, instead of doing the whole system, that way, let's do fine slices of this system. We do want to be able to adapt.
• 16:55 Basically it comes down to, if we find out something, we learned something when we put out our increment there or put out our MVP and it invalidates half the stuff that we've worked on in the backlog, we don't want to have spent a huge amount of time and investment in trying to create a lot of fine grain stories, because that's going to be a major, major inertia to change.
• 17:16 Shane: But then how do we know what we're going to build?
• 17:18 Steve: Well, that's what again, what we're relying on our product management, our Product Owners, and maybe sometimes that's where the MVP comes in. That's answering the question what is the most valuable thing that we're going to put out there? I mean, that is part of the product development process.
• 17:33 What is it that really satisfies a need? What is the most important thing? What is the thing that we can do to determine if our hypothesis about a product or service that we're going to deliver is correct? So how do we speed the learning cycle? We've come full circle to saying what's agility about, agility is about how do we accelerate that learning cycle to find out what is really valuable.
• 17:55 Shane: Changing topics.  There's a whole lot of conversations going on - business agility. We know we want organizations to transform to become more agile. Value streams as a way of working and listeners will know that that's a favorite topic of mine, because I think it really is important that we look at end to end flow and that value comes in achieving customer needs, not in delivering features.
• 18:25 What is this business agility stuff. And where's it going?
• 18:29 Steve: 18:29 That is a really good question. I reflect on this a lot because I have this ultimate fear that business agility is becoming a cynical way to sell certification courses to HR and marketing and non it groups within the organization. That's sort of my cynical fear.
• 18:48 And sometimes I ask the question, you know, we are software developers, we are engineers. What makes us really think that we understand how a business runs. I think there's a little bit of arrogance on our part because we're all very excited about business agility, and we believe that we're leading businesses to a bright new future, the ability to be nimble, the ability to pivot quickly, to be able to survive in an age of disruption.
• 19:19 Except we're really late to the party. This has been stuff that's been around for a long time. You can do a lot of research Burns and Stocker, for example, time-based competition, Chet Richards. These are all materials from the eighties talking about using time for competitive advantage and basically the business being able to learn.
• 19:40 So I think it's incumbent on us to be a little bit humble to learn from the past. 
• 19:45 The optimism in me says this may also be the opportunity, particularly in the IT world, to dissolve that artificial barrier between IT and the business. I always consider it a problem when we start having that conversation about, well, there's the business and IT, and let's look at what IT does for  business:
• 20:07 the most valuable thing of business has is the way they get things done. What are their business processes? How do they do marketing? How do they do procurement? How do they deliver their products and services to their customers? How do they work with their suppliers? None of that can operate without the IT, right.
• 20:24 To be competitive today all of your processes rely on IT. None of our processes are mere automations of manual processes. And yet we still continue to believe that IT is some kind of cost centre bag on the side. It doesn't create value. I take the attitude that it is part of the business and that we have to stop this idea that on the business side are business analysts and business architects design these glorious business processes, and then we can leave it over the fence to IT and say, you guys can do your agile thing and implement this.
• 20:56 It really has to look at now, how do we carry that concept of the MVP and the MMF up into the business? You know, how do the people with technical skills work with the people who have accounting backgrounds and marketing backgrounds, how do they work collaboratively together to say, how can we build a business that can kick the crap out of our competitors?
• 21:15 How can we make decisions faster and learn faster about the way we should deliver services? And that's what I see as being business agility.
• 21:23 Shane: As experienced IT professionals who've been playing with this agile stuff and not just playing a lot of organizations have brought agile into their IT space and they've done quite well with it.
• 21:36 The problem the agile manifesto was trying to solve has largely been dealt with, by many organizations. I think there's a lot of bad agile out there still, but for many, we are definitely seeing benefits. We're delivering stuff quicker. How do we share that knowledge with the other parts of the business without being arrogant and pretending that we know it all?
• 21:58 Steve: 21:58 Well, I think that's the first thing, you know, having a little bit of humility, you know, we have figured out how to get people to better work together in the IT world, in the software world, in the product development world. You know, the agile mindset,  collaboration, you know, instead of treating, uh, those guys from marketing, what a bunch of fools they are, how do we reach out to them and actually work with them and understand their issues and how do we work with sales now and ultimately in a company, every single dollar that accompany has comes in through sales.
• 22:28 How do we deal with the administrative services? You know, the people who are working in HR, the people who are working in procurement, people are working in accounts payable and accounts receivable. I think we really have to have an element, not only humility, but we've actually ourselves have got to get interested in the business.
• 22:46 One thing I do notice among a lot of IT professionals, they have very little interest in what the business actually does. They are associated with their peer group and they take pride in their professional capabilities and talents, which is more than appropriate. But also, I think it is necessary that if we're going to bridge that gap and dissolve that business, IT barrier, as an it professional, I have to take interest in the business. You know, one of the things we're demanding that the business takes interest in us.
• 23:14 Shane: Yes. Software is eating the world.
• 23:16 Steve: Software is eating the world, but I think we need to also take interest in the business. I've actually seen too many software groups within a business, actually bully the business and I think we have to be a little bit more humble and a little bit more open to understanding how do we engage with the business? You know, we're not an Island unto ourselves. We're not order-takers. We need to be participants in that business.
• 23:39 Shane: If people want to continue the conversation, where do they find you?
• 23:42 Steve: I finally have got a website up for myself, which doesn't look all that great, but you know, it's getting there so they can go to steveadolph.com my website, or they can reach out to me at steve@developmentknowledge.com
• 23:56 Shane: Thanks very much,
• 23:58 Steve. Thank you. I've enjoyed this.

Mentioned

• Agile 2019
• Book: Patterns for Effective Use Cases
• Blog post: End the tyranny of user stories
• Time-based competition
• Steve’s website