Episode 53: Shape Up: Agile

Welcome to Lunch with Tech Leaders, where we have engaging conversations about software development and cloud engineering with industry leaders and subject matter experts. These episodes are created by the Great Lakes Tech Leaders, an online community of technology practitioners. Please come join the conversation by visiting gltl.rbn.ai. Again, that's gltl.rbn.ai. Now strap in, because we're deploying to production in three, two, Hello, everybody, and welcome to the latest episode of Launch with Tech Leaders. My name is Adam Oberhausen. I'm the vice president of Customer Solutions with RightBrain Networks, and I'm your host for today. Joining me today is software and data consultant, Tom Kowalski. Say hi, Tom. Hello. And of course, last but not least, my good friend and comrade, business technology consultant, Joe Coleman. Hey there, Adam. Thank you for the intro there. As always, folks, you guys have any questions listening in, throw it right there in the chat, and I'll be sure to... Make sure it gets covered throughout the discussion here. So thank you so much. Thanks, Joe. In this episode, we're going to discuss a product development methodology known as ShapeUp. We're going to touch on its origins. We're going to discuss the shortcomings of some traditional methodologies. Then we're going to pivot to the core principles of ShapeUp and take a deeper dive into how the ShapeUp process works. First, I'll kick it over to Tom to introduce our subject matter expert and active practicer of ShapeUp. Yeah, I'm interested in these things, organizational and practice agile waterfall back in the day and scrum and all that. So yeah, I'm a... excited to uh to learn more about shape up and that's why i brought lance back right at the show yes because he practices it in his job daily so yeah we can we can learn about it from an expert practitioner having me yeah yeah okay so yeah i wanted to start with a little background on shape up lance i i'll lean on you if you want to kick off the conversation. But what I understand, it was developed by a firm called 37 Signals, which is founded back in 99. There's a guy there named Ryan Singer, who is kind of the mastermind of Shape Up. Do you want to talk about it, or would you like me to just recap my notes here? Yeah, I... You can recap your notes. I don't know much about Ryan's background that much, but I do know that he created it. And I did look at our notes before to see that. I guess he has a pretty prolific history that I don't know about. So if you want to. Sure, sure. I'm happy to educate you. Sure. So 37 Signals sounds like they're a software dev shop. They started in the late 90s, around 2004 is when they launched their Basecamp product, which is like their only product to this day. Like they dropped the 37 Signals and became Basecamp from what I understand. But that wasn't until... until 2014 when they decided to solely concentrate on Basecamp. Don't they also do a K, right? The email service as well. I feel like that's, yeah. I just know this right from the DHH. He goes by. Yeah. There's a lot of talk right now in the circles of cloud, right? Because they ditched AWS. I think we've talked about it in his little write-up on that. Yeah. So Basecamp was basically an internal tool they developed for project management. Then it became its own software thing. And now it's a very popular tool that a lot of teams are using. And through Basecamp, they developed this process that they call ShapeUp. And this was mostly done by Ryan Singer, who played a pivotal role in the 37 Signals. He's the head of product strategy at Basecamp. Basically, he's been involved with the design strategy and implementation of all their products over the years. In terms of what his impact on product development world is ShapeUp, which we're here to talk about today. You know, he basically challenged a lot of the traditional beliefs, not just with Waterfall, but even Agile and Scrum, which I think is very exciting because I've, you know, been doing Agile Scrum for a long time. And I wouldn't say I dislike it, but I also think it's not perfect. And so I think it's great that there's another. alternative out there. And I hope there's more that come. So that's really it. You know, Ryan does a lot in the community. He does a lot of workshop and talk. His design philosophy, Ryan Singer, leans towards simplicity, clarity, and focus. Those are kind of like the three key phrases he uses a lot in his content. You know, really just encourages designers and developers to think critically about their choices and prioritize meaningful functionality over superficial additions, which I think we all can applaud too because, you know. Feature bloat is one of the worst things that can happen to software. So, yeah. Yeah, I mean, specifically, too, you have to know your customer, too, because feature bloat is only real in the sense that, like, it's the context, right? It's like, if you don't have, if you're not kind of custom wrapping the functionality around the customer of your product, then you can, that's how you end up having all this feature bloat. You're just like. your context is I'm gonna develop all these features for everybody as opposed to okay I know who I'm talking I'm talking to a human being and I'm asking them for feedback and this is what they said you know it's not always you don't always want to listen to the individual but sometimes that feedback that they give is is pretty critical and will propel your product to the next level because a bunch of other people hundreds or thousands of other people also want that same feature but the key is just listening to the people that you're building products for. And ultimately, ShapeUp is a way of doing that. So Agile was too, you know, but there were a lot of problems with the way that Agile and Scrum kind of were implemented in large organizations because of this mentality of a sprint. And if you're sprinting all the time, every two weeks, it can really drain your team. And it is really hard to... develop and be and have your developers be creative designers developers be creative on features when they only have two weeks to implement something and then suddenly the stakeholders decide oh we need to shift gears all of a sudden and it can be a real knee-jerk reaction to things so that was one of the if anything like the one Big thing that ShapeUp promotes is stop having these two-week cycles. Agile can also be that, right? You can have an agile system where you just increase the length of the cycles to two months. And that's a big part of ShapeUp is you have, instead of every two weeks, having the business stakeholders meet and talk about the iteration and what we're going to do next. And then, you know, you're sort of pivoting along, which can make sense in certain circumstances. If you are a startup, I don't think large businesses necessarily, unless they're building a new product, like in the very beginning, maybe it could make sense to spend the first three months on a two week interval because you're really getting that quick feedback from the customer and trying to get, you know, something you're trying to find that product market value. But once you found it, let's switch to something longer. Two months, every two months you get. As business stakeholders, you get six times during the year where your decisions matter as opposed to your micro decisions. But then you really get to think about them. By making less decisions, you really are thinking hard about, are these the most important things that need to be implemented? Yeah. Maybe we should go back and talk about it. Yeah, let's take a step back. What is shape-up, right? We kind of talked about the origin, right? Ryan a bit. But what is shape-up? Right? Like, how does it differ from Agile? Okay, so I'll rattle off the core principles, and then I'll let Lance riff on it. But basically, core principles of shape-up. Fixed time, variable scope. So you work in fixed cycles. Default is a six-week cycle with a determined end date, but flexibility and scope. Next core principle is the shaping of work. Sorry, two-week cooldown, too. And then a two-week cool-down period after the six weeks. Next core principle is the shaping of the work. The senior team defines rough solutions to problems but leaves room for teams to figure out all the details. Next core principle is you do, it's called betting instead of planning. Deciding on which projects get the green light for the cycles without making promises for the future. That's when Lance was kind of talking about the stakeholders getting to decide six times a year what the team, what the delivery team would focus on. So yeah, so it breaks down two months, right? Six times a year and makes sense. Within there, there's all these, you know, then beyond that, you get into the process, which we'll cover, but anything on the core principles that you think needs to be called out or filled in, Lance? That's, I mean, that's the basic, that's the high level thing. So you can obviously take any, the shape up process is this, and then it has a bunch of other stuff you included in there and like. you know how you can build teams together with a designer and programmer pair it gets really specific about how you can design your product and tools that they've had base camp has had success with designing their products that you can also adopt but you know with all of these things i think it's interesting to to read shape up and then adopt the parts that you like into your team that you think makes sense. You don't have to like Scrum. You don't have to, you don't have to try Scrum, fail at it for whatever reason, and then hire a consultant because you didn't follow Scrum to the, to the letter. Right. You know, and that's the reason you failed. I don't, I don't think that's, I think, you know, try it with your team. See, see what things you resonate with. And, and then if it didn't work kind of assess why, but you know, for us shape up has worked really well. because we were on that two-week cycle and it was actually not only was it a pain in the butt for the developers or maybe even not so much a pain in the butt for the developers because they're still kind of you know they're in this time box two-week thing to like deliver something that's fine but on the stakeholder side we were every two weeks coming in and making decisions and and people get really fired up on the core team about like what is the core principle of what we're trying to accomplish and and we're doing this every two weeks and it is actually for this business stakeholders can be it's just a lot of emotion attached to something that maybe we should just breathe a little bit and and let let things happen in a longer period of time and let developers be creative and then we can reserve you know and then we can also what's also nice is that period of time is enough time to start planning out the next cycle and start to think about you know these are really the most important things to that we're going to be in having locking down what the developers can focus on for the next two months. So I think you've touched on a lot of the shortcomings of why your team gravitated towards ShapeUp. And I want to rattle off the shortcomings of Agile, and then maybe we dive deeper into the ShapeUp process to answer some of these questions about how it actually works. But with traditional Agile Scrum, there's over-planning. Arguably, you're over-planning detailed planning for long periods. Conditions change rapidly. Doesn't always align. There's fixed scopes. So teams feel the pressure to always include all the specified features regardless of how things might be changing in a dynamic environment. Too many meetings, right? We all get stand-ups, plannings, retros, scoping, grooming. It's endless. The burden of backlogs, which I can't wait to talk about this because in true shape-up, there is no backlog. The short iterations, which I think, Lance, you've hammered a few times now, just that two-week mentality of you're always sprinting. It's just unsustainable. Lack of flexibility, the overemphasis on estimations in Scrum, I think is just like, I'm going to do a future episode on estimations because I think that's just like a huge Achilles heel of any delivery. Yeah, those are the shortcomings. I really love timeboxing. And what's interesting about the ShapeUp process is that, The responsibility of whether or not something got done within that time box in the shape-up process is not just a developer problem. It's also a business stakeholder problem. Did you define the problem and the solution well enough prior to the developer working on it? And did you understand the scope of that work within that period of time? And did you uncover all of the things, the rabbit holes that could happen? that could make this even longer. It's, it's now it's partnership. Yeah. And the six week cycle is enough that the way I read the, I read the book and it's basically six weeks seems to be the sweet spot where it feels urgent enough. Like there's urgency to get this done in six weeks, but it's also not like crunch mode, right? Like there's enough room in there to that, that month and a half, you know, it feels like you have just enough time to like take your time and be thoughtful. but also it's time box enough where there's that you need that pressure to complete. So diving into the process here, the first step in the process is the shaping. We touched on it. It's the steps and criteria for shaping the projects. Since you live it, Lance, I'll let you describe how your organization does shaping. Yeah. I mean, during the, it usually happens towards the end of the cycle and then it bleeds into cool down a little bit, but. the business stakeholders will over the six-week period of time will you know you you inevitably as a business you collect feedback from consumers customers from from your from your customers and maybe their customers customers but anyway you get a lot of feedback about what's going on and what what you think is going to be priority and so you're as business stakeholders you're always talking asynchronously with each other about you know what potential pitches are going to land And then what we do is during cool down, that's the betting table period, which maybe you can discuss what betting table is in a minute. Leading up to betting table, that's when we're shaping up these pitches, they're called. And sometimes that involves a developer. Sometimes that involves a designer. It can involve a lot of people at the company, but it's more like asynchronous communication where it's like when needed to... To get this pitch ready for betting table, we will pull in the necessary people that have the necessary information to help complete this pitch and make sure that by the time it is scheduled for the developer to develop, there is enough scope and there is enough description about the problem, the solution, etc. The whole pitch is in a great form for that developer to be able to succeed in that six weeks in producing that work. All said. So with your team practicing ShapeUp, do you actually... When you're doing the shaping process, do you actually define some boundaries that are set for setting boundaries and doing the wireframes, which are fat marker sketches and breadboarding? Is that part of your guys' process that we want to touch on? We don't do enough breadboarding. I wish we did. We don't have enough designers on our team. That is definitely a lack of resources situation with our team. So that being said. You can do this process without having enough designers on your team and you don't need to necessarily have the breadboarding, but it really does help the developer when they do get a breadboard and some sort of sketch. And we try to provide that as much as possible when we can. Okay. Let me give some quick definitions. So setting boundaries ensures that the team doesn't wander off track and waste time on things that don't align with the project's main objective. Wireframes. Rabbit holes, there you go, that's a good one. Wire frames are low fidelity representation of each page's structure. The fat marker sketches are extremely simplified drawings using a thick marker to represent UI elements. So you're not giving your front end team every little detail, kind of give them the broad strokes, right? And then breadboarding, representing the components of a page and their interactions without a visual design. So I don't know if I've ever... actually even seen a breadboard or maybe it's just like a flow chart or I'm not sure, but it's a new term to me. So, and then that leads us into the bedding table. So Tom, if you've got any questions on, on the shaping process, feel free to chime in. Yeah. I'm just, what's like a copy, you know, an example of like a feature project, right. That you would shape up, right. Like what's a concrete, like, you know, we're talking theory, like, Oh, but what's, what's something, you know, that you've done, right. Like paint me a picture of like, we've used it for early a pitch a pitch you would call it yeah i mean there's so there's small and large versions of it um that's actually we kind of work backwards a lot of times where we think about things in weeks so you know maybe a a small customer requirement comes in and we're just like oh that probably will only take a week let's make a pitch for that potentially and we'll make it better in the future And then we make it better by the time it hits betting table. So some of these pitches are only a week long for the bigger stuff. Let's say we wanted to implement some recurring payments feature on our pool because we do payment portals. We need to add something that's bigger, chunkier. We'll take six weeks to do. Then we'll say, okay, this thing will probably take six weeks. And then what we do is working backwards. From what we want to accomplish, we start killing the scope. And we're just like, okay, now we've got a pitch we think will actually fit six weeks. Talk to the developer, our lead developer. We talk to potential developers that we think are going to work on this pitch. And we get it down to, okay, this makes sense. This is probably going to be six weeks, if that makes sense. Okay. Moving along, we go into the betting table, which is how stakeholders decide on what gets built. So the betting process replaces traditional roadmaps and planning. It's a process where the stakeholders place bets on projects they believe should be pursued next. And I will hand the baton to Lance to talk about how this works in practice. You're going to get your chips out. You got to get the background chip noise. You know, no, it's a fun process. What we typically do is maybe this, because we're such a small team, we can do this. their other to save time what we do is we take all the pitches that we've built over the period of time and this this isn't how shape up does it but we've optimized it so that we kind of throw all of our pitches into based on their time we have we have three teams so sorry i'll go back we have three teams that we allocate work to and each team can take on you know, six weeks worth of work. And so what we do is we just throw all the pitches into the teams, kind of not haphazardly, we kind of have an idea of what we think that certain teams are going to be able to handle. And we just throw the random ones in there until it fills up. And then from there, we start betting on, okay, the stuff that's not in that cycle right now, is this, do we think it's going to, is higher or lower priority than the things that exist in there already? and then if we think it's higher we then move it around and and adjust things that's how we do it that's not how uh the shape-up process uh is is on paper how they do it they they go every pitch and they everything has to fight for its life kind of thing but by the time you hit the betting table you really have to be prepared with all the stuff you think are you're gonna want because if you're not sometimes you're in the very beginning we actually had to do We had to redo the betting table and that we, it's not fun doing that. So, so the formal betting process, which I think you guys are, you know, doing a close, you know, you're aligned with the process, but it says here, you start with the pitch. The shared projects are presented as stakeholders. Then you get into the evaluation. Projects are assessed based on potential impact, feasibility, and alignment with company goals. And then decision. Stakeholders decide on which projects move forward in the next cycle. And so it sounds like you can actually have multiple pitches into one cycle because, like you said, a pitch might only take three days. So it could be like a change to an existing system or even a bug fix could be a pitch. Okay. Yeah. So the benefits are that it keeps the focus on the high priority projects and allows for flexibility in changing business environment, which, you know, arguably Scrum allows that to, I guess it depends on how strict. teams are with their roadmaps and you know I've seen teams try to do a roadmap for you know a year out and what no usually anything past 90 days is just pie in the sky. What I've felt with Kanban I really liked the idea but as as I've kind of thought about it more and witnessed different teams using it one issue that you have is like you have this backlog of things that are on the most important thing that the business considers need to be accomplished and you're supposed to just pull from the top. But the problems are, how do you know that the person that now has available allocation of work is going to be the best person to do that work? And then it can feel like, what am I really supposed to do? Like a business stakeholder didn't say, I explicitly need, should be doing this and expect you to do this. So you're kind of just like, It's this weird, like, I don't know if the time that I'm spending right now is what I should be spending time on. And so there's a lot of communication issues with, oh, I didn't get assigned this. I'm not, am I qualified to do this, you know, et cetera. And I think a lot of backlogs, a lot of items in backlogs are just, it gets created by the team itself. And the stakeholders have no idea. All they see is a backlog, which is a black hole of endless work. So question though, Lance, You've got all these pitches prepared for the betting table. If a pitch doesn't make the cut, does it go to a backlog for the next cycle to be considered? So we do keep a pitch graveyard. Yeah. But when it comes to the next betting table, if you're going to re-pitch something, you have to make it good. You have to redo it. You have to make sure that this is going to win this time, right? It's there, but you have to re-pitch it if it's going to make it. And for whatever reason, it didn't make it this cycle. Maybe because it wasn't ready. You didn't do a good enough job articulating its importance, the scope, whatever it is, didn't make it. So yes, we do keep a backlog, pitch graveyard, but those have to be re-pitched every time if you actually want to think about it and do it that cycle. How does it work with the coordination of the teams? We actually did it one week, Sprints, the last team that I was working on that we did a scrum process, and it allowed us to... you know, set expectations for other teams, like this will be done this week, you know, this will be done this week, you can start working on this and use that, right, the different systems coordinating, going six weeks seems like, you know, or two months, right, it seems like you're really drawing that out. So how does that work with coordinating, like, you know, this API has to be done on this system in order for this team to work on that? How does that work out? Well, every time we finish the betting table, we then take that betting table and I take take the entire cycle that we've planned out, and I send an email to the entire team. So that's the expectation setting. These are the things that we as a team have decided need to be accomplished in the next two months. So that goes out. Everyone's pretty clear on that. And then once that happens, the first week or so, teams are meeting. People are meeting and looking at their pitches and discussing them. And they're sort of doing a discovery about what... who I need to talk to and do I need to get more detail on this process? So that's when they're really starting to go and talk to other people and figure out how they're going to get this done. So are there dependencies within teams during that two-month cycle? Or is it like, hey, you got to wait. If you're waiting for something to be done from another team, you got to pitch that for the next. two-month cycle. Is that how that works? Example, Lance, the back-end team needs to get an endpoint stood up for the front-end team to complete the work. So do you have to lay it out sequentially to say the back-end team needs to deliver this in the first week of the shape-up or of the cycle so that then the front-end team can actually get what they need to start doing on week two of the cycle? Do you have to get that granular? Is that kind of what you're asking, Tom? Yeah, yeah. I get it. So we try our best to make things not dependent on other teams, but if they do, we do sort the pitches. So if there's smaller pitches within that cycle for a team, we do sort it by what we feel the priority is. So let's say you did have a team that was working on something that was dependent on another team. You could set it up where maybe let's say you had two pitches for that team the first three weeks, They're doing something that doesn't depend on any other team to get what they need to accomplish. And the second one, the second pitch, maybe it does depend on another team. And, you know, by the time they're done with those three weeks, hopefully that other team has finished the thing that they were depending on. So you can kind of, it's the business stakeholders that are having to be mindful about the dependencies and plan it for people. We want to be respectful of our time here. We have... a few more sections of the process that we should cover, which are the building, the building phase, the six week cycle and the two week cool downs. I've touched on them a little bit, Lance, if you want to recap and just kind of talk about how the actual building process goes. I think you, I think we just did. So yeah, there's much to touch on there. Well, I mean, and what's really nice is that you've kind of, you trust your team to accomplish it. They have more autonomy and they, and you know, It's like giving someone a nice long project to just like, okay, let's just figure this out and get creative. So that's what I really like about it. It's a lot less stress to deliver everything in six weeks than it is at different times as opposed to every two weeks. So if you do have, you could have like six 1.1 week pitches, right? But like a couple of those pitches you might accomplish really fast in the beginning and the last few takes a while. The opposite could be true. And then talk about two-week cooldown. In my notes, it says, a break after cycle used for retrospection, addressing bugs, and prepping for the next cycle. I mean, are your developers just sitting around playing Xbox for those two weeks, or what are they doing? It helps down. In the beginning, we did have a lot of periods of time where... there would be some bleed over and you have to, you have to kind of as a team get better at that. So yes, in the beginning, you'll probably find that your first few cooldowns, you may have some bleed into there from, from the cycle. So, so in the cooldown, you can also include stuff like, okay, I've, I've deployed and finished things, but I want to go back and refactor things and make things better. The code look nicer, maybe write a few more tests. So that could be in your cooldown bug fix. I like that. I like that. Yeah. And then bug fixes are like, you know, maybe, maybe. Maybe even bug fixes that were in a previous cycle come up, like maybe, and you didn't kind of prioritize them, but now you can start addressing those if the company deems them a priority. But we do try to like, obviously as an organization, make it so these bugs aren't popping up every cool down. Yeah, sometimes we'll, you know, the developers, if there's enough time, they can work on open source projects or whatever it is. It's still work that they're doing, but it's not, you need You need some sort of reset after a large project. And that's another big reason why sprints can be hard because you never get a break, ever. And you talk a little bit about how ShapeUp deals with risks and unknowns. And in particular, I'm curious about scenarios where I'm sure it's had to have happened where you kind of get into a pitch, you get into a building phase, and the dev team realizes, like, sorry, stakeholders, but this thing was not scoped properly at all. this is a train wreck. So can you talk about how you deal with some of those challenges that might come up? So that is to me a failure of the business stakeholders getting that pitch ready because, you know, and obviously there are certain things that do come up sometimes. There is a section for R&D. So you can also have an R&D phase. If the thing that you're wanting to work on is so, there's so many rabbit holes you don't know about, well, maybe you should schedule an R&D pitch. where it's like, you know what, for two weeks or six weeks, I want you to dedicate all of that time to just figuring out what these rabbit holes are. So you're scheduling time to figure out more information about this to reduce the risk when you actually start to implement. This can be tough for business stakeholders because you're always just like, no, I need this done. But if you do that, just as a business stakeholder, you have to keep in mind that... Okay, you may fail this pitch, right? And if you do well, you may have if you try if it's so important then you may have to repitch this and kind of zombie the existing feature but like that's just not really in the spirit of wanting to like you really should be deploying something after six weeks with those one-week pitches you actually should be deploying those every single time too. So it's like if you had three if you had six one-week Pitches like deploy every week. Yeah. Deploying, the more that you leave this thing isn't deployed, it gets worse and worse, right? Because you don't get that customer feedback. So what we like to do is we like to make sure that, okay, fine, there was an unknown that was found and that did delay things, but let's figure out a way to cut scope and deploy this thing at the end of that period. And then we can make another pitch later if we really need that extra functionality we killed. Does your team use Basecamp to manage the shape-up process? No. We use something called Clubhouse. Okay. And that kind of came from the Kanban thing that I was obsessed with before and have since learned from. But it really works well for moving cards around, and so we're really advanced at using it. So we can do the betting table really easily in it because we just move cards around. And then once those are done, we create epics, and then we put... stories underneath and then those are the pitches is this something that has to be adopted you know across the entire organization or it could this be like a like you know team specific type of process because the last organization it would kind of had the different different processes work for different teams so is this kind of like an all or nothing for the org or do you think it could work like per team once in agile once in shape up good question i think you could mix and match It's really up to the business stakeholders and the developers willing to try something new. It's funny, I've actually heard some pushback from some teams, a friend of mine, where their company is doing ShapeUp and his initial reaction was, no. And I'm like, actually, you just try it out and you'll actually be less stressed out about the process and you'll be more creative. Just go through a cycle and see how it feels. And he was, I think he's reporting. good results now, but he was worried because one company before that, I think, tried ShapeUp and it was disastrous. And I think it's just, you know, you also have to keep in mind the context of Basecamp and sort of their work culture and remote life and not putting so much pressure on everyone to sprint all the time. So if your business really is incompatible with that culture, maybe ShapeUp is not for you. I don't know. Do you think ShapeUp scales? Like, do you think it can work? huge dev shops or product management? I mean, I think Basecamp has like 150, was it developers or employees? And so, I mean, and each team is only two people. So if you think about it that way, you can scale big time. Let's say if you get 60 teams, but your business stakeholders are just associating. uh work to those 60 teams but they get to decide okay these are the let's say 120 oh well so 60 teams i mean yeah you're you're making a decision every every two months for 60 60 teams about what's the most important i think i think it can scale i don't know i don't know if there's an upper limit because you know obviously you're you're you're creating that you're gonna have a long meeting if you're if you have a to plan six weeks worth of work but Yeah. Does everyone get on the same cadence, right? Is it like every team, like they're all starting the same day or is it going to be staggered? Okay. Yes. I recall reading in my research for the show, but I didn't put it in my notes. Is there, is it desirable to have a two person team for each pitch? That, that is the Holy grail according to base camp. Okay. I missed that. We missed that. That's a big thing. Well, I mean, I don't know if they've included that in the process necessarily, but they talk about it on their rework podcast and some other places. You can have bigger teams of five people, whatever it is, or maybe you have some mix-up. Typically, because we're short-staffed on the design side, we'll have one designer assigned to several teams, which isn't desirable, but we've been able to... the amount of design work that we need as a company isn't as high as maybe some other companies or maybe we're just not using our designer as efficient as well as we should be. Maybe that designer should be talking to customers more than we have them, right? Yeah. Well, this is really interesting. I think we could probably do a follow-up episode on this because I think there's more to dive into here because I've got a lot of notes that I haven't even touched on. I want to take this opportunity to thank Lance and Tom for joining me on the show here. It was really interesting. I'm excited to try ShapeUp. I want to find a project that I can try it out on. I think it could, you know, being in a consulting world and, you know, thinking about project-based work, you know, ShapeUp could be better. It's another tool in my tool chest to try a different way to manage projects. I mean, experiment with the intervals, right? Like, it doesn't have... You could do once a month. Like what if you had three weeks work and then one week cool down? You know, I think that it's just the time boxing isn't something you have to be set on. Whatever works for your business, right? If you want to bill monthly, maybe it makes sense to have a monthly cadence where you have the three weeks and then the one week cool down and then you bill the customer based on that scope of work. Yeah, great insights as always. We'd love to have everyone join us again next week. where Ray Welker is going to continue his series on infrastructurous code, and he's going to be comparing and contrasting some of the many popular tools used in the space. So look forward to that episode and hope everyone has a great rest of their week and take care. You too. Thank you.

In this episode, we delve into the innovative "Shape Up" methodology, a brainchild of Ryan Singer from the renowned software firm 37 signals, now known as Basecamp. We explore the genesis of Shape Up, its departure from traditional Agile and Scrum practices, and how it addresses many of Agile's pitfalls.

Join the conversation at http://gltl.rbn.ai