Episode 389: Ryan Singer on Basecamp's Software Development Process

This is Software Engineering Radio, the podcast for professional developers on the web at se-radio.net. SE Radio is brought to you by the IEEE Computer Society and by IEEE Software Magazine. Online at computer.org slash software. This is Nate Black for Software Engineering Radio. My guest today is Ryan Singer. Ryan is the head of product strategy at Basecamp. He is the author of the book, Shape Up, Stop Running in Circles and Ship Work That Matters. which explains Basecamp's software delivery process. Ryan, welcome to Software Engineering Radio. Hey there, thanks for having me. We had Basecamp CTO David Hennemeyer Hansen on the show in episode 216 to talk about Ruby on Rails, and he talked about his thoughts on software architecture and software design. In this episode, it will be a little bit different. We're going to be talking about Basecamp's approach to software development methodology. Let's start by talking about the book. Shape Up is a free ebook that describes your software development methodology at Basecamp. Why did you write Shape Up? We had gone through an internal process over the course of the last few years of trying to articulate what we had learned. You know, as you go through the growing process from being a tiny startup team to bringing on more and more people. you go through these different phases where you need to start to take on more structure and you have to start to articulate what you're doing, you know, because in the beginning, everybody just kind of learns by osmosis. And, you know, the founding team kind of has a bunch of stuff in their gut and in their intuition that you want to be able to turn into some sort of a structure that other people can repeat. So we had to figure out as we grew. how to articulate what we had been doing that made our product development process so successful over the years, especially since we started working on Basecamp 3 in about 2015. We had more people on board and we just needed to actually kind of firm up. How do we really explain all the things that we have been doing that were sort of almost kind of a secret sauce for us? And then as we were going through that process of sort of articulating to ourselves, you know, what is shaping? What is bedding? What is uphill and downhill work? All these kind of things. We had lots of people continuing to come to us, you know, friends and peers from the outside saying, how do you guys do it? And it felt like the right time to do a book. What do you see as being really different from other methodologies that are out there? One thing is the pendulum swung too far away from upfront design with Agile. What we see looking out at a lot of other teams is not enough decision-making at the higher levels of the company and a lot of decision-making getting pushed down to the teams that are building. and too short of a timeframe where there's just two weeks at a time, two weeks at a time, which makes it really hard to set a course where you have a bigger vision of what you're trying to accomplish. And it makes it hard to steer the product strategically. So we have more upfront design, but we're not swinging the pendulum back to waterfall. We're doing the right amount of work on the work to figure out what the right work is. So it's like... We need to figure out what the teams are going to do and what they're not going to do and what the boundaries of the solution are. But we need to do that at the right level of abstraction, at the right level of roughness, so that we're not giving the team a spec, but we're also not giving them something that's too abstract and too fuzzy. We need to really set those guardrails on what we think a solution is. And then once we've done that shaping work on what we think the work is, we're much more deliberate about making bets. So we don't just kind of keep throwing time, more and more time at things. And we don't allow things to just keep running. We define a clear appetite up front. This is how much time we intend to spend on this thing. This is how much time we think this thing is worth. And then we have a circuit breaker in place so that if we spend more time on something than we think it's worth strategically, we actually kill the project. And we can talk more about that later. So our approach to betting is much more deliberate. And then finally, when we're doing the building, and the teams are actually executing the work, they are taking responsibility not for tasks, but for the entire project. So nobody's queuing up tasks for the team or stories or cards. They have the boundaries of the shaped work, and they are figuring out their own tasks and discovering what the work is for themselves inside those boundaries. And as they do that, the focus isn't on velocity or what's complete versus what's incomplete. The focus is on what's known and unknown. So we're really focusing on risk and we want to make sure that we sequence the problems in the right order so that we're clear about which things are solved and which things are not solved. Because it's the things that you think you're going to be able to do, but you haven't actually solved yet that can really sink a project and drastically screw up the amount of time that you spend and the amount of time that you have left. So those are some of the main ideas that are different. You don't have this backlog of tasks. that are assigned to people or in fact there's no backlog at all. Could you talk about that? We don't have any kind of a backlog and we see backlogs as being problematic in a lot of ways. I mean first of all it's just a major drag to have this big queue of things that you're supposed to do that you never get to. For someone who is in a position of actually making decisions about you know what to do next. The backlog is just a portfolio of options. It's not a terrible thing. But for all the other people who are not actually in the position of making that call, the backlog feels like a bunch of stuff that we're supposed to do that we haven't gotten to. And on top of it, the backlog becomes the place that work goes when we don't agree. So if we're not actually going to do something, then we just say, okay, we'll throw it on the backlog. So then the backlog becomes this big credibility problem. You say that you're going to put it there instead of saying no to it. But then you never get to it. So there's sort of a mixed message there. And it just becomes a big weight on everybody's shoulders. And it's all old stuff. So what we want to do instead is we want to be more thoughtful about a few things that are contextual and timely and relevant. So we have this betting table. So we're working in, we're not working in two-week sprints. We're working in six-week cycles. And between the six-week cycles, we have a two-week cool-down period. And in this cool down, we have what we call a betting table. And that's where the people who are in a position to decide how we spend our time evaluate a few options to decide what to do next. And what they're looking at isn't a long backlog of old stuff. The only way that something gets to a betting table is if a person personally brings it to the table and advocates for it. And the work that's getting brought to the table are potential bets. So this is work that's been shaped, work that somebody spent time figuring out. outlining, identifying the major risks, figuring out the major technical issues that are going to be a factor, doing the sort of the key tent poles of the design. So there's work that's being brought to the table that's already kind of roughly solved in terms of the boundaries of the work. And somebody's bringing that saying, this is the right time for this. And this is important right now. And this is the thing that I think we should do next. So instead of having a big queue of things, You've got maybe three or four things at the table that are really thought out and are the right things for what's going on in the company right now. And then that's a much deeper, more productive conversation than it would be with just kind of trying to groom a big old list of things. What's going on during the six weeks of the cycle? I think you said there are two tracks. What are the tracks and what's going on in those tracks? You know, when you're really small, the people who do the shaping and figure out what the work is, and the people who build the work all need to be the same people. If you're just a team of three or four, you have to wear all the hats and you just have to alternate roles and you work in a kind of ad hoc way. That doesn't work once you get to a bigger size. At our current size now, we're about maybe a dozen people on the product team and 50 in the overall company. We're big enough that we can have some people like myself and Jason, the founder, working on shaping what to do. And we can do that on a different track from the teams that are actually building out projects. So there's a sort of a shaping track where we're figuring out what the work is and kind of forming up potential bets. And then there's a building track where teams of one designer and one or two programmers take something that was shaped and they work out what that actual design and implementation looks like. And they ship that within the six weeks. And the place where these two meet, they cross over at the betting table. So in the two-week cooldown between the six-week cycles, we're looking at the work that was shaped. And it could be something that was just shaped yesterday, or it could be something that's been sitting since six weeks ago, or something that we revived. There's no strictness about that. It's just whatever is timely. And we'll look at a few options. And then if we think that this is the right time to bet time and resources on an idea, then that'll go to a team in the next six weeks to build. Okay. And that idea of first determining your appetite or time budget for the project and then making the project fit, I think is what you labeled fixed time variable scope. Yeah. And we're, of course, we're not the first ones to talk about fixed time variable scope. That goes back to at least to extreme programming. You know, a lot of the basic principle there is informed by stuff like that. So, you know, some of your listeners, of course, are going to know about Kent Beck's work and all of that. But the difference is that this is not a just within the context of programmers. We're not just talking about like an engineering team. We're stepping all the way back. to what we could call, you know, people are calling quote unquote product today, which is we're looking at the strategy and the design and the technical implementation all together and figuring out what it is that we want to do and how much time we want to spend on that. So we're not just doing fixed time variable scope for technical implementation. We're actually thinking, what do we want to do in terms of the whole product concept? When you have a smaller team that's responsible for both shaping and building, they're not, going back and forth and having a discussion and then going back to their desk and building. There's still, I think, this separation where the shaping part is continuing to happen until you have something that's shaped enough that then you send it off to be built. Yeah, or you give it to yourself to build and then you just change hats. Okay, but there's still this separation in terms of you wouldn't start building it until the beginning of a new cycle. That depends on your size again. I actually don't think that cycles, And in our experience, cycles, strict cycles don't make a lot of sense when you're very, very small. If you're only three or four people and you kind of all do everything, then you can be very ad hoc with how you manage your time together. The communication cost is very low. it's not complex to figure out who's available and what's possible. You can just drop something in the chat and then immediately change course because you have such a tiny ship together. So when we were smaller, we didn't have to adhere to six-week cycles and two-week cooldowns. We could just say, hey, let's do this for the next two weeks. Okay, we don't know what we're doing yet. We're doing some shaping. Okay, now we're good. How about for the next three weeks we do this thing? And it could be a different unit of time. Didn't have to be repeating the exact same unit, all that sort of a thing. The issue is that once you have more people, then managing the capacity in itself becomes a big challenge. There's just too many people to figure out who's available and what is everybody going to work on. So you need some more regularity and some more structure in order to operate at that scale. So we introduced the strict six weeks after we had gotten bigger than that original tiny team. Are there any guidelines or recommendations you have for people to decide when to impose the structure? Or is it just a matter of feeling when things are starting to get hard to manage? I think the general rule is that all of the things that people do at larger scales hurt you at smaller scales. So very often we look up to big companies and we think, well, I should do it like them because they're successful and they're a bigger company. But when we're small, we have luxuries. that we don't have when we're bigger. Just being able to wave your hand and say, hey, everybody, let's just do this other thing for the next couple of weeks instead. Or we don't have to be fixed to six weeks. Let's just do three weeks for this thing and then move on. That's a luxury. And being able to also share all of that context between the people who shape and the people who build, if you're the same people. I mean, you can do incredible work when you're small enough to do that. So I think the general principle is Do what smaller teams do as long as possible until stuff starts to break. And then when stuff is actually breaking around you or you're feeling pain and you're struggling because you can't wing it anymore, only then should you start to impose the extra structure. That makes sense. Let's talk more about shaping and really go into detail on that. Where would you like to start with shaping? What is shaping? We touched on it a little bit. So shaping is the transition from how do we get from a raw idea that is just like, you know, quote unquote, build a calendar or the customer wants X or the founder came up with this idea yesterday, you know, whatever it is. How do we get from that to something that is a good potential bet with more risk removed where we can say, OK, we know what it means to build this thing. So there's a few phases that we go through then to do this shaping work. The first thing is we have to set the boundaries. So, you know, what happens is somebody will say, oh, you know, the customer says they want to have categories on the message section. And then everybody says, oh, you know, I heard about that too, but maybe we could redesign it so that we could have a new organization sidebar. And then before you know it, there's this sort of out of control conversation about, you know, redesigning everything. Before that happens, you want to step back and say to yourself, well, wait a minute, how big is this problem? How meaningful is it for us strategically? How much time is it worth? How far do we want to go here? So, you know, it's natural, of course, to want to build the best, best, best of whatever you can come up with. But the constraints change the definition of what good is. So objectively, a steak dinner is better than a hot dog. But if you only have five minutes. the hot dog is the better choice, you know? And so we're looking at, as ideas come up, we want to start off by defining what we call the appetite. How much time do we want to spend on this? How interesting is it? How much does it matter? So something can come up, like the calendar, for example, we were getting this customer request repeatedly for Basecamp 3 saying, please build. a calendar view into Basecamp 3 and we did not want to do it because we had built calendars before and we built a pretty good one in Basecamp 2 and it took us like six months to do it. And we thought, man, we do not want to do that again. And we also knew that only about 10% of customers used it. So we were saying to ourselves, we don't want to do that. But we, of course, want to make our customers happy and we are getting this request. So if there's something we could do that was more like a six-week size project, then we'd be open to that. So that's defining the appetite. Now you've set some boundaries and those boundaries are constraining the solution space. So if we can't come up with some kind of a six-week size calendar or what it means to build a calendar that would be meaningful in six weeks, we don't know how to move further down the shaping process yet, right? Because we're just sort of like, well, I don't know how to do that in six weeks. We might need to do more problem definition then to give ourselves more constraints. to find the right place in the solution space. So what we did in this case was we interviewed some customers who were asking about this calendar and we kind of backtracked to unpack what was going on for them when they made the request and what exactly they were struggling with so we could figure out what mattered about a calendar. And eventually when we did that, we came to a point where we had kind of a really, really basic raw, like a rough. concept of what a simple calendar would mean and all the things that don't matter for this problem. And we were able to sketch just in a fat marker on a whiteboard. Here's the concept. I think this is something we could do in six weeks and it would scratch the itch based on this is our appetite. This is our understanding of the problem. And this is now our sort of rough idea of what the solution is. Once we've got that, then we actually have kind of an idea to bring to the table. We've got something we think we can do. that is worth the amount of time. And we think that it's feasible, but very often the people who are shaping, shaping is a sort of integration between what is strategically meaningful and design skills. So you've got to be able to look at it from the customer point of view and sketch out something that is drawn out in user-facing terms. Of course, if you're doing that as somebody who's a little bit more leaning toward the design side, there might be things that you don't understand about the technical implementation, or there might be things about the way that there are interdependencies in the existing system, or it might just be more complicated than you think. And so in order to be in the shaping role, you need to have enough technical literacy to not be way off the map. you know, about feasibility and what's doable in what amount of time. But there's still going to be a depth of understanding that you might not have that somebody who's deeply technical has. So then we go from this kind of, you know, imagine sort of two people in a room with the door closed on a whiteboard with a lot of shared context, just kind of jamming out breadboarding ideas. We talk about breadboarding in the book. It's sort of a notation system that allows us to move at the right. at the right speed and without getting lost in too much detail. We're kind of jamming on the whiteboard together and we're like, aha, okay, this is going to work. Oh, awesome. Yeah, what about this? Aha, okay. So it's like this super intense collaborative mode. Out of that, we get some kind of a concept and we're going to change modes and we're going to need to actually share this with a few people who are more technical than we are to get pushback on it. So this is what we call de-risking or looking for the rabbit holes. So we're going to take the concept to a couple trusted technical people, and we're going to redraw it in front of them kind of from start to end on the whiteboard. And we're going to say, here's what we're thinking. You're going to go from here to here to here. And we're going to connect this and connect that. And that's how we're going to do the job. And then the technical person can push back on you and say, yeah, but what about this? What about that? That's not quite as simple as you think, you know, and they're going to help you to sort of harden the concept. And then if you need to, you can go back. into the earlier shaping phase where you're kind of reconcepting in response to that or it might be that you just get all of your questions answered and you're able to really button up the thing so after we've gone through sort of setting the boundaries doing the shaping of actually coming up with the concept and then looking for those rabbit holes and de-risking it then the last step of shaping is if we get to a point where all this is making sense then we can write it up as a pitch and the pitch sort of summarizes all this work that we've done here's our appetite Here's our understanding of the problem. Here's the broad outlines of the solution. Here's a very rough sketch of what we think this looks like. Here's the rabbit holes that we've identified or our answer to the technical questions that are going to come up. And then this is the potential bet. This is something we could take to the betting table and then lobby for and compare against other options to see if it's something we're going to do. You talk about fat marker sketches. Yeah. You're not really going into high resolution, detailed description about what's going on. In fact, there's no kind of wireframes that are being made or detailed design and shaping, but any of that detailed stuff would actually be done later in the implementation phase. Yes, we do not want to fall back into making some kind of a detailed spec. We don't know enough upfront to spec every little detail. It would be a waste of our time because, of course, we would find out on day three of the actual project that everything we thought was going to work out a certain way isn't, right? But that doesn't mean that we don't do any upfront design. So it's all about doing the design at the right level of abstraction. So we need to be at that level where it's rough enough that we're leaving a lot of latitude for the team to actually work out what the real details and the fine-grained decisions look like. But it also, there has to be enough structure there at a course level so that we know that what it is and we know what it's not. And so the breadboarding and the fat marker sketches kind of help us to work at that right level of abstraction. Could you explain breadboarding? Breadboarding is a metaphor from electrical engineering. You know, if you're tinkering with electronics, you don't want to have to solder a board just to try out an idea, you know, because that's difficult to undo and then you have to throw the board away when you're done. if you want to if you have to solder all the components with a breadboard you have you know this little plastic thing with some contacts to to easily connect the different leads of your different components to power and you can just plug and unplug a few components to see if you turn the switch on if the circuit does what you think it's going to do or not and so it's it's allowing you to prototype the connectivity between components to see if the thing does what you think it's going to do and you're not making any industrial design decisions You're not choosing the color and material of the chassis or placing the switch, how many millimeters from the left or from the top. You're just wiring everything together. And it's kind of a mess of wires. And you're plugging and unplugging things. But it allows you to quickly prototype, is this the right way to get from A to B? And if I connect all these things in this way, does the circuit work or not? So we can really think of a software design as a circuit in the sense that you have to be able to get from the beginning to the end. and everything has to flow in an uninterrupted way so that you can actually execute the task that you need to do. Breadboarding is a way to quickly cover a lot of ground when you're thinking through some kind of a user-facing interaction and some kind of a flow that happens in the software. If we had to draw wireframes, then we get dragged down into the wrong level of detail. Anytime we are figuring out if this should be on the left or the right or above or below, we're too far down. We're too far down in the weeds. And what we want instead is to focus on what are the affordances? What are the places where the affordances go? Not in terms of, you know, XY position on the screen, but in terms of almost more topologically, like it belongs on this step. So the dashboard is going to have a button that says add invoice. Now, it doesn't have to be on the left or the right, but it's in that place. And then from there, if you click that, it takes you to this other place called the add invoice screen. And on that place are these affordances. So it allows us to very, very, very quickly sketch out an idea and cover a lot of surface area where we can see exactly kind of what the interface is doing, but we're not actually looking at a visual layout. And so that gives us both the latitude that we need, so we're not boxing the team into a specific design. And it also gives us the sort of speed that we need so that when we are actually exploring different ideas for what the solution is, we can cover a lot of ground really fast without getting bogged down. So at the end of the shaping process, you would have put together a pitch, which I think would consist of something about the problem statement, these fat marker sketches, breadboards, some kind of document. Could you explain what the pitch looks like and then what we do with that? in terms of bringing it to the betting table? Yeah, all we're trying to do with the pitch is take everything together that we would need to share this concept with somebody who doesn't have all the context that we had. So for example, if you start to present an idea for this quick and dirty sort option that you're going to add to this forum feature, what can easily happen, you've probably had these conversations before, you're trying to pitch the quick and dirty version and then somebody else is pointing out all the faults of your quick and dirty version, and they're describing a much deeper version that's better, right? And this is where whenever you have a kind of committee situation, the scope just runs out of control because everybody's trying to make it better and nobody's talking about the constraints. So the main thing that the pitch needs to do is it needs to present your idea of what to do as a solution, but it has to present the constraints at the same time. So that way, if you say to everybody, look, a very small percentage of customers are reporting this issue. We don't believe this affects a lot of people, but it's a little bit of a disproportionate load on support. So if we can come up with something to fix this problem in just, let's say, two weeks, we're willing to do it. But if it takes longer than that, this doesn't affect enough people and we've got bigger fish to fry. Then everybody can say, aha, okay, we've all got ideas for how this could be better, but we understand why the appetite is only two weeks. So now we can evaluate all of the trade-offs that were made to get to this kind of compromised scope. that's good enough to scratch the itch given what it's worth. So that's the kind of context that we need to put into the pitch so that people can properly evaluate it. And then what we're doing with that is we're taking that to the betting table and kind of who, what the betting table is and who it is. We can't be overly prescriptive here because companies are of different sizes and they have sort of slightly different org structures and everything like that. But basically there's somebody in your organization who gets to decide how programmers and designers spend their time. And what we want to do is that person or those people who have the power to make that decision, we want to align those resources of designer and programmers together into integrated teams. So we're going to have teams of one designer and one or two programmers. And we want to be able to give those teams a piece of work that's been shaped. so that they have the best odds of being successful because they know what to do and what not to do and how far to go and where to stop and what done more or less looks like given the amount of time that we're betting. And so we need to have the people who can make that decision. Plus, whoever's been doing the shaping needs to be able to sort of, you know, lobby for and defend whatever it is that they shaped. And then depending on the case, you may have a couple other people around to sort of advise or chime in or debate. So that this is kind of a negotiation about what is the right thing to do next. And so the pitch then is a potential bet that somebody might choose to bring to the table for a given cycle to say, this I think is a thing I want to lobby for us to do in the next cycle. I think there's a built-in assumption that there's always more work that could be done than the amount of time and resources available to do it. Yeah, I think that tends to be true. So what you're doing is you're just trying to narrow. the scope of the decision down to just the work that's gone through the shaping process. So that's well-defined enough that you could be successful in implementing it and that you could also make a determination, hey, like this will really make a difference. It's important that we do this work and it's defined enough that we can actually start working on it because that upfront shaping work's already been finished. Yeah, and it's a skin in the game process. If you put a bunch of stuff on a backlog, everybody has to look at it again. Why? Just because the backlog said so. The backlog doesn't get to say anything. It's just a list. People should have to lobby for things. If I want something to happen, then I need to remember that thing and bring it to the table and say, I think this thing is important. There's no list that's going to do that for us. In that way, there's an automatic selection function that's winnowing everything down because We only have limited amount of time and attention and people actually have to choose something for themselves to bring to the table to advocate for. Why do you call it betting versus planning? What's the key distinction? So when you plan, you say, this is what's going to happen. And that is using the language of certainty. And with betting, we're actually using the language of risk. So bets have some different properties than plans do. So the first thing with a bet is you have a When you make a bet, you bet a fixed amount. And that means that there's a cap on your downside. You should never bet a certain amount. And then when the moment of truth comes, have to pay more than that. That doesn't make any sense. But that's what we do all the time in software projects. Too often you say, let's spend two weeks on that. And then of course it doesn't work the way that you expected. And then you throw another two weeks and another two weeks. And then before you know it, you don't even know how much time you spent on it compared to what you originally wanted to. That doesn't make any sense. we put in place what we call the circuit breaker. This means if we bet on a certain amount of weeks for a team of designer and programmers to do, and they don't finish within that period of time, it's over. They don't automatically get any more time to do that thing because that time, that thing wasn't worth more time. And who knows what has come up in the meantime. We might have a much better, there might be something urgent that just came up. There might be a great new opportunity we just identified. Who knows? There could be a lot of other things. So we shouldn't be beholden to that old thing just because it took too long. That doesn't make it worth the extra time. So that's the first thing is that bets have a capped downside and we can enforce that with the circuit breaker. The second thing is when you make a bet, you have some sort of a payoff in mind of why you're making the bet and what you hope to get out of it. And we've done that with the shaping work. So we shouldn't just give something to a team and say, peck at it and see how far you get. We're betting on a specific piece of shaped work. There's a certain outcome and a definition of what done looks like that we are hoping to get out of that bet. And then the third thing is that if you make a bet, then you have to honor it. And what it means to honor the bet is that if we give the team, let's say six weeks to build this particular piece of shaped work, we have to actually give them the six weeks. Giving them the six weeks means we don't interrupt them. So we don't go and tug at their shoulder and say, hey, can you just do this other thing instead today? Or we just had this one thing come up. Can you help me with that? Or whatever it is. We don't interrupt the team. Not only do we not interrupt the team with other work, we also don't interrupt the team with stupid meetings that destroy their productivity. So we don't have daily stand-ups. We don't have regularly scheduled meetings of any kind. Instead, we give the team the room to work on things. for the right amount of period, the right amount of time that they need in order to, before they raise a hand or gather together to decide what to do next. You know, the structure of work, the actual problems that you need to solve and the things that you have to build to get the software to do what it needs to do, this structure is highly irregular. It's much more like an organism or like an animal skeleton than it is like some, it's not some kind of a periodic crystal. It's not like the work doesn't come in day-sized chunks or week-sized chunks. There's a problem you have to work on for three days and then you get it solved. And then you work on something else for two hours and it's solved, right? And then you work on something for one day and it's solved. And then you have a thing for like six days that you work on, right? So this irregularity means that the team needs to be able to decide when is the right time to meet, when is the right time to get help and that kind of a thing. So we really, we leave the team alone. for the whole six weeks. And then they have the actual amount of time that we bet on to execute the thing. I think we touched on this a little bit earlier, but what you're saying is there's no task level assignment at all. There's no definition at the planning phase of the tasks or who's going to do them or anything like that. We don't know any of that upfront. Every time we try to say, these are the tasks, first of all, it's disempowering. you know then you're reducing the team to ticket takers and code monkeys and grunt workers if you just give them a cue to work off of all the time but second of all there's a there's also an epistemological issue we just don't know up front what the real specific tasks are and if somebody tries to play architect at that level of scale that's the wrong level to do it there it's just going to blow up in our faces as soon as we encounter the reality So we're working with the grain of how things really are. We can do upfront planning at a higher level of abstraction where we say more or less, this is the design concept and these are the main technical tent poles that we expect. But when it comes to the actual work, the fine grain work, we can't predict that upfront. So it's better for the team to have the latitude to discover and capture their own tasks during the six weeks. What's the composition of the building team? Very simple. We've got one designer and one or two programmers, depending on the size of the work. That's it. And then toward the end of the project, we'll have a QA person come in. But the QA is not a gate. It's not a checkpoint that all the work has to go through for some kind of acceptance or something like that. Rather, we expect the designers and programmers to build perfectly shippable work. that does what it's supposed to do. And then we reached a certain size where, you know, small compatibility issues on different types of browsers or devices can multiply in absolute numbers to quite a few affected people. And then all it takes is a few dozen reports of something in support. And it feels like a big issue, even though, you know, relatively speaking, it's not. So we found it valuable to have this QA person come in to sort of as an extra as an extra level of help. to find the kinds of things that the team wouldn't have time to find. So it's really about edge cases and tricky things. It's not about the core functionality. But that's it. It's just the designers, the programmers, and then a little bit of QA at the end. That's the team. Could you talk about what the building process looks like? In particular, how does it get started? How do you get the ball rolling? Yeah, so because the team doesn't have a list of tasks that's been assigned to them, the very first... few days of the project are going to look like there's no work happening from the outside because the team has to get familiar with the pitch. They have to get familiar with the lay of the land of the existing system. Does this connect to that the way I think it is? How does this work currently? That sort of a thing. So there's a period of getting oriented and starting to sketch out approaches. So right away from the beginning, the designer is going to be identifying some core piece of work to start stubbing out. And the designer's goal is not to produce a pixel perfect mockup and then hand that to a developer. Instead of that, the designer is actually going to be just stubbing in the essential affordances again that need to be there. Because what does a programmer need? A programmer doesn't need a font or a decision about the color blue. Really, the programmers need to know what are the endpoints in the interface that I have to wire together so that it does something. So the first cut of the interface for a specific chunk of the work can really just be some fields and some buttons and some text that is just enough to functionally afford the process without all the visual styling and the final decisions about this color blue and on the left or on the right, that kind of a thing. And so while the designer is getting started on the first piece of design like that, there's enough information in the shaped work in the pitch. for the programmers to be thinking about, you know, what's the right way to model this in the back end? If we're going to be making changes to the database, what's the right way to start to think about this? So they're already being productive, even though they don't have design yet. And then the goal is that by the end of the first week, or maybe the very beginning of the second week, the designer has put together enough design for one specific chunk of the work, hooked it up in a rough way, and then the programmers are connecting that to controller actions or wiring it back to the model or whatever they need to do. And there's something that you can click on. So we're integrating early on one chunk of the work, both front end and back end, that we could kind of slice orthogonally apart from the rest of the work that needs to get done. And that first piece of work should be, of course, not just the thing that you've done 100 times before. So you don't, of course, you don't start with the login screen. You start with something that is of interest in the domain and that will teach you something because it's something that you haven't exactly built before. You want to start working on something that has enough interdependency with the other problems you're going to encounter later that as you tug on that string, it's teaching you about how all the problems are connected to each other. So that's how the team starts. There's a little bit of radio silence at first as they get oriented. The designer is focusing on the affordances over the, it's not a pixel perfect design yet. And the team is scoping out one chunk of the work that's valuable that they can integrate and get to a point where you can actually click on it on a beta server very early in the process, like by the end of the first week. Is there an example that comes to mind or maybe one from your book about that would illustrate? things that you leave out versus things that you would focus on as you're trying to get that one piece done? The main thing to do is to just have this clear split in your mind of make it work before you make it pretty. And most teams, even agile teams that are supposedly not supposed to be doing this, are basically just doing high frequency waterfall where a designer makes something all the way to full fidelity and you hand it over to a developer and then they implement it and you repeat and you repeat. And we're doing the opposite of that. we just need to get the components to click together so that I fill in this form field and I click this button and it takes me to the next screen and it says saved or it shows me whatever I need to see next and it's like look it works that's the victory moment that's the point where we're kind of over the hill and we don't have uncertainty anymore about whether this is viable then when you've done that now you can layer in you know extra style, you can play with the presentation of it, there might be some more refactoring to do, there might be more edge cases to support, but it's really about just getting those bones in, getting the integration between what are the main UI elements and then can I click on them so they actually do something. That's where we want to focus at first. Okay, so the first version might just be, it might just look like unstyled HTML, but you could click on something and It would actually make the desired change in your database. Exactly. At the end of the day, it's from end to end, from top to bottom. Exactly. Right. So if we kind of picture the work as two horizontal layers, a backend layer and then a UI layer on top, we want to take that pie in slices and do vertical slices where there's a little bit of UI and a little bit of backend together. And then we've got something real. If we just do a whole bunch of backend first, and then we think that all of this is going to be useful for us later, then we're doing speculative work and it's not going to connect the way we think. If we do a whole bunch of UI first, then same thing. We've done a whole bunch of work, but none of it actually does anything. But if we do just a little bit of UI and a little bit of backend and we wire them together, then there's no doubt that we accomplished something that is going to stay in the code base and it's going to get shipped at the end. We've actually accomplished something. the universe of unsolved problems has shrunk because we can actually say, here's a part of the problem that we don't have to think about anymore. You talk about scopes and scope mapping in the book. Are scopes those slices of the pie? Yes, exactly. Right. So you can't see all of the scopes up front because what we've got with the shaped work is we have a kind of fence around the perimeter of some work that's to be figured out. But then the interior of that fenced off area is like a wilderness. It's like a place you've never been. And you have to walk that territory to actually figure out what it's going to take to do and what the interdependencies are and what the structure of the problem is. So you can't just map everything out up front. But as you start to build out the first, you kind of pick a central scope that you think is worthwhile to do first. And as you start to work on that, you're going to bump into all kinds of other things. You know how it is. You get in the code and you think that you're trying to add a method to this class over here. And then while you're there, you already realize like, oh, but this thing also calls that other thing from here. I'm going to have to make a note of that, right? So you're actually building knowledge of the interdependencies in the system as you kind of wander around, even just trying to do that very first thing. But then what happens is you get the first thing built. You kind of take on the next thing. And then you've bumped into enough by maybe the end of the first, maybe by the second week, that you can start to map that territory. And you can start to say, okay, of all the things that we need to do to fulfill this concept that was shaped, there's basically these maybe three or four main areas that we could sort of treat orthogonally. And then you can kind of draw out these different scopes and you can say, aha, okay. We treat naming scopes the way that a good programmer treats naming. objects and functions and namespaces and stuff like that. Naming is hard, but naming is really, really important because it gives you the ability to start to string sentences together with the different pieces of the problems. So for example, we had this project where we were building permissions for clients using Basecamp and the scopes broke out into some things that had very specific terms like bucket access, recording visibility. uh you know things like that and these had a a specific meaning to the team that was working on them and then they could say let's get bucket access to the point where it's firm and then we can we can go back to styling the recording toggle you know and then they're they're sort of speaking the language of the project and they're being very deliberate about which problems they're working on at what time and then they can they can do that technique we talked about earlier kind of again and again and again where there's enough back end on this scope there's enough front end on this scope where we say, uh-huh, that one is more or less solved. We don't need to worry about that so much. So now maybe instead of taking that all the way to full polish, let's shift gears and work on this other scope because there's some scary unknowns in it. So this is where they're mapping the territory and they're also kind of roving around and they're being very intentional about how far they build up the different layers within each scope. You also gave some examples of... poorly defined scopes and some signs of poorly designed scopes. I think one is that they're just not named well or they're what you call a grab bag. Is that right or is that the level of the project? There's a few signs to tell you if the scopes are right or if they're not right. It's generally a smell if a scope has a generic name. If your scope isn't domain specific and it's something like front end, you know, front end or bugs or something like that. That's a grab bag, like you said. The issue with a scope called front end is you never know when you're done. It's not carving. Front end is a horizontal cut. It's not a vertical cut. So what we want to do is we want to make vertical cuts that tell us when this part of the problem is done. So instead of front end, we want to have store, reply, trash, send, things like that. And then within those vertical slices, then we integrate both front-end and back-end tasks. So that's one smell. Another smell is if the scope is too big, then it's not helping you. If a scope takes longer than a week to do, it basically becomes a project. And the whole notion of a scope is that we should have a chunk of the work that we can carve out from the rest and integrate over, and then the universe of our problems has shrunk. It should be relatively small. And it should be something that we need to be able to see what done looks like for it. And a sign that the scope is right is the scope start to act like buckets for the tasks that you discover. So we talk about imagined versus discovered tasks. And as the team is working and bumping into things and finding things that they're going to have to do later, if the scopes actually course to the anatomy of the work and they reflect the... the parts that are orthogonal from each other, then as tasks come up, you're actually going to be able to bucket them inside that scope and say, ah, okay, that's actually about recording visibility. No, that's about bucket access. That's about trashing or whatever, right? And this way, the work always has a place to go. And it's easier to kind of have conversations about the work because you have a kind of large scale structure that's telling you kind of what you have to do. And it's not just a giant pile of tasks. You had two different methods of showing progress. So you said in the book that teams don't like being interrupted for progress updates all the time, but managers and decision makers also don't like constantly asking for progress. It's kind of... Yeah, nobody likes it. Nobody likes it. So you have actually two different tools that you use. One are to-do lists and the other are the hill chart. Could you explain what the to-do list and hill charts look like in your system? Yeah. So of course we have to capture. tasks we have to know what to do you know and if we're not going to queue those up in some kind of you know list in advance for people then what are we going to do so the way that we handle this is the team start off with just discovering some tasks that they think they're going to have to do because like i said you can't see all the scopes from day one because you have to walk the territory before you can map it so in the beginning there's just going to be a kind of a loose set of tasks that aren't really scoped that are just a bunch of sort of key things that the team has identified that they're going to have to do. Then as you start to work on a specific scope and you start to map things out, then it becomes natural to aggregate these tasks per scope. So the way we do this in Basecamp is we have a project, the team's working inside of a Basecamp project. That Basecamp project has a to-do section in it. And that to-do section allows you to group to-dos together into lists. And so the team will name the lists after the scopes that they've found. So they'll create, if they have a scope that's called, let's say they're working on some kind of a messaging feature and there's a delivery aspect to it, there might be a scope called deliver or send. And that scope might include some UI that needs to happen for different states of successfully sending or updating to say that it was delivered or whatever. And then of course, there's going to be backend issues with actually performing the delivery. So those tasks might go together in a list called send. And then if new things come up that have to do with that work, then you just keep adding tasks to that list. And then you've got other lists that are named after the other scopes. So that's basically kind of how do we bucket the work? How do we capture the work? And how does the team know where to put the work as they go so that they have a kind of clear way to deal with with sort of there's more work over here on this issue and this thing came up, but I'm not going to deal with it yet, but I know where to put it over there. So the work is captured in lists and the lists correspond to scopes. That is just so that stuff doesn't get lost, you know, and it also enables the conversation about the work because people can discuss back and forth in the comments on a particular task, you know, the details of the work. But that's really just about capture and not losing things. When it comes to showing progress, we have this other tool called the hill chart and we've actually kind of been talking about it in a way uh so far we talked about this notion that you reach a point where the ui is stubbed out and you've you can see exactly kind of okay i'm going to wire this to this and this this and that in the controller and this is where it connects in the model and is that api where i think it is let's see uh-huh yep it is okay so that connects with the way i think and okay this looks like it's going to work you reach a point where All of your unknowns are gone, but you're still not done. And we use the metaphor of climbing a hill. You know, when you're climbing up a steep hill, you can't see the top until you get to the top. But then when you get to the top, then you can see down all sides and you can see everything. So the early phase of a scope is where you're figuring out kind of what is the exact approach. Do these different pieces of the system connect the way that I think that they do? If we wire this together, are we going to like it the way we think we're going to like it? So there's this work that you do to sort of figure out what is the actual approach? How do things connect together? Is it going to work the way that you expect? And you're doing just the minimum amount of stubbing and spiking to validate that. But then you reach a point where you say, yeah, this is figured out, but there's still execution work left. So that's what it's like to be at the top of the hill. You can see everything else that you need to get done. So I like to use sometimes the analogy of if you're building a piece of IKEA furniture, there's a big difference between when you have a whole bunch of parts lying on the floor and you're like, all right, I don't know if this is going to be 20 minutes or three hours, right? But then there's a different point where it's kind of standing and you've got four screws in your hand and you're looking at it and you can see four holes and you say, okay, I have work left, but I have very little uncertainty about this work, right? It's a different risk regime. And The way that we think about risk is very binary. Either it's solved and you are 100% certain this, you are going to be able to finish this thing and it's going to work, or it's not solved and an unknown could bite us. And if an unknown bites us, if something doesn't click together we think it's going to, or there's something about the way that it works in the UI that isn't satisfactory, if there's something that we don't solve, It might take a day to solve it. It might take another week to solve it, or it might take six months before we have a eureka, or it might actually be unsolvable given the way the existing system works. And that is a huge risk. So we're viewing the uphill part of the work as getting all that risk out, getting to the point where we are sure about it, and then we can believe that the thing is going to be okay and it's going to get into the final shipped product. And then the downhill work is just the remaining execution. So on a per scope basis, we have this hill chart and we can draw a dot that corresponds to each scope to show where it is on the hill. And the teams just drag this on the hill. And this is totally from the stomach. It's not some artificial velocity point estimation, blah, blah, blah. It's not some made up number that people don't even know what it means. It is right from the gut reflecting where are you in terms of known and unknown on this specific piece of work. from getting your hands dirty and actually being involved in it. And then by looking at that hill chart, this is something that the teams can update asynchronously. It's actually fun when you get to a point where you solve something and then you drag that dot up to the top of the hill and you're like, look, that's figured out. That's kind of a moment to celebrate. Or if all work actually starts at the very, very far bottom left of the hill, even if you think you know what to do. head work isn't the same thing as opening up the hood and confirming that those end points are where they think they are or that that method takes the arguments you think it does or whatever it is. So it can also happen that you have an idea about what your approach is. You get in there into the code and you say, uh-huh, that's where I think it is. And you drag yourself up a quarter of the way up the hill and you say, look, I've validated some of my assumptions. And then so the team is kind of celebrating their progress and showing that they're getting somewhere by updating the hill. And then at the same time, someone who is outside of the team who's interested in how they're doing. This could be somebody who's a bit more in a product manager type role, who's wondering if the project is going successfully or not. Or it could be somebody who is in maybe more of a sort of a performance evaluation role. So maybe there's a more senior programmer. that these programmers report to, and this person wants to know if this programmer is kind of, what's the rate of their problem solving? I mean, are they getting somewhere or are they stuck or how's that going? And then regardless of the case, either those people could just take a look at that hill chart, again, asynchronously, and they can see if work is moving up and over the hill or not, and they can even see at what speed on the second order. because Basecamp actually allows you to see snapshots of the hill over time. So you can see today versus three days ago, you know, what's moved. And this gives a really good sense of what problems is the team solving? And are they stuck or are they actually getting to the solution? And are they taking things all the way to full polish when there's unknowns that they should be addressing first? So it also lets you evaluate. sequencing decisions that the team is making in terms of which problems do they take on in what order and which scopes do they allow to sort of sit at the top of the hill knowing that there's some other unknown that they better push up before they just do all of that known work of getting the other things downhill. So there's a lot that can happen there in an asynchronous way where we avoid a lot of those sort of painful and annoying conversations of, hey, what's the status on this? How's that coming? What's going on there? run out of time fittingly the thing we haven't talked about yet is how to decide when to stop can you talk about wrapping up a project first of all let's just remember that we've created a whole constraint structure now the team is working within a six-week cycle or if they're not in fixed cycles because you're a smaller startup you're at least in a in a fixed time box for this project the team was given shaped work with a lot of latitude for how they fill it in They are responsible for making the trade-offs of how they fill it in. And we have the circuit breaker so that if the project goes over time, it doesn't automatically get more time. By default, it gets canceled. And of course, the team is uninterrupted, so they actually have the time to be successful. The team is in this situation where if they make the right decisions, they should be able to finish and they should be able to ship this thing because all the right constraints are there to help them do that. But of course, there's some forces of nature that are always working against you. Scope is always growing. It's not just that there's the bad client or there's the clueless boss or whatever who's constantly giving you more work to do. Scope grows by itself, even when you have really well-shaped work, because you just get in there and you realize, oh, but we could also do this and we could do that and we could refactor this and this should be better and that should be better. There's just no end to it. So the team needs to be able, to constantly deal with all of these new things coming up that they discovered that they could be doing. And so we call that scope hammering and it's a constant thing. And the simplest tool for that is one that the team can apply day after day after day. And it's just asking the question, if we had to ship tomorrow, could we ship without this thing or not? So really just, is it a must have or is it nice to have? And then we have a simple tool for that. So any task that the team comes up with or discovers or bumps into, when they add that task to a to-do list for a scope, they mark it with a tilde in front to indicate if it's a nice to have. And the important thing is that they always ask themselves a question. So we really expect our teams and we teach them and encourage them and expect them to engage with the scope. You never just see things and then add a task. Before you add that task, you ask yourself, is this a must have or not? And you need to be tough about that question. And then so we'll have a lot of work actually with these little till days on the front of the tasks. And that indicates, okay, if we have time later, you know, if we get the main things done and we're satisfied, then we'll come back and reconsider this. So that's the first thing to helping us actually finish. The second thing is we need to set the right reference point so that we can call what we're doing a success. Very often, teams are working on a project and they're constantly thinking about, well, what would make it better? And so you're looking up to an ideal of what's the best version of this and then are we there yet? What we want to do instead is we want to look down to a baseline. And the baseline of performance is what are customers or users doing today without this thing? So we've got this work in a branch. Customers don't have it. What are they doing today? Or what are they not doing today because they don't have this? And then we want to make that comparison back down to what life is like without this thing for the customer base, instead of making that comparison up and forward to the even better version that we haven't built yet. And when we make that performance comparison from a work in progress down to the baseline, then we can say to ourselves, aha, this is definitely better when it's not perfect and it has all these flaws, but it's definitely better than what people have today. you know, or it's better than nothing. And from that point of view, it becomes easier to make those tough calls and those tough trade-offs to say, what really is that must have and what is that nice to have and make the call to ship it. Great. Before we wrap up, is there any must have, must discuss things that we haven't covered you'd like to talk about? Yeah, there's one thing I do want to mention, which is that there's different phases of the work when you're working on an entirely new product. or if you are working on a completely foreign technical foundation. So what I mean is like if you're working in a language you've never used before, or some kind of a new technology that you haven't used at all, and you really, really don't have firm ground underneath you, this sort of shape that build process does not work in that scenario. So there's sort of two phases. When you're first working on a brand new product, There's an early phase where you don't actually know kind of how the main features hang together so that it's going to be viable. And you don't really know exactly what the correct database model is going to be and the main modeling in the back end, how that should be architected. We call it R&D mode and production mode. In R&D mode, we deal with it differently. So it's much more of a skunk works type project. We're going to have a very senior programmer and an experienced designer. are going to team up and they're not going to shape something and then say, now we believe that this is a really good bet and then bet on it because you just don't know enough yet when you're starting brand new on a brand new product. You don't have any established architecture that you're working within to have that certainty to bet on. So instead, we're just going to bet a fixed amount of time, let's say six weeks. And within that time, the goal isn't to build a project to completion and then deploy it. Instead, there's going to be a few tentpole features that this Skunkworks team knows needs to get figured out. And then they're going to be firing tracer bullets and just building things halfway up. Just building things, just spiking enough to get some certainty about the architecture. Then once the main points of the architecture are settled, and you can say, okay, more or less this feature lives over here, and that's over here, and that's over here, and this is how it all hangs together. Then you can flip the switch. and you can move into production mode. And then because you have this sort of solid ground of a settled architecture, that's where you can start to do shaping and bedding where you say, I'm going to define this work for another team to do. You know, when you're in that R&D phase, it's normal and natural and okay to work for like two weeks and then scrap everything that you did and then do a totally different approach because you just don't have the firm ground underneath you yet. But you can't keep working like that forever. You need to get to a point where you pour some concrete, you make some commitments on the foundation, and then from there, now it's clear kind of where load-bearing structures for future features can go. And then you're in a place where you can shape something and give it to other people to execute and you can expect them to be successful and ship at the end of that. So I just want to call that out that the way we deal with shaping is different in those two phases. In the R&D phase, shaping and building get mixed together in a blurry mix. with the Skunk Works team, just spiking out stuff to figure out what the right basic architecture is. Versus in production mode, we can have these very discrete steps where we're shaping, getting to a point of a potential bet, making the bet, and then expecting the team to execute on that. I think there's something else you mentioned toward the end of your book about onboarding, like how to begin shaping up. Maybe share some similarities with the R&D phase where you just want to take a few, maybe one team. and get them started. Did you want to talk about that? Sure. We've seen a few different cases for how people get started. And it can depend on a lot of factors, like how big the company is and what your role is in it. So of course, we've seen some people just start whole hog where there's a founder learns about the method and kind of relates to a lot of the struggles that we talk about. And they're like, you know what, we're going to work this way. And then they just call it and they switch to everything. We have seen that. In other cases, there's been times where somebody in a more kind of a CTO role starts to see all the difficulties they have with the two-week sprints. And they start to think, maybe we would be able to get more meaningful work done if we had a longer cycle. And then they switch to maybe like a six-week cycle. But they might not quite relate to the shaping work immediately, especially if they're in more of a CTO type role. So what'll happen is they'll find that they have much more room to get meaningful things done. But then... After some time, then they'll start to realize like, oh, if we shaped the work, then we would have even better outcomes with this new capacity that we have. We would be like putting the right work into this six-week box. So I've seen that where we start with cycles and go into shaping from there. I've also seen it where somebody is more in a product role or a senior design role, and they don't have control over the way that resources get scheduled and kind of how programmers spend their time. So what they do is they start by shaping a project. that has such clear boundaries that they then can kind of go around and shop that to people inside the company and say, look, I've got this really meaningful thing we can do. And I think that if we just had a team of three, we could get this thing released in six weeks and it would be a big win for us. And people say, oh, look at that. I've never seen work. I've never seen work that was so clear before. I can really see kind of what the end of this looks like and what we're doing and not doing. And then, okay, fine. Let's carve out those three people. And then they have a lot of success with it. The project goes well. And then it's like, okay, let's do that again. And then the question becomes kind of how do we structure ourselves to repeat that? And then that leads you down a path of putting cycles in place so that you have sort of a regularity to the availability of your resources and then having a sort of routine of shaping so that the work that you put into those. into those teams is risk reduced. So there's all kinds of different starting points and it doesn't have to be the whole business at once. It can be a single project. It can be within a single team. If you have quite a lot of people, it can just be one team. The important thing I think is to first start having the conversations with the team using the language that the book gives you. You can start to talk about the shaping work when you maybe didn't have a word for it before. And you can talk about what happens when you don't shape. You know, that meeting that you have, that grooming session when there's all kinds of technical questions getting raised about the work and you have mock-ups, but you don't have any good answers to the technical questions. And then everybody feels a little bit queasy committing to it, knowing that there's too many unknowns and everything's rushed. And we know what that's like. So we can use the language to talk about that. Or we can talk about uphill versus downhill work and what goes wrong. when we keep extending time on uphill work and stuff like that, or the difference between our estimates versus our appetite. And those will start conversations that can be really productive. And then as you start to identify where you can do better, and you've got this whole toolbox to reach into, whether it's cycles or betting tables or pitches or whatever it is, you can figure out how to start to assemble that into a process that makes sense for the org structure you have and the current scale you're at. Where can our listeners go to find the book and to find more information or more information about you and what you're doing? Yeah, so the book is at basecamp.com slash shapeup. And you can read it online or you can download it as a PDF. And we're also going to be working on other formats. So publishing on the web has allowed us to keep making changes and fixes to it as we get feedback. We'll be doing a print and an audio book and e-book and stuff like that down the road. You can also sign up there at Basecamp.com slash ShapeUp to get notified when those other formats are ready. And then I'm RJS at Twitter. And if you want to see updates on the book or commentary on these topics, that's the main place where I've been posting those bits. You have the three-letter Twitter handle, huh? Yeah, it's been on there for a while. Well, Ryan, it was great having you on Software Engineering Radio. Thanks a lot. I really appreciate it. For Software Engineering Radio, this has been Nate Black. Thanks for listening. Thanks for listening to SE Radio, an educational program brought to you by IEEE Software Magazine. For more about the podcast, including other episodes, visit our website at se-radio.net. To provide feedback, you can comment on each episode on the website or reach us on LinkedIn, Facebook, Twitter, or through our Slack channel at seradio.slack.com. You can also email us at team at se-radio.net. This and all other episodes of SE Radio is licensed under Creative Commons License 2.5. Thanks for listening.

Ryan Singer on Basecamp’s “Shape Up” software development process. Basecamp has ditched the backlog and 2-week sprint in favor of solution “shaping” and strategic 6-week projects, using tools like scope mapping, checklists, and hill charts to understand and reduce risk.