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!