Welcome to our first keynote for the third day, you know, we have none other than Ryan Singer with us, you know, for those of you who have, you know, used base camp, you know, from 37 signals Ryan, you know, was part of the team of three that initially started creating base camp. He's been, you know, the integral part of the base camp team from then and played over the 17 years played various different roles. So someone who really, 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 shipwork 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 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 manage that how to actually make that happen. And I started at base camp 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 clear pattern that stands out. You see most software teams today are working in the 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 a 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 to be pulling and then and then and then solving or building against. And this is there's actually the you know if 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 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 for years with that one is that if we take this the viewpoint from the from the programmers from the engineers from their standpoint they actually very often feel too much like order takers you know they feel like 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 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 and there's this this kind of big celebratory finishing moment where you can say the project is done. There's this things do ship eventually, but they, 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 to to mix into the next start of the project. And it's a situation where the programmers 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 programmer time to get things done that we've identified as being important and valuable from the business perspective, right. And so that's that's a big a big a big thing there is just a question 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 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 weeks sprint after two weeks and we follow one after another and there's no clear end in sight. Over the years at base camp from from from the time that I was there from 2003 all the way up through through through earlier in 2021. There was a constant experiment going. And the one thing that we always wanted to do was to treat the prod the project work differently from the reactive bug fixing kind of support type work. What we wanted to do is for that project work we wanted to carve out a box in time and say there 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 that protected time. So I wanted to share my screen here so I can give you some pictures to understand kind of what that looks like and how we do it. So the vision is that we're going to create this time box and the 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 it's going to be done in six weeks and nobody is going to interrupt people in that six weeks and 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 we're going to be doing is we're going to be going to be doing a 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 you know 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 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 and then they're 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 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 tradeoffs 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 base camp we shipped project after project for years under this model very on time very consistent with very energized excited team and when 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 like how does this actually work and what are the different phases so I'm going to start by talking about this shaping aspect so what does it mean to shape the work to 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 the 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 the 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 the we call it the first 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 base camp the project was actually to build a calendar 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 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 how your meetings are planned during that day or is this 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 is 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 are going to be able to do that 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 see 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 if we look at kind of what was shaped versus 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 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 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 take we're going to give ourselves a six weeks window of time we're 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 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 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 so 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 that are also kind of core to the well honestly sort of the shape up language and this starts with a hand off 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 very important word here 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 a just 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 actually 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 to accomplish 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 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 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 we want to actually 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 and there's something that you can click on something that gives a result very early we're talking before of the project or in the first week of the project some 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 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 ten 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 when we actually do the work that we would just discover what the tasks really are you know when we think we're going to do something we say oh it sounds easy you know 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 see oh wow what about this what about that what about this other thing right and here when we talk about this actually doing the work of building a scope and discovering the tasks a metaphor is useful for the work 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 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 what's going to be involved in that 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 it's 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 were 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 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 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 and 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 through this go up and down this hill finding out what we really have to do and doing it and then we reach a point where a scope is actually finished and here we can see this by looking at our if we go back to our map of scopes 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 which of these things is the right thing to take on next factoring in the importance of it factoring in the amount of time that's left factoring in especially the unknowns and the risk so going back looking at our breakdown of scopes picking what to do next finishing that and then we reach a point where 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're in week 3 or you're in week 4 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 6 weeks if we have to do everything that's in here and this is where we need to do a regroup this is also by the way in shape up we sometimes also call it hammering the scope or taking out the scope hammer and this is basically saying time to make some really tough tradeoffs time to make some tough decisions about what's in and what's out so that we can get this thing finished 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 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 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 that was 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 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 that are hard to plan for so there's this kind of two week zone before the next cycle starts called the cooldown 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 cooldowns and then there's some way and this is going to be different depending on the company and the relationships 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 but as the company grows then there can be a specialization here so on a parallel track the shaping and betting 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 work 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 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 what does it mean to make a bet what does it mean to actually protect people's time 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 and then thinking of things like risks like imagined work versus discovered work 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 things are taking too long there's too many different kinds of work mixed together 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 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 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 one question here right off the bat how did you arrive at this magic duration of 6 weeks let's see answer live I'm learning the zoom tool here did you arrive at this magic duration of 6 weeks yes was there something can you just stop your screen shoot certainly is that better so the question was how did you arrive at this magic duration of 6 weeks and basically it was trial and error the thing is that if we only have 2 weeks let's say and the goal is to actually be shipping something at the end of the 2 weeks then it's simply not enough time to take on anything that is going to be a meaningful change in the product really building a new feature adding substantially different functionality you can't do that in 2 weeks and then if you only have 2 weeks then you're back in this never ending sprint treadmill so 6 weeks is long enough to actually complete something meaningful and we've tried in the past 8 weeks 10 weeks longer things like that and the problem with something longer than 6 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 8 week cycle it was only until the 2nd or 3rd 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 now is 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 6 weeks actually there are there are demos and reviews inside of that and that's what I meant to highlight thank you for asking I meant to highlight that with the notion that there's something that the team can 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 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 right 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 mockups it's much better to do to think of it like getting the parts and then wiring them together on the floor like if you buy a 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 wired together and then after they're all wired together it happens or the same thing with the house 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 it doesn't 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 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 and there's 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 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 conflicts come up so here of course nobody has a crystal ball but there are different categories of risk there's a difference between looking at something in the shaping face 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 we can 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 and 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 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 hahaha yeah this is also a good one to mention is there any feature missed to complete 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 betting 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 and it's the work it's the 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 with something unexpected that then derails the teams ability to work independently during the cycle so let's see I'm seeing I'm seeing one minute left I'm looking for another couple of questions okay hahaha just taking a look at the different questions here the number of people mentioned that they see similarities with agile frameworks and that's great because I was schooled on agile frameworks a lot of this came from applying different agile frameworks and trying to understand what works and what doesn't so of course there's going to be overlap of different kinds yeah so the question here is there a definition of shaped work 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 know what we're trying to do from a business 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 you know exactly equal in their design strength their implementation knowledge and their skills 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 strengthened one of them and literacy in the others you know and and that's that's basically 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 are 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 was responsible for which aspect that is all we've got time for there has been a fantastic session of intensely packed full of lots of nuggets of great pieces of information and ideas so thank you for that