Transcript for Episode 288. Launch Plans
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast, living large in New York. I’m your host, Michael Nunez and today, I have our cohost.
[0:00:11.5] DA: Dave Anderson.
[0:00:12.9] MN: Oh my God and today, we’re talking about launch plans.
[0:00:17.1] DA: Launch plans, are you hungry?
[0:00:19.6] MN: Are you hungry? Get ready to launch.
[0:00:22.1] DA: Get ready to launch.
[0:00:24.1] MN: Launch your launch plans, we’re talking about launch plans and I’m so excited. Dave Anderson is back. He’s been out for some time.
[0:00:31.7] DA: You got some time, two reasons to be excited, there’s someone over here in the shadows I see.
[0:00:36.6] MN: Yes. We definitely do. Today, we have with us Alex Bernardin, what’s going on Alex?
[0:00:43.0] AB: What’s up? Long-time listener, first-time cohost, what?
[0:00:47.5] MN: There you go, let’s get this bread. So Alex, tell us a little bit about yourself.
[0:00:51.7] AB: Well, I am a lead product manager with Stride right now. I’ve been building web applications in one shape or another since like 1996. First I was a dev, then I was a dev team manager, project manager, Agile coach and now a product manager. So I‘ve seen a lot of projects.
[0:01:11.3] DA: Yeah. You got a lot of hats in your desk drawer.
[0:01:14.5] AB: I got a lot of hats, I got a lot of hats.
[0:01:17.1] MN: Seen a lot of launch plans and a lot of lunch plans but today, we’re talking about launch plans.
[0:01:23.7] DA: So yeah, tell me why I need a launch plan? Like, I like to keep it simple, you know, we’ve talked about continuous integration, continuous delivery. Like, I‘m just fire hosing my commits to main, they’re all…
[0:01:34.6] AB: Good baby.
[0:01:35.2] DA: They’re all going out there for the world, I’m doing incremental delivery, I’m doing it right, like, I don’t know why I need more of a plan than that.
[0:01:43.0] AB: Your test suite is broad.
[0:01:44.6] DA: My test suite is broad and deep.
[0:01:47.6] AB: Yup, you got the robots testing everything, all the things, right?
[0:01:52.4] DA: Yeah.
[0:01:52.2] AB: It's completely safe. Totally safe. So okay, number one, not every team has that kind of test coverage, right? Like that’s just reality. Some teams are small, some products are new, you just don’t have the kind of test coverage where you have that confidence level. So that’s one scenario.
[0:02:08.8] DA: Yeah.
[0:02:09.1] AB: Another possibility is even with all that test coverage, sometimes it’s a big idea. Marketing’s got a big idea. It’s going to be a big splashy launch, right? “We’re changing the web application layout, we’re changing the whole page layout and it’s going to be huge and it’s a rebrand. We’re moving the navigation because left side navigation is boring and now we want top navigation because that’s the new sexy because everything comes full circle.”
[0:02:37.1] DA: And I guess what you're telling me is I just shouldn’t move the navigation items over to the top one by one and like randomly do that for users? Okay.
[0:02:46.7] AB: You know, section by section on the site, like the navigation’s just different on one page versus another. Yeah, that might be bad, that might be unpleasant.
[0:02:53.8] DA: Okay, I’m starting to feel you.
[0:02:56.2] AB: So yeah, the big clues would be if there’s multiple teams involved or there’s like a bunch of moving parts and maybe there’s database changes or backend changes.
[0:03:05.8] DA: Yeah. I feel like I’ve been in a situation where there’s like integrations that are really hard to fake. Like so you can like, test them to the best of your ability. Maybe you have a second environment but there’s only one sales force, there’s only one stripe really. So when you go live, you’re going to really experience what changes you’ve made.
[0:03:28.6] AB: Yeah, for sure, for sure. Big cases definitely are a win. The timing’s really key and other people who are not intimately involved need to know what’s happening, maybe customer support needs to know when a particular feature has gone out. Maybe they’re going to change a bunch of FAQs on the site when that feature changes.
There’s all sorts of possibilities where multiple teams are involved and multiple moving parts and it’s like, “Okay.” Sometimes there’s a sequence that’s important or you just want to make sure people know things at certain times. Those are all good clues that you can’t just, you know, let CD do its thing. If you just let CDs do its thing, things will get messy.
[0:04:07.7] DA: Yeah, yeah. CD will not send my press release or notify the sales team or, you know, any number of other things. It can though, like maybe they’ll work on that.
[0:04:23.4] AB: What about you Bobby? I don’t know if you have used launch plans before?
[0:04:27.4] MN: No, I think. I think a lot of the time, it’s left to like the CICD work. When I’ve seen launch plans, when I hear a launch plan, a lot of the times it’s not very agile unfortunately, where it’s like, “Oh, we have a launch plan and the day we’re going to release this thing is in three months. So, get to it.”
[0:04:48.2] DA: Right, promises were made.
[0:04:48.4] MN: Actually, hit that or not. Yeah, promises, that’s where I get like the idea of the launch plan is great if you were using it to plan on a date that is not set but 90% of the time, it’s like, “Oh yeah, I told the people and the suits upstairs we’d be done in three months, so.”
[0:05:05.7] DA: Right. Go now, yeah.
[0:05:06.9] MN: “And we told them we’d deliver everything. So let’s launch that,” and it’s like, “No, that’s not the way to do that.”
[0:05:14.2] DA: Yeah, I guess what I‘m hearing you say is like there’s a [inaudible 05:16] in that.
[0:05:19.6] MN: Yeah, it’s a very, very interesting tightrope that you have to follow because I imagine, you know, with the launch plan and you can have every single organization aware of this new feature that’s going to be released with your brand and what to do step-by-step is great but often times that gets overwritten by a due date and then everyone works towards that due date versus working towards the building of the thing regardless of time, if that made sense.
[0:05:52.7] AB: And so the way that I’ve often… I get what you're saying totally. I totally acknowledge that, and that is one of the antipatterns I would say with the launch plan because I’m not talking about something that you’ve written three months ago. I’m talking about something like, it should be on the scale of days or maybe a week and the way that I’ve done it has always been sort of like NASA, right?
Like there is the launch moment and then there’s things that have to happen before the launch and maybe that’s like… maybe that’s just step-step-step but maybe, there is a script that has to run or a data migration or something that’s going to take two hours. “So okay, let’s make sure we do this two hours before we want to hit that launch. Oh okay, we got to notify so and so a day before because they have to do a thing and somebody else has to do something. Well, that has to happen three days before.” So you’re working backwards from the moment but it’s all relative to that moment of launch.
[0:06:48.1] MN: Right.
[0:06:48.5] AB: It’s like, it’s not predetermined, it’s not preset. It is whenever we’re ready, we’re going to start this routine and now because we talked about it, we know, this routine is going to take… maybe it only takes 20 minutes, that’s fine but maybe it takes three days because of these things and if you know that then you say, “Okay, well, whenever all the other pieces are ready, we’re going to need three days. From when we say go, it’s going to be three days.”
It's like in Star Wars when they go to blow up not Alderaan but the second one and they’re like, waiting to clear the planet, right? And they’re like watching the picture of like the Death Star coming around the planet and then finally they’re standing like, “Okay, we’re clear,” and then he says, “Okay, you may fire when ready,” and then they start the whole process and because they took so long, then they get blown up.
But if they had known how long that thing was going to take to fire and they know how long it takes them to move around the planet, they could have hit it, they could have had that shot.
[0:07:45.7] DA: Right, right. They could have just peeked around the corner and sniped them. Just like right there. Just like poof and then go back.
[0:07:55.3] MN: Yeah. I mean, I gotta watch that scene because I’m no Star Wars.
[0:08:01.1] DA: I like burned it in, a noted fan of the Empire. Empire did nothing wrong.
[0:08:07.0] MN: Oh man.
[0:08:08.1] AB: Hey, for the record, for the record, for the record, not a fan of the Empire but there is always, in any situation, you could see where optimizations could have been made, right?
[0:08:20.4] DA: Yeah, okay. Yeah, yeah, that’s fair, it’s a case study. Okay, I can appreciate that, yeah. Okay, okay, I appreciate that. Yeah, so we have kind of our things, like our pre-launch checklist, our launch checklist and our post-launch checklist at the very least. Like three categories but you know, obviously, you can get pretty detailed with that.
[0:08:43.4] AB: So you can and like fundamentally, the motivation for using a launch checklist is it comes out of… not comes out of but if you ever read the book called The Checklist Manifesto, it’s a great exploration of like why checklists are awesome and why they’re so useful in so many places.
Like everything from people flying a plane to people running surgery, like the basic idea is, it’s not that what you’re doing in any of those moments is particularly difficult but if you have it, if you have thought it through beforehand and you know the steps, then you just remove the need to be making those evaluations in that moment.
[0:09:23.2] DA: Right.
[0:09:23.6] AB: It makes it safer and it makes it so that things can happen more consistently and with your failure points. So when we fired up to do this episode, “Hey, it’s been a minute. Oh, wait, we have a doc. Oh, the doc has a bullet list. Oh, we’re supposed to do this step. Oh yeah right, we’re supposed to do breakfast check. Oh yeah, right, we’re supposed to do this step-step-step-step-step.”
[0:09:42.4] DA: Yeah, that’s accurate. We do kind of have a checklist on there. Oh, Manifesto, didn’t know, didn’t know what’s on it. That sounds pretty great though. I would love to check out that book. I feel like there’s probably something adjacent to like flow in that as well. Where like, when you have a structured backlog of work, it makes it a lot easier, like you don’t have to think about what pants you are taking off of the closet. It’s like these pants from the top of the backlog, so these are the pants I’m wearing today.
[0:10:14.6] AB: Wait, how many metaphors is that?
[0:10:17.2] DA: It’s too many, sorry. Okay, let’s move on.
[0:10:20.8] AB: Pants, do you stack your pants in your drawer?
[0:10:24.0] DA: Yeah. Yeah, I have a pants backlog but I actually have a t-shirt backlog more like.
[0:10:29.3] MN: It’s a queue where you just pick up from the top of the queue and…
[0:10:32.2] DA: Yeah, the top of the queue.
[0:10:33.3] MN: That is how I have my t-shirts too.
[0:10:35.0] DA: Yeah, yeah. Actually I take that from Bobby.
[0:10:38.0] MN: I have a queue of t-shirts that I just take and I go.
[0:10:41.7] AB: I just put them on and I’m out. If it is Friday, it must be Rick and Morty, there we go.
[0:10:48.4] DA: I gotta have a checklist though, yeah.
[0:10:52.6] MN: So I do have a question about the checklist. How do you know if you have too many in the checklist? Because I think here is a problem that I can imagine would exist. You know, some people like to look like they do a lot of work and that can include adding a lot of items on a checklist. So if it is like, “Yo man, if we have a 50 checklist document it’s going to look like we’re doing everything.”
But it could be very, very wasteful. Is it just like the idea of knowing exactly the thing that is blocking the previous thing and then putting that in the checklist and then just kind of deleting any checklist that isn’t fully relevant or required?
[0:11:36.7] AB: For me, I consider myself an Agilist with a capital A, so I like to keep it as simple as possible. I like to have just barely enough structure to get by. So the thought process is, what are the essential pieces? You want to make sure that anyone who needs to do something to get the product out is included in that conversation because then not only are you making sure you have your bases covered but also everyone knows. Everyone has heard the conversation, everyone is like, “Okay, this is what we are going to do. These are the steps we are going to follow. Cool, great, everyone is on board.”
But then yeah, it really is about keeping it as simple as you can. I mean ideally, you’ve got scripts. Ideally, you have CICD. Ideally, you have automation so that you are not having to go through and type a million commands. But it is that conversation amongst the team of what really has to happen and if that list is short then keep that list short. Like please, keep it simple. Make it a five minute process.
[0:12:45.5] DA: I am wondering how important is it for the checklist or launch plan to make sense to someone who is not on the team or someone who is not involved in carrying out the work?
[0:12:59.6] AB: I am a fan of having a designated launch coordinator. So on the team that I am on right now, we had a situation a month ago where we were going to be rolling a feature out and as we were about to roll it out, we said, “Oh wait, wait, wait, if we are going to roll this out, it is a new feature for customers. If we’re going to roll this out, we should really be empowering people to turn notifications on and off,” which we hadn’t built yet.
Like, “Oh, okay. We gotta build that first,” so we put the branch kind of on a shelf, right? And now we have two different features that are not technically connected but they are going to go out the same time and both of the product managers on the team are going to be on vacation that week.
[0:13:43.9] DA: Perfect.
[0:13:45.1] AB: So it’s like, “Huh, you know what we should try here? Maybe we should try a launch plan because that would make us all feel a little more comfortable that it had been thought through.” And then it was just like boom-boom-boom, do the things and in that situation, what we decided was, “Okay, there should be…” so you avoid what’s called the tragedy of the commons, we’re going to have one person who is going to be a launch coordinator.
[0:14:09.9] DA: Right, accountability.
[0:14:11.1] AB: There is nothing magic about that job. It’s not like you need special skills but it is someone who has been in the conversation, has thought it through and they are going to drive it. They are going to be the one saying, “Okay, do the next thing. Okay, do the next thing. Okay, do the next thing.” It is like if you have an emergency if you’re in a medical context.
There is one person who is kind of running the code, right? They are running the situation and they are paying attention to all the things and they are saying, “You do this, you do that,” and so having that coordinator pre-chosen means like someone is going to make sure this thing happens. Does that make sense?
[0:14:50.7] DA: Yeah and it’s not like the rock star who is pulling out all the stops to get it done or think of all the things that’s happening. The team that has vetted the plan and agreed on the plan.
[0:15:05.7] AB: Yes.
[0:15:06.1] DA: But they are the ones who are like you know, setting the rhythm for it.
[0:15:11.8] AB: Yeah, we did a similar thing with an incident. If you had a problem or an incident we would say, “Okay, you have to have an incident coordinator,” and that is just the person who is sitting there watching and kind of moving things forward, right? So that it does not have to be the most senior person but it could be anybody on the team. It is just like, “Okay, this is my role in this situation.”
If you do that, then to me you can apply the same concept that you do with user stories, which is to say this document doesn’t have to make sense to anyone off the street. It just has to make sense to the team who is going to use it.
[0:15:46.2] DA: Right.
[0:15:46.7] AB: So it has to make sense to the launch coordinator and it should make sense to the team. It does not have to have all the data that someone who has never seen the thing could be able to run the launch. That would make for a very large complicated document.
[0:16:03.7] DA: Right and I guess there’s probably something as part of that as like communication is probably the launch plan or like an executive summary of like what all value is being driven or like from different perspectives depending on the future like the user or the executives or shareholders or the public.
[0:16:27.0] AB: For me, I use this document really fairly precisely to drive the safe deploy of a feature and tend to do the follow up checks. It is not about reporting status on the project, it’s not about showing value to stakeholders. It’s really just that moment of, did all of the technical pieces line up? Did the feature go out correctly and was it checked to make sure that it’s live and that it’s, you know, didn’t breach?
[0:17:01.9] DA: Is it in front of the users and they’re like, you know, engaging with it?
[0:17:06.3] AB: Yeah and that’s where we have like we’ll have some posts deploy steps as well, which are good to pre-think like, “Hey, you are turning on SMS notifications.” How can we tell if that worked? How can we tell if anyone got a notification? Somebody better figure out where that monitor is, go find that report because if you’re looking for it when you need it and you realize you don’t have the log in and the person who can give you the login is on vacation, that’s not going to be good.
[0:17:37.0] DA: Yeah, yeah it’s a good validation on how observable some of the hidden parts of the system is. I think that’s when you get into like logging and like exception tracking and visibility on these like integrations and things like that.
[0:17:52.8] AB: Yeah, definitely.
[0:17:55.5] DA: Cool.
[0:17:55.9] MN: I’m going to need a launch plan for myself. I feel like checklists would be really good to have for me to just operate in the world, although I am a little impatient with writing a checklist. This is definitely something I want to incorporate even in my own life but it is also in the deliverables that I have just so that I don’t push to production and then like freak out whenever something goes wrong, you know?
[0:18:20.0] AB: I love checklists. My wife is even more type-A than I am. I’m like type-A retired but we have checklists that we use when we are packing for trips.
[0:18:29.6] DA: I was just thinking about that, it was like my vacation.
[0:18:32.5] AB: We have a separate one of the dog. Then we have a dog packing checklist. We have, yeah, checklists are great. I’m a big fan.
[0:18:39.4] DA: Yeah, it just makes me think of like my first backpacking trip I ever did, where you get like that RAI checklist and you’re like, “Okay, this is how I am not going to get into a horrible situation,” like you know? Yeah, like taking a flight, getting into the wilderness, like deploying some code in those real times, you know, it’s high stakes, you got to get it right. You want to get it right the first time.
[0:19:05.8] MN: Yeah and did you do that with the checklist, whether you are out fighting in the wild or deploy into production.
[END OF INTERVIEW]
[0:19:12.1] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers just like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
Links and Resources:
Our seasoned cross-functional agilists work with you to develop technology, ship product and deliver value. We leverage our diverse expertise across industries and throughout the organizational growth cycle to your benefit. We bring best practices, emergent practices and creative solutions to your problems.