How we work at Basecamp | SaaS Conferences | SaaStock Tour London 2018

[Music] yes oh there's pieces of paper all over the place and that's because it was too complicated to fit on a slide and you don't need to see it because we're in a nightclub so it's not very practical to read it right now but but you can take this home and I'm gonna hit sign up sort of the key points here and then there will be sort of next steps for you if if you if this is interesting for you by digging deeper and also I'll be around so you can you can come talk to me and ask further questions about about what's on here but we're going to hit a few important things the subject of this talk is how do we release the things that we actually intend to release you know you we talked this morning about how important it is to build the right things in order to be positioned properly and then Dez did a really good job of hitting similar points where he was talking about you know the importance of focus and and choosing which things to build in which things are the right things and the wrong things to build but it kind of none of that really matters if you have the problem that most software companies have which is that like you you you have this thing that you want to release but somehow you know it's just kind of another another month went by and it didn't get out right under is that does anybody understand this problem is this okay so the question is how do we actually do this stuff that we want to do and not end up doing other things I've been at Basecamp for 15 years and we've been doing these things that I'm talking about here the whole time in some form and then we've just kind of recently started to spell it out better so what I'm going to do is I'm going to take a little tour of the key things of how we're working and you'll understand it without getting into every detail we're gonna hit three things in particular that are really important and then we'll take a look at a tool that we use to kind of know where we stand when we're in the midst of a project so that we actually get the thing out alright so the first thing I'm going to do is start in this upper right area in the strategy area and this is sort of where we started this morning what we talked about so this energy is an ongoing function of the company so this is not happening inside of a cycle this is not happening at a certain time it's it's a running thing and the situations that cause customers to buy that's what we talked about from the demand side this morning and then there's these other inputs like using it ourselves or taking stories behind what our customers are asking for and these things are informing us what matters on the demand side so this is telling us like those key requirements that we talked about this morning and it's also telling us sort of water.that giving us a diagnosis of what are the things that we could be improving in terms of the actual product right what are the things that we should be changing and then those are turning into what we call pitches and a few of us are it's like our job to come up with sort of ideas for what we should build next but also everybody in the company is submitting pitches at different times and a pitch is basically a write-up that says here's a problem here's something that's going on and then here's our idea about it has to include some kind of a concept or a solution for how we're actually going to like solve it you know so that's a pitch and when a pitch comes in the default answer always to anything that comes up no matter who it comes from is no no maybe one day maybe one day is the is the escape valve right so that so that people don't feel - you know what I mean it's like it really means no but we said you know maybe one day okay so so know maybe later is the default response to every single idea no matter who it comes from anywhere okay all the time so this is a this is something that's happening so throughout you know every day every month every year we're accumulating all kinds of different ideas but these things there's it's not a backlog it's not a queue it's not some kind of a burden on our back it's just stuff that we're saying no to so then it comes time to actually do something and this takes us into budgeting so we build in six weeks cycles and there's a lot of you know you say cycle and you say iteration and you say sprint and these are like words that people use you know what I mean but it doesn't mean any thing in terms of success I mean everybody's agile now right but everybody has the same problems a bad morale with the with the engineers and frustrated management and the product people the stuff that's getting built isn't the stuff that they want to be built right I mean nothing has gotten better actually so cycles alone don't help so a couple of things I'm going to point out here are the things in the inlet with the bold outlines and these are the things that are really different that we do so we put work into a cycle and a cycle for us is six weeks so that's an a cycle includes at Basecamp two teams each team is one designer and two programmers we are extremely efficient so we have one designer two programs and programmers maybe one or two QA people and that's an integrated team and they're given some work to do and when it comes to the work inside the cycle everything that happens during that six weeks they have a mentality that they have to expect to release what they're working on they have to be done this is like a sacred word for us done so they can't plan to get more time if they don't get it done it's not gonna happen this is it it actually has to be done so by doing this this creates a kind of very productive pressure right because if the thing actually has to happen like it's not just like oh well you know we'll do another sprint right or will do another few runs if it actually has to happen then they're gonna have to make trade-offs they're gonna have to say they're gonna have to make decisions about how the heck are we gonna pull this off right so this is fundamental we're gonna ship it or it's not gonna happen and our hit rates very very high there I should say that this is true for about 90% of the projects that we do and then there's the odd case where we know that what we're biting off is a little bit too big for one cycle so then we'll do maybe two cycles back-to-back on the same thing but even in that case the work that scoped off in the first cycle should be done and over with and done means I don't have a subsequent integration step I don't have more there's it's it's ready to go at a moment's notice we could give it to a customer that's what done means so they have to be done now if you give a team six weeks of time and you tell them they have to be done this is a recipe for disaster because like how are they actually gonna pull that off right and if you just say do it that doesn't enable it to happen right so we actually have to do some things differently so that this can happen year after year after year as as normal practice and so this this has to do with actually thinking about how we define the work in the budgeting process so there's two things that we've noticed over the years the first thing we noticed may be familiar to you which is that every time we define some work there's always more work than we thought right so we've never had a project where the scope was the same than we thought or smaller than we thought and every single project the scope has been bigger than what we thought right because you start to get your hands dirty and then you discover all there's this edge case and there's also this other thing and then if we change this then we can't do that without changing this and bla bla bla bla bla right so the scope is always bigger so even if we gave if we gave the team you know three weeks work worth of work in six weeks you know then maybe then maybe we'd have a shot right at success because they could the scope could grow by double and then they could get something done but it turns out that that that wouldn't solve it alone because even if we got the amount of scope right we've also learned that our plans are always wrong so every time we sort of define what the feature should be on paper it never maps to the thing that actually works that we like in the end that we release now we have a very we have a very good success rate when it comes to the sort of outline of the concept right like the basic idea of what we're shipping we tend to be very very right on because we have a lot of experience when we when we come up with the design concepts but the details and the specifics they're always surprising right so how do we allow for this so David one the founders he he has this this quote he always says there's got to be some version of this idea that we can do in six weeks this is like his slogan and I really like it a lot there's some version of this thing that we could do and so what we're gonna do is we're gonna say that the budget is fixed the scope is variable and we're gonna give the teams the power to actually figure out what that version is which means they're gonna find out kind of where's the bone and the fat and the meat and they're gonna figure out where to make cuts as they actually get involved with building the real thing so the way that we define the work when we kick off a six-week cycle is we're not having a checklist of like these are the things that have to be hit and we don't have like a specification or anything like that rather we have a concept so and the concept says here's the problem here's what matters about it here's what we understand about why we're doing it and here and then here's the general outline of how we think this is going to work so this is an example of an actual sketch that Jason drew in a in a write-up - this is a formal right up to the team's saying like here's the concept for this thing this was a feature we shipped last year to to group - dues within a list and adding another level of hierarchy there's actually a lot of detail behind this there was a there were a lot of mechanics that we kind of worked out in the concept how to deal with things that are kind of not part of the list and then you move in between and how are you gonna insert items there's a lot of things we worked out but this is the level of fidelity and there was no sense of like it has to do this and this and this and this it was a concept so the teams are gonna are going to deliver some version of the idea and and the scope is variable and the other thing the last thing that we do that's unique here and this one I think is extremely important and maybe the most rare which is that we could give the team the expectation they have to finish and then we can tell the team you have latitude to cut scope okay you you have to be done but you get to cut scope okay so and we're gonna give you a reasonable concept and you're gonna figure out the details very very good but then there's another problem which is that even under those ideal conditions if as soon as the team starts to work somebody taps their shoulder from sales and says hey can you can you can you just work on this other thing it's just real quick right or support taps their shoulder and says hey you know we just got this bug and like we just need to track down this thing in the logs and because can you look at that right every time that happens is time lost from the team every time the team gets pulled into a meeting is time lost from the team and if we're talking about six weeks like there's no way they're gonna be able to get anywhere if if if every day they're getting pulled away by other things and you can't just tell the team hey be real focused on this project right because this problem exists at a higher level of the organization right because if the engineers who are building or the designers who are working on the feature are getting pulled over by for somebody from support I mean who like there has to be a statement from leadership at the very top that says we are deliberate about the way that we use our time so the way that I wrote this here is you have to make a bet you have to make a bet that says we believe that if we spend six weeks on this feature to the exclusion of everything else including bug fixes including other stuff that sales wants or whatever it is right to the exclusion of other things then you actually take some risk and you make the bet and then you find out after the six weeks if it was the right choice or not right this is really really fundamental so we want to be deliberate about the allocation if you have to deal with bugs that come up then you can allocate time for the bugs right if you have to deal with certain customer requests then you say we're gonna we're going to pause the cycle for a week and we're gonna you know you can be creative but you have to be deliberate about it and this way the team's time is totally protected and nobody can do that other than the leadership right protect the team's time so they can actually focus so those are the big things that that are different about how we are working in these cycles that allow us to actually ship regularly so then the other thing that I want to show you is sort of how how do we maintain a macro sense of where the teams stand and how do the teams reflect on where they are kind of in the actual cycle right because they're it's very important you can't just start building one corner of the thing and then look up and five weeks have gone by and then you know hunting and now you're in trouble so we we've been thinking about this for a while and we came up with with a way to sort of communicate this which is the way that a lot of people think about work and especially the way that work tends to be estimated and planned and and tracked in software companies it is like this there's this notion that there's this assumption that it's kind of a labor right like how many story points or what's the velocity right and there's this notion that well if we could just kind of count up all the work and count up all the people and then do the math and we're gonna know when it's gonna be done right but this is wrong because this assumes that you have certainty about the work to be done right so actual work looks like this there's an uphill phase where you don't even know what the work is and even if the work is really well defined you say hey fix this bug right totally clear outcome completely clear like what what has to be done once you actually get you have to get into the code or the programmer has to get into the code to even figure out what the heck is going on that causes the bug it can't estimate something they don't understand right so there's this uphill phase of figuring out what the work is and then once you've actually gotten your hands dirty and you've looked at the problem and you've spiked a few things or cupcaked a few things or whatever it is you know you've tried some stuff then you get to a point where you can you kind of reached the top of the hill which is where you can see the edges of it you're like ah we're gonna build that we're gonna change that we can't touch that and then I'm gonna fix that and everybody's around and we can do this yep good okay let's do this right and then from there it becomes more linear from there it's easier to estimate and the risk the character of the risk is totally different for these two worlds for these two sides of the hill right because any work that you haven't figured out even how to do or what it is what happens if you get to the 11th hour you can't suddenly throw more resources or put extra deadline pressure and somebody who doesn't know how to do something right but if you know how to do it and you've figured out the problem and you understand the work then it's like oh well throw a few more days of this right this is worth another we'll stretch it for two weeks fine because we know that we're dealing with certainties here and we're not just gonna get bitten by by some sort of a black hole right something that we can't solve this is very different kind of work so we want to do is we want to know where the work stands not in terms of 50% done or 60% done we want to know where the work stands in terms of uncertainty right so this is a tool that we built internally at Basecamp and this is gonna be released at some point soonish and this is what we use to actually track this internally so these are to-do lists in Basecamp and each list has a dot and the dots are manually dragged on a hill and the hill shows where the work stands in terms of unknown or known so we're dragging from unknown to known and from known to done so these things here when I when I just I haven't been following the project I come in I look at what's going on and say uh they've solved these things and I know what these things are and these things that they've solved first are probably the scariest riskiest things right and if they're not and we're gonna have a conversation and this is going to enable that conversation right how come these things are over the hill and those things aren't when those are the things that were scared about or those are the things that are the most untested or the most novel right so this is this is how we see it and then there's this link I can click on the top that shows me a history so this is me looking at the project over time and I can see how they start learning they're spiking they're trying things out they're learning what works getting over the hill right and then climbing over so this is real progress this isn't labor progress this is problem-solving progress over time and one thing I want to emphasize is that so I can click on one of these for example I can click on this green dot and now I see just the history of this one scope of work and what's interesting you should notice that the dots here there's only one task left in this particular scope of work so the the dot doesn't it's not algorithmic it's not like when there's 10% of the tasks are left it goes over here this this is manually placed by the by a person to indicate their understanding of how done it is so we're using a measure of done that is an algorithmic on a task list this is this is like pretty deep you know like is it done or not not like checklist 20% right so this could mean that there's a lot here and that's why it's not at the bottom it could mean that they anticipate a bunch of QA issues are gonna come in but none of them are gonna be none of them are gonna involve scary unknowns right or it could also be that this is just sort of where they left off and if I checked in the next day I'd find that the dot was down here right so one more thing I want to show you what this hill stuff is sort of what troubleshooting looks like and how it enables us to troubleshoot so this is a project from recently February and I checked in on the project and I noticed that stuff was getting done and solved but there was this one scope that just wasn't moving and for quite a while for quite a few days the scope wasn't moving at all notify everybody that an event was rescheduled and we're on the uphill which means like danger right if this doesn't get solved it's not going to happen and time is ticking so I pinged Scott who was working on the feature and said hey man what's going on with that you know like is it just out of date or what's going on he goes oh I you know the back end of this is done but we found some tricky UI stuff right so I said oh well can you just factor out the back end part it was oh yeah sure no problem this is before this is after the conversation so he takes this renames it to notify of rescheduled back-end indicates that it solved and nearly done creates two new scopes of work notify of reschedule hey this is our like inbox in Basecamp and this they don't even know it they haven't even looked at it they don't know what they're gonna do about it right totally left side how are they gonna deal with the email templates for this they have they made some progress but it's they're still unknowns right this is where the thing really stands okay so now that we've split it apart thing is when separate scopes of work are identified then you can track their movement independently because that's really the thing we care about is the movement right like where where is the progress being made so now that these are broken out I can see them moving independently right so here they they were no so notice notice they didn't take the email thing over the hill because they saw this as a risk right too many unknowns we better figure that out better push that up the hill further okay now we've got this nearly figured out and then the amount of work wasn't too bad so already by the next day over to the other side and we're in good shape so those are the kind of conversations that were able to have we've been doing this actually for 10 years but we didn't have the hill as a visual language for what we were doing that's that's fairly recent so that's what I wanted to share with you there's a lot on the paper these three concepts are called out so expecting to be done setting that expectation protecting the team so they can actually doing it by making the bet and dedicating the resources and shielding those resources off from anybody who steals their time and then shipping some version having a concept instead of a bunch of check check boxes for what this thing needs to be so the team can actually adjust and cut scope as they go these ideas go all the way back to getting real which we wrote in 2006 but I would say this is a bit more and maybe fleshed out in rigorous and I also wrote a piece about this called running in that touches on the core idea of the hill and a couple things like that so that is what I had for you we've got a little bit of time for questions now any tips for smaller teams to protect product team in a setting this so look there's no unavoidable whirlwind of stuff like who's the boss so whoever is the boss can do this and if you're not the boss then then that's then you have to live with the boss you don't like how do you keep track of all is that clear it's a decision it's a resource allocation decision right so if you're the boss you can decide what people spend their time on it's a decision that's why it's called deliberate resource allocation it's really important how do you keep track of all the ideas we don't haha freedom enjoy okay how do you measure and ensure that the engineering team is as productive as it can be I think it covered that if the scope is variable the incentive is to minimize it look if if if the team is there to deliver something of value that that the people who pay them are going to be pleased about they're not going to cut the bones out from the animal they're gonna cut the fat right I mean this is assuming that your team is competent and understands what they're building and why how do you measure okay how does the internal tool work to measure progress if you know how far up the hill of uncertainty you are is it really uncertainty now we're getting epistemological look it's a it's a practical question right how do you feel about this have you even looked at it have you cracked it open at all totally on the left side do you have a concept about how you think you're going to approach this then maybe 20% up right have you validated your concept for how this is gonna work and your maybe 40% up or 50% up or I don't know what percentages mean anymore you're getting further toward the toward the hilltop and then if if if you validated the concept and you poked around and there's nothing else that sir gnawing at you like and not sure about how we're gonna handle that then you're at the top anybody who does development work knows what it feels like and they they will tell you what it feels like at each point that's that's sort of the why we went with manually dragging because the people who do the work they know what happens to the great idea if it's not done at the end of the Sprint is it Bend so if it doesn't happen then we generally assume that it can't happened because we have good people so either the concept was wrong or maybe there was something weird that happened in terms of maybe we made a mistake and somebody was on vacation and we didn't know and then somehow they couldn't manage right it's possible that we make mistakes and something can't get done what we do is if we get to the end of the project and the important scopes of work are over-the-hill then we can feel very relaxed about investing the extra time you know what I mean like no problem we give it another three weeks they've solved all the problems they know what they're doing just needs a little more time if we're at the end of the cycle and the thing is uphill still and hasn't gotten over then what are we investing in it's like we're just kind of doubling down and something we couldn't solve right so if that's the case this needs more time to bake or marinate on the strategic side on the pitch side on the product thinking side right and then for morale reasons we're not gonna like you know is give it immediately to a different team or something like that you know we'll probably you know keep it in the back pocket for a while and then one day he'll come maybe time to try that again right it hasn't happened very many times we have fix-it Fridays that's excellent yeah we do this thing called a bug smash so that's like once in a while a cycle will be just fixing bugs we also have a two-week cooldown period in between cycles and the two-week period is a nice time to to like whatever smash whatever you want you know what I mean or fix up something that that's been bothering you so I think that's I think fix it Friday is a really good example of this deliberate resource allocation right you're saying like don't bug people with with this during the normal day and then we've allocated a time for that that's pretty good I I do think that fix-it Fridays regularly be too disruptive if you're working in six weeks and you lose a day you know what I mean like somebody was just on the edge of figuring something out and now they have to destroy the whole house of cards that they built up and then build it again on Monday that's very expensive so I would I would avoid that I would I would rather put these sort of fix it Friday tech concepts whatever they are at the edges of the cycle instead of mixing them into the cycle and that way the cycle is a protected focused zone what about refactoring refactoring well so you you you know anybody who's asking about refactoring knows that you you refactor in order to to build right you don't reflector something that's already done just to refactor it refactoring is a part of building something new so that's that's that's just work inside of the cycle to ship something do you believe every project needs six weeks no so we have we have two things that are drawn on there it says that the cycle is budgeted into what's called big batch and small batch a big batch project is where we have a team who expects to use the whole six weeks on something and small batches where we give them like through a three or four or five like little projects that are maybe a week or two weeks each and then they kind of fill in the six weeks as they can with those smaller things and this is really nice because this way if you have to cut things from scope on a previous big batch then you can use a future small batch if you want to like add some enhancements or things that you wish you had done before right so that works out really well in general the notion of six weeks is it's not like a magic number it's more like we want them to see that the end is in sight this is also on there they need to be able to see that the deadline is coming at them from day one because if it's not then they're gonna wait to make the trade-offs you don't I mean like when you have to make the decision you start to make the trade-off so if you can per say ah yeah we'll just we're gonna screw around for the first few weeks and then when it starts to feel serious then we'll then we'll make decisions you want it to feel like their decisions matter and impact whether they will ship or not from the beginning and the cycle has to be short enough for that to happen but then at the same time if you do like a two-week cycle every you've probably all seen that it's just meaningless chaos right because nothing can be done it violates the done rule so very few things meaningful can be done in a two-week cycle so we want the minimum size where something can be done and and then we don't want it to be so long that they can't see the end from the beginning what are your thoughts on weekly sprints that doesn't mean anything weekly sprint it doesn't mean anything does infrastructure get handled with the same cycles of work so we actually have a different team that works on purely infrastructure in the sense of like there's no feature related to it so if it's purely plumbing and it has to do with performance that's run by a different team and I can't speak to that I'm speaking to what we would call product here which is like changes in what the customer season uses how do you prioritize bugs bugs are not bugs are are the edges of what works their natural consequence of doing anything and every product is full of stuff that is bad that we don't like but it needs to have a core of stuff that's good that we like and once in a while a bug will pop up that's too bad and then we will allocate time to fix it and small-batch is a pretty good mechanism for doing that but we choose the bug the bug doesn't choose us unless it's like something just really really I mean you know what I mean if somebody's data is disappearing down the toilet every few weeks or something then okay we have to we have to solve that but very that happens very rarely I'm over time so that's uh that's that's what we could do yeah so feel free to continue the conversation [Applause] [Music]

Channel: SaaStock

Views: 32,915

Keywords: SaaS, B2B, Basecamp, Scale, Agile, Product, SaaStock, SaaS work culture, Work at base camp, How to get more productive from your employees, SaaS Product, Marketing strategy, SaaS Project management, How saas companies work

Id: ATpJBeuknaQ

Length: 30min 36sec (1836 seconds)

Published: Tue Apr 24 2018