This is a transcript of episode 220 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
Squirrel relates the tale of a sad client who refined their MVP so much all the business value was lost. Squirrel and Jeffrey reflect on the true meaning of “viable” and how boredom can be a sign your team has lost sight of delivering customer value.
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
Introduction
Listen to this section at 00:11
Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.
Jeffrey: Hi, Squirrel. I’m really excited, because you have a story for us!
Squirrel: Oh boy, do I have a Squirrel story. I’m going to elide the details. If any of my clients hear themselves in this story, it’s because it’s a classic story, not because I’m telling it about you. So the client approaches me and says:
Client: Squirrel, we have this terrible problem. We’ve been trying to get this new software in production for a very, very long time.
Squirrel: If listeners are imagining how long it is, double that, that’s how long it’s taken them. And they said:
Client: We’re really close, what we want you to do is to work with several people, not just in the tech team, and just get it over the line. Let’s just get this thing live because it’s been so painful and blocking us for so long.
Squirrel: I said, “Great, let me talk to those people.” I went to the first one:
Fist Person: Yeah, we’ve been working on this thing forever.
Squirrel: So what’s it going to do?
Squirrel: He described a bit about what it would do and why it would be better. I asked, “how are you feeling about that?”
First Person: It’s okay.
Squirrel: I had the impression that it kind of was ready for you. It was the others that were blocked?
First Person: Oh, yeah, yeah, this is ready for me.
Squirrel: Wait, why aren’t you excited? If we could get this live next week, wouldn’t that be thrilling?
First Person: Sure.
Squirrel: What’s going on here?
First Person: Well, let me tell you the story. I came in a long, long time ago. I had these big dreams, and then I heard about something called a minimum viable product, an “MVP.” I heard that what we would do is a minimum viable version of these great dreams. I said, Well, let’s see how that goes. That’ll give me some value. That’ll help me in my team. And a while later it was still delayed, so we decided to make a minimum viable version of the minimum viable version. I was getting less excited. There’s, a lot less in here. And now this product is the minimum viable version of that minimum viable version of the minimum viable version of the great dreams. We’ve minimum viable’d it to death. We’ve done MVP cubed and I’m not too excited anymore. This doesn’t do anything for me.
Squirrel: When I told you this story the first time you laughed and now you’re laughing again. That’s good, because I think that laughter is a laughter of recognition. I think we’ve all been there.
Minimal Value Perceived
Listen to this section at 02:45
Jeffrey: It is recognition. I think what happens here is almost a definitional thing. I think often what happens with Agile and these different concepts that people have is in a sense they don’t take the idea seriously. It’s like the terms come to be placeholders for something else. An MVP is a good example of this because you can’t really MVP an MVP, that doesn’t work.
Squirrel: You wind up like this poor guy!
Jeffrey: Well, the whole point of an MVP is you’ve already said this is the minimum viable product and you cannot get smaller than this. When you go and say, “we’re going to MVP the MVP,” what you’ve now said is you’re no longer working on the same dimension. I think that’s important. What’s the dimension that we’re minimizing when we talk about minimum viable product? The important thing is that it’s about what’s viable for the user, for the clients, for the customers. It’s a minium viable product. We’re saying this is the smallest unit with value we can deliver to the world where they can go use it and realize that value. If you’ve defined that and then said, “now we’re going to make a minimum viable version of that,” what you’ve actually said is you’re going to change what you mean by viable. The one that I see most often is “we’re going to go from what’s viable for the client to what’s viable for us to deliver in the time frame we want.” So we go from an external definition of viable to an internal one, and I imagine that might have been the process that was going through at your client’s.
Squirrel: I have the strong feeling it is. What they wound up with is something that they’ve got very focused on, that’s why they brought me in just to “get this over the line, just get it finished.” The challenge is of course, that that doesn’t add an awful lot of value. In my consulting I’m always looking for how to make the team insanely profitable, and this isn’t adding any profit. If anything, this is adding a loss because we’re going from something that kind of works to something that kind of does a tiny increment more. That doesn’t justify the investment.
Jeffrey: When I heard this I was thinking of the different experiences. It’s not that doing things that don’t have client value are wrong, and I should be clear about that.
Squirrel: I was going to ask you about that, yeah.
Jeffrey: Sometimes people would claim there’s valuable reasons to do things internally also. There are valid technical reasons, even if you don’t get client value. I think that’s true. Examples are when we can make a system more stable, or we can reduce the maintenance cost. Generally, I would say they fit exactly along the line you said, which is “are we making the platform more profitable?” If it will take fewer people to run and operate, then you are making it more profitable. Even if you haven’t changed the client value, you can reduce internal costs and that’s worth doing. You can be making an investment. You can have big dreams of what you want to do, but are maybe going to need a different platform, so replacing your platform or replatforming. You might do this kind of work over a period of time, replacing pieces and pieces until finally you’ve done it, the clients haven’t seen anything different and you’re celebrating! The clients see nothing different. Yet we’re on the new platform. So those can be reasons to do certain work. In that case of replatforming, if it’s either to reduce your internal costs or it’s providing a foundation for a future value, then I think that makes sense. But what you’re doing in these cases is not an MVP. An MVP is a client-facing thing. I think that’s one of the cases where words matter, agreeing what important words mean is important. As I told you Squirrel, that reminded me a bit of one of the stories apocryphally involving Churchill, which is if you call a tail a leg, how many legs does a dog have?
Squirrel: I guess five.
Jeffrey: It’s four, because calling a tail a leg doesn’t make it a leg. That’s what happens here I think. People would call something an MVP that is not about client-facing value and therefore doesn’t actually deserve the term MVP. It’s a misuse of the term. I suspect that’s what may have happened in this case and certainly it is something I’ve seen happen in other places.
Smallest Meaningful or Least Taxing
Listen to this section at 07:24
Squirrel: Two of my favorite concepts here both come from Alastair Coburn. I think he came up with the names for both elephant carpaccio and walking skeleton. Both are about doing things in very, very small increments. But each increment is of customer-visible value. That’s the hardest possible thing to get across, because it is so easy to focus on what’s feasible, on what it is that you can actually release. You say, “well, gosh, I don’t know how I would do the database, and the mobile app, and the business logic in between, why don’t I just do the database table? That’s something I can release.” As you say, doing that is not a bad thing to do. It’s not something that should never appear on your back log and should be crossed off. But to call it an MVP or to call it part of elephant carpaccio or a walking skeleton, any of these small incremental customer feedback mechanisms, doesn’t get you what you need. And that sounds like what was happening to my client, that they were expecting to get increments of business value. They’re not seeing that, and that’s what’s disappointing to the person that I interviewed.
Jeffrey: You know, it’s interesting the example of a walking skeleton, because I just recently experienced that myself. I would say walking skeleton is a technical term for something more about internal value, that you get something end to end which probably isn’t the point you’re going to a client. It’s to the point where you can say, “Yeah, actually we can move this number from over here in the database and have it show up over here on what will be a user-facing thing, so we can prove things work end to end.” I remember working once on a dashboard product how it started was “can we have the project title show up on the on the HTML report?” That was all it was. “Here’s the name of your project.” Not a lot of value, but we could prove that these things worked end to end. More recently we were working on something that delivered a kind of signal and it was “can we have the model results show up in the end page” just to show that things were working technically. At no point where they are saying “look at that, we’re ready to show this to clients.” We weren’t thinking we’d actually delivered client value at that point, we wouldn’t call it an MVP, but we would we would say we started getting our skeleton in place that we’re going to build everything else on. If you think of that, maybe the analogy here is the flesh of the carpaccio is the business value, getting the bones of what you need to go build your elephant.
Squirrel: But all of those produce visible results that are meaningful. We always like to give diagnostics because we’re about Troubleshooting Agile: if you’ve got a person who’s responding in the way my client did, “this is just so minimal that it isn’t valuable to me, I can’t even see how it will become valuable.” Then I think you’re missing the point, even if you’re trying to do a walking skeleton, because what that person should be able to do in your case, Jeffrey, where you get the title up, the person says “well I can’t show this to the client yet, but yes, I am getting it on Thursday mornings at 10:00. It has the right thing in it. Now, I want you to fill in the columns, put actual data in. I can see how this will turn into value.” The challenge for this person was he couldn’t even see how it could turn into value. He says, “Look, it just makes this tiny thing a little bit better, which doesn’t matter to me. This is meaningless.” That’s when you’ve MVP’d the MVP, which is a great danger.
Jeffrey: I really like in your description of the story you emphasize an important signal, which is that the person was bored. I think another way to invert this is, you have an MVP when there is some user who’s going to be excited.
Squirrel: Yup.
Jeffrey: If no one is excited about what you’re delivering, it cannot be an MVP. I think that would be a very strong test.
Squirrel: The quantum of excitement can be small. It can be “Look, I’m cautiously optimistic. I see that this is headed the right direction. I mean, all we have is a title that’s being delivered by email. But I can see where this is going. I’m going to increase my excitement when you get this.” That’s where you say “wait a minute, say that again,” and you write that down, and then you get as close to that as you can. But what you can’t do is start from total boredom and somehow imagine excitement will appear. That’s your signal that you’re on the wrong track and you should re-platform your replatforming, think differently about your MVP and what the “V” part actually means.
Jeffrey: Yep, that’s right.
Squirrel: Excellent. Well thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.