Shaping the Work: Assigning Whole Projects, not Tasks - keynote by Ryan Singer #AgileIndia 2021

Welcome to our first keynote for the third day. We have none other than Ryan Singer with us. For those of you who have used Basecamp from 37signals, Ryan was part of the team of three that initially started creating Basecamp. He's been the integral part of the Basecamp team from then. uh and played over the 17 years played various different roles uh so someone who really uh you know has the credibility to talk about this subject and obviously he's put a lot of that wisdom in his new book called Shape Up and certainly if you've not read that book I would strongly recommend reading that book. His claim is that if this book will help you stop running in circles and ship things that really matter, ship work that really matters. So without too much delay I want to hand it over to Ryan and Take it away, Ryan. All right. Thanks a lot for that introduction and thanks for having me here. I'm very happy to join. And I even have a reasonable time zone overlap with India right now because I happen to be in Moscow. So that's very good. And hello, everyone. I'll tell you just a little bit of background behind the talk. So I've been working in the software industry for over 20 years now, and I've worked in actually all different layers of the stack from doing hands-on coding to a lot of user interface design. And I did that. I've done that for about for all of the 20 years. And then I've been working in product management and kind of leading the development process and working between programming and design and strategy for 12 years now. And then for the last six years, I've actually been focused very much on the strategy side and how to kind of decide and figure out what is important to do next and then get from a raw idea to something that actually ships and how to how to manage that, how to actually make that happen. And I started at Basecamp in 2003 with the team of three there. And over 17 years, when I was at the company, we went from three people to over 60 people and saw a lot of change and a lot of different challenges coming actually through those different phases of growth. And that informs kind of what I'm what I'm here to talk about today. And in 2019, I wrote a book called Shape Up, and it basically synthesizes a lot of the experiences that I had and things that I learned through all the different trial and error that we did over the years there. And let me just get this connected here. Very good. Okay. And what does this all have to do with you? So actually, if I look at what's going on in the industry today, I see a lot of, there's actually a very common, a clear pattern that stands out. You see, most software teams today are working in a kind of process where there's a lot of either tickets for engineers to work against or cards in some kind of a Kanban or a sprint-based system. So there's a lot of tickets and a lot of cards. And either there's a kind of ongoing stream of work that never ends of these tickets and cards and stories, or there's maybe chunking into two week sprints, which is also very common right now. And what you see is basically like there's an environment from the standpoint of the programmer where they constantly have a mix of different small issues that they're supposed to be pulling and then solving or building against. And this is, there's actually, you know, if you're in the world where you're solving bugs, where you are fixing different types of unexpected issues that come up from sales or from support or marketing needs something urgently, then of course, there's always a part of the business that is very reactive where... it's based on tickets and issues and doing kind of a mixture of different work for all kinds of different people all at once, right? And that's always going to be a part of the work for programming and for programmers. But the thing is that when it comes to actually doing projects, when it comes to doing things that the business thinks are strategically important, doing that in an environment which is based on cards and tickets doesn't actually work very well. And there's a few kind of issues that we've seen over the years with that. One is that if we take this viewpoint from the programmers, from the engineers, from their standpoint, they actually very often feel too much like order takers. You know, they feel like they're working in the back of the kitchen, just cooking burgers to order instead of using their creativity, instead of using their problem solving ability. And that's because the issues are coming to them one after another with do this, do that, do this, do that, and there's not a lot of room for them to really think and contribute there. And then the other thing is that from the programmer standpoint, often there's this feeling like being on a never-ending treadmill, you know, the work is never done, there's never a moment where it all comes together and there's this kind of big celebratory finishing moment where you can say, ah, the project is done. Of course, things do ship eventually. but it often takes quite a long time before that moment comes. And then even when things do ship, there's often a long tail of issues that are left over after it's shipped. And then that long tail of issues, it starts to mix into the next start of the project. And it's a situation where the programmer's attention is always divided across many, many things. And they feel like they're playing whack-a-mole trying to solve different issues. There's also problems from the standpoint of the management. from the owners, from the founders, from the executives. And from the management standpoint, very often the question comes up, why can't we ship like we used to? Why is it taking so long for projects to get finished? Why is it so hard to find a program or time to get things done that we've identified as being important and valuable from the business perspective, right? And so that's a big thing there is just like, why aren't we actually able to get things finished the way that we did? earlier in the history of the company. And the other challenge is that from the standpoint of product leaders and from the standpoint of managers, it's really hard to get a clear answer of where do we actually stand on this project? Is this thing close to being done? When is it going to be done? And we see that in an environment where that's two-week sprint after two-week sprint, these sprints just follow one after another, and there's no clear end in sight. Over the years at Basecamp, from the time that I was there, from 2003 all the way up through earlier in 2021, there was a constant experiment going. And the one thing that we always wanted to do was to treat the project work differently from the reactive bug fixing kind of support type work. And what we wanted to do is for that project work, we wanted to carve out a box in time. and say, for these people, for this project, they are only doing this project. And we are only going to focus on this one project for this many weeks. And then when it's over, it's going to ship and it's going to be finished. And we are never going to have to look back at it again to really kind of create that protected time. And let me actually share my screen here so I can give you some pictures to understand kind of what that looks like and how we do it. The vision is that we're going to create this time box. And the period of time that we settled on that worked the best was about six weeks for this time box for a single project with about two to four people collaborating in that. And that's a mixture of designers and programmers and QA. It depends actually on the details of the project, but something like two to four people, basically a small team in a six week time box. And if we really want to say, this project is going to happen inside the six weeks, it's going to be done in the six weeks, and nobody is going to interrupt people in that six weeks. Then we have to start to ask ourselves some questions. How are we going to actually structure the team and design the process so that we can achieve that? And that's so we can do it over and over again. And so the first thing here is actually, what is the input to that six week time box? And this is what in the book is called shaped work. And shaped work means that we're not just taking a research problem and giving it to this team. We're not giving them something that doesn't have any known solution at all and asking them to go do discovery and figure out if it's going to happen or not. We're giving a viable concept that with a reasonably understood element of risk to it so that we can be confident that the team can actually successfully build that within the six weeks. And we're going to look into more detail of what that actually means to shape the work. And then the outcome of that is work that is done and shipped, completely done, not with a bunch of issues left over that bleed into the next cycle. And then if we're going to actually ask teams to do that, that's going to create a kind of pressure inside of this box, right? Because there's work that's supposed to happen and there's an expectation that it will ship and it's not going to get more time than that six-week time box. So then how do we actually... give them a chance to be successful with that pressure. And the way that we do that is we don't give the team any tasks. The team is going to actually figure out what the tasks are. So the team is going to define the work, what the actual work is. They are going to produce the tasks for themselves, and they're going to execute on those tasks. And the big thing that's going to enable that to be possible is the principle of fixed time and variable scope. and you've probably heard this if you're a student of kind of old school original agile because this is a very key concept that we're going to fix the time but we're going to allow wiggle room in the actual scope of what gets shipped so that we can make trade-offs of what is really important what is a must-have and what is a nice to have during that six weeks so the team is actually going to make those trade-offs and they're going to be able to figure out how to do that so this is the basic principle of what we're doing And at Basecamp, we shipped project after project for years under this model, very on time, very consistent with a very energized, excited team. And since the book came out, I'm actually really happy to say that I get emails every week from teams saying that they've been adopting this and they're doing the same. So let's dig into how does this actually work and what are the different phases? So I want to start by talking about this shaping aspect. So what does it mean to shape the work to give the team to do inside of this time box? And here, the first really important concept is the difference between an estimate and an appetite. Very often, technical teams will come up with a concept of what they think they want to do, or they'll start with some designs of some interfaces, and then they'll say, how do we go do this? What is it going to take to go do this? And that's where you start with a design and then you put a number on it, right? You say, here's the design, how many weeks or how many days is it going to take to do? Here we take the complete opposite approach. We start with the number, the six weeks, let's say, or we call it the appetite. How much time do we want to spend on this? And then we come up with a design that fits to that number. So instead of the fixed design and the number changes, the number is fixed and the design changes. So we come up with something that can go inside of that. The second key principle. is a question of the level of abstraction. So abstraction versus concreteness. This is, does a project start with pixel perfect, high fidelity, perfectly graphic designed screens? Does it start with a very broad just statement in words? You know, like we're going to go build a calendar or we're going to go build a meeting planner or we're going to go build a conference platform, right? And what are the levels in between there? And here, I want to give you an example from a project that we did at Basecamp. The project was actually to build a calendar feature. And the thing is that if we say build a calendar, it's really unclear what that means. And if we just say build a calendar, then the team has to make an unbelievable amount of decisions to shrink down this vast project to six weeks. Does build a calendar mean, you know, a detailed very complex interactions for a day view where you are dragging boxes to schedule, you know, minute by minute how your meetings are planned during that day? Or does build a calendar include features to send invites and find overlap in people's schedules and coordinate when people are available to meet? Does it include sharing, right? So there's a huge possibility space for what could be inside of a calendar. And at the same time, if we over-specify it, So if we become, instead of being too abstract, if we're too concrete and we design pixel perfect wireframes, then the team isn't going to have any flexibility to adjust the scope as they discover things that they didn't expect about either the technical complexity or about what is actually important and feasible to do from the user standpoint. So we want the team to actually have the freedom to come up with the detailed design themselves. So this what is that middle layer of abstraction? And it looks like this. It looks like a rough sketch, or it looks like describing a path of affordances and how things are wired without actually specifying the exact locations in two-dimensional space or the exact proportions or colors. And you can look at the book to see more examples of this. But here's a case where we said, look, for the six-week project, what matters about the calendar is actually that people can see on a level of a month grid and on a day-by-day basis if there are free spots available or not. And this had to do with our understanding of the background of the problem. I'm not going to tell you the whole story, but you can find it in the book again. And the key thing here is that if we define the basic goal as there's going to be a two-month-at-a-time interface, you're going to be able to see when there's availability versus when the day has stuff scheduled on it. And then underneath that is going to be kind of a scrollable agenda view to click into one of those days and see what is scheduled on those days. This shrinks down the universe of the problem space to something that is, we understand it to be possible within the six week time box, but still there's a lot of room for creativity and there are going to be a lot of small problems and engineering decisions and design decisions to identify and to solve. And then if we look at kind of what was shaped versus what actually, let's see, the keynote wants to respond. That's good. What was shaped versus what was delivered? Here we can see that in the end, the team actually came up with a high fidelity design for this, and they had to make a lot of tricky decisions about how the interaction works of scrolling this agenda view and what happens in different states. There's a lot of subtlety there, right? So here you can kind of see the level of abstraction that we come into a shape project with. I'm going to keep moving so that we can cover enough here, but you can always go to the book for more detail. The output of this process that we call shaping, this happens before the time box starts, before we make the commitment to the work. This output is something that we call a pitch. And the pitch is basically written language that explains the background of what we're trying to do, the intention, the purpose of what we're trying to do, and then a kind of guided tour in words of... how you will move from here to here to here to here and i like to use the analogy of building a house you don't have to give uh the exact dimensions of every room but we can have an understanding of whether there's going to be two bedrooms or three bedrooms you know the relationship between when do you where do you walk into the house and how do you get to the kitchen and where is the bathroom located relative to the kitchen like things like that so it's about the relationships and the big parts kind of how are the different things connected and then some very rough sketches that just help to make sure that there's an understanding between you know that this is possible and kind of how the pieces might fit together while still giving a lot of freedom to the teams so that's the shaping part and then there's one other step that happens before we get into the time box which is what we call betting or the betting table and here we are using the word bet and betting instead of plan and planning And this is to help everybody involved to take on a kind of attitude of risk management and to internalize the fact that there are always going to be unknowns. There's always going to be things that we can't predict. And to take a kind of cautious attitude where instead of like, this is the truth, this is going to be perfect. And however long it takes, we're going to just do it until it ships to say no. We're going to give ourselves a six-week window of time. We are going to do the best that we can to kind of shape something that is valuable but also doesn't have a lot of risk, that there's a good chance of success inside of that time box. And then to make the bet means to make the commitment. And betting also means that we have to answer the question of who gets to make that bet, right? Who actually owns that time? Who owns that decision? And this is where we can actually give the management or the executive level, kind of the hand on the steering wheel that often starts to become lacking as the company grows, where it can say, no, this is the point where I can actually make decisions about steering where we go strategically, because we get to decide on a cycle by cycle basis how time is spent and what the objective is. And here are a couple of important points. The bet is never longer than six weeks. and of all the companies that have tried shape up and there are many now who have implemented shape up nobody has had i've seen success with cycles longer than six weeks and i think the reason for that is just simply human that we cannot actually see beyond that horizon of six weeks beyond at a number bigger than six it becomes something that's just in our head and it's not something that we can feel in our stomachs anymore it's not something that we have an intuition of how much work actually fits into that box And so this is kind of like the horizon of how far we can see. And sometimes it's a single six-week project to fill that box. And other times it might be a handful of small projects, and we call those small batch projects, that can fit into that single six-week box. And then a key thing, we never bet more than six weeks at a time because it's too hard to see that far into the future. And that also means that we preserve our optionality. We preserve our freedom. so that if something comes up during the six weeks that we didn't expect, if a new strategic opportunity appears, if a big technical problem appears that we didn't anticipate, we can completely change course after six weeks and do something else. Okay. And by the way, if I wasn't clear enough, the expectation here is that this project is actually going to deploy after six weeks, right? And we're going to walk away from it. That's really going to be done. So that's the shaping, figuring out what to do, the betting at the right level of abstraction. the betting which is actually making the time and resource commitment carving out that six-week time box for that small team then let's look at what actually happens inside of this time box what does the team do and how can they be successful to actually finish this project and so here we have a few different pieces and a few different important concepts uh that are also kind of core to the the the well honestly sort of the shape of language and the the this starts with a handoff This is where there's a meeting between the people who shaped the work and the people who are doing the work to make sure that the intent is understood, to answer any questions, and especially to be clear on the level of motivation and purpose. What is this thing about? And then the first thing that the team is going to do is they're going to do what's, there's a very important word here, which is they imagine tasks. So there's a difference between imagined tasks, the things that we think we're going to do when we start a project. versus the real tasks or the discovered tasks, the things that we actually find out by trying to do the work, the things we find out that we actually have to do, right? And so the best we can do in the beginning is to just imagine what we think that we're going to have to do. And here I'll give you an image of what that looks like. So here I've got the written pitch on the left, and this is describing the work. and this was also something that would have been discussed between the people who shaped the pitch and the people who are going to to actually do the do the project then by going through this pitch then the team that's building is going to come up with all of the imagined tasks that they can think of all of the sort of specific implementation things that they think they're going to have to do in order to make this a reality and often these are going to be at a level of technical detail that is a level down from what was in the pitch a level more concrete and more specific so here they're actually saying from top to bottom these are the things that we think we're going to have to do to to accomplish this project then from there the next step is to actually break that work into scopes because we don't want to just be pulling at different tasks and then hoping that it all comes together at the very last minute we want to actually kind of identify what we can call scopes of work vertical slices where there's some piece of front end, some piece of back end, and we can say a whole piece of this project is working. There's some part of this project that is working that demonstrates that this project is actually going to happen, right? And there's something that you can click on, something that gives a result very early. We're talking by day four of the project or in the first week of the project. There should be something that the team can build. and show that already works and we call those scopes and to get to those we can take all of the imagined tasks that were dumped and kind of group them according to how they are orthogonal to each other what are the things that be that can be completed independently of the others according to the relationships and interdependencies and then by sorting those into separate groups and it's good to have no more than 10 so that it's something that everyone can kind of manage as a map so that everyone can kind of go up in the helicopter and look down at the project and see all of the work that's standing there. These become named and they become sequenced and then the team says, okay, which one of these things do we want to try and build first so that we can show that we are getting somewhere? So then there's a question of actually taking one of those scopes and doing work. And here it's when we actually do the work. that we would just discover what the tasks really are. When we think we're going to do something, we say, oh, it sounds easy. We just have to do this, this, and this. And then when you actually get into the code, when you actually get into the problem, you say, oh, wow, what about this? What about that? What about this other thing? And here, when we talk about this actually doing the work of building a scope and discovering the tasks, a metaphor is useful. And this is the metaphor of the hill. And here we can say that work is like a hill. There's always an uphill phase, which is the learning phase. And this uphill phase is the part where we're figuring out what do I actually have to do? What is involved? What are the things that I didn't know before? And the only way to move uphill, it's not actually head work. It's by getting the hands dirty. It's when we actually start to open the existing code. and see how things are wired and how we're going to have to connect with that, that we start to realize, oh, we're going to need a data migration for that. Oh, can we do that? Like what's going to be involved in that, right? So that's the uphill work. Then there comes a point where you're at the top of the hill, where you've figured out everything that you have to do. You can understand how all the pieces fit. You have the real, real knowledge of the actual problems. And then you can look down and say, now it's a question of execution. Now it's a question of just basically labor to get all the things done. And through those different phases of uphill, top of the hill, and then over the hill, we can actually see that the task list looks very different. So here, the team, we're looking at one scope, and the team actually defined two tasks that they understood they had to do for a scope. And this is what it looks like when you're at the bottom of the hill. But then once they started to try and do those two things, Then a lot of other tasks appeared. And this is what we call the discovered work. So by the time they got to the top of the hill, you can see that there were at the bottom here, these are tasks that were done. And at the top, there's more tasks than before. So actually, by trying to complete the tasks, we got more tasks than we had before, right? This goes against a lot of the assumption of project managers that you define tasks and then the number of tasks shrinks as you work. As you work, the number of tasks grows, right? but then you reach a point where you're at the top of the hill, you understand the work that's involved for this particular scope, and then you can execute all of those things and reach a point where you're done. So scope by scope, we can go up and down this hill of finding out what we really have to do in doing it, and then we reach a point where a scope is actually finished. Right. And here we can see this by looking at our if we go back to our map of scopes and say, what is the thing that I'm going to work on next? Here you can see that a few of these scopes are now finished. A few of them are outstanding. And then we have the question of, well, which of these things is the right thing to take on next? Right. Factoring in the importance of it, factoring in the amount of time that's left, factoring in especially the unknowns and the risk. Right. So going back, looking at our breakdown of scopes, picking what to do next. finishing that right finishing another scope and then we reach reach a point where if if the scopes were all quite clear and if nothing has really become a big challenge in the work along the way we might just keep finishing these scopes one by one and we could actually reach the end of the project by going through this loop but also what can happen sometimes is we actually need to do something which we could call a regroup and this is where you know you're in week three or you're in week four of the project and you start to get into a scope that you hadn't worked on before and you realize oh there's a lot in here and we're not going to be able to finish this within the six weeks if we have to do everything that's in here right and this is where we need to do a regroup this is also by the way what this is in shape up we sometimes also call it hammering the scope or taking out the scope hammer right and this is basically saying time to make some really tough trade-offs time to make some tough decisions about what's in and what's out so that we can get this thing finished And that means going back to this work and really looking at what is a nice to have versus a must have, and what are some things we can do in order to change the scope so that we can finish it. And there's a lot more we can talk about that, but we have to keep moving with the time that we have today. And so then there can be some changes to the scopes there, some changes to the work, some adjustment there, and then back to completing the scopes and then reaching a point where the project is finished. So that's basically kind of what that process looks like from the standpoint of inside the time box and getting to done. And if we want to zoom out then and then say kind of, how does this actually play out as a process that happens again and again, you know, inside the company, then we can say that after the six weeks, then there's a two week process, which is called the cool down. And actually in this two weeks, there is nothing scheduled, nothing planned. There's nothing that the team is actually committed to doing. This gives a kind of breathing room for the team, which of course is just pleasant to have. It's like this moment where everybody can go, ah, right? It's also this breathing moment that allows for coordination between different parts of the company. During that six-week time box, no one was supposed to be interrupting the team. Nobody was supposed to be bringing bugs or issues or reactive work. to that particular team they were protected from that but then during the two weeks time opens up where they can meet with other teams where they can coordinate with other departments where they can handle bugs or different unexpected issues it's like a free form time where they can do whatever they whatever is needed of them and whatever is valuable it also allows some wiggle room for issues that might arise with you know scheduling the deployment or things related to release or preparing the announcement or the marketing for the release different things like that that are hard to plan for. So there's this kind of two week zone before the next cycle starts called the cool down, where those things can take place. And then if we zoom out, we can say that this actually happens again and again. And there's a track where there's people who are building and executing six weeks at a time, followed by the cool downs. And then there's some way, and this is going to be different depending on the company. and the relationships and the skills that are in the company, there's some way that the work needs to get shaped and bet for the next cycle. So there's a shaping and a betting process. And this might happen in parallel because you actually have different teams or different people with different expertise doing that. It can be very different, of course, if you have a tiny, tiny startup with just three or four people, then everybody is kind of doing everything right. But as the company grows, then there can be a specialization here. So on a parallel track, the shaping and bedding is getting prepared for the next cycle. Then when it's time for the next cycle to start, there's work ready to go. There's a commitment being made. And then when it's time for the next cycle and the process repeats again. So this is kind of a high level view of the whole process that's described in the book. And there's a lot of different ways to adapt this. There are a lot of still... different adjustments to be made on a company by company basis but the main thing that i would hope that you take away from this is the main concepts and the language right what does it mean to shape work what is the difference between an appetite how much we want to spend on a project versus the estimate where we take the design as something fixed and try to attach a guess to it right what does it mean to make a bet what does it mean to actually protect people's time right what does it mean to give people a project and have them come up with the tasks and have them define the work versus giving them tasks and tickets that they're supposed to execute right and then thinking of things like risks like imagined work versus discovered work right breaking work into scopes and delivering one thing at a time so those are the kind of things that can become parts of the language that you use and they can become kind of the beginnings of conversations that you have with the team to try and find new ways of working if you are experiencing those problems that I mentioned in the beginning, where things aren't shipping, things are taking too long, there's too many different kinds of work mixed together, right? All of those kinds of things. So if you want to learn more, you can read the book for free online. That's at Basecamp.com. My website is feltpresence.com and you can find articles and also my newsletter there where you can get kind of the latest thinking and new processes and new detail about these different steps. You can also find me on Twitter to get different news and work in progress, and I'm rjs on Twitter. So that's what I had in mind to share with you. I wanted to leave some time for questions, and we've got 10 minutes left for questions right now. So let me actually open up the Q&A and take a look at what we have in the questions here. Yeah, one question here right off the bat. How did you arrive at this magic duration of six weeks? Let's see, answer live. uh yeah i'm learning the zoom tool here how did you arrive at the magic duration of six weeks yes was there something sorry yes ryan could you just stop your screen share while you're answering yeah thank you okay is that better okay so the question was how did you arrive at this magic duration of six weeks and basically it was trial and error uh the thing is that if the if if if we only have two weeks let's say and the goal is to actually be shipping something at the end of the two weeks then It's simply not enough time to take on anything that is going to be a meaningful change in the product. You know, really building a new feature, adding substantially different functionality. You can't do that in two weeks. And then if you only have two weeks, then you're back in this never ending sprint treadmill. So six weeks is long enough to actually complete something meaningful. And we've tried, you know, we tried in the past eight weeks, 10 weeks, longer, things like that. And the problem with something longer than six weeks is that it's just too hard to feel the deadline when it's so far away. And what happens is it's only when you would like, for example, when we had like an eight week cycle, it was only until the second or third week that you could kind of feel that deadline pushing. And you need actually, the team needs that feeling of that healthy feeling of back pressure from the deadline to motivate them to collaborate and make trade-offs together, to make them actually look at each other and say, uh now's the time that we should have a conversation about what really is a must-have and a nice to have and it's the feeling that that deadline is coming so if it's too close then you can't get anything meaningful done and if it's too far then you don't feel the pressure and it doesn't motivate trade-offs so then we have a question here are there no demos and reviews outside the team during the six weeks actually there are um uh there are demos and reviews inside of that and that's what i meant uh to highlight thank you for asking i meant to highlight that with the notion of scopes, that there's something that the team can kind of deliver along the way where something is done, something works, something is interactive and clickable. And that is a really good demo moment. It's a good moment to get feedback. It's hard. I actually think it's important not to try and over prescribe when and how that should happen. But the important thing is that there are these regular moments. where the celebration is happening because something is solved and over with and done and the whole problem of the project got smaller. You should have this feeling like where the map is getting checked off in different places and the territory of unknowns is shrinking. And so from the standpoint of the programmers, it means they get to have that feeling of like, yes, we're getting somewhere. It works. It's real. And not having that kind of nervous anxiety feeling of like, well, I hope it all works when we try to integrate it on the last day. And then from the management perspective, they have that kind of 10,000 foot view. They can come in with the helicopter and they can very easily have a discussion with the team about what's done and what's outstanding because of chunking into scopes like that. Let's see. What would be the ideal team composition here? This is an interesting question. This is going to depend very much on the type of work and it's going to depend also on the type of designers that you have. There are some teams that have designers who code, and there are some teams that have designers who are more like graphic designers who produce two-dimensional drawings at a high level of definition. And actually, there are many, many ways to do this. The main thing that I would avoid is I would avoid starting with high-fidelity mock-ups. It's much better to think of it like... getting the parts and then wiring them together on the floor. Like if you buy a new stereo system and you intend to install the stereo system in the ceilings or on the walls, you don't immediately buy the different components. And then as soon as you take them out of the box, attach them to the wall. First, you plug them together to the receiver, you plug them together to your phone, and you put them on the floor wired together to see, does it sound good? Does it work the way that I thought? Do I understand how the parts wire together? and then after they're all wired together then the finishing happens or the same thing with a house right you don't start with the paint and the furnishings you actually there's a lot of framing and basic construction that happens first and so i would definitely recommend orienting the process first around wiring things together and make things that are ugly but working because so much of the risk and so much of the danger in a software project is actually having a lot of half-built stuff that looks great but doesn't actually deliver on the experience it doesn't function the way that it should and there's deep technical problems that are unsolved in the back end most of the risk is actually more in the back end than in the fonts and the colors and the typography the the aesthetic experience is of course very important it's a question of sequencing it so that we attack the right kind of risk at the right stage and a lot of that stuff where we layer in the fine proportion, the perfect colors, the right typography, that stuff can actually happen much later in the process after the raw kind of ugly parts are proven to be working together in a way that functions according to what was shaped. So that's a comment there. In terms of tools of breaking down scope, actually I wrote an article about that. If you go to my website, feltpresence.com, you'll see on my newsletter, newsletter number 15. describes that. That's something that you can do on a whiteboard. You can do it in Miro interactively. And I also have some tooling of my own that I'm working on that you might see if you follow me on Twitter. That's going to be coming out quite soon. How would you estimate, let's see, how would you estimate the scope of work which is discovered while going towards the top of the hill? Often that's where promise comes, yeah, that's where conflicts come up. So here, of course, nobody has a crystal ball. and nobody can see all of the unknowns in advance. But there are different categories of risk. There's a difference between looking at something in the shaping phase and saying, we understand the APIs. We understand the existing code that we already have. We understand the systems that we need to integrate with. And if we follow the chain of what has to connect to what, there's a point where it stops. There's other kinds of work where we can't actually see from the beginning. It's a library we've never used. It's a type of integration we've never done. And we can't actually see the ending. You know, we can't say it's going to be this connects to this connects to this. And then we don't connect to that. And this part stays the same. And we can't see those boundaries. So if you can see the boundaries of where the dependence is between the parts end, that's a good sign that you're going to be able to have something that has a reasonable kind of a probability distribution of how long it's going to take. But if you can't see the end of how the things interconnect, that's where you get the runaway long tail. That's where you get the rabbit holes and things like that. So that's a kind of a short answer to that. Let me just see if we have anything else for the last two minutes here. Yeah. This is also a good one to mention. Is there any feature missed to complete the... So is there any issue with completing the development because of dependencies across different teams or between different tracks? This really belongs in the shaping and bedding. So here, orthogonality, the independence of things, is a design decision. So in many, many cases, orthogonality is a choice. It's something where we say... We could build this in a way which is modular to this other part, or we could build it in a way which is coupled to this other part. And software developers know this very well from making their own decisions within an individual feature of how to encapsulate things or how to separate responsibilities and so on. And it's the same principle of good software development at the project level. How do we separate concerns on a project level? How do we encapsulate on a project level? This is actually very, very important. And it's the work, it's a sign of actually a very effective CTO that they're viewing the project level the same as they view the code level. Of course, there are things where there are interdependencies, but we should actually be designing for those when we design the commitment, when we make the bet. So they don't come up as something unexpected that then derails the team's ability to work independently during the cycle. So let's see, I'm seeing one minute left. You've got time for another couple of questions, Ryan. Okay. How does the team know it is shaped enough? Who is responsible for the shaping? So shaping actually is a mixture of front end, back end and business strategy. It's actually where the three things come together, because before we actually dedicate time and people's time and energy to go build something, we should have an understanding of do we do we know what we're trying to do from the user standpoint? Roughly, do we know? Do we understand the viability? Do we understand what's involved? from the implementation side? And does it match with our business values? Is it something that is strategically worthwhile? This question of appetite is very much a business question. Is it worth spending the time on this thing right now? And you are never going to have a perfect unicorn who is exactly equal in their design strength, their implementation knowledge, and their business knowledge. But you're going to have somebody who is stronger in one of those areas. but enough of a generalist that they can collaborate with others or do those or touch on those other zones themselves. And so what you're looking for in the role of the shaper is somebody who has the ability to pull those three things together. And there needs to at least be strength in one of them and literacy in the others. And that's basically a way to start there. The question of whether it's shaped enough is, is it something where a team is going to be able to understand it? The intention is going to go through. There is a solution that is already described. At a high level, there is a way to do this. It's not just go build a calendar. It's build a calendar with these constraints. And these things are out and these things are in. And because these things are out and these things are in, this is what makes it viable inside of the six-week time box. And then the responsibility for whether that actually happens within the six weeks is a function of both what was shaped. and the performance of the team inside of the time box. And then that's something where there are different aspects that you can pull apart of who is responsible for which aspect. That is all we've got time for. There has been a fantastic session, intensely packed full of lots of nuggets of great pieces of information and ideas. So thank you for that.

As software teams start to grow, some common struggles appear:Team members feel like projects go on and on, with no end in sight.Product managers can't find time to think strategically about the product.

Founders ask themselves: 'Why can't we get features out the door like we used to in the early days?' We saw these challenges first-hand at Basecamp as we grew from four people to over fifty.

In this talk, Ryan will share how the Basecamp team operates and talk about his new book that will help us Stop Running in Circles and Ship Work that Matters.

More details: https://confengine.com/conferences/agile-india-2021/proposal/16151

Conference Link: https://2021.agileindia.org