Applying Shape Up in the Real World

Ryan Singer

Ryan Singer

#software-architecture

Applying Shape Up in the Real World

by Ryan Singer

In this presentation titled "Applying Shape Up in the Real World," Ryan Singer addresses the challenges of implementing the Shape Up methodology in diverse organizational contexts, particularly in software development teams using Rails. He emphasizes that while Shape Up provides a structured approach to project management, most teams struggle to apply it due to structural differences and varying pressures within their organizations.

Key points discussed include:

- Real-World Challenges: Singer highlights the disconnects between teams and the business side, where developers feel pressure to meet deadlines without understanding the overall context of their work. This leads to confusion and inefficiency, despite potentially high productivity levels of frameworks like Rails.
- Understanding Shaping: He introduces the concept of "shaping" as a means to define the scope of projects within a fixed timeframe, contrasting it with traditional estimation methods. Shaping encourages teams to determine how much time they can allocate to a project and to make trade-offs accordingly, illustrated through examples like real estate shopping.
- Involving Technical Teams Early: One of his key insights is the importance of including technical expertise in shaping discussions. By understanding the technical constraints and possibilities early on, projects can be better aligned to reality, reducing complications later in development.
- The Nature of Pitching: Singer argues against shallow project pitches that lack substance, advocating for clear directives that frame problems and prioritize solutions.

- Team Autonomy: He discusses the advantage of providing teams with the autonomy to understand and execute projects in their entirety, rather than simply completing assigned tasks. This requires good shaping practices that provide adequate context and definition.

Examples like the development of the calendar feature in Basecamp illustrate how the concept of "appetite" aids teams in making informed decisions about project scope within defined budgets.

In conclusion, Singer encourages teams to adapt the principles of Shape Up to fit their specific needs, fostering collaboration and communication among product, design, and technical teams. He invites further discussion and insight-sharing on the challenges and successes teams face when integrating these principles into their workflows.

He also points to ongoing resources, including his book and courses, to facilitate deeper exploration of these ideas.

Overall, the talk underpins the importance of context, collaboration, and trade-offs in applying Shape Up effectively across various team structures and project types.

00:00:15.639 It's amazing to be in a room full of Rails developers. It's such a cool atmosphere, and I'm very happy to be here. So, thanks a lot for this opportunity. I'm going to talk to you a little bit about Shape Up in the real world.

00:00:28.240 I was trying to think about what "real world" means for the people in this room. In many ways, as a Rails developer or part of a Rails team, you are kind of like a rare island of super productivity.

00:00:41.680 David was talking about the one-person framework yesterday, and inside the work of building, there's this super productivity. But at the same time, there are still challenges, like how do we actually interface with all the other parts of the organization? How do we deal with product, design, and the pressures of deadlines?

00:01:07.280 These problems seem to exist, even if we're using a very productive framework. This is a little bit of what I mean by the real-world challenges that you may have experienced.

00:01:19.680 Let's see if any of this resonates with you. For example, someone on the product or business side might ask, "Are we done yet? Are we ready to ship? Where are we on the project?" On the technical side, it turns out we said it would be easy, or it seemed like it wouldn't be that complicated.

00:01:32.960 It's also a little bit difficult to explain to the business folks why this is taking so long. Another Disconnect that can happen is related to project formation—how we determine what we're going to do and turn that into work.

00:01:52.000 We might experience a situation where the designer brings a beautiful masterpiece in Figma, perfectly illustrated, and it seems all solved. The engineer might respond that there’s too much detail or that it doesn’t correspond to what is possible with the systems or libraries we have.

00:02:22.959 On the other hand, we might get something from product that is too soft, such as, "It's going to be fast, powerful, and exactly what customers want." But what does that actually mean in terms of what we're tasked to build?

00:02:41.120 Even if we're able to avoid these difficulties and have a coherent concept of the project, in many teams today, this coherent plan often gets shredded into tickets, a phenomenon you may know as Scrum.

00:03:02.919 It means that something understandable, that made sense as a whole, becomes individual slices of work. If we were the perfect designers of Ikea, we could create a modular kit where the instruction manual only requires understanding one piece at a time. However, it takes skilled people a long time to make Ikea kits work, and this is not something that can be solved in a quick grooming session.

00:03:50.480 As a result, people get these individual slices of work, but we often don't understand what they mean. There's all this questioning that happens when we're supposed to be building: What is this? What is that? How do I make this decision? Because we don't have the context.

00:04:12.480 If we step back and understand the progress being made on the project, we often see that while we have a lot of individual slices of work, they don't necessarily add up to what is actually done.

00:04:31.400 It might be pieces like updating an API, addressing compatibility issues, or refactoring a messy part of the code. But where are we in terms of where we're trying to go? Has anyone experienced these sorts of problems before? It's interesting because even when you have a great framework and are very productive, these challenges can still exist.

00:05:03.560 I've been fascinated by these problems; I’ll admit I’m somewhat of a nerd. I've been interested in this for over 20 years. While at 37signals for 17 years, I had the great luxury of being part of a team trialing different approaches to avoid these traps.

00:05:12.000 It was a long process of trying various methods to interface between different phases of work and skill sets required to build and ship effectively.

00:05:25.680 In 2019, this all culminated in the book I wrote called Shape Up. One aspect that surprised me after its release was how people seemed to care about it. I started receiving questions from teams trying to implement Shape Up and realized there were many intuitive aspects of the method that were never articulated during my time at 37signals.

00:06:05.720 While the book covered numerous big principles, the actual implementation led to many questions and misunderstandings. Today, I want to share five major angles to understand what shaping is about and what it looks like in practice.

00:06:45.680 I hope you leave with the understanding that you don’t necessarily have to follow all the steps in the book, but that there are pieces of it that can fit your team context. The first thing I want to talk about is one of the most essential concepts in Shape Up: the idea that shaping is fundamentally about making tradeoffs.

00:07:25.760 In the book, I introduce the notion of appetite, which contrasts with estimation. When we discuss estimation, we typically focus on the solution we want to build, asking how long it will take. Appetite, on the other hand, flips that approach around.

00:08:07.520 We start by asking how much time we strategically want to spend on a project. From there, we define our options within that time frame. This concept is sometimes referred to as 'fixed time, variable scope.' Some people misunderstand this term, believing it means we impose a six-week deadline for the team to figure out what to cut, adding unnecessary pressure.

00:08:47.160 A better analogy is like shopping for a house within a fixed budget. For instance, if we envision a three-bedroom, two-bath house with a great view, we cannot exceed our budget. Therefore, we may need to make tradeoffs—whether to sacrifice location for size or keep a view while reducing space. This process helps us understand the scope.

00:09:30.040 Another example comes from when we built the calendar feature in Basecamp. Instead of approaching this as a major new feature requiring six months, we acknowledged that it was only worth a six-week investment, leading to the necessary tradeoffs spent on what proved essential.

00:10:10.440 The next misunderstanding is that shaping is inherently technical. It demands the knowledge of a builder. Some teams attempt to shape without involving technical expertise early in the process.

00:10:56.960 However, if we are renovating our space, a beautiful design must also consider technical realities. For instance, if there is no electricity in the planned location for a lamp, it ultimately requires additional work that wasn’t initially factored into the time or costs.

00:11:27.640 Involving technical people at the shaping stage helps uncover the true costs associated with our plans before moving to execution, avoiding complications that could arise once the build starts.

00:12:01.160 Additionally, understanding these technical aspects facilitates open conversation about trade-offs we might need to negotiate. This contradictory nature of needs between product expectations, experience, and technical realities necessitates active engagement and discussion.

00:12:43.440 Many teams today attempt to resolve these complexities asynchronously, through written documents and comments, which can lead to shallow responses that lack depth. When coding, deep focus is often necessary to solve complex issues, suggesting that shallow discussions won't yield effective outcomes.

00:13:02.080 We often leave discussions feeling like everyone is correct in their opinions, but in the end, all must come together to agree on a unified concept. It underlines the importance of shaping work during live sessions.

00:13:45.960 Making trade-offs is difficult even in live settings, yet having that interaction fosters better collaboration. It represents a space where product needs, design, and technical considerations can all be addressed, potentially fostering alignment.

00:14:24.240 In software development, the time budget often stands as the greatest constraint, and it's essential to ensure that during shaping sessions, all participants can explore technical complexity and implications carefully.

00:15:02.960 Additionally, when designing solutions, there’s an immense advantage in building with Rails because the conventions provide established communication frameworks. This allows teams to collaboratively approach complex interactions and resulting discussions more clearly.

00:15:47.280 A common misunderstanding regarding Shape Up relates to the idea of a pitch. People often refer to producing a pitch as merely arguing for the importance of the project instead of creating a clear directive for builders on what needs to be accomplished.

00:16:39.360 You've probably seen projects with a detailed document that argues for its importance without offering the technical details on how to implement it. Without precise directives, the project ends up lacking substance.

00:17:26.720 To address this issue, we’re starting to reframe how we describe the outcomes of shaping, moving from pitching an idea to framing the problem and identifying the project’s priorities.

00:18:14.080 Once we have alignment on what we’re tackling, we can reshape that into actionable components. The notion of packaging shaped work means we’re prepared for actual implementation, avoiding the pitfalls of fragmented understanding that can result from breaking down a cohesive plan into disconnected tasks.

00:19:01.640 Autonomous teams are often seen as an attractive aspect of Shape Up. They represent how we can grant teams the project as a whole — allowing them to fully internalize the scope and decide how to execute rather than just handing out task lists.

00:19:47.680 While some may struggle with this idea, thinking we need elite teams for autonomy, it’s more about providing them with well-defined contexts to work within, rather than merely the caliber of team members. Good shaping ultimately allows for those inputs that give teams productive autonomy.

00:20:36.000 Better input also entails ensuring the project is achievable within the allotted timeframe and that the team is equipped with the necessary context to understand relationships between tasks across the larger project.

00:21:34.480 Furthermore, clear packaging of work creates the latitude for how much detail or instruction the team needs based on their experience levels. This enables them to operate effectively and confidently, fostering a virtuous cycle of learning.

00:22:19.680 If you're interested in exploring more about this approach, please visit my website. The book is still available for free, along with articles and resources that detail ongoing updates from working with various teams.

00:23:05.360 I staff courses that explore what it means to implement these ideas in your context, and I welcome your experiences, questions, and any challenging points you might want to discuss so that we can further this conversation together.

00:23:46.880 So, if we see each other in the hall, please stop me and share your questions, ideas, and insights. Thank you for your time today!

Rails World 2023