Shaping The Work

Ryan Singer: Thanks for having me here. I'm happy to talk about Shaping and Shape Up. Shape Up is the book that I put out last year now that describes the way that we at Base Camp go from a raw idea of something that we think we want to do to a ship project. And actually, the reason, I want to talk a little bit about why we wrote the book and what it's for. Because in the short time that we have makes more sense for me to try and give you some motivation and connect the dots about why this might be useful to you. And then of course you can actually read the whole book for free at Base Camp.com/ShapeUp. So, actually Jason invited me into a room for Jason, Base Camp founder, invited me into a room for my six-month semi-annual review a couple of years ago and said, "I think you should write a book next." And I had never written a book before, and I thought that this was a terrifying idea, but of course I said, "Ah, good idea. I'll go do that." And I had no idea how to do it but he could tell that we had so many peers in the industry who were telling us a lot of difficulties they were having. And we were reflecting on some of the difficulties that we went through in our earlier growing pains as an organization. And we had actually gotten to a point where we had systematized the way that we work enough and that it was a good time to try and share it. The struggles that w that we're seeing with other companies and also with ourselves when we look back into earlier in our growing pains were one big struggle is a lot of teams say, "Why are projects dragging on so long? Why is it that we can't ship the way that we used to? In the early days when a startup is only three people, four people, things just happen organically and they happen quickly. And then as the company starts to grow things to start taking longer and longer and what is going on there and how do we get out of it? The other big problem that I'm hearing, especially when it comes to folks in the UX world and folks who consider themselves to be leaders of the product. There are people who feel that they're supposed to be thinking about what's important to do next. They're supposed to be creating a vision of what we should do next strategically with the product what's important. But they just don't have any time to think about that. They're so busy in the small details of the work that's going on week by week by week. They're in so many long, probably unnecessary meetings that they're busy all day with all these micro details of the work in process. And there's no time to really think in a strategic way about what's important to do next. Very often actually we'll even hear about folks saying that they end up spending their time on a Saturday or a Sunday, actually trying to think about what's important to design and tackle next to actually move the product forward. These are big challenges and we've actually managed to overcome these really well. And this is what ShapeUp is about. It's about how do we get, how do we create a rhythm within our product organization where we are regularly choosing something we want to do, deciding how much time we think that it's worth and then actually shipping that thing or some version of that thing that we feel good about and doing that again and again and again, and the way that we really do this is I'm going to introduce a handful of concepts to you that are the main ideas. And then you can go to the book for the details. The first thing is we talk about shaping the work. And when we talk about shaping the work, this is about defining the work at the right level of abstraction. What I mean by that is there's a level of abstraction. That is too concrete and this is what happens when, for example, we'll often see teams where the designers will create wire frames or pixel perfect mock-ups and then these go downstream to get implemented. And if the work is defined at such a fine level of detail upfront, there's no latitude for creativity. First of all, right? Because you can't draw a wire frame and then say, "Well, make it look like this but not exactly like this." Right. You're going to get locked in to all of these very early visual decisions that weren't necessarily the right decisions. The other thing that happens is when the work is defined too concretely upfront, it always blows up in your face later because the things that work on paper, the things that we think are going to work in a very specific visual concepts, very rarely translate directly. Once they actually go into code and into something interactive and we start clicking on it, we realize, "Oh, that's not really what we wanted." So, we don't want to be too concrete. And then at the same time, there's a lot of pitfalls if we're too abstract and too abstract is where we say, instead of delivering a specific wire frames and pixel perfect mock-ups for a feature idea, we say, "Let's go build a calendar and we just use the word calendar." And then everybody nods their head because they think they know what calendar means, but this is the illusion of agreement. It sounds like something that we all know what it means, but then when it comes to the details, there's a massive amount of latitude in the definition of what calendar is. So, for example, does a calendar mean that we going to allow you to drag queen cells on a month grid? Is calendar mean dragging the duration of a meeting in 15-minute increments? Does calendar mean that we're going to be facilitating the RSVP process or figuring out how to send invitations or figure out overlaps in people's schedules. There's a massive amount of latitude there and this drastically changes the scope, the expectations, the out of time, all of that. So, there's a middle zone in between where we define the work at the right level of abstraction. And I'm just going to give you a couple little examples of that so you can see that I'm just going to share my screen here and what we're looking at it this actually came from the book. This is what we call a fat marker sketch but we used to do this on paper with Sharpie markers. And the idea was that we would use such a blunt instrument that it would make it impossible for us to specify fine details, but at the same toleration ships. So, this is actually a calendar concept that we built for Base Camp. And this concept was something that we wanted to build in only six weeks. And we knew from experience that building a full featured calendar required. It was easily a six-month project because of all of those complexities that I've mentioned earlier, but we knew for strategic reasons that this was only worth six weeks that the demands from our customers that really mattered strategically were actually very few and quite simple. So, we came up with this concept, which is basically like when you book when you book a flight and you see two months side by side. We only rendered events as dots inside of the cells. There was no dragging between cells. There was no spanning of events across cells. There was no a high-fidelity interaction here. You can move back and forth between this two up month view. And then we would display an agenda view underneath. It's like the Apple's phone app where you could see what that dot was and that it would give you some detail for that. This is an example of specifying the concept at a level that constrains what the team still leaves them a ton of latitude for the actual implementation. There's another technique that we use called Breadboarding and this is even one layer more abstract. And this is a concept thing technique where we basically just use words and connections to specify the affordances and what appears on a screen. So, here's the basic idea is if we're going to talk about and then draw bar underneath. And then we can say on the invoice screen, there's going to be an affordance to turn on the auto pay option. The auto pay option is going to take you to a screen called set up autopay and then here we're going to have the credit card fields of a logo for the financial institute. What we've done here is we've described what needs to happen, functionally. What needs to be there in order to actually perform the functionality, but look at all of the design latitude that we're leaving for the team. We're not even saying this is on the left or the right or above or below. There are no two-dimensional relationships here at all. Purely topological relationships of what connects to what early while still being very specific. So, for example here, we can say, "Well, should we introduce an option to pay the balance now? This is for a recurring option for paying an invoice. And we can say, "Well, no. Actually, this is the wrong place to do that." We can totally revise the concept and say, "We're going to have a pay screen and from the pay screen, we'll have an option to auto pay in the future and so on." Right? So, you get the idea of how we can very quickly adjust the concept and before we were allowing for a lot of variability in the scope, because we're not defining it down to the small detail but at the same time, we're bounding scope because we defining the important things that are in and that are out, right? This level of shaping is where we do project definition at the right level. Now, a couple of other major concepts that I want to share with you in the short time we have here indicating time estimation and scheduling. So, very often when teams are designing work, they design a concept and then the question becomes, "Well, how long is it going to take to do that?" And then we have, what's called an estimate, right? The estimate is where you start with a design and you put a number on it. We work the opposite way instead of setting an estimate on some work, we define our appetite. The appetite is how much time do we actually want to spend on this thing. Very different question here. We reverse the process instead of starting with the design and then giving it a number. We start with a number and then come up with a design that can fit inside of that time box. So, with the example of the calendar, if you just said, well, what is a good calendar? Then, of course, it would include all of these high-fidelity interactions for dragging events and dragging the edges of events to change the duration, all kinds of things like that. But when we say, well, we only have an appetite for spending six weeks on this calendar that changes everything because now we've introduced time as a design constraint. So, the time isn't how long it's going to take, the time is going to constrain. What are we going to build? And out of this, we came up with this notion of what we called the Dot Grid Calendar which was a very, very limited calendar but because of our understanding of the demand and the circumstances that our customers were in, we understood that we could actually scratch the itch that we wanted to scratch within the amount of time investment that we wanted to make. So, when we combine these two together, when we set an appetite instead of an estimate, and we define the work at the right level of abstraction, so that it's very clear what is in and what is out, but there's a lot of latitude for how exactly that gets executed. Then what happens is we can use fixed time variable scope. So, we very often talk about building some version of a concept. We don't need to build the version that was specified down to the pixel. And we don't need to have a contract where every single bullet point will be there. We understand the spirit of the idea. We've shaped an idea that we think is viable within that amount, within that appetite. And now the question is how do we actually make that time commitment and give that to a team and get somewhere with it. So, here's where we talk about planning instead of bedding or actually betting instead of planning, sorry. So, very often teams will choose something to do and then they'll make a plan. This is what we're going to do. Well, we use the language of bedding because it communicates the risk that's involved, whatever concept that we choose, different concepts that we choose to schedule are going to have different odds. According to how well we've understood the interdependencies of the work, how well we've shaped it, how well we've scoped it. The work that we do in the shaping actually affects the likelihood that we are going to be able to ship it in the amount of time that we think we're going to spend on it. Now, at Base Camp, a typical team is one designer and two programmers working together. And the way that we schedule projects is we have what we call the bedding table. Reshaped work is like a potential bet. Something that we could do. It's like a good option. Then at the betting table, we make a decision for what are we going to do in the next six weeks? And we work in six weeks cycles. Six weeks, the exact number six is not so important but the basic size is. A lot of teams are working two weeks at a time. Two weeks is not long enough to really finish anything meaningful. And if you try and reach some a meaningful goal where you're actually shipping the work, I mean, you can't run when you're looking down at your feet and working two weeks at a time is a little bit like looking down at your shoes. On the other hand, if we make the time horizon too far and we say like, "Okay, let's fill out six months for a project." Nobody can feel the pressure of that six-month deadline coming. Until you actually get around six weeks away. So, there's a natural horizon where you can feel the deadlines pushing back on you. And what we've found is that around six weeks is the right period of time where it's long enough to actually accomplish something. But it's short enough that the teams can feel that back pressure from the beginning. And so, this back pressure is actually motivating them to make trade-offs. And the way that we make this back-pressure effective is by having a tough policy around what bedding means. So, when we talk about making a bet, it means that we're going to take this shape concept, give it to a team. And they're going to build this for the next six weeks. And at the end of the six weeks, this is going to ship. Now, there's three things that make a bet, a bet. The first is that we don't make a bet unless we actually expect some a payoff. So, we're not just building incrementally two weeks at a time with no end in sight. When we make the bet that we're going to spend six weeks on something, we know what done means from the beginning because of the shape concept because we've done the shaping. We have a definition of done at some version of this is going to be completed within that latitude of the variable scope at the end of the six weeks. So, we have a clear payout of what we hope to get from the bet. The second thing is that when you make a bet. You're making a commitment. It's something that you honor don't make a bet and then say, "Oh, just kidding. I'm actually not putting; I'm going to take my money off the table again." No, it's a commitment. What that means in the context of doing software development is that when we say that this designer, they're going to get the six weeks. We are not going to interrupt them with other things support isn't going to come and say, can you fix this bug? Sales isn't going to come and say, and we don't have sales but if we did sales, isn't going to come and say, "Hey, I need you to stop what you're doing and build this feature so we can close a deal." Six weeks for this team is a commitment that we're making. It's the bet. It's the money we're putting on the table and saying, we are willing to risk this to get this outcome. The third thing that makes a bet about that is that there's a cap on the downside. If we say that we're going to bet six weeks and then the project starts to take 10 weeks, 12 weeks, 18 weeks. There was no meaning in placing the bet. Right? We should have a sense that the maximum we will lose, if the uncertainty blows up in our faces and we don't get what we hope to get out of this is the amount that we bet that's a cap downside. So, in order to implement this, we have a policy that we call the Circuit Breaker. The circuit breaker means that if the project doesn't finish in six weeks in the appetite that we've set for it by default it's canceled. So, we don't automatically extend the work ever. We never just say, "Okay, we started it. We have to finish it. So, let's give it more time." If we shaped the work and we had done the work to say, we believe that this is a good bet. For this of six weeks, that there's some version that can ship at the end of the six weeks and then it doesn't happen. There was something wrong in our model, there was something wrong in our understanding, there was something wrong in our design concept, there was something wrong in the performance of the team, whatever that thing is that was wrong, we need to actually look at that again and decide, do we want to reinvest in this faulty thing? The other thing is that something much more important might've come up in that six-week time. It could be that the thing that we thought was the best idea we had six weeks ago is now actually less important than a new opportunity that we discovered or a crisis that has appeared or who knows what could happen. Right? So, we also want to give ourselves always the optionality to abandon something that didn't work and to do something more important rather than continually reinvesting in it. So, this circuit breaker is very powerful. There's a third and final aspect that I'll mention in this brief overview, which is that we do not assign any tasks to teams. Nobody creates tasks for teams. What we do is we give them the whole work. We give them the shaped concept. We give them the time box of the six weeks. And then we say inside of this, the boundaries of this concept and the boundaries of this time box, come up with the best thing you can come up with. And then the teams themselves by getting involved in the work by trying to integrate and produce it together, they actually capture the tasks that they discover. So, there's a huge difference between the tasks we imagine we have to do. The imagined tasks and the tasks that we discover we have to do by actually getting our hands dirty in the work. Those are the discovered tasks. So, what the team is doing is they're creating their own tasks. They're capturing the tasks, the discovered tasks that appear as they get involved in the work. And they are actually self-managing and making the trade-offs about what works to sequence in what order, what problem is important to solve first, which pieces of design and backend to integrate early in order to actually successfully complete the project in the six weeks, in a way that's satisfactory. And in the book, we have a lot of detail about the methods that we use in part three for how the team actually does this sequencing, how they bundle different aspects of the work into different scopes, how they manage unknowns and knowns with the Hill chart. There's quite a lot there, but the key point is that because they have the shaped work and the latitude to adjust the scope. And because they have a hard boundary with a real ending. Because of the circuit breaker, this circuit breaker creates a back pressure. This back-pressure motives and motivates actually the designers and the programmers to collaborate more, to decide what to tackle in what order at what level of fidelity. And because they have this productive pressure but they also have enough time and the right amount of direction in the shape concepts. This massively energizes the team. This is actually one of the main things that I love hearing about teams who adopt Shape Up as they say that they've never seen so much collaboration and so much excitement out of the collaborators because they actually have more to contribute. They have more creative latitude than before, and they have more responsibility than before actually to make tradeoffs about what is important and when to keep polishing one screen. And when to say, actually that screen is good enough, let's move on to this other thing where there's more risk. That's a high level summary of the things I wanted to talk to you about appetites versus estimates, working at the right with the right time horizon, six weeks to get something meaningful, finished and shipped rather than two weeks on a treadmill or six months where nobody sees the end and nobody's reacting and making trade-offs the notion of fixed time and variable scope. Using the work that's shaped at the right level of abstraction to give creative latitude making bets, instead of planning, capping the downside of our bets. And giving teams the whole work and giving them actually responsibility for the whole and the integration of all the parts instead of taking them with tickets for the individual components of the work. So, with that I'd like just to see if you have any questions for the time that's left.
Rory Madden: I'll jump in there yet. So, thanks very much, Ryan. That was really good. I really like that talk. And I'll jump in with the first question. So, this one, I actually threw it in calendar. I love that concept. It was a great, great concept because it's complex enough with the calendar, when you're shaping, is there a risk that you're taking away some of the context from the builders then? So, when you're shaping, you're saying we're just going to go with the dots that's for a reason and you've chosen a particular reason. But is that rationale being handed over to the team as well? So, that when they have to inevitably make more decisions, are they going to be able to understand why it's been shaped the way it has?
Ryan Singer: Oh, that's excellent. I'm really glad that you asked that because it I left out a detail, which is the way that we present the shape to work to the team. So, actually, we write what's called a Pitch that presents first, the shaped work to the bedding table to choose whether or not to bet on it and then if it gets bet on, we pass this further onto the team. The pitch is not only describing the solution of the shape of work. It's also describing the problem in the motivation. And this is where the appetite is also very important because if we say, "Look, we're only doing dots on the calendar." Someone could say, well, come on. That's clearly a worst calendar. We should be doing all these other things. And you say well, but given the appetite and given the context and given these things that we've understood by talking to customers, this is why this is the right solution. So, it's actually what we're doing is we by shaping the work, we actually are giving the teams the context that they need to make the trade-offs. Another one of thing I think that's very important to mention here is I think that that just product teams have become way too democratic and they should become more authoritarian programmers and designers. Programming is very, very hard and requires deep expertise and tons of time, all day dealing with small, difficult, hard puzzle problems. Design is the same design is really hard and it takes all day to solve hard design problems and figure out how to implement them correctly. Designers and programmers have deep amazing expertise. They don't have time or skill or the resources to go talk to customers to model strategy, to understand why we're building what we're building. They need to know the context around what's been given to them, but they need leadership. Somebody actually needs to spend the time to talk to customers to do the higher-level design work, because this isn't a power question. It's not a governance question. It's a time and work question, talking to customers and coming up with concepts that meet their needs requires hours and hours and hours of time that people who are dedicated programmers or designers don't have. So, this is something I think that's really important to look at as a way that each of us actually adds a different type of value and then compliments each other. So, I look at our team members, they can do a level of design that I could never implement, and they're going to come up with solutions at a fine grain level that I could never come up with that are 10 times, a hundred times better than what I could do. But I have a specialty in my shaping role of actually trying to understand what's going on strategically with what customers are trying to do. So, I want to actually be able to package that understanding in a way that gives them boundaries then enables them to do the things that they're really good at and then we're being very complimentary to each other.
Rory Madden: [00:27:12] Great. I'm just going to paraphrase. I'm reading. There's a lot of questions coming in at the moment, but there's a theme coming here, I guess, that slightly contradicts that viewpoints versus we had Marty Cagan on yesterday and he went very much the democratic route but can you give people a bit of an understanding of what your team looks like? Because I'm seeing a lot of people asking what's your makeup and then on second point to that as the shaper, how involved are you in the delivery?
Ryan Singer: [00:27:42] So, my goal is as a shaper is to be the least involvement possible and to be available in a support role if questions come up or things need to get workshopped. We don't have any regular meetings at all. During the six weeks, there are no regularly scheduled meetings of any kind. The only meetings that we have both within the team and across like outside the team with certain the person who shaped or someone senior or whatever. Our ad hoc workshop sessions with two or three people where a very specific question has come up and they have ad hoc designed decided to talk with each other. The actual build teams, the important thing. So, I've seen Shape Up implemented, of course, in our own case at Base Camp, where we have designers who are both our designers are both doing the visual design and they're doing the front end build out. And then our programmers are mainly doing the backend aspect. And that's the way we were built and integrated at Base Camp. I've also seen this work in other companies where you have a few more hops in the chain. Where you have a front-end engineer person who's not actually conceiving the interaction, they're more implementing the view and then you have like a stylist who's doing more like the graphic design of how the interface should look, but they're not implementing it in code. And you have a backend. You can have more layers. The point is that all the layers that you need to actually build something are integrated on the team and the team is as small as possible. So, we should have something like two to four people on the build team and all the skills that are necessary to build are there. And there's no management necessary because the team is self-managing and we don't need to have any, basically, that's all we need.
Rory Madden: Yeah. I'm seeing a lot of people trying to keep track of all the comments coming in as well. So, that is a lot smaller than I guess at traditional teams would be in a lot of organizations and they can maintain for the two-pizza team. And a lot of companies struggle with that. Trying to keep the time.
Ryan Singer: No, you can't really build anything targeted with where as soon as you have a giant team, then you're spending all of your time coordinating with each other and you're not actually in the work. And when we have a very small team and we scope work for what can this unit of, what can this combination of people do in six weeks? Then we design with this is about designing the work. Usually teams take the work for granted. They don't really design the work. They just say, this is what we have to do. And then they keep throwing more people and more time at the work. What we're doing is we're designing the work so that it suits the people. So, that it's actually something that we can execute.
Rory Madden: Great. And just on that, like keeping it constrained and that ties in with a few of the questions. What about bigger initiatives? So, something that it's going to take more than one team, the coordination across teams.
Ryan Singer: Yep. Here's the thing. If you want to do something big and you just define a giant thing that's going to take six months or a year, nobody's going to actually be clear on what they're doing until they start to feel the deadline. So, you're going to get six months away. You're going to get six weeks away, more or less from the six months deadline and all of a sudden everybody's going to start going into hyperdrive, staying up late and working late and it's going to be chaos, right? Because nobody had a clear pressure of what done looked like at the right scale. The thing is you can't just go build something giant. You need to decompose and this is what design is all about. You have to decompose the problem into orthogonal parts into parts where you have these parts are interdependent. These parts are interdependent. Let's separate those into separate definitions of done. Right? So, what we have to do is we have to take this giant hairball of work, follow the interdependencies. Find what we can, I'm sorry, orthogonalizes or factor or decompose. Right? Find your word that works for you. But it's an analytical process of looking at the dependencies in the work to be done and defining the entire thing. If we finish this, this is a piece we can understand. It's a piece we can shape and having understood this and shaped it and defined it. And given it six weeks, we are very confident at the end of six weeks, that thing will be done. So, what we want to do is we want to do that over and over again. And we might have to have some of a larger macro appetite in the sense of like, we might have to do dedicate, let's say four or five cycles to this big effort. Right? But the thing is already in the first six weeks, we're probably going to discover the things didn't work out the way we thought. Right? And what we wanted to be able to do then is on a rolling six week basis, adjust our planning of what is the next thing we're going to build or how are we going to redefine the problem so that we have the sense that we're going to be working on this big thing but we're always taking spoonful that fit into our mouths. We're taking problems we can understand that are tractable and we're setting boundaries that we can make trade-offs with then so that we actually succeed as we move along.
Rory Madden: And I guess you've touched on it there. How often are you wrong in your bets and by wrong, so wrong is probably not the right word, but you said it's going to take six weeks. It takes four or it takes eight like I know as you were saying you don't automatically renew, but how often are you not correct. So, it could be short or it could be long?
Ryan Singer: Yeah. So, first of all, Parkinson's law or you've all probably heard about work is never short and it doesn't matter if it's short because remember this was an appetite, not an estimate. The appetite was the question of strategically, is this worth the resources? If this was worth to the business six weeks and it only costs four weeks. It's still worth six weeks to the business, right? So, that's not a problem. This is about business value, right? When we talk about appetite. When it comes to things going over, we've had cases where we thought it was going to be six weeks. We get to the end of the six weeks and it's not done. For us, this is quite rare. I can think of maybe three cases in the last three years it was really, really not done at the end because we have quite a bit of experience with this shaping which allows us to hit the target pretty well but it definitely happens from time to time. The main difference if we're at the end of the time and the work is not done, this is actually where the Hill chart came from. So, you can look into the book to see what the Hill chart is. The question is, are there things that are not finished that we don't understand or are there things that are not finished that we completely understand? And we just have to tighten screws. This is like, if you're building an Ikea piece of furniture that difference when you have all the pieces on the floor and you're holding your head and you're like, "How in the world is this going to come together?" Versus when you have like three holes left and you're holding three screws in your hand and you're like, "Okay, I'm not worried about this at all." Right? If we get into a situation where we actually see the three holes that we're holding, the three screws then we're very likely to reinvest. And at the next betting table, we'll say, "Okay, we're going to give two weeks of the next cycle to finishing that work because we understand it. If the table is standing but there's a piece of wood lying on the floor because there's something we don't understand. And we would rather deal with that on the shaping track, outside of the building cycles, we're going to troubleshoot that or if it's worth it and figure out what is it that we're not understanding here so that when we do invest more time that it's going to be meaningful. But I can tell you for sure. We had two or three projects that we just completely abandoned because they didn't happen in the amount of time. And I have never regretted that every time we've pulled the circuit breaker, it has always felt like a relief because we freed ourselves of something stupid that we were doing something that we didn't understand that was too tangled up or didn't have a well thought out concept.
Rory Madden: That's great, great example. I've been in that experience before of actually cutting something, cutting your losses. It's painful at the time I found because you've invested so much, but it is the right decision.
Ryan Singer: Yeah. And when it's seen as the context around it, that look this was a bet from the beginning, there was always risk in it. Then it's not the team's failure necessarily and we can also do a debrief to say, was this a shaping issue? Was this a performance issue? Was there some random, very unexpected thing that got in the way? Like we can have very productive conversations that help us learn when this happens.
Rory Madden: Great. Well, I'd like to thank you for joining us today. It's always good. I always like hearing different opinions when everything is all just a bit too same, it can get a bit worrying. So, I really enjoyed hearing just a little bit of a different opinion on how teams should be working in and shaping collaborating. So, thanks very much for joining us today, Ryan.
Ryan Singer: Yeah. Happy to do it. For those who still have questions, please check out the book. I think you'll find a lot of answers there and you can also find me on Twitter, @RJs on Twitter and you can DM me there, whatever. I can answer some things.