How to Drive Bottom-up Adoption of Shape Up – Chris Boakes (Sr. Software Engineer at Zoopla)

It wasn't that we were working in a bad way, I think. And I think that's quite important to come across because sometimes you go into a place and you're like, we need a drastic change here. It wasn't that there wasn't that. We didn't need to do it. But I could see from having worked in it before that there was loads of value that we could get from it. And I think the first thing which made me want to suggest it was, I'd been working there a few months and it was over the Christmas. break that when we came back, one of our engineers said, Oh, I did loads of, I did loads of work over Christmas because nobody was bothering me. And I was like, Oh, that's interesting. So like we have, you know, this really skilled, a bunch of engineers who are capable of shipping really fast and shipping really well, writing lots of really good code. So what is, there's, there's a blocker here. Something that's blocking them from being able to do that faster. Can we just do this all the time? Can we get that kind of Christmas break feeling all the time? And that's when I kind of thought, okay, I'd mentioned Shape Up to the team really kind of ad hoc. I just kind of said, oh, we should, maybe we should look towards this. And then I thought, okay, it's time. I need to actually put some time in, read back through the book, really understand it. And I want to present it to the team as this is going to be a fundamental shift in the way of working. it's going to be really valuable for us. Welcome to Shapers and Builders, the show about better ways to deliver great software products. Today I'm speaking with Chris Bogues, senior software engineer at Zoopla. Zoopla is a real estate company based in London, UK, which is best known for its property search website, zoopla.co.uk. This conversation is part of a series about companies that use ShapeUp, a delivery framework originally created at Basecamp. If you've never heard of ShapeUp, check the show notes for a link to the video Shaping in a Nutshell by Ryan Singer, former head of strategy at Basecamp and author of the book ShapeUp, Stop Running in Circles and Shipwork That Matters. In our conversation, we dive deep into how Chris pitched ShapeUp to his team and got both his peers and engineering leadership to agree to trial a new way of working in an organization that's largely running on Scrum. Chris had previously worked with ShapeUp at a startup and when he joined Zoopla, an organization with hundreds of engineers, he immediately started spotting opportunities to improve the way his team worked. If you're an individual contributor who's thinking of adopting ShapeUp in your team, this episode is for you. Enjoy. So Chris, I'm actually super excited for our conversation. I've been looking forward to this for a long time. So happy to have you on today. It's great to be here. Thanks for having me, David. I want to ease a bit into our conversation on ShapeUp and maybe just can you give us a quick rundown of your background, your professional background and your current role at Zoopla? Sure thing. So I've been an engineer since the days of Internet Explorer 6 where I was creating GIF fullbacks because it didn't support PNGs. So I've been doing this a little while and I work for Zoopla now and they were founded in 2007. So they've been around um, quite a long time. And then most commonly known in the UK as a property website where you can find places to rent and buy, but they also have a bunch of other offerings. And one of which is Alto, which is a sales and letting CRM for estate agents. And that's the side of the business that I work on. So it's business to business that's been in development for 13 years. So again, quite an, quite an old product, uh, product, quite mature, um, and product and tech as a whole is 200. 78 so there's quite a there's a split there between the consumer side so the the website and customer tools and software as well as central functions like data science and on the side that i work on which is alto we're split into different domains so it's a huge it's a huge product and being split into kind of different areas of it has kind of helped us develop a deeper understanding of those sections um and we're split into nine nine small teams. So I work on a team of 10, which is six engineers, one QE, one head of product, one product manager, and one designer. And I've been working here just under a year. Cool. You've basically kind of answered all my follow-up questions that I would have had. Good job. Right. One thing I like to also ask about is the funding model. Are you all bootstrapped or self-funded or VC backed in any way? Yes, so we're owned by a private equity firm, a US private equity firm called Silver Lake Partners, and they bought us in May 2018. Okay. So 2018, it still feels recent, but it's five years ago. Is that anything you notice in your day to day in terms of how goals get communicated down the line or passed on? Any growth pressures that you're feeling in any way? No, we haven't really felt any of that. not too hands on, there hasn't really been any kind of interruption to making a great product and having really good iterations on that product. There hasn't been any kind of, they haven't really got involved to that extent at all, which is good. Okay. Yeah, makes sense. I'm really into, I mean, there's a current interest of mine. I'm really into understanding how TV series get produced and they always have this notes getting passed from the network to the production teams and that's what I think of sometimes you know you have these companies that own companies that pass notes sometimes cool Awesome. I just want to make sure that I really have a crystal clear understanding of the setup. You mentioned there's kind of a nine team split across nine domains. Is that just on the B2B side, on the Alto side that you mentioned, or is that across all of it? That's just on the B2B side. So there's the consumer side, which has their own setup. So because product and tech is 278, that's a huge, it's quite a big, it's quite a big team. It's certainly one of the biggest teams that I've worked on in my career. So yeah, they really have to be split down to be able to understand their own areas of the product and to create, to be able to iterate on it and to understand all of the problems. It's such a huge ecosystem to understand as a whole that it really makes sense to have people split up like that. I think teams. Yeah. Yeah. That is a really a huge organization for sure. I understand that you have a bit of a longer background personally with ShapeUp and you've been, we talked about this previously, you've been kind of the spark for ShapeUp now at Zoopla. Can you tell me a bit about your early experience? Maybe when did you first encounter ShapeUp? What were your thoughts around it? Sure. So I first came across ShapeUp when I was working at the company before Zoopla actually called Onvi. They were a startup and I guess you commonly see ShapeUp. being used in startups for a lot of great reasons, which I'm sure we'll get into in this podcast. But it was, it was, I'd like to, I'd love, I'd love to say that it was a kind of big bang. You know, this is incredible moment for me, but it really wasn't actually, I was just, I kind of floated into it. It was what they were doing there by default. So they already, I didn't join the startup right at the beginning. They already had this in place. and i was i was kind of like oh this is interesting i'm used to working in scrum for my entire career and this isn't the default here so i was quite curious about it but one thing i picked up on was um we didn't have as many meetings when i don't love going to meetings um so that's pretty cool and also i noticed that we were shipping quite fast we're shipping a lot faster so it felt like you know you work on a personal project if you're working on a blog and or whatever or writing some code in your own time it seems to go faster and it had that kind of feeling it felt like we were just we had a lot more momentum than i was used to um but i didn't i didn't really question it too much and it was only till i came to zoopla afterwards where i went back to scrum that i really started to see the value of shape up and i was kind of like oh no this this way of working was actually super interesting so it was it was a strange way to come about it and yeah i you would you'd think that it for some people it might just be a huge a huge shift and it feels great but for me i i didn't didn't pay too much attention to it until i started to go back to scrum yeah interesting there's this um song comes to mind uh what's it it's by counting crows this you don't know what you've got till it's gone that's true that's a great that's a great great analogy for that i um well you mentioned uh what you noticed at the startup was that because of ShapeUp it felt like you were shipping faster and to some people I think in the broadly let's call it Scrum Camp or Agile Camp that's gonna feel like a contradiction right because the cycle and the rhythm of ShapeUp is six weeks whereas the typical Scrum cycle would be two weeks and you are expected to finish like a self-contained piece of work in Scrum after two weeks much faster than six weeks right? Yeah. How does that not match maybe your actual experience that you've had? So Scrum can absolutely work for teams. There's a reason why it's an industry standard and there's a reason why it's been used so widely. It can be great, but it's not always great. And there's definitely a trap which some teams can fall into. And that trap can be things like a backlog which... becomes a kind of dumping ground for tickets. And the sprints which you mentioned, the two-week sprints, carrying them over. If your tickets, the point of it is to finish that and move on to the next one. But what's the reality of that? Does that actually happen? And a lot of the time, it's too short to actually, either you're looking for work towards the end of it, or you're carrying work over. And that's not always the case. As I said, there's a bunch of teams that work well with this and it's not a problem for them. But I have seen it a bunch of times in my career where you just carry tickets over and it's just this infinite, infinite kind of just next sprint, next sprint, next sprint, next sprint. And so I kind of, I feel like, you know, your original question where you're asking, you know, why aren't people necessarily shipping within that two weeks? It's that kind of too short of a timeframe to make trade-offs. with shape up you have that six week cycle it's it's long enough where you can see the end and it's enough time to make trade-offs along the way i feel like with that two week sprint it's it's too short and obviously in shape up yes the cycle length can change six weeks is quite nice and you know we're going to experiment i think with changing up the cycle length but the two-week sprints is is are you falling into that scrum trap or are they working well for you i think is the easy here yeah Yeah, I mean, just from personal experience, that resonates completely. I'd love to understand how, when you joined the team that was already using ShapeUp, how did they onboard you into the framework? Did they make you read the book or did they have like a custom doc that had all the nuts and bolts of it? Yeah, so I remember speaking to the head of product at the time and he said, have you heard of ShapeUp? And I said... nope he said oh we've got this kind of internal document which just had yeah like you say the nuts and bolts just to kind of break down i glanced over at it and he said oh there's another talk which you can send to i think it was probably one of ryan's talks um and i kind of yeah i i glanced glanced glanced over it but i didn't i didn't get invested in it too much because i didn't need to we already had the kind of pitching process nailed down we had the cycle length nailed down we had um a lot of things that you you would need to consider if you're setting up fresh, that was already established. And that's great because it means that you don't, you know, I think if, I think it would be quite a high barrier to entry if with ShapeUp, all engineers had to know the book inside out. I don't think it would scale well. And I think it would be really difficult to implement and, and you can see it's being adopted a lot. And I think that's a sign that, you know, once you get all these things in place, engineers can kind of just go along with it. And I think that's a good thing. Yeah, I think that's the way I was leaning with my question was, was there a speed bump or is it really easy in getting just glancing over something and going, yep, I can put me on a team coach? Yeah, definitely. And I think it is that it's the latter. You can just kind of jump right into it. I think if you're trying to move from another way of working to it, it's more complicated. And I think there's things that you need to consider. uh there's a lot of stuff to kind of set up and get your head around if somebody is probably doing that and there would have definitely been you know a moment when that startup began where they had considered ways of working and they would have had to you know educate the the ceos of the company and say this is where it's valuable all of that stuff was done for me and that's kind of cool because i'm i'm just an engineer i want to write code i love writing code i love solving problems with code And I think if you have to do a lot of work to make ShapeUp work, it may not be the right framework. But for the instances where I've used it, it has been really valuable. So that's how I would, yeah. Yeah, I mean, now you are kind of that person working to implement ShapeUp, right, in a way. So maybe that's a good time to start about, yeah, your... You know, you land at Zoopla and you're back in Scrum land. What were you thinking? What was your experience there and what sparked Shaper to consider Shaper for you? Yeah, so I joined and it was a super talented team of engineers. There was a bunch of really great people. I think when you join somewhere, even if you're a huge fan of ShapeUp, you don't want to walk in the door and go, hey, everybody, I have this really great way of working. Let's do this. Let's change everything. Because you don't know how they're working. You don't know what works for them. You need to pay attention to what they're doing and see what's coming up in their retros. What are the pain points? And to be honest, Scrum wasn't working. It wasn't working too badly for the team I was in. It's quite a senior heavy team. um we were definitely shipping but we had fallen into that scrum trap in places where we were you know carrying tickets over and i felt like there was it wasn't that we were working in a bad way i think and i think that's quite important to come across because sometimes you know you go into a place and you're like this we we need a drastic change here it wasn't that there wasn't that we didn't need to we didn't need to do it but I could see from having worked in it before that there was loads of value that we could get from it. And I think the first thing which made me want to suggest it was it was I'd been working there a few months and it was over the Christmas break that when we came back, one of our engineers said, oh, I did loads of I did loads of work over Christmas because nobody was bothering me. I was like, oh, that's interesting. So we have this really skilled bunch of engineers. who are capable of shipping really fast and shipping really well, writing lots of really good code. So what is there's a blocker here? Something is blocking them from being able to do that faster. Like, can we just do this all the time? Can we get that kind of Christmas break feeling all the time? And that's when I kind of thought, okay, I'd mentioned ShapeUp to the team really kind of ad hoc. I just kind of said, oh, we should maybe we should look towards this. And then I thought, okay. it's time i need to actually put put some time in read back through the book really understand it and i want to present it to the team as this is going to be a fundamental shift in the way of working but it's going to be really valuable for us so you know people can come to shape up and they could they could have they could have had really big problems i don't think our team had huge problems at all yeah um which is good because it almost makes that transition to shape up a lot easier um i think if you're if you're so far um really struggling with scrum and things are going in the in it you know in the completely the wrong direction um is there work to do to to move towards shape up maybe can can you just go straight into it i don't know um i mean i don't i haven't i haven't worked in enough places that use it to have to give you a good answer for that um but we we were actually we were working okay which made transitioning to it a lot easier interesting um i mean i talked to a bunch of teams where they do feel stronger pain and then ShapeUp was a fix. But I've also, to be fair, I've also heard stories where it was more looking for upside than kind of fixing things. So that's definitely cool. I'd love to understand, because you mentioned you first dropped it kind of ad hoc, but then you had this process of, okay, now I want to pitch this and give it a real shot. How did you structure that pitch? What were you anchoring it on? So I kind of... went down the route of these are really common problems that software engineers face. And we have a, you know, we have a few of these problems. One of them was that we were spending almost an entire day on agile ceremonies every two weeks. So every 10 days that we're working, almost an entire day is spent on retros, refining, and, you know, we try to make them as fun as possible, but There are certain things that bring me joy. Like I really enjoy writing code. I love solving problems. I've mentioned that. I don't wake up and go, oh great. I can't wait to add some acceptance criteria to a ticket, which says change the border from hash CCC to hash DDD. It doesn't bring me joy. So there was, you know, I'm an engineer pitching to other engineers and also to product. So there's two, there's two strands. So there's one. product need to understand the value and how it can really help them. And there's also the engineers. It's like, how does that affect your day to day? So I actually, I was quite, I wanted to make it really good and I was quite serious about it. So I put together like a full presentation. I read back through the book, I made a bunch of notes. Um, I, I, we actually had an upcoming project, which would have been the perfect fit for this. So I was pitching it as let's trial this for this project. Um, it was a perfect fit because we were building a developer portal and a developer portal the audience and the problem we're trying to solve um is engineers which we are so it's kind of the ideal and it's brand new so it's the ideal project for this so i kind of went and i created i created i let i put quite a big space in the calendar to answer questions and there were a lot of questions um but i put together a presentation i went through that presentation kind of in detail i tried to be as passionate as possible Because I was passionate, I really wanted to give it a try because I thought it could be great. I love that you thought about the audience in terms of product and developers. What were you pitching to the product side of, I guess, to the product manager on the team? What was their upset going to be? I think the good thing for them, there's a couple of really great things from ShapeUp from a product perspective. And that's why you commonly get product. um has a product and product trying to implement it it doesn't always come from engineers and the upside and it's quite it's quite an easy sell to product because we'd we'd kind of missed our quarterly objectives um from the last quarter and we were rolling into this next quarter and the the upsell of hey we're going to work in a six-week cycle i think we can pretty much get our entire quarterly objectives done if we purely focus on solving one problem is a great thing to suggest because, you know, they're going, how do we get stuff out the door? How do we ship a lot of value to our customers? And if you can offer a solution for that, even if it's just a trial, great. Immediately, like there's a huge, there's a huge upside to that, especially if you're working within quarters. If you're working in quarters and you're saying, hey, actually, we can probably ship most of this in about six weeks. There's trade-offs that, you know, you need to give us that focus time. You need to. kind of protect the team in some way. Yeah. But that's the, that's the kind of product from a product perspective, it's super valuable and also giving the team autonomy. So like getting engineers really involved in making those trade-offs so they don't have to be involved in the day to day because, you know, product going to stand up every day is, does that need to be there? Um, I mean, we have, we'll get into it later, I'm sure, but we have a product check-in where we can discuss our trade-offs with product once a week, but. That's not in the book. That's just something we decided to do. But it means that product can then think strategically about their product. So it frees up time for them as well as for engineers, which is great. Yeah, for sure. I mean, just out of, again, personal experience, it resonates so much where as a PM, you're also often filling this PO role in the scrum process and having to, just in time, deliver the next batch of things to do. And it's, you know, you're... always thinking about the next one because it starts so soon and then all of a sudden you have six weeks of breathing room for sure. You mentioned that you put something on the calendar to give this passionate pitch and that there were a lot of questions. I'd love to understand what the main themes of those questions were. Yeah, and every time I talk about ShapeUp, I've given this kind of presentation to a few different teams now. and the same questions definitely come up even if you go through them in the presentation and the most common one is bugs what do we do like we have all of this stuff we have all the stuff that we're doing like what do we do with those and there's a couple of answers and there's a thing that we had to do which is not in the book and when it came to bugs it's that it's exactly as it mentioned in the book so the answer is just you know, can it go in the cool down? Do we need to do this right now? Is it more important than the value that this product cycle is bringing? Yeah. Um, but we, we were in a kind of unique situation where we had a bunch of manual tasks that we were doing day to day. We were moving towards automating them all. And to be honest, we're quite close to that point now. And they, they can't just go away. We can't push them to a cool down period because they have an immediate customer impact. And. I think you have to look at things and it says it in the book to take parts of it, which are great, but also you don't have to do it exactly by the book every time. Yeah. So we had basically somebody on the bench. So one person for the first cycle who was basically just picking up these day-to-day tasks. And we were trying to frame it in a way of don't just pick up bugs, come back to the cycle if you're not doing them. try and be involved in the team, but it did protect the entire team to focus on that one problem. And it was super valuable because we saw that value. We saw that what happens if we focus and what happens if we don't get distracted by bugs. And, you know, we're moving towards not having that person at all. We've had that kind of person for the last few cycles, but gradually that role and role, that role is becoming more and more redundant as we become more mature. Interesting. Cause, uh, um, Was there somebody volunteering for that role or was it a shortest straw kind of situation? Someone volunteered very kindly. I mean, I definitely wouldn't love to take on that role. It's not the most enjoyable thing to do, but it was really valuable also because it highlighted what we were actually doing day to day, whereas before it was split between the teams. There was no real way of quantifying. how many day-to-day distracting tasks are we doing? If one person's doing it and you can monitor what that person is doing every day, you can kind of go, oh, all of this stuff was a huge distraction for the team. Maybe that's why. we weren't shipping on time and you know there's a it really highlights that but yeah i did feel did feel definitely very sorry the team were extremely appreciative of that person and cool actually for the future cycles we split that role so we did we've done three week three week because six weeks is a long time for one person to be doing it That's, I mean, it is interesting. And you've mentioned this in the beginning that, you know, in your words, you say, you said you're working with a great bunch of engineers. And what I've seen that great kind of translate to is at least for ShapeUp, having a pragmatic mindset and taking ownership of what you do and wanting to be involved in the, what is the product that we're building. Whereas, and I think that's totally fair for some, someone to have a different role where they would, they just love being in a, you know, in some teams you have this solution engineering role where you just there to cater to these one-offs from B2B customers and so on. So, and actually I've seen, I just spoke with Stefan Bernmann-Valenta at Prosperity Solutions in the last episode and he mentioned how now that they have these distinctive roles that engineers are super happy to be able to say, I'm more of a solution engineer, I'm more of a product engineer. Do you see something in your team as well? Or are you just all laser focused and wanting to build product? I think, I mean, it's quite difficult because I'm primarily a front end engineer. And sadly, this role has mostly been going is quite back end focused. So we, you know, the two front end engineers on our team, me being one of them, haven't really had to jump into that. I mean, I'm personally, I love the product engineering side. I'm very product focused. I can't speak for the rest of the team. I'd have to ask them. But people don't seem to be completely averse to doing that role, especially as it becomes less and less time consuming. We've actually, throughout the cycles, we've been working towards automating a lot of that manual effort, which that role. had. So when it comes to fixing bugs, there is something which is quite satisfying about this customer is having this problem with blah, blah, blah. I'm just going to ship a fix. And then you get this great message saying, oh, we've, we've, thank you so much for fixing this and turning it around so quickly. And there's something satisfying about that. Absolutely. It's just, how does that work in your work, in your workflow? How does that work with your cycles and the other, the other product vision and the other things that are also super valuable is weighing it, weighing it up and getting the right balance. Yeah, for sure. And then if you have the space for it, you feel good about saying yes to these requests, right? Absolutely. Yeah. Cool. You mentioned how kind of everything came together where you were in the perfect situation because you were just looking to start work on the developer portal. Was it then you also that wrote the first pitch or how did that work out? So this is another thing that we didn't do exactly by the book because it's quite difficult if you're coming to brand new with an entire organization which is working in scrum to do something against the grain and completely different so you have to you have to be pragmatic like you say um so for the first pitch we collectively did it so in the book i know it's supposed to have you know representatives from design representatives from engineering representatives from product we were doing we it happened to align with our quarterly product planning. So we have a thing called big room planning where we look at the quarter and we look at what we're going to do. And that's something they already had in place. So the beginning of the first cycle, we work mostly remotely, but we are all together in one room. So the actual first pitch doc was, here's the problem. And the problem was that we have a bunch of third parties who want to integrate with our solution and we don't have a platform for that. So we want to provide something where people can ingest our APIs, they can read docs and create integrations to go into our marketplace. And I was kind of thinking this is perfect because we have a full understanding of the problem because we are engineers. If we were working for another company, we could come to this and say, what does good look like? So we had that quarterly planning. We're all in one room. So we did that kind of finding the elements bit before. So we went through and we sketched out that really high level customer journey. So, you know, they need to land on a page, they need to log in, they need to register, forget password, they need to create an integration, these really high level things. So that would be a part of the process anyway. And then we went into that slightly more detailed, getting the right amount of detail, finding the elements where we were going, okay, we're on a page that's got a form. it submits the form we've got a bunch of questions here like does the name need to be unique what do we do about errors all of these things that naturally would occur in a pitch doc um and the appetite was it was an easy one as well because we were just going to trial it in a six week cycle we we're just going to say let's just see what happens let's let's see how this goes for the first one the the appetite is really meaningful when you when you get more mature and once you've done it a bit more. But for the first one, certainly we were kind of just like, let's stick with six weeks. It seems like the golden amount of time. So let's just see how this works. So yeah, that original pitch doc came about as more of a workshop. And I think that's okay. It did have the entire team. I know they talk about, you know, you don't want to distract the entire team when you're doing these as it progresses. But for the first iteration, being all in one room, And working in that way was super collaborative and it was great. And I think that's a good thing about ShapeUp. You don't have to just have two engineers and the rest of them can't do it because of whatever reason. Let's be pragmatic. What's valuable works for your team. And if people are getting involved in that workshop process, especially because they are the customer, if that works for you, then great. It's not a huge amount of time outside. It gets you more engaged with the product. Yeah, for sure. I understand, though, that it was all this time still you leading all this endeavor, or did you try to shoulder the pressure of, you know, for example, running such a such a workshop? So that takes effort. Yeah, I wasn't really running it as a shape up thing because we were kind of doing anyway. So it was it was super easy. So we had product product and we had delivery at the time kind of really helping out with that workshop. So we didn't I didn't actually the effort came. when we were trying to figure out, you know, what does day to day look like? What's the hill chart? What's the scope? What's the task? Like that kind of area of it, which is more shape up than like, I know they don't talk about, you know, we don't use planning in the book, but just finding the elements, it was quite easy because we were kind of doing that anyway. So we were in a really great position. to just do that and for it not to be very disruptive and just kind of roll into it which was a really nice way to ease into shape up yeah and i imagine that just having everybody in the room also for the first cycle for sure gives everybody the understanding of what does it look like to find a good level of abstraction not too deep not too high um exactly exactly because then down the line they are going to get a similar input for the next cycle right at and then um something where if you're coming from Scrum and maybe you're more used to getting spoon fed acceptance criteria, this isn't that with shape up, but you've seen firsthand how the shaped package gets made then. Yeah, absolutely. Yeah. And I don't, I still think we we're still working to get this pitching process, right? Like we're still not there. But that's okay. I think you have to accept that you're not going to get it perfect first cycle. You might not get it perfect second cycle. You've got to work towards it. And that's kind of interestingly why we kept one of the agile ceremonies, which was retrospective, but we just do it every eight weeks. So it's not particularly tight. Instead of every two weeks where you can't get stuff done, how do you create a good feedback loop? I mean, I'm sure there are other solutions, but retrospective is a good feedback loop. It's how is this working? What can we improve? Can we get our pitching process better? Was there anything that was too distracting? What can we do in the next cycle? It's fine. I think you can definitely pull stuff in like that. It's what works for your team is the kind of key takeaway for me. Yeah, definitely. Hey, I hope you're enjoying the conversation. I wanted to take a moment to thank you for listening and to let you know about the Shapers and Builders job board on shapers.builders. Yes, that's the domain. You'll find jobs in software development, design, product management and other roles at companies that work with ShapeUp. Many of these roles are remote and teams who use ShapeUp generally run at a more sustainable, healthy and meaningful pace than the hamster wheel of two-week sprints. So if you're looking for a job in tech or trying to find great people, head over to the Shapers and Builders job board at shapers.builders. Now let's turn back to the conversation. I think that's a good point to look a bit at where you are now. So I'd love to just get the, yeah, get the elements of your implementation of ShapeUp that you have now after, what is it, three cycles? Yeah, so we're actually coming, we're kind of mid third cycle. So it's still really new for us. It's quite an interesting point to talk about it because. We've taken some learnings. We've got a lot of learning to do. There's a lot that we're not doing that we can do better. And there's a lot that we've done, which has been super valuable. Yeah. So let's pick those apart. Yeah. Cool. Where do you want to start? Things that worked or things that you're still struggling with? Let's go with, let's start with, let's start with the positive. So things that work. Things that worked. So the first iteration of this was hugely successful. We had delivered our develop a portal within that timeframe. And product was super happy. The engineers were super happy because, you know, we, we had all this focus time and we, we were really involved in coming up with a decent solution. So making those trade-offs along the way was great. I think we, we started with, I think it was 10 scopes and 30 something tasks. And we ended up with 15 scopes and 80 something tasks. and we completed i think 55 or 60 tasks or something and the rest were kind of nice to have and that's a great sign that we were making trade-offs along the way we were going this isn't important or this is hugely time consuming and not that valuable um doing that to be able to release it in six weeks was something we hadn't done properly before so we were like that was great it was really interesting to um use it for a project where the whole team was super engaged um so product loved it the engineers loved it we had a few kind of pain points around tooling but it's not really super relevant to talk about that i think for this podcast because it's you know there's easy easy ways to solve the tooling point but most of the stuff that came out of the retrospective was super positive it was you know it feels really refreshing to do this um so yeah that was you know that was really nice we then moved into the cool down phase where we were able to do a bunch of kind of tech health which was really nice still think we've got work to do on our cooldowns but um yeah we can talk about that yeah um and then the the second cycle that we did again it worked really well we had the whole team for both of these cycles we had our entire team of 10 working in the cycle and that is quite different to the book so the book is and one thing that i'd love to get to is spinning up and spinning down teams so Who do you need for this? Just get the people in that you need for it. And then for the next cycle, what have we got? What's valuable? Who do you need for it? That works really well on organization level. It's quite difficult to do at a team level if you've only got 10 engineers. But in our third cycle, we have done that. We have actually split the team into two. We had one really back end heavy kind of value proposition. And we had one that was really heavy on the UI with a little bit of back end. So we've, we've split the team into two and that's where you really start to see a lot of product value because you've got, oh, Hey, we're not just doing one thing in six weeks. We're basically doing, we've got two separate strands. So we're shipping more, we're shipping, we're shipping faster. We're shipping more regularly. So I think it's worked so far. It's worked really well for us. I think there's, um, there's still things that we want to change and there's still things, there's still learnings that we're taking along the way. Absolutely. But I think. people have seen the value and other teams have kind of been going oh what is what's this team doing shape up thing um why do they look so happy yeah what is this like really like fresh looking engineer doing over here um yeah so i think um uh overall it's been super positive i think we've had a lot more focus time i think we've shipped a lot of value um which is which is really what which is what we want to get to. So I think we're healthier and we're happier than we were before. Yeah. In terms of the what doesn't work so well, what are we still figuring out? We need to nail down our pitching process a little bit better, I think. At the moment, we're still working with kind of this quarterly objective thing which is going on in the rest of the company. And it's how does our shape up cycles? How does that fit into that? How do you leave time to get customer feedback and understand what's valuable? So we've got work to do that. And I think that at the moment, the kind of pitches on the engineers aren't pitching as much. We can come to product and say, Hey, we've got this great idea, but it tends to be smaller things that we just want to do and cool down. Yeah. less big cycles. I think there's some work to do around like nailing down that pitching process and getting close, like even closer to the problem than we currently are. Um, but that also comes with time. It's, you know, we can reflect on that and we can say, Hey, what did this pitch look like? What could we have done differently if we were to do this pitch again? So it's what does your feedback loop look like? Have you got a healthy feedback loop? Can you speak to product? We're, we're really lucky because our product, um, our head of product is. really loves it too she's really passionate about it so she's really open to listening to ideas from the team and that's really healthy it's great because you don't want somebody i think if you have product um coming to you with just hey let's do shape up yeah it it can be kind of you know as an engineer like oh it's another thing that we've got to do you know it doesn't really feel like if you have a really healthy if you have a healthy uh feedback loop with with product it's you know it's great so we can we just keep keep going keep keep doing those retros after every cycle getting feedback what can we do differently um so we we've got work to do around our pitching process and i think we've got work to do around our cooldowns as well because i think they're supposed to be a little bit more engineers have a bit of breathing space to just pick up things but i don't think we're at that point at the moment i think we're potentially trying to do too much in a cool down period and then it then it just looks like a sprint um and you're back at where you were so i think we've got work to do to improve that um and to create more breathing space more learning space um and just focus on getting those kind of bigger cycle pitches looking really nice for the team so yeah we've we've got we've got work to do there and also we wanna we don't wanna have this bench person role forever that's It's not really a part of the book. It's not really, I don't know. But it is an implementation that a lot of people, a lot of teams naturally gravitated towards. So literally, I don't know, I would say eight out of 10 teams that I speak with, they have this on-call person, they call it, or rotation. That's super interesting. Yeah. That's good to know. I took this from my last company who had the same thing. I was like, this isn't mentioned. but um maybe yeah maybe that's just because i think when base camp have done this right it's a very that it's worked for them without that they don't necessarily need that role and that's great exactly it's like what's the reality of other teams who are working in a scrum way like how does that transition look is it okay to have roles like this just while you're working towards something i think it's absolutely is and sometimes just have they just have more bugs they just have more day-to-day tasks if your product is 13 years old you're gonna have bugs there's gonna be stuff um you can't ignore it you can't go hey we've got this really great way of working sorry sorry we're not going to do any bugs you know it doesn't work yeah so how does it work in reality Yeah, exactly. I think that's just, yeah, like you mentioned, it wasn't the reality at Basecamp, so it wasn't in the first book. But I think generally, it's been acknowledged that this, you know, Ryan even has this course now that he's calling Shaping in Real Life. So there's, and he's stressing that with this course, I think. That's cool. That you have to tailor. shape up and you can you encourage to uh one thing i've you mentioned you're still iterating on the pitching process and feeling like engineering is moving too far from that um have you discussed ideas for how to rectify that or what are your thoughts on getting yeah so i i'm actually talking to product this afternoon, probably should have recorded this podcast tomorrow about a few ideas as to how we can, um, like kind of nail that down because the, the bets are quite interesting because the bets work really well. If loads of teams are working in shape up and you can basically go, here's a bunch of bets, you know, CTO or, or whoever's in the room. What's what's, what do you think? What's really important from a kind of, you know, the direct strategic direction of the product. Um, We kind of work where product will have a rough idea that it was based on customer feedback. It's not just we want to do this thing. We have a huge kind of user UX team user research. We have a lot of data on how people are using our product. So they already have an idea as to what's valuable. But the problem with that is that I think the teams are like sometimes. more detached from that problem space. So in the scrum world where you're just picking up tickets, you're very detached from that space. Yeah. You're kind of, you know, just looking at what's my piece of the puzzle. I've got to change the button color. I keep using that example. But like, yeah, and that wasn't what we were. We didn't have a button color with ACs. Don't worry. But you're quite detached from, you're quite detached from the problem. And it's how do we get closer to the problem? So like, how do we get? that kind of user research how do we understand how people are using this product because it's a big product and you know product have a big understanding they have that strategic direction it's like as engineers i think there is value in us understanding that because when we're making trade-offs the more we understand the original problem the better calls we're going to make because we can go you know this this customer is having a problem here and actually this this this part of the this scope doesn't really contribute to that so we can make that trade-off if we're if we have better access to the original problem if we have a better pitch dock um so betting i don't i think we're quite far off getting an actual betting table set up um i think that's okay i think i've kind of accepted that getting a betting table would be quite far in the future. We'd have to have a lot of different teams working in it. Yeah. And also it's a complex system with loads of domains. Betting table can work great if you're in a startup and you've got a brand new product. Easy. It's there from the start. Keep doing it. If you've got a 13 year old product, it's harder to get a betting table set up, I think. I mean, it can be done. I'm sure you've chatted to people who have done that and done it well. But I think we're not there yet. I think there's work to do if we wanted to get towards that place. So what ideas are you going to pitch if you want to share? So I want to nail down what a good pitch looks like. So there's sometimes at the moment, it's a little bit of a kind of mishmash of this is part of a design, but we haven't, the team haven't breadboarded it. Or maybe we have breadboarded it for some pitches. And it's kind of. how do we like what's what process is going to be put in place where it's the same process every time the document looks the same every time we're not getting you know for the last cycle we had it we were kind of falling into that trap of where we had more of a finished design before we start and that means we are more detached from the problem space and it's like how do we avoid things like that because we did it really well for the first cycle how do we make that work for every cycle yeah so those are the ideas i want to kind of come in with and and say, how do we get a really nice pitch doc and what's the right amount of detail? How do we define that? Because at the moment, it's a bit unknown what level of detail we're going to get when we start, if that makes sense. So we really need to nail that down. Yeah, definitely. I mean, I can see that trap of, now I'm going off on, I'm speculating, but I can see a trap of where in the second cycle or in follow-up cycles, you're like, All right, now I'm going to write one big thing. But again, I'm just going to write it myself. I'm going to hand it over and not lean on leverage that involvement. That was so great in the first one. Yeah, exactly. And it's also, you know, how do you do that really nicely in a remote setup? Because the first one, we're in a room. We've got some whiteboards. People are really engaged. How do you keep people engaged? How do you get them really excited about the problem? How do we do that for all the pitches? Because the first one, it's a brand new product. So people are already excited anyway, because it's fresh and new. If you're going back to iterate on something, it can be less exciting. So how do you make that exciting? How do you get people involved? And it could just be as simple as, what's the data? What's the usage like of this current product? what some of the feedback we're getting let's have a look at that raw feedback and you know some engineers are super interested in that because they're like we made a trade-off and this person doesn't like this thing or whatever it is i think it can it can be really helpful for for us to move a bit closer so i'm curious to i kind of want to get the the few things to answer your original question is i'd love to get the problem fleshed out more so we have a little bit more detail about the problem i'd love to see um the appetite actually considers not necessarily a six-week cycle because in our current cycle we've got uh we've got two strands but the second strand is really we'll probably work with this three two three week cycles there's nothing which says you have to keep doing six weeks yeah is then you fall into it you don't want to fall into the trap of it being a six-week sprint or something silly so you you kind of want to you know always question what is the appetite so nail down the no other problem nail down the appetite get the right amount of detail for the solution and also create more time for the risks and rabbit holes. Because at the moment, we can call out risks and rabbit holes and we can say, this is a problem, but we might not actually have time to investigate it. For the first one we did, and we were able to get that thin-tailed chart of when we're going to ship really thin. We've gone into a couple of them where it may not be as thin-tailed. It's how do we make that thin-tailed? How can we improve that? So I kind of want to improve that entire process, get that pitching process really watertight and obviously iterate on it, get feedback on it. Ask engineers, do you think you had enough detail? Did you have too much detail? Find what works for us. And even if it ends up being not the same as what's called out in the book, that's okay. Maybe we do need a few more detail in certain areas. Maybe we need less in other areas. I think that's fine. It's just, it's, it's finding, okay, engineers, what do you think product? What do you think? Like, what do you want? What do you want to get out of this? What's valuable? Constantly asking that what's valuable for us. How do we get better? How do we ship faster? How does our day to day look? Constantly asking those questions and making it really good is kind of key. That's, that's what, that's where I want to get to. It's like getting a good feedback loop and getting the teams really engaged. I mean, it's clear to see your passion for this. And I want to just get into that topic a bit more where, you know, you come in as the new guy. And after just a few months, you have the audacity to suggest switching the way of working in a way. What do you attribute it to that you were feeling confident to step up and suggest these things? I think it was a mixture of I knew how good it could be for us. As in, I knew that if we really... Because I knew that everybody was really talented. I knew we had quite a senior heavy team, which is shape-up. I mean, you can absolutely roll it out to less experienced engineers, but it works very well quite quickly, I think, if you've got a senior team, you're questioning things already. Yeah. So kind of, I guess what gave me the audacity to suggest it was just not going in with everybody, look at this amazing thing. We have to do it like this forever. It was, let's try that. Let's see how it works. Like, here's an idea. These are some of the pain points that we have. Let's address those pain points by just changing the way that we're working because we've been doing retrospectives every two weeks. um which is quite a short amount of time and yes you can change the retrospective length but you can't meaningfully change anything in a two-week period i don't think maybe you can maybe that works for some teams and that's great but for us you know just doing keep keeping iterating keeping to iterate on scrum um just didn't keep iterating keep iterating on scrum it wasn't yeah wasn't working so Just going in and saying, hey, like, here's how it would work for us. Here's how it would work with our upcoming project. What do you think? What are your concerns? Like, do you want to give it a trial? And I basically said, you know, so that nobody was being called out on the call. I said, just private message me and say, are you up for giving this a go? So then I just had my Slack open. I was just waiting for messages, hoping that nobody's going, no, I'm not comfortable with this. Yeah. Unfortunately, people were like really open minded not for giving it a try. But it can be hard if you go into a team and your team's been working in a particular way for a while. It can be hard to go in and say, you don't want to be the person that goes in and says, I've got better ideas. And that's not the case. Like it wasn't, you know, I don't have better ideas. It's saying, hey, I've come across this before. Why don't we give it a try? Let's just see how it goes. If it doesn't work, we just go back to it. I think some people are a bit scared to jump into shape up because they think, what if it doesn't work? It's like, well, you're not going to ship anything. You're still going to ship something. It's just exactly. Even if you don't hit that six week marker, find out why you didn't, you know, what was, what was your shaping process like and make it better. You don't have to. Yeah. You don't have to do it by the book all the time. It doesn't have to work first time. If it doesn't work for you, then go back to the other way. What's the downside? There isn't really one. So kind of selling it in more as a let's just try it out and see if it works. And fortunately, it worked for us, which is good. It would have been quite sad if we had to go back to Scrum. Yeah, I can understand that. We're coming up a bit on time, and I want to make sure to... there's one thing i want to hear of you which is you've now rolled it out to one team your team and you've started experimenting with splitting the team which is kind of having more teams of shape up in a way i guess but how are you thinking about rolling it out beyond the the original team yeah so there's i'd love i'd love to see um us getting it more at an organization level even if it's just for alto which is our kind of business to business product I think it would be quite difficult to do that across both products. I think it's okay to just do it per product as in if you had a, if you had ShapeUp, if most of the teams in Alto were working in ShapeUp, you'd really have the ability to go, you know, this, we could get these engineers working on this. We could get these engineers, we could get engineers pitching to a different level of person. You know, there's, there's a lot of, I think a lot of value in having that, but also. other teams you know scrum may be working okay for them and if it's working for them and you know they're getting they're getting what they need to done and they're happy then you know you can keep doing it but the good thing um well i guess a couple of teams have have reached out and said could you come and talk to us about shape up and i presented the idea to directors the cto already had some really great conversations and some good feedback from them And I've been given the green light to help facilitate adoption for other teams. So if other teams want to try it, I can be there to run a workshop or an education session to help guide them for their first cycle and kind of do a Q&A, which is super helpful because I do think that it can be tricky if you haven't worked like this before and you don't have anybody guiding you. I think it's actually quite hard. I don't know. I mean, maybe you've had conversations with people where this, where they have done it and they haven't worked like it before, but I think it would be tough. I think it'd be really tough if the team just went, we're doing shape up and hadn't experienced it. Yeah. Bottom up for sure. I think the cases where I've seen it work was where the head of engineering, you know, someone in a leadership role is coming in and saying, we're going to try this. And then it's kind of a mandate, right, of sorts. But yeah, bottom up. Yeah, bottom up, yeah. Which is actually, I mean, you can look at it as a good or a bad thing. It's good because we have the flexibility to work in a way that works for us. If it was mandated the way that we work, I'd have to go to, you know, leadership and say, hey, let's change the way we're working for every team. And it might not work well for some teams. It might not work well for, it might work well for other teams. Then what do you do? Whereas if you have the flexibility to understand what works for your team and then show that value to other teams and roll it out that way, it's a little bit more kind of organic. It can feel like you can demonstrate that value to leadership rather than mandating it. And I think that's quite a neat approach to rolling something like this out. So even if no other teams work like this, and I know there are teams who are, I think, going to try it already. So I know that's not the case, but. um even if nobody didn't it was just working for our team there's still value in that like i'm happy a day today like we we've got really nice iterative approach to our product and that's it's quite selfish but um it's good i think if you're passionate about it to also speak to other teams and say hey like i'm here if you want to like go over any concerns questions um let's talk about it and i know there's one team who are just going to work towards it like they're quite far that they're quite heavily on the scrum side and they'd like to use it but they feel like it might be too soon so it's like okay let's focus on vertical slices of our work and some of the themes of shape up yeah not doing it and then moving towards it and that's okay too i think there's no right answer for this stuff um yeah and i think if you look at shape up and say this is the only way this is the right way this works for every team i think that would be a mistake i think if you're if you come to it and Take everything, like take really great learnings from the book. It's 15 years of Basecamp or whatever. It has huge amounts of experience, wealth of knowledge there, a lot of learnings. But that's what worked really well for Basecamp. There's nothing which says you can't take stuff from this that works for your team and apply it to your team because take learnings, find what works for you, and you'll have a kind of happier, healthier product, I think. Yeah, for sure. You briefly mentioned now getting to talk to the CTO and leadership about ShapeUp. What were they concerned about? I think the concerns were, you know, what's wrong with the scrum process? As in like, where, because it's obviously, there's a reason why it's an industry standard and there's a reason why a lot of teams work with it. And some of the great challenges. which I wasn't actually really expecting was, can you like take a radical approach with Scrum? Can you fix it with Scrum? Could you shorten, you know, could you have, you don't have nothing which says you have to have those ceremonies every two weeks. Why can't you just have a ceremony every four weeks? And it was really great conversations about that. And it's, it's actually super nice to hear. different people's perspectives and some really great challenges about which I hadn't even considered. I didn't have great answers for at the time. And I was kind of, I guess my main response was if we're finding a way that works really well for us, even if it could be fixed with Scrum, then what's the difference? If we've got a really nice way which kind of works for us, why fix it with Scrum if there's something else which can, even if it doesn't solve all of our problems? If it solves some of our problems, what's the harm in having it? And I think they were really receptive to that feedback. Um, and we just had some really healthy conversations about it. And, um, you know, they've all read, I, I kind of, I wrote a blog post about our experience and posted our engineering blog. And a few people have picked up on that and asked a lot of questions and. I actually really enjoy having conversations with people about it. I really enjoy the questions that they ask. Me too. Yeah, it's cool. I mean, you have a podcast about it, so I would hope so. But I love talking about it and I love kind of hearing people's perspectives. And I actually really like it when people challenge it and question it. Yeah. It really helps you kind of ask the right questions about is this what could we do about this approach? Like that's an interesting perspective. And Yeah, I love I love hearing people's perspective and I love hearing what they think of it and how it's worked for them. Yeah, I think I am again, I'm speculating, but what I've just from my experience, I've heard leadership be concerned about in having multiple ways of working inside an org is you know, moving people from one side to the other and having, you know, not having a shared understanding. But you've kind of partially also addressed this fear in the very beginning when you were like, I got dropped into a ShapeUp team. It didn't take me long to figure out what I had to do. Like, it's not rocket science. Yeah. I think, I guess one of the, and this isn't a criticism from Zoopla, but one thing that comes up. quite frequently, and I'm sure you've had this discussion is what if the engineers are less experienced, like, can they make trade-offs? Does it scale well to teams that are less experienced? And I think that's a, it is a really valid point because when you get to senior level engineers, you've naturally made trade-offs in your time in one way or another, you may not have called the trade-offs, but you've had to make calls as to. And you've questioned things, hopefully, once you get to that level, you're used to pushing back and questioning and all of the stuff which really helps when you're working in a cycle and you have to make those trade-offs. How does it work for engineers who it may be their first time making trade-offs? And I guess my response would be, don't just give it to a team of less experienced engineers. Have some senior representatives. Work with them. Have a conversation. Maybe let them do some shaping. see how they go, feedback on that, kind of guide them. And there's always learning. And that's, I think that's the case for anything you do. If you're, if you want your more mid-level engineers to become senior, it's good to guide. It's good to provide feedback. It's good to, and it's, it can just be a part of that process. It's, you know, if they, if they want to learn and they're keen to learn, then why not give it a try? Like it's, it doesn't matter if you get it, if you. don't get it right first time. Nothing's going to explode. It's software. It's fine. You'll survive. Look at the bigger picture and try and explain to them what the value is and get them to understand what the value is. So yeah, I do think that the more mid-level engineer or less experienced engineer criticism is valid, but I don't think that there's no way to solve that. There's absolutely a way to solve that. And it's just... um what's your setup like and there'll be a there'll be a way to solve it i'm sure like i don't think it's um it's an unsolvable problem which should block you from using shape up definitely and i mean of course i agree with you because as you know i'm also quite passionate about shaper but in a way with if you force somebody more senior like yourself into a getting spoon-fed tickets situation you are capping the upside in a big way whereas if you allow people like yourself to contribute, push back and shape the thing that gets made and then maybe have to grow other people into being confident to do the same. I mean, all you get is upside, right? Exactly. Exactly. And also, yeah, it goes back to that. What's the downside? What's going to happen? I think you can look at it as really black and white and it's like, it doesn't need to be like that. You've got a potential huge upside. and if you don't you haven't got a massive downside it's a yeah it could be great it could be like this even if it's down here you've still made an improvement and if it's the same as you were then you've lost nothing in the first place so like it's um it's i think it's nice to you know have these conversations but a lot of the time part of me is just like just try it just try it see how it goes find out what works there's people to guide you you know it'll be okay it'll all be okay i think that's Those are looking at the time. Nice words to kind of wrap up on. I love that you're so passionate about this and through your blog post, you mentioned people have reached out to you. If you continue to be available for that, what would be the best way for others, listeners potentially to get in touch with you? There's an email on my website, which is just chris at chrisbokes.com, which you can email me at or I'm on LinkedIn, chrisbokes. Twitter, CBOX. I've had a few people reach out to me and I love talking about it. So likely the answer will be yes. Cool. I'm going to put that in the show notes and I'd love to check in in a year or so to have the same conversation and see how you've rolled out ShapeUp further and iterated on your implementation. Definitely. Thanks a lot for having me. Cool. Thank you so much. This was really amazing. Loved it. Cool. Cheers, David. Cheers. There you have it. I hope you enjoyed the conversation with Chris. I certainly did. If you like this show, please leave us a favorable review on your podcast platform of choice. And to find jobs at companies that work with ShapeUp, like Zoopla, remember to check out our job board at shapers.builders. Thank you so much for listening and I hope you have a great day.

#8: Today I am speaking with Chris Boakes, Senior Software Engineer at Zoopla. Zoopla is a real estate company based in London, UK, which is best known for its property search website Zoopla.co.uk.

This conversation is part of a series about companies that use Shape Up, a delivery framework originally created at Basecamp. If you've never heard of Shape Up, check the show notes for a link to the video "Shaping in a nutshell" by Ryan Singer, former head of strategy at Basecamp and author of the book "Shape Up - Stop Running in Circles and Ship Work that Matters".

In our conversation, we dive deep into how Chris pitched Shape Up to his team and got both his peers and engineering leadership to agree to trial a new way of working, in an organization that's largely running on Scrum. Chris had previously worked with Shape Up at a startup and when he joined Zoopla, an organization with hundreds of engineers, he immediately started spotting opportunities to improve the way his team worked.

If you're an individual contributor who's thinking of adopting Shape Up in your team, this episode is for you. Enjoy!

Links:
Chris' blog post on Shape Up at Zoopla: https://zoopla.blog/posts/2023/shape-up-at-zoopla/
Chris on LinkedIn: https://www.linkedin.com/in/chris-boakes/
Chris on Twitter: https://twitter.com/cboakes
Zoopla: https://www.zoopla.co.uk/
Shaping in a nutshell: https://www.youtube.com/watch?v=h_8M23wVjXk
Shapers & Builders job board: https://www.shapers.builders