Fixed Time, Variable Scope in the Shape Up Methodology - Ryan Singer

Nice to be here. Thanks for having me. The title might sound a little bit technical or niche, Fixed Time Variable Scope in the Shape-Up Methodology. You might not have heard of Fixed Time Variable Scope before. You also might not have heard of Shape-Up before. But don't worry, because the real topic of the talk is two things that we deal with all the time, time and scope. And the different types of difficulties we get into, especially when they don't match, when they don't fit, when we have some kind of contradiction between them, okay? So that means, of course, all the things that I don't have to tell you about, like projects running long, things blowing up that we thought were going to be simple, all kinds of stuff like that, right? And what I want to do is kind of, this talk isn't about like how you can adopt ShapeUp or how you can adopt a methodology or something like that. I want this talk to be more about like some basic truths, you know? And then some language and tools that you can take away, like stuff that you could start talking about and using immediately after this talk today and immediately in your work, like little pieces of things that you can use right away. So first of all, I just want to establish some very simple definitions. I saw that Rich Hickey gave a talk once at an ETE, and he's like my talk hero. He always starts talks with definitions and stuff like that. So it's part of the tradition here. So about time. When I say time here, what I want to talk about is project time. This can be very different depending on how your team runs or how your company runs. Some folks have actual hard fixed deadlines, this project needs to be finished in three weeks. It was designed to happen in three weeks, and then it's going to ship, and it's going to be finished, right? Maybe that's more rare. More often is, you know, we're going to chip away at something, sprint after sprint after sprint. And in theory, at some point, it should be done when somebody starts to get angry enough, you know? Like if the salesperson or some executive starts to, like, beat the drum, and you say, oh, okay, apparently the time is ending, right, for this thing, you know? So it depends on the structure that we're in. If we have this kind of very clear, let's say explicit box from the beginning, or if it's more of an implicit thing, like yeah, we're working two weeks at a time, but I kind of can feel that after three cycles, it's going to be too much for this thing. So whatever it is, take a moment to kind of think for yourself, what environment are you in? What does that feel like? When can you feel the end of the time? That should always be there, this kind of checkered flag at the end. There's this sense of whether it's implicit or explicit, there is an end to the time. So we're going to be talking about this time box a lot. And then the other main concept we're going to talk about here is scope. And we're going to think of scope very simply as what goes into the box. So there's something that we want to do. There's some stuff that we want to be done. We agreed that that's what we're going to do, and we're going to put it into the box, and if the scope fits inside of the box, then we get to have a party, right? Because what we said was going to happen actually was possible, and some time went by, and then what we promised actually happened, right? Maybe this doesn't happen often enough, but this is the reason for talking about any of this stuff, is because that's actually what we want. You know, this is the reason why I ended up writing this book, Shape Up, was because after all these years of iterating at base camp, we kind of got into this rhythm where we were actually finishing stuff, like over and over and over again, even hard stuff. And it just feels so good, you know, to say, like, we're going to do that thing. And everyone says, that thing? And we say, yes. And when will we be done? On this date. We say, really? Yes. And then we reach that date and we go, like, wonderful, we shipped. It's fantastic. That's what we want, right? But of course, it's not happening. There's so many cases where that's not happening. And if it was a side project, if it was just a technical issue, then we could say, well, you know, it's like that. But the place where it becomes difficult is on the human level because we have those conflicting expectations, right? Somebody's pissed off. Somebody's exhausted. You know, somebody's frustrated. We're not happy if we're responsible for it when projects drag on and on and on. And there's the aspect of things taking too long, of course. But if they took long and in the end we got to a fantastic result, then you say, well, that's the price you pay. But very often they take too long and in the end we're not satisfied, right? And maybe you are in a situation, I see a lot of teams where they manage in the end to get something good out, but there was so much babysitting along the way. You know, so much intervention, jumping in, course correcting, making sure that somebody's unblocked. So much work just to get there, right? And then this can be exhausting, and it also becomes a bottleneck. So I don't need to tell you about these kind of problems all day. I think you know about these things. What I want to do is start to give some perspective now. If we look in terms of this picture of scope and time, why is this happening again and again? And what are some real practical things that we can actually do about it to get different results? The number one cause of missed expectations, of things going differently than we expected, of conflicts and problems inside of a project, are the things that we don't talk about, are the unknowns. All of our processes are based on this assumption that we have perfect knowledge. We are going to write the tickets. And if we do the tickets, then the work will be done, right? And if we had perfect knowledge, and we knew what to put in all of the tickets, or how to define the work, then there would be no problem. And we know this from our experience, because all of us can successfully make breakfast. You know? You have a fixed time box. There is a certain amount of time that I need to eat if I'm going to have breakfast today before I have to be somewhere or do something. And I know exactly how to do it. I can accomplish that, I promise you. I will manage to eat breakfast. And it's because we have a knowledge of how to do it, how the things go together, what we can and cannot do, how long everything takes, so we can successfully manage our breakfast. But the difficulty comes when What we're trying to do is something that we haven't done a million times before, something that we don't have perfect knowledge of. And when we're in that situation, this model of the hill is a really useful mental tool, because it highlights how there's two very different kinds of work when we're doing something that we haven't done before. There's first this what we call uphill phase of figuring out, well, what is it that I actually need to do here? Imagine like when you first open the IKEA box. There's this moment of like, you're not immediately connecting things. There's a little bit like, what is this? And then you kind of get oriented and you're like, aha, okay, now I know. And then once we know what we need to do, once we've done the learning, answered the unknowns, figured out what's going on, what our approach is, then we say, aha, now it's execution. And then it's easy. Then we have this just work of going, the downhill work of doing it. And the contrasting example I like to use is if, if I'm going to have like a special dinner party. And I want to cook, let's say I want to cook Indian food, and I've never done it before. So I want this to be a special night, and I want to do something unusual. So I'm not going to cook the thing I've cooked a million times. So the uphill work is I'm looking at YouTube videos of how to cook different kinds of curry or something. Or I'm looking on my Google map to figure out where is the place where I can buy this weird spice that I've never used before that's in this recipe, and I don't even know what it is. I've chosen the thing that I'm going to make. I have my little list of like this is what I need to buy. I have the Google pen of like where I need to go to buy it, right? And I have the time box of this is when the dinner is, this is the amount of time I have to cook, this is how long the recipe takes, right? And when I've done all that work to get that information, then when the day comes, there's probably still going to be some surprises, but the chances are pretty high that I'll be serving some food that night. Because I did the uphill work. Because I recognized that there were all of those unknowns. I knew they had to be solved. And I really treated that time box as a real thing that I need to be prepared for. So if we take that kind of mentality of cooking the special dinner, and if we looked at our normal projects through that lens, then we could say, well, in an ideal world, or you could say, in theory, this is how all of our projects should be. We have a time when it's supposed to happen, this number of weeks or this period when the capacity is going to be available and the cycle is going to start. And there's some kind of work that we're going to do to figure out how is this feature going to work, or how is this implementation going to fit together, or what APIs and libraries are we using, or whatever. We could figure it out, get to the point where it's time to kick off, and then it should just be downhill. But more often, even though in theory this should be possible, that's not what happens, right? Our hill, our downhill ride, which should kind of be so easy inside of the time box, is instead becomes like this, well, like this kind of pit or hole, you know, where instead of just sliding down, you see there's something, something went wrong, and now we are, And we're out of time, right? Of course, it usually doesn't just happen once. You know, we extend, right? Okay, well, a bunch of things came up, but now we know. Now we understand, you know? And we give it another window of time, a new box of time. But then, again, we hit something we didn't expect, right? And then we have to give it another extension. And we've had, this is, of course, when we're scrambling, when we're rushed to make trade-offs, when all these quality problems are appearing, right? Why are these unknowns appearing? Where are they coming from? Are they just intrinsic to software development or something like that? We do not need to take the view that this is just how it is. There is a cause and effect going on here. And the cause and effect relationship, we can use a word for it. We can say that all of these different blowups that happened inside of the time box They were actually planted in the uphill phase. These were time bombs. They were questions we didn't ask, people we didn't talk to, work that we didn't do, and then it blew up in our faces later. So how do these time bombs get planted? Where do they come from? I'm gonna give just a couple examples that you might be able to relate to. It's about how we do this uphill work. So the uphill work can look different depending on how your team runs. One example might look like this. So you have the artist who produces the grand Figma file, and everything has been solved. It's all here. Just look at the Figma file. It's all there. And we have a pixel perfect specification, but it's of the surface. And if we want to know what that Figma file actually means in terms of implementation, then we have to look at it with our x-ray glasses. And we have to figure out what are all of the assumptions behind there? And what does it actually mean? And what is the behavior that it's supposed to be implying? And is it actually technically possible? And of course, those considerations weren't made when that Figma file was drawn. we have a lot of unknowns, things that we couldn't see because they weren't there in the work. They weren't answered, right? So we're finding out, oh, we can't build it the way that they thought because it turns out we have a technical constraint, or we use different libraries, right? Or it looks pretty, but we don't actually know what it means in terms of a certain edge case, right? Or this is way more complicated than it looked on the surface, those kind of problems. The other case that can happen, I just realized I blew through a slide there, is kind of the opposite case where instead of the perfectly detailed pixel perfect design, we kind of don't get enough. It's like a business person or a sales person is saying, these customers want it, and these customers want it, and these customers also want it. And here's a graph showing how many people have been asking for it for this long. And it's going to be fast, and it's going to be easy, and it's going to be very powerful. And you're like, okay, but what is it? And it's three bullet points of what this feature is supposed to do. It's the business requirement. It's the outcome. Now, those things are valuable. In fact, they're critical, and they're really important when we're framing a project to figure out what are we putting our time into. The business outcome that we want is essential, but it's not uphill work. It's not telling us what to go build. It's not helping us to understand what are the unknowns that are going to blow up in our faces, right? Because we don't actually know what the work is, right? And then there's this idea that we are going to do some kind of discovery after the cycle starts, which means what? Like we're going to somehow figure it out, but it's much too late for that, right? So of course, we're getting blowups inside of the time box. In all these cases, and of course, by the way, I didn't draw it, but there is, you know, we have a lot of technical people here. We are guilty too, right? Because we have the architect, you know? And the architect is like, of course, no problem. The API call, we'll talk to this service, and then this service will call this service, and we will get all the information we need, and it will work, right? And then there are so many technical constraints and realities underneath those nice big boxes in the diagram, right? So this kind of thing about shaping too high or being too fuzzy with what the work is, it can happen in many forms, right? In all these different cases, this work happens to sort of figure out what the scope is. And then we reach that point which kind of should be the top of the hill where a commitment gets made. Where we say, okay, the clock is gonna start and the Figma file is locked. Or the sales person said, this has to be the thing that we build now, so we said yes to it. So we end up agreeing to some scope, but we don't actually understand what's really in there. And it's like signing a contract, but you didn't talk to a lawyer and you don't really know what it says. So then some surprises appear later on. And effectively what happens here, this is kind of the typical picture of how time and scope relate to each other, is not out of intention, but just out of the normal realities of normal life. The scope kind of gets fixed and the time becomes variable, right? And this is implicit whenever someone says, can you give an estimate for this? Because if we're estimating something, it means the scope has already been decided. All we get to do is put a number on it. So the time is variable. Now, when we talk about fixed time variable scope, that's the opposite situation. So let's get into a different way of doing things in a different perspective. So the other way of doing things is to flip this around and say, all of the problems happen. when we said we were going to do something by a certain day and we didn't get there. So how about we start with time? How about we start by saying the time is going to be fixed. This is our appetite for how much we're willing to invest in this rather than just estimating a piece of work. And now viewing it as a design problem of what can we do given that time? So that means varying the scope so it fits into the box. So when we talk about fixed time variable scope, it means we're doing the work on the uphill part before the clock starts ticking, before the time box begins to figure out what actually goes into the box, what's going to fit. I want to highlight one thing in case there's anyone here. Are there any folks here who are already kind of no shape up or have read the book or something like that? Yeah, quite a few. So sometimes people have this kind of misunderstanding, which is probably my fault of how I explained it in the book. They get this idea that fixed time variable scope means the project is going to ship after six weeks, and it's your responsibility to vary the scope so that we get there, which is a very cruel thing to tell a team because they know that the real scope didn't change. The outcome that people want, the business reason we're doing this, the pressures we're under, none of those real things changed. and now I'm also supposed to somehow be cutting things, so this is going to happen, that's a recipe for disaster, right? We're going to come back to what it means to vary scope inside of the time box, but what I really want to highlight here is that the main, the real time when we can vary scope is before kickoff. That's when fixed time variable scope happens. It means design, actually. It means making trade-offs before we make the commitment. So let's look at what that actually looks like. This thing where we fix a time and then vary the scope to figure out what can fit into the box, this we call shaping. So we're shaping the scope so it fits into the box. It fits into the time. And if we have a notion of the amount of time that we strategically want to spend first, and this we could call an appetite. You know, this is like shape-up lingo. But actually, you don't need this word appetite merely having the idea that we have a fixed amount of time we want to work within and then trying to work with scope. This is everything, actually. And maybe we could say, what could we accomplish in this many weeks? Well, if we extend it and we gave it more time, what could we accomplish, right? But the key thing is that we are fixing the time and then doing design. And to vary the scope, we're adding and removing things from the box one by one we're not doing a giant design and then trying to look at it with our x-ray glasses to understand what's inside and what's behind it we're putting things that we understand together one by one if I make this call to this service that I've used before in this framework using this pattern that I've used before and I'm going to get this data in this data structure that I know very well And I'm going to modify it using this transformation that I've done 100 times. I'm going to do this, this, this, and this. I know how long that takes, and I know what the result is. It's fun, by the way, to talk about this stuff with the technical crowd. Do you know what I mean? Because it's really a technical thing. How do things work? What do I understand? How can I put pieces together? It's one by one by one putting the pieces in. So, let me give you just a quick example of two real life projects so that you can get a sense of what this looks like in practice. So, the classic example I like to give just because it's very easy to relate to is this project to build a calendar that we did at Basecamp some years ago. We had a version of Basecamp in the past that had a very feature complete calendar. I would say we were not very thrilled about that project because we put so much work into a lot of really complicated interactions. I mean, calendars are complicated, and in the end, there wasn't really a lot of usage, and it didn't feel like that was the best use of so much of our time to get there. So, we were on a further iteration of the product. I think it was version three of Basecamp, and the question came up, should we build a calendar? And we said, not again. But then the support requests kept coming, and the feature requests kept coming, and eventually it was like, well, we don't want to build a calendar, but maybe we could build a calendar. There's probably something we could build that's inside of our appetite that we'd be willing to spend time on that could scratch the itch for the people who keep asking us for this, right? It can be a high fidelity dragging and dropping interactions. It can be a time zone stuff of a million kinds. It can be so many things, and month views, and day views, and year views, and everything, right? So the question is, if we're willing to invest six weeks into this, and really not more. So here you see this empty time box sitting there, right, to be filled. We're willing to give six weeks to this thing so we can satisfy that we are answering customers, right? But we don't want to spend more. So out of all of these things that a calendar could be, what are the things that we could say are out, and what are the things that we could say are in? What is the kind of functionality that we could put together that would be useful? And we did some customer interviews, and there's a whole aspect of this that I'm not talking about today, which is kind of the, let's say, the framing side of what really is the problem and what would scratch the itch. And we did that work and we found out that, you know, people aren't looking for a fully functional calendar. They are inside a project management tool and it's more just about communicating some very important days, you know, pertaining to the project, you know. So we came up with an idea that we could get away with a very simple kind of two-month view with some dots in it. and an agenda list underneath. And we wouldn't have a lot of those complicated interactions, and it would be enough for these customers who were asking. So we came up with this sketch, and it kind of felt reasonable. And if we now look at what are the pieces that we're talking about here, there's this two-up grid with just dots. We don't have things that span multiple days or anything, just dots. And we drew it up, and we talked to each other, and we asked some hard technical questions. And then we come to a point where this uphill work feels like it's done. And lo and behold, we put it into the box, we executed it, and we were able to celebrate, because after six weeks, we shipped the thing. So all of that work, yes, there were a lot of nice little judgment calls along the way to prevent the scope from getting out of control, because scope is always It's the nature of scope. They say gravity gravitates and scope grows. Scope creeps. That's just what it does, right? So there is also an aspect of kind of fighting back. But man, if we don't put the right stuff in the box to begin with, good luck, right? Most of it is what we put into the box. Here's another example. A lot like saying we need a calendar. I was working on a project where the leadership said, we need notifications. They wanted push notifications. And this was for a really big web-based private intranet with thousands of users, hundreds of microsites, a ton of surface area. There was no native app. And the mobile views were kind of there, but pretty rough. And so basically asking for native push notifications meant Well, how are we going to turn this giant web monster into a native app? And of course, the project sat for 18 months without any kind of progress because nobody knew how to start, right? So I came in and I asked the question, is there something we could do in a time box of less than six weeks? Is there something we could do that would be meaningful, right? And the question was like, why are you asking for notifications? You say notifications, like what is actually going on? And we did this framing work, and I had some conversations. And what we figured out was, actually, there was an old mailing list that they really needed to turn off. There was an old mailing list, and it wasn't part of the identity system and the SSO. And so all of these really important announcements were going on this kind of uncontrolled, unsecured list. And you've probably seen these kind of legacy situations, right? And it's like, if we could just have notifications on the internet, then we could send it through there, and we could turn off the list. And you say, ah, so this is about turning off an email list, right? So with this as our outcome, as our kind of checkered flag, you said, haha, maybe there's something we could do in less than six weeks or even shorter about that. And what we ended up shaping was a few simple pieces. First, this notion of we're going to allow you to kind of follow or unfollow one of these major kind of entities inside of this giant intranet. So I care about updates from this thing or not. We're going to build a new kind of global news feed, which aggregates those updates of things you follow. We're going to send email notifications if something happens, because what we're fighting against, what we're substituting, is email. We are going to do mobile-friendly detail pages for the updates you land on if you click through the email, because people are probably reading their email on their phone. And we're going to have to have some kind of a way to unfollow everything or unsubscribe or something like that. And we're looking at these things and we're like, I think this is enough. I think this is something we understand and that we can do. Of course, when we talk about what's in the box, a big part of this, even maybe the bigger part, is what's out of the box, right? And making that explicit is also very helpful. So what was out was we didn't need a native app to do this. We didn't need to have notifications about things that weren't news. because this mailing list they were trying to turn off could kind of be interpreted as, it could be implemented as news. We don't need any kind of like notification preference setting mission control thing that was going to become a scope nightmare. And we don't need to have any mobile views, even in the web, for things that aren't news related. We don't need to improve any of that stuff, right? So you can feel the walls, right, of what we don't have to touch. In this case, we kind of laid that out. And we're still in our uphill phase. We're not ready to commit. And we're saying, yeah, but are there any time bombs here? And this is a really critical part of shaping. It's not only what we choose to put in, but it's also having the technical people there before the commitment is made to say, what could blow up? What do I not know? What have I not done? What have I not seen before? It's not that we have to have a crystal ball, but of course the more experienced people are like the good old grumpy plumber who's seen everything. You invite the plumber in and you say, we need to redo the pipes in the bathroom, and of course he says, yeah, but okay, we need to put a hole in the wall. I need to look at what's behind there before I give you a price. So it means some spiking. It means looking a little bit into the existing systems. So we took a look. behind the walls at the existing systems, and we found some worrying factors. So when it comes to this follow and unfollow feature, well, it meant that a bunch of very different data types all had to quack the same way. And will we be able to do that for all of them? We had to talk to some back-end people about that. When it comes to email notifications, sending an email sounds easy, but if your system has only sent transactional email once in a while when somebody needs to recover a password, and now you want to send tens of thousands of emails all simultaneously, maybe we have to talk to somebody about that. And even just making the mobile friendly news page, it turned out that the old Web views had been made using kind of a slightly funky framework, and the people doing the new work didn't know the old framework, and they had their own CSS framework. You know what I mean, these things? Yeah. But all these things had answers, right? And we were able to make trade-offs, and we were able to diffuse those time bombs, right? And get to a point where we said, yeah, okay, we understand this work. And we put it in the box, and we were able to finish the project on time. And more than that, Since we had put kind of the architecture in, now we had a kind of natural path in the system for what a notification is, even though it was an email. Right now, we're actually shaping a native version of this app. And it's using all of those kind of same pieces. And it's mostly using web views and hybrid views and stuff like that. And the path became so much shorter to actually having a native app that does notifications. I'm not only talking about kind of single projects here, right? It's also about how does this then enable us to do the next thing, right? Okay, so that is the first most important aspect of fixed time variable scope that I wanted to tell you about today. It's what happens in the uphill phase. It's what happens before kickoff, before we make a commitment. It's when we're choosing what goes in and out of the scope so it fits the box, okay? There's a second kind, and this second kind is also really important. The thing is, what we're talking about here, in a way, is upfront design. We're talking about making more decisions in advance. As soon as we start talking about upfront design, especially among engineers, probably your hair is standing up a little bit, and especially if you manage, your hair should be standing up, because you say, my engineers are going to kill me. The last thing they want is for me to tell them, I have solved everything, and here's what you should build. Right? Nobody wants that. Yeah? But of course, at the same time, nobody wants to be told, here's a project that's going to blow up in your face. Right? Or here's a project, and we don't really know what we're asking you to do. Right? They also don't want that. So we don't want to be micromanaging. We don't want to be telling senior people how to make decisions that they could better make themselves. We don't want to be telling designers and everybody. We want to have that creative freedom. So this second aspect of fixed time variable scope is something we can call latitude. And it happens in the downhill phase. So we have a choice of how much we spell out things on every single project. So we can decide that this is something we've understood, we've looked at, that is doable. But we're not going to say, here is the schema. Do you know what I mean? Or here is the implementation approach. We're going to say, we are very sure, because we've done the upfront work, that this is a realistic thing. We are very clear about what it is and what it's not. And please be creative and find the best way to go about doing that. So when it comes to latitude, There's a lot of different kind of practical things just in terms of what does it look like to kind of turn that latitude dial. So this, in terms of the interface, in terms of the product design, this is like rough sketch versus a Figma file, or this is a breadboard instead of a wireframe. In a more technical case, this is like I could specify a data model, we could work out what the data model has to be, or we could more describe the behavior that we want to happen at certain interfaces and then work backwards and then give the team much more room to figure out what the best model is. Those are all decisions that can be made. The thing that's really important about all this is that there isn't This is a misconception that I created with how I wrote the book also. The book makes it seem like a rough sketch is objectively better than a detailed wireframe or something like that because it has more latitude. But the thing is that whether more latitude is good or more latitude is bad depends on who you're giving the work to and what the work is. So if you have a very junior engineer, less latitude is actually better for them because they're going to be able to make more progress, right? If you give them too much latitude, they're not going to be able to succeed. But if you give less latitude to a senior engineer, then they're going to say, come on, you're treating me like a child. I can do this much better than you, right? So who we're giving the work to. The other thing is that independent of junior, senior, there are different people who have more skill or knowledge in different areas. You know what I mean? So there's the person who knows everything about this gnarly backend area. There's this person who knows all about the accounting system. There's this person that can do really gnarly JavaScript interaction stuff. People have different areas of strength and different things that they know better. So the question about what is the right latitude when we're shaping is all about the people and the people on this particular project. It's a matching problem. Who's working on it? Have they done it before? Have we worked together before? Do we know each other? Do we understand each other? Which areas are they stronger in? And what's a time bomb for them, right? There's an objective time bomb, but what's something that's gonna blow up for them as opposed to somebody else? This is good also to think about because sometimes you'll see people get interested in shape-up, and then you'll have like a kind of a CTO kind of person do shaping. And the CTO's view, And maybe they were there when a lot of the old tech debt was first written. The CTO's view is very different from the person who just got hired four weeks ago. The CTO knows where all the bodies are buried. And the person who just came in is going to stumble on all those things and burn a lot of time. So we have very different perspectives on the same objective system. So that's a little bit about latitude. kind of depends on the person and the project and your experience and their experience. It might not be so easy to answer the question of, well, what should I give people? If it depends so much, then what do I do? There's a really helpful exercise that I'm going to give to you right now that you can do at kickoff. And this is something that you can do no matter what process you use. Everybody has a kickoff moment. no matter how you work. This is something that you can do in half a day. So this is the structured kickoff exercise. What this does is it turns the one-way communication of like, here's the work, any questions, into a two-way communication. You're going to see what that really means. But basically, it allows us to see inside the heads of the people who are taking over responsibility for the work before we kind of mutually agree that the clock really starts on the cycle. So how does this work? Five basic steps. Five easy steps. First step is, and these are performed by the technical team who is responsible in the time box. These steps are done by the person who's taking over the work. So the first step is, whatever we shaped, whether it's a Miro board or a fully written up kind of shape-up style package or whatever it is, they review that. Here's what we think we're asking you to do. Then the second thing is they take that time box. Maybe it was three weeks, maybe it's six weeks, maybe it's two weeks, whatever that time box is, and they just divide it into nine. They're going to look at everything that is in that shaped work. And they're going to detail what they imagine all the implementation tasks are. Of course, it's not going to be complete. There's going to be discovered tasks. There's going to be unknowns. But everything that they can think of based on their past knowledge that they're going to have to do, they're going to fill that out and factor it into nine boxes. So they're going to get to something like this. These boxes we call scopes. So there's nine scopes here. And imagine that this is a six-week project. Well, you divide six weeks by nine. Each of these boxes is not really more than a few days. This is something that you can look at, and you can look at what's in the box and say, is that really doable in less than four days? And if you're doing a two or a three-week time box, then you can really feel it. You know what I mean? Because you've only got 14 days. If you're scrum, you only have three days because you have so many meetings. You divide that by nine and that's the time in each box. If we were creating a whole bunch of tickets for this shape work, we might have 50 tickets. If you're in the middle of a piece of work and you say, where are we? You say, I don't know. These out of these 50 tickets are done. It's really hard to understand that. But if we say we have no more than nine things that we need to do, and yeah, we have some details about what they mean, then if we say, well, I got this one done, right? You say, ah, that thing is done. OK, we're getting somewhere, right? There's a bit of an art to this which can be learned, which is to make these scopes orthogonal from each other, to make them more like vertical slices and less like horizontal slices. kind of fun, I think it's fun stuff, I guess I'm a nerd, about how to factor the scopes. But I've been very surprised to see how many teams take this exercise and they don't do anything particularly strategic about how they do the nine scopes. And simply slicing it into nine boxes is a giant benefit. I've been very surprised to see that. So it kind of doesn't matter that much. to already get a really good feedback on how you're doing. So they've taken everything that's in the work and they've done their best to represent it as nine major chunks. And the third step then is they have to ask themselves a question. Out of these nine, which one scares me the most? What are the ones out of these nine that I've never done before? What are the ones out of these nine that have something that makes my hair stand up? Or something I've seen before that is gnarly or I think is missing in what was shaped. Do you know what I mean? Where do I think as the builder the time bombs are? Even though in theory they've all been diffused. So here the builder who did this exercise marked these two as two things he was worried about. So then the fourth is now that we've narrowed it down to nine major chunks of work, we know which things are the riskiest. Now we ask them to sequence. What are the first three things that you think you should get done? The natural thing, especially for more junior developers, is to try and do the knowns first. Because it feels good to show that you can do stuff. But what we really want is to do the unknowns first, because we want anything that's going to blow up to blow up as early as possible so that we can adjust with the time that's left. The guidance here is to look at what you flagged as being the risky things, and prioritize those in the top of the first three scopes in your sequence. Yeah? Simple enough. So here we have a sequence of this is what the builder thought their approach should be. I'm going to do this, this, and then this. And then the fifth step is we look at it together. Now, the ones who were responsible for the shaping, if they were different, come together with whoever did the exercise, and now we have a really interesting conversation. The conversation isn't just a one-way thing of, we have figured it out and now we're going to clarify for you, but probably the shapers are going to hear about unknowns that they missed. Probably things are going to come up that we thought were obvious but are actually really unclear. Maybe there's going to be areas where the approach that the developer is going to take could be a lot simpler because the person who did the shaping says, oh, but we don't have to reinvent the wheel. We have a library we made for that five years ago or whatever. Do you know what I mean? So a lot of exchange, a lot of back and forth happens here. Yeah. Sorry, there was one other thing I wanted to tell you about, which is that a funny thing happens with this exercise. I talked to a few companies who adopted kind of shape-up type tools, and they did their first project. They shaped their first project, and then they brought it to the team, and they were about to start their first cycle, and they had the kickoff exercise, and they gave it to the team, and the team said to them, look, every box is like this long. I literally talked to a team a couple of weeks ago. They said, Our first six-week project was actually, we understood it was actually six six-week projects. That's a really, really good thing to find out on day zero. You know? And so, on the one side, this is about the relationship between you know, this kind of where the uphill meets the downhill and whoever was doing the shaping and then handing over that responsibility to the people who are going to be doing the building to answer this latitude question, right, of how much needs to be spelled out. But it actually goes beyond that because this is a way for us to have a map of the whole project, scope and time in one view. And it can be a really nice kind of instrument or like a measuring tool for us to understand how we shaped. How well does it fit the box? Were we able to put, did we put too little in, or did we put much too much in? And to have an instrument for that, that gives us that feedback on our shaping, is a very useful thing. OK. So that's what I wanted to share with you. To wrap up, let's look a little bit at what we talked about here. So there's some language here. Time bombs. as a way to understand unknowns that could have been avoided, that blow up in the time box. Uphill versus downhill work, different kinds of work. In a lot of organizations, only the downhill work is like tracked as real work. There's meetings and there's building, right? Uphill work is different. We're doing work where we're digging in, and we're actually answering technical questions, and we're making trade-offs, and we're figuring out what goes into the box. Shaping is the uphill aspect of figuring out how to vary the scope, what goes in and what's out, so that it's something that's doable, so that we can get to that moment where we actually celebrate together, because we met expectations that we set, right? And the latitude is, we just talked about, about how to open it up and leave more space, you know, so that the team has more creative input or more ability to decide about the solution, and also when to narrow that down when that's also constructive. So when to use all this stuff, there's two situations that I would kind of look for, you know. Everybody is so busy that you can't just kind of change the way that you work on any given day. But there are certain problems that are big enough that it starts to hurt everybody and everybody starts to say, can we do something here? One of them is if you really start to get into delivery problems that produce tension, where there starts to be finger pointing, where there starts to be conflict, we need this and we never get it from you and you're not performing, that kind of stuff. So if you start to see those kind of delivery problems escalating, then you could start to look into these tools. The other thing is that you might not see those delivery problems escalating because you're so good at babysitting, right? If you're really good at jumping in at the right moment and rescuing the team all the time, then it can feel like things are working. But what you'll notice is that when you start to have new ambitions, like you want to be more strategic or you want to take on more responsibility, you never have the time. So if you get into a situation where you're trying to kind of move up yourself, but you seem to always be busy in the weeds, then this is a good signal. How to start. If you get into that, if you see those situations coming and you want to do something differently, what can you do? You do not have to go adopt Shape-Up. Please don't become a, by the book, dogmatist. It's much better to start using the language. to talk together and get some clarity around what's blowing up, what are we missing, what's not working. And this structured kickoff is something that you can do on a single project right in the kickoff you already have and say, we're just going to try this this one time. And you'll get a lot of feedback on kind of where the mismatches are. And then if you want, if you think it would be meaningful, then you can start to go deeper into the shaping toolkit and stuff like that. And when it comes to going deeper, most important is to think in terms of tools and not in terms of process. There are special moments when a company wants to overhaul their process, but basically never. It's really rare. But there's always an opportunity to reach for a new tool in a moment where we might be able to do a certain step better. So, think of the book as a box full of tools and maybe I could take this and maybe I could take that. Then there's also the shaping in real life course where you can get more of this, really get these different tools in your hands and understand how they fit together. There's my website, feltpresence.com. And actually, also, I really like to hear from you. So if you have questions, if you're just interested in this stuff, write me on LinkedIn, write me an email, all that's on the website. Because I just love learning about what's really happening with people with this stuff. This exchange is actually where a lot of this happens. And we have a really cool alumni network growing now of people who have been through the course. It's amazing to share experience like that. So that's all. That's what I wanted to share with you. And we have like 10 minutes for questions. I hoped we would have a little bit more, but maybe we can also chat in the hall later or something like that. So thank you very much. So I'm sure you're familiar with Agile and Scrum sprints and sprint planning and backlog refinement and grooming stories and getting to your definition of ready and definition of done. stuff probably most of us do all the time. Yeah. And a lot of what you're talking about here has a lot of similar in that. But can you maybe just talk about how your process kind of relates to Agile and Scrum practices and how it differs and when you'd use one or the other? Yeah, sure. Short answer is if what you're doing works, then you don't need any of this. And that's great. When I hear Scrum and Agile, I mainly think of Scrum because I kind of don't know what Agile means. And a lot of this is in the spirit of the original kind of Agile people and stuff like that. But Scrum is what you see in practice. And when I think of Scrum, I mainly think of a kind of a process of dealing with tickets. We create a bunch of tickets, we put them in a stack, and then we do them for a couple of weeks, and then we create a new pile of tickets, and then we do them for a couple of weeks like that. Tickets are really, really good for urgent work that can't wait. That's why all help support platforms, all customer support platforms are ticket-based. So there's always a place for tickets when there's a fire burning on the other side of that ticket. And that's why you have to track the status of that ticket and is it still waiting or not because there's somebody that it's burning on the other side. If you're trying to do a whole project though and you specify it as a set of tickets that are all going to be done independently, I call this the paper shredder. The idea is that we take one whole thought out thing and we shred it into tickets. And we hope that somebody's going to be able to put all those little pieces back together again, and it's going to look like it did in the beginning. And what we see is that it's really, really difficult to succeed in that because there's a lot of context between tickets. I'm doing this ticket because of that ticket. Or these three tickets, they add up into one thing that has to be reviewed together, but then we're going to have to make a decision about how to change something else. So the kind of ticket approach to doing project work doesn't take interdependencies into account. So it can more easily happen that you get into a lot of these time bomb kind of things, because there's so many cracks between the tickets, or there's a lot of missing context. So that's some kind of short. So in terms of the uphill versus the downhill work, if we focus on the uphill two-part question, one is, what would you envision would be the type of staff that would be most heavily involved on the uphill side and um and then in terms of if you have a six weeks for your downhill in your practical experience how much of that you know if you have a six week downhill how much would you have in the uphill to plan for that in terms of you know real life experience that type of thing um there's very different kinds of projects you know there's the um let's say uh let's pick some extremes like You're a company that builds WordPress websites, and you're building the 500th WordPress website. You can shape it in a one, two-hour session, and you know what you're going to do. There's the new feature that customers want, that sales wants us to build, but it's not going to be exposed to that many people, and we think we understand it pretty well. Maybe we could shape that in three sessions. There's the major critical new feature that is a little bit of a science project because we don't feel we understand it, but we know we have to do something to be more competitive in that area. Might be a year-long strategy effort to really frame it and understand what the problem is and go down different paths and come to a place where we say, ah, this is what we should do, and then invest a few cycles in building it. It's always a question of looking at the work and what does the work need. And that hill is going to be taller or shorter depending on that context that we're in. And then in terms of who to put together to do it, a big source of time bombs is when the person who defined the work didn't understand all the aspects of the work. So if a designer does it and they don't understand the technical reality of building it, and there's going to be a lot of problems. Or a builder alone does it and they don't have input from product or an experienced person, and somebody in leadership cares about the experience and then something has to get changed later. So it's about kind of understanding who knows things that need to be known in order for us to do this well, and then bringing those people together for that uphill work. Thanks. Thank you. So how close or how far is this from the waterfall technique? I don't know what waterfall means because I don't think anybody does what people were reacting to when all the agile people were spooked about waterfall. When the agile people started talking about how bad waterfall was, it was the 90s. And you had spec books like this, you know? And we're talking about like doing design upfront on a six week project or a three week project. I mean, so I think if you are spooked by waterfall, you know, then you're not suffering enough. Because if you still believe that we can just make it up as we go two weeks at a time forever, you know, then probably you're at a fat and happy company. or a lazy company or something like that, and you don't need to perform. But as soon as you start to feel that pressure of like, oh, we actually have to get something done that works by this date, you'll realize like, oh, we have to think about what we do first. We have to plan the dinner. I can't just let the whole dinner guests, they can't all show up, and now I'm going to start watching YouTube videos about what to cook. I think it's just cause and effect. But if we're not under pressure, then it's fine. I hope you don't mind. I don't mean to be too salty about the waterfall thing. It's just that there's a lot of overreaction about that word in the agile circles, so I'd push back a little bit. If you have simultaneous shapes going on, is it important, do you think, to have them be exactly concurrent? Do the time boxes have to overlap exactly? So in terms of the cause and effect of things, You know, you have some capacity that's opening up where somebody needs work. You have a mouth to feed, right? So that's downhill work that you need to go uphill in order to provide. Now, how that capacity comes to you, like when is that next window or when is that next kind of hungry mouth coming to you where you have to give them work? We have to talk about what's going on in the company. There's so many differences there. There are companies who decide that for certain kinds of efficiency, they want all of the teams to be on the same cadence, so they feed all the mouths at the same time. This is how Basecamp ran. They wanted every team to show up ready for new work at the same time, and that allowed leadership to operate on a certain schedule. But that assumes a lot of orthogonality of all the teams. It assumes that all the teams are fully independent and they can all finish at the same time because they're not waiting on each other for things. And if you're in a situation where you have different teams who are waiting on each other for different things or somebody suddenly becomes free because they're blocked, then you have this situation where all of a sudden I need to have some work ready for someone and you need to be able to kind of jump around more. So this depends very much on the setup. One more maybe? Thank you. I really loved your talk. I personally sympathize with a lot of this, unfortunately. But two questions. One, mainly around the number of scopes that you had mentioned. You mentioned no more than nine. Any reason behind that specific number? And one thing that I think really, really resonated with me, the idea of how much information you're giving to your engineers. You don't want to necessarily spoon feed them, but at the same time, you don't want to not give them. you don't want to give them nothing, right? So how do you find that balance, like that sweet spot? Is that more along the lines of the people you have, or is there an exact amount of information you know that will just work? This is, you loop through it with the people, and it's a relationship with each person. And if you do this exercise, it gives you that feedback moment of like, okay, I have the work in my hand. and I'm imagining how they're going to react. And now I gave them the work, and it's four hours later, and they're showing me, like, this is how I understood it. And you're like, oh, really? Or you're like, yeah, totally. So that's a one-on-one thing between you and each person. And the way that you learn that is by looping through it. The reason for the number nine, the number nine isn't holy. It's kind of ten-ish. It's basically like this. I think of it as orders of magnitude. Like, you either have one thing, 10 things, or 100 things. One thing, you have a project. It's a time box, it's an investment, it's these people, it fits into the strategy of the company, and this, you know, it's one thing, it's the project. If you've got more than 10 things, you're already in some kind of, like, backlog list thing. You know what I mean? Like, if you've got 20 things, like, I don't know. You know what I mean? It's like a big pile of stuff. It might as well be 50, it might as well be 100. But if it's 10, then you look at 10 things and you're like, okay, I can kind of see them all. Then the other thing is that the scopes, they have this aspect of cutting the box into segments. If we've got six weeks and then we divide it by ten or nine or whatever, then that's a meaningful size, you know? If we divide it into two, it's kind of like too big and we can't understand what's in it, you know? So that's just, it's just kind of a weird, like, thing that seems to work. It's also like the six-week limit, you know? You can do shape-up with three weeks, you can do it with two weeks, with one week, you can do it with whatever. It's just that if the cycle gets longer than six weeks, nobody can understand what's in it anymore. and you can't feel the box enough to feel like it's too full. If you're talking about like 12 weeks, it's like, oh yeah, we could build a whole app in 12 weeks, sure. And then you're on like week seven and you're like, oh, no way. But with six, that's kind of the upper limit, I think, of this kind of horizon of what you can feel. I think that was all the time he had. Well, maybe we can do, we have a cocktail hour later, is that right? Yeah, at 5.15. Uh-huh. So feel free. I'll hang out at the cocktail hour for a little bit, and then we can chat also if you didn't have time here. Yeah. Thank you. Cool. Thanks a lot.

When Ryan singer published his book on the Shape Up methodology, he had certain aspirations for it’s adoption beyond the walls of Basecamp, where he was the Head of Strategy at the time. It’s safe to say that the industry’s reaction to Shape Up has exceeded those aspirations.

Five years’ worth of conversations and analysis with adopters in a diverse collection of organizations has brought clarity to the original message, as well as new thoughts on how to be most effective in the methodology, and how to produce the best answer on the first try.

Originally conceived by Ryan from the product side of the equation, he now offers a detailed look at what it means to adopt Shape Up as a technical practitioner, especially with how to translate “pitch + appetite” into a working solution.

__________________________________________________

About Ryan Singer
Ryan is the author of Shape Up and former Head of Strategy at 37signals. He has worked on every level of the software stack, from UI to code to product strategy. In 2021, he founded Felt Presence to help more companies stop running in circles and ship work that matters.

__________________________________________________

About the Conference
Entering its 18th year, Emerging Tech East (formerly Philly ETE) brings world-class speakers to speak about leading-edge technologies being used today, and emerging technologies that will be important for attendees to know about in the near future. Over the last two decades, ETE has become one of the premier gatherings of developers.

__________________________________________________

Powered By Chariot Solutions
ETE is hosted by Chariot Solutions, a software development consultancy.
 For over 20 years, companies of all sizes and industries have 
looked to Chariot as a partner to help them solve their toughest software challenges, and move their business forward. 

Are you a business looking to build and manage software solutions optimized for your unique needs? We're here to help. We’ll apply our strategic, high-touch approach and extensive tech experience to solve your most complex business problems. Reach out today. Visit us at https://chariotsolutions.com/

__________________________________________________

Sponsored by Lutron
Lutron is the worldwide leader in lighting, automated shade and temperature controls. From apartments to small office spaces to entire building complexes such as the New York Times Building and the Guggenheim Museum, Lutron is at the forefront of innovating IoT products for smart homes and connected buildings. Learn more at lutron.com.https://www.lutron.com/en-US/pages/default.aspx