Ryan Singer - Applying Shape Up in the Real World - Rails World 2023

It's amazing to be in a room full of Rails developers. It's such a cool atmosphere. I'm very, very happy to be here. So thanks a lot for this possibility. It's amazing. I'm going to talk to you a little bit about ShapeUp in the real world. And I was trying to think, like, what does real world mean for the people in this room, you know? And in many ways, as a Rails developer or a Rails team, you are kind of like a rare, island of super productivity. You know, David was talking about the one person framework yesterday. And so inside of the work of building, there is this like super productivity. But at the same time, there's still the challenges of how do we actually interface with all the other parts of the organization, the other parts of the business? How do we deal with product? How do we deal with design? How do we deal with the deadlines and pressures of supposed to finish things? And these problems seem to still exist, even if we're using a very productive framework. So this is a little bit of what I mean by some real-world challenges that you may have experienced. So let's see if any of this... is something that you may have seen before. So for example, someone on the product side or the business side is asking, are we done yet? Are we ready to ship? Where are we on the project? And then from the technical side, it turns out that we said it was going to be easy or it seemed like it wouldn't be that complicated. And it's also a little bit difficult to explain to the business folks why this is taking so long. So this is one kind of disconnect that can happen. Another thing that can happen is more when it comes to the project formation, how it is that we figure out what it is that we're going to do and turn that into work. So we might have, for example, this experience that the designer comes with the beautiful masterpiece of a million perfectly illustrated things in Figma, and it's all solved. It's all figured out. This is what we're going to build. Have you seen the Figma file? It's perfect. It's beautiful. And then, of course, the engineers say it and they say, no. There's too much in it or it doesn't actually correspond to what is possible in the systems we have or the libraries we're using or that kind of a thing. We can also see the opposite case where rather than getting too much hard detail up front, what we're getting is too soft. right we might get something from product or business which is like it's going to be fast and it's going to be powerful and it's going to be exactly the thing that customers want and it's going to be you know the new reporting feature and you're like okay you know like what does that actually mean so like what are we actually going to go build what does fast easy powerful mean right what do we go actually do right and even if we're able to avoid these difficulties and we have a very nicely shaped coherent concept of here's what it means technically here's what it means in terms of interaction here's how all the pieces fit together you know even if we're able to come up with that in in a lot of teams today i don't know how many here but in a lot of teams today that coherent plan goes through a paper shredder it gets shredded into tickets Maybe you've heard of this paper shredding machine. It's called Scrum, right? And it means that something that was understandable, that made sense, that was a whole, right, that worked together as a concept, it's now individual little slices of work, right? And if we were, you know, the perfect designers of IKEA, then we could make the modular kit, right, where there's the instruction manual and you only have to understand one piece at a time. I think they actually have some very skilled people working for a long time on the IKEA kits. It's not just what happens in a two-hour grooming session or something like that, or whatever they call it in Scrum. So people get individual slices of work, and then of course, we don't know what they mean. So then there's all of this questioning that's happening when we're supposed to be building. What is this and what is that, and how do I make this decision, and so on, because we don't have the context. right? Or the team that we're giving the work to doesn't have the context. And finally, in addition to the sort of struggle on a task-by-task basis of trying to make sense of out of these tickets, if we step back and try and understand the progress that's being made on the project, are we getting somewhere? Are we moving toward the thing that's important that we're trying to accomplish? What we see is a lot of individual slices of work, but it's like they're not adding up to what is actually done. It's like this little thing about the API and this compatibility thing and this gross thing that had to be refactored and all this stuff. But where are we actually in terms of where we're trying to go? So has anyone seen such problems before? Yeah? OK. So even when you have a great framework and you're very productive, it still can be there, these things. I've been fascinated by these problems. I guess I'm some kind of nerd. I really like these problems. And I've been interested in this for more than 20 years. And while I was at 37 Signals for 17 years, I had the great luxury of being part of a team who was kind of doing all kinds of trial and error, you know, to figure out how can we avoid these different traps. And it was a long process of trying out a lot of different things of how do we actually kind of interface. you know, between all of these different phases of the work and these different areas, these different skill sets, these different things that have to come together to actually repeatedly build and ship. And in 2019, that's what got formalized in the book that I wrote called Shape Up. And one of the things that kind of surprised me, you know, the book came out. And then now for three years, I've been independently helping folks who are trying to do this with their teams. And when the book first came out, first of all, I thought no one would care, really. And I'm quite surprised that some people seem to be reading it. But then more than that, I started to get questions from people who were in teams trying to do ShapeUp. And it became clear that there were a lot of things that were happening almost by magic. in the teams that I was on when I was at 37 Signals. There was so much intuition, you know, that it was hard to take everything and break it apart into little pieces that could be explained and get it into that book. So a lot of big principles came through in the book. But when it comes to actually doing it, you know... with the team that we have in a very specific circumstance, there's a lot of questions and also quite a few misunderstandings that came up. So what I want to share with you today are kind of like five major kind of new angles to understand kind of what shaping is about and what it looks like to do it. And what I would hope that you come away with is not the idea of like, now we have to go do shape up or something like that, but rather like, oh, that's a thing that makes sense to me. That's something that I think our team could do. And maybe we don't have to do all these other things, but here's a piece that I can really use. So the first thing that I want to talk about is one of the most essential kind of concepts in ShapeUp. And it's fundamentally that shaping is about making trade-offs. We talk in the book, there's this notion of appetite. I talk about this contrast between estimate and appetite, right? And some of you have heard that, that the estimate is where we have the thing that we think we're supposed to build. This is what we want. This is the solution. This is what we're going to make. How long will it take, right? So we start with the design, and then we try to figure out what does that thing cost, right? And the notion of appetite is we flip that around and we say, how much time strategically do I want to spend? How much time do we as a business think it makes sense to invest in this? And now we're going to go backwards to the design question. Given this frame of time, what is possible? What are our options? What can we creatively come up with that fits to that appetite, that fits within that period of time? And the thing that is often misunderstood is that this is also called fixed time variable scope. And sometimes when people hear fixed time variable scope, they think it means we're going to tell the team it has to be done in six weeks, and they're going to figure out how to vary the scope, which is not very friendly, right? Because they start under all of that pressure, and now they also have to figure out what is important and not, and how can they make cuts and everything, and this is difficult, right? So it's more like this. It's more like if we're shopping for a house, okay? So let's say we're going to buy a house, and we have a certain fixed dollar budget of what we can actually spend on the house. Now, we might have an idea of what it is that we want, that first solution idea, right? We say, okay, we want three bedroom, two bath, and it's going to have a terrace. And not only that, but we're also going to have a beautiful view outside the terrace, right? It's going to be in a very nice location with a nice view that we can see from outside. And then we look at the realities of what is this cost, and it turns out that it exceeds the budget, right? So what do we do? We don't just spend a whole bunch of money that we don't have. There's a point where it's just not possible. We say, okay, so what can we do? And here we come into the trade-offs. One option is maybe we have all the space that we want, the three bedrooms, the two bath, but we're going to have to do it in a different location where we don't have the view, and instead we're seeing the apartment building next door through our window. Or we could compromise on the size. We could say, you know what, do we really need all that space? It's like, yeah, I wanted to have like a separate studio to work in, but, you know, maybe we could have a smaller space, but with the view still, right? And then if we make that trade-off, this is something that we can afford. To make this concrete, I mean, those of you who have read the book might know this example, but it's just the best example I can think of. It's the calendar, because it's so easy to understand that the calendar exceeds... most budgets. It's just such a giant, sprawling thing. So then we say, okay, if we have, let's say, six weeks and the calendar is not the main, like, so this example is from when we built the calendar feature in Basecamp. It was a small feature of a bigger thing, you know, and it had a specific purpose to satisfy certain customer requests. It wasn't really core. So instead of saying, this is going to be the big new thing and we're going to spend six months on it or we're going to spend a year on it, it was only really worth not more than a six-week investment. So we had to make those trade-offs. What is it that's going to be in? What is it that's going to be out? We have to make hard compromises by asking ourselves the question of what is actually important here? Wrestling with the scope, not saying to the team, it's a whole calendar and you're going to figure out how to do it in six weeks, but really wrestling with what is important to us. And that's how we came to this concept of it's basically a month view. We have an indicator if there's something on that day. We have an agenda view that scrolls below when you select a day with an indicator on it. And this is one of those things. You can look at it kind of piece by piece and you say, aha, I understand what it takes to build that. I can see the moving parts of that. That's a doable thing. The next thing that's very often misunderstood is that shaping is actually technical. Shaping is about what we can build. And so it requires the knowledge of a builder. You know, when teams do the equivalent of shaping, or even very often shape-up teams do what they call shaping, they have people in these roles who are responsible for doing that. Now, of course, there's meaning to thinking about the design and making everything beautiful. And there's a great necessity to look at it from the product standpoint and say, does it do what the business needs? Does it do what the customer needs? How does it fit in with all of the other things that we're trying to spend time on and where we're trying to go strategically? So it's not that these things don't have a place. It's that it's not enough. Suppose we're doing a renovation. And for the family, this is like the business case. There's a good reason why we want the renovation. And we want the renovation to be beautiful and to be a good experience. So we have this very nice design. And we have a new couch and new paint color and new furniture around and everything. And in particular, we put a lot of time and energy. The designer found the perfect lamp. They spent days looking at every lamp and choosing the perfect lamp. And now we have the 3D rendering. And it's like, here is the redesign. And we say, beautiful, looks perfect. But something very important is missing here that we cannot see on the surface. Is there actually electricity in that wall or not? Because if there isn't, this has huge impact on the cost. Now we're going to have to rip a hole in the wall and we're going to have to do electrical work. It's not just installing something, right? It's like really new holes in the wall and a whole lot of new time and cost that we didn't anticipate. So we need to have this technical person in the room in order to actually be able to see the costs of things. I like to think of it sometimes like the, you know, like the grumpy old plumber who has seen everything. And if you invite the grumpy old plumber and say, you know, we want to redo the pipes in the bathroom, he will insist on first knocking on the walls and then poking a hole to see the pipes, you know, before agreeing to the project. Yeah. So an example of this is let's say we're in the room and we're trying to shape something and the technical person is there instead of coming later. Product might say, we've got this idea. we realized that we could import some data we have in a different place and we can actually skip one of our onboarding steps and this is going to really improve conversion. It's a great idea. We've done all the data on it. We have the data we need to skip the step. So this is what we want to do. The technical person then, instead of saying, yeah, it should be fine, says, you know what? Let's have a look at the code. Let's actually see what this thing that you're calling that one step that we're going to skip actually is. You've probably been in this situation. before you go and you pull up the code and it doesn't take long to see oh there's actually like three different states here from customers in different segments on different integrations and if they're this customer we do that and it's it's way more complicated than we thought right it's not just skipping a step right now this is the kind of thing that we're catching now on day zero in the project actually before kickoff instead of having the drawing and then having this come up in week one two three of the build time right The other thing that's happening here is we're seeing the actual cost of what it is that we think we want to do. So by involving technical people, we can actually reveal the true costs of the different options that we are considering on the table. When it comes to making these trade-offs that we talked about, seeing the cost is one aspect, right? Because we cannot weigh two different things against each other to see if they're going to fit in the appetite in that time box. if we don't know that this thing is way more complicated than it seems or how long this is going to take versus that, right? So we need to be able to see the true cost, but we also have to do more than that. We have to wrestle. We have to actually deal with the fact that the experience might call for one thing, but the technical truth calls for another thing, and what the product people want and the schedule they want calls for another thing. And how do we... how do we deal with all of these conflicting needs? How do we deal with all these conflicting constraints? We actually have to wrestle with that somehow. And a lot of teams by default, especially in these days, think that they can do this asynchronously. So the idea is like we're going to put something into a document and we're all going to comment on it and then we are going to somehow get to some understanding or consensus or we're going to raise issues or whatever. But we should ask ourselves some questions. about this process. I think there are cases when it can work, but let's ask ourselves some questions. When we are commenting on a document that we were notified about, do we actually go deep into the problem or not? Think about like when you're coding. If you need to solve a coding problem, you have to build like that whole castle of the problem in your mind. You know, you have to have that like unbroken time where you have like the whole thing built up. And now you can walk through all the rooms and you can evaluate your possibilities, right? And then you're like, aha, okay. And if someone interrupts you, it's like the whole house of cards falls down, right? Because it required that focus to go deep and build up the whole problem in our minds. So are we actually going deep into the problem or are we getting shallow responses because people are actually chiming in in between other work, right? And are we actually narrowing down to a solution? Are we actually removing things and saying, ah, it's not that, instead we can do this? Or are we just piling up more and more ideas and objections and suggestions? You know, the thread is getting longer and longer, but threads never get shorter, right? So, like, how do we actually narrow in on what it is that we're doing? And do we actually align on a conclusion? You know, when is the document over? And when did we look at each other and say, yeah, that's right. Usually what happens when we work asynchronously on a document is everybody gives their comment. This is like online communication in general. Everyone gives their comment and then we all walk away thinking I was right. Right? Which is fine. But when it comes to actually integrating efforts and shipping a project, we can't all have different opinions and say that's where it stands. We actually have to wrestle with each other to figure out what is true and what's going to work and what do we have to give up. Right? So very often the decision isn't made, which means that a whole lot of scope actually gets dumped onto the team in the next phase of work and then they have to deal with it. So instead of that, I recommend actually shaping in live sessions. And the thing is, making trade-offs is hard enough, even in a live session. I mean, to make trade-offs... We can't just keep adding things. We have to actually agree that we're going to give up the extra bedroom because we want the view. We have to lose something, and that's very difficult to do. It's very difficult to do asynchronously, and honestly, it's still difficult to do when we're shaping live in a room together, but the conditions are much more working in our favor when we are in a two- or three-hour intense shaping session together, and we can direct the flow, and we can say, okay, but... that conflicts with that and we only have this much time, what are we going to do? We can really integrate in a way that isn't possible async when we're live or it's at least a lot easier to do it. So what that means is somehow the needs of products, the needs of the interaction design, the experience side and the needs of the technical realities, that these are all somehow represented. That might be three different people. that might be a different mixture of people who have these skills in your team. That's something for you to look at. But it's the wrestling between these conflicting constraints, just like we talked about in the case of choosing which of these very different options do we go with. And when it comes to doing this in the software case, it's usually not the dollar amount, which is the budgeting factor. It's the time amount. So we have this notion of like four weeks is the budget. We don't want to spend more time than that. It's not worth it and we have other things we want to do. Then when we're having a shaping session, we can use, in this case, a tool like breadboarding where we're not just talking. It's not like a meeting, but we are actually getting into the work and saying, I'm imagining that we have this component and we go to here and then we use this library and then this appears on the screen and we're trading possibilities saying like, okay, is that going to work or is that not going to work? And usually, whenever we start to sketch out a flow like this, if we challenge whether this is going to fit inside of the time box or if we have these different difficulties appearing that we have to wrestle with, then we start to say we see these kind of problem spots here. Like, ah, OK, so we were going to have a filter on the news feed. What did filter actually mean? What's the version of filter that fits into this if we do it all in one project? Or what's the version of filter if we if we leave that out or is there a version that gives us everything we want but it's simpler to implement right or this photo collage when the photos appear on the post there's a lot of different interaction ideas that someone is suggesting we could oh you could zoom in like this and then we can animate to the side and it's like okay are we going to build a custom component do we have a thing that does that right so all of these different things start to get exposed this is a place where I think you actually have a great advantage working in Rails because your ability to describe a unit of technical work is, how do I say this? It's like you have so many conventions working in your favor. There is so much understandable structure in the way that the app holds together that it's easier to have a conversation and to quickly sketch out. a kind of an architectural idea of how the hip bone is going to connect to the leg bone and what that means in terms of complexity and cost and actual code. It's easier to see all of that. If you're working in an environment which is more like a lot of custom JavaScript, there can be places where that's a good fit, but it can also be a little bit more like spaghetti, and it's a lot harder to understand what it really means when we're talking about it in a session like this. So this is really a great advantage. Shaped work is Also, this is interesting. There's been this misunderstanding that comes out of a word that's in the book, and the word is the word pitch. And in the book, there's this idea that when we finish this, when we get to the end and we have all of our trade-offs and we have a doable concept, that we're going to write this up into a pitch, and then maybe it happens, maybe it doesn't, something like that. And what I've seen is that... A lot of people have read the book, heard about a pitch, but they end up doing something like this. They end up writing something that's more like a sales pitch, where it's describing why we want to build this thing. It's making all the arguments for how this is a smart thing to do because customers want it, and we've heard a lot of requests, and the data shows, blah, blah, blah. There's making a case for why we should spend the time to do this, but it's not actually telling us. what to go do, right? So it kind of seems like it's shaped because it's a document and it's called pitch and the book said something about pitch, you know, but if it doesn't actually tell the builder, if a builder can't take that and say, I know what to go make, right, then it isn't really shaped. And seeing this again and again and again has prompted some changes. So we have a little bit of a change in the API of shape up here. We have some new language. So it turns out, that there's always some kind of work step happening somewhere which we could call framing, which is, what is the problem? What is the opportunity? Are we really going to spend time on this? Is this real? Is this more important than some other thing that we think that we want to do? Why would we do this next instead of something else? It's all about the business case and the meaning of doing this project. And then, if we frame something, and we have alignment around like, yeah, this matters, this is a good idea, we should do this. And not only that, but we should do it like soon. Then we can take that and say, now we're willing to justify that time and energy to properly shape it. Right? So it's kind of like flipping everything around, you know? And this seems to work much better. We can use better language here too now. Instead of saying pitch, we can say that the end result of the shaped work... is something that we package. We package the shaped work so it's ready for delivery. So we're past the point of trying to sell something. Actually, we figured it out and we're ready to keep moving on. Once we have something nicely packaged and it communicates what to build, it can happen in the time that we have, it's understandable to the team that we're going to give it to, what actually happens? How do we actually give it to the team and what results can we get there? Again, I think you've seen the reasons why we don't want to do this. We don't want to feed it through the paper shredder because all of that work that we did to make something that makes sense as a whole is going to get dismembered into individual parts that don't have context. Instead of that, there's something that a lot of people are attracted to about ShapeUp, which is this notion of the autonomous team. The idea that I can give the team not tasks, but the whole project as a whole and they figure out the tasks and all the small implementation details. And this can be very attractive because you think, wow, you know, I'm going to have so much more time as someone who's on the leadership side because I won't have to handhold as much. And I can imagine that certain people on my team would be really energized by that, by having more ownership, let's say. But it's also a lot of people say that it sounds nice, but it seems impossible. And it seems impossible to just give the team so much responsibility. And this comes from a misunderstanding. People think that we need this special elite team of super senior engineers and designers who code in order to do that. And that's because they imagine that it's like doing this means leaving the kids alone, like to fend for themselves. And they're not mature enough for that. But actually, this isn't the case. Autonomy, what enables the team to be autonomous is actually the shaping work. It's not really about the team and who's on the team. It's way more about what we give the team. So it can be true, of course, if we have a very mature team, it's easier to leave them alone, right? But this is not the main thing. The main thing is actually, if we give the team better input, this is what allows them. to work on their own autonomously. And more than that, when we give the team better inputs, meaning better shaped work, they can actually work alone and through that they can grow and develop more of that maturity. So there's a, what do you call that, virtuous cycle happening there, right? So what do we mean by better inputs? Better inputs means that shaping work that we talked about. The project is doable within the time frame, from the beginning, because we made those trade-offs. The team has the context that they need because they see the relationships between everything in the project and the meaning of the project, and not just a whole bunch of disconnected tickets. And the third thing is when we package the work, when we spell it out in a way that we can hand it off to other people, we can choose the latitude that matches the people that we're working with. Latitude meaning how much freedom or how much specificity is there. If someone is more junior, it doesn't mean that we can't do this. It means actually that we think of them and we spell things out a little bit more or we give them a little bit more guidance so they're able to be successful. And if they're more senior, then we step back and we say, I'm not going to tell you. how to write that test or how to think about the performance of that query, I know that you can figure that out and you leave more freedom, right? So the latitude is not like some fixed thing. It's actually a dial that we can turn in order to give the team what they need. Okay, so that's what I wanted to share with you. If you're interested in this and you'd like some more, you can visit my website. The book is still available for free. You can find that. There's new articles and videos and things kind of sharing. what has been evolving through working with a greater variety of teams on all of this stuff. There's also the course, Shaping in Real Life, which is kind of how do we actually figure out what it would mean to do this in our team, right? And I would love to hear from you and hear your experiences and questions, especially objections and hard questions would be fantastic. So if we see each other in the hall, please stop me and ask questions and also feel welcome to write. I'd be really happy to hear from you. That's the end of the time here, and thank you very much.

Teams everywhere are tired of scrum and curious about Shape Up. But very few of them are able to apply it by-the-book, because their companies are structured differently than 37signals, where Shape Up was created.

That hasn’t reduced the demand, however. People understand that estimating story points and writing better tickets isn’t going to solve their problems. There are disconnects between the vision of what to do and what actually gets built. Building takes longer than expected and scope gets out of control. Programmers are treated like ticket-takers when what they really want is to see the whole problem and creatively solve it.

Over the last couple years, Ryan Singer, author of ‘Shape Up’, has worked with a wider variety of companies with very different structures — teams with big gaps between junior and senior, where programmers far out-number designers, and where external pressures make six-week cycles out of the question. The result is new language, new techniques, and some broken rules, that will help you apply Shape Up in a way that’s custom-fit to your team.

Links:
https://rubyonrails.org/
https://basecamp.com/shapeup

#RailsWorld #RubyonRails #rails #shapeup #scrum

Thank you Dell APEX for sponsoring the editing and post-production of these videos.Visit them at: https://dell.com/APEX