18 months ago, I wrote about why I believe sprints are taking the joy from building software. When I met Matthew in my course and learned his org fully adopted Shape Up, we started working on this article. 

His team ran eight Shape Up cycles. Here's what worked and what didn't. 🎤 to Matthew!

In December 2024, we came out of a reorg a leaner engineering team than we had ever been. We had a choice to make - accept that we were just going to be in maintenance mode, or find a way to actually ship.

We are a 10+ year old company, with a large and complex codebase. And, like many organizations, our engineering teams’ feedback was consistent: too many interruptions, unnecessary meetings, and context switching, without enough time to focus. 

We had always been an scrum-based shop - 2 week sprints, planning, stand ups, ticket pointing, backlog grooming, etc. We had limited resources and we were going into 2025 assuming that we would just be in maintenance mode moving forward.

Having recently explored alternative SDLC methodologies, we had some familiarity with the Shape Up. This seemed like the right moment to give it a try.

We had some internal discussions on how we would adapt and what our processes could look like, then prepared a presentation for leadership on what would change. Leadership, obviously, wanted to get more than “just maintenance” out of the team, so they were willing to let us try a new methodology - especially if it meant being able to produce more features. Shape Up meant some changes in expectations from their side, but they supported the changes and gave us the go-ahead to move forward. 

After sharing out with the team and some refinement of the new processes, at the beginning of January 2025 we had our first Shape Up project cycle.

Basecamp’s official Shape Up guide is full of great guidance and process, but (as they recommend) we had some modifications to make to accommodate the makeup of our team. 

Leading up to a project cycle, product, engineering leadership, stakeholders - or really anyone in the organization - brings a project pitch together. A project pitch outlines a business problem that needs to be solved, not the actual feature to develop.

Once ready, the pitches are presented to the company leadership team, where they ask questions, provide appetite for each project, and help prioritize. Appetite is another Shape Up term - instead of committing to specific features, we decide how much time we are willing to invest in each problem. It can be a full cycle, but can also be smaller parts. 

These meetings are not about presenting the solution. The pitch process forces people to break down the problem to the basics - as the pitch might not get picked up, or the appetite for the project might change. This helps prevent the common case where the product org brings to the table detailed solutions instead of problems.

We've found that through this process, we often end up shaping pitches even further to bring alignment with leadership's goals as the projects became more clearly defined.

On shaping: Shaping means defining the problem and solution at a level of abstraction that's concrete enough to act on but loose enough to leave room for the team to figure out the details. 

This whole process happens in parallel with the projects that are in flight. Engineers are brought in when necessary to talk about technical constraints, evaluating scope, or to  provide their input on feasibility:

During the cooldown, the product & engineering leadership team chooses the projects for the next cycle (called bets in ShapeUp). 

Teams are formed around the selected projects. Often projects will require specific skills or knowledge, but we try to rotate engineers into areas they may be less familiar with. This allows us to pair senior engineers with more junior engineers to share knowledge and experience.

One of the tenants of Shape Up is that we are committing to solve a problem within six weeks. This can be a challenge for projects that may take longer as it goes against the principle to commit to multiple cycles. Often, there are clear themes that we can identify carrying over to the next cycle. If this is the case, we usually carry over a couple engineers from the teams between cycles.

Part of the goal, though, is that people gain experience across the codebase. This means that cycle to cycle, someone may switch projects every couple weeks. 

Another important aspect of each project team is the Tech Lead. Since we are a flatter organization, this provides a way to have a single point of contact for me on each project. The Tech Lead also provides leadership for the team in decision making, stakeholder coordination, and scoping. 

(An additional side effect of the Tech Lead role is that it gives engineers experience that can lead to a future people manager role or continued growth as an IC/technical leader)

Every team has a PM, a tech lead, product engineers (generally 3-4, but can vary in size), and an assigned Platform/SRE engineer for support.

Each team has the full autonomy to decide how they operate:

The cycle starts with 1-2 exploration weeks. Usually there are more meetings, as the team begins to shape the scope of the project. We found that taking time for this part is crucial for the success of the projects. The scope is much easier to negotiate at this early stage, before you are rushing to implement. You can properly investigate the risks or the tech debt you might create.

Tech leads coordinate together on any impacts to each other's teams' projects. This is facilitated by a weekly tech lead meeting where tech leads have an opportunity to share status on projects and anything that might need coordination with other teams

The sync with the business side happens throughout the process:

That last bullet is really valuable. Often, we’ll have a stakeholder demo the functionality delivered to the entire company. This closes the loop on projects the business has prioritized with the impact the project has had for specific stakeholders.

The next (and super valuable) part of this process.

The cool-down is a two-week period where the engineering team itself gets to lead what gets done. Teams or individuals can work on identified tech debt they've discovered, complete documentation for projects, handle smaller support requests from the business - whatever just needs to get done that doesn't fit into a project.

There are cases where an urgent request comes through from the business that takes priority, but in general we have been able to use this time as intended, 

Overall, that is the flow. We are now in our eighth project cycle since starting Shape Up, and have seen multiple advantages from working this way.

3 main reasons: Better developer experience, stronger business buy-in and involvement, and consistent delivery. 

I can't emphasize enough how much value this process has given in terms of available focus time for the engineers. 

First, Shape Up provides focus through clear priority guidelines. Any request that comes through outside of the pitch process is triaged before any individual engineer is interrupted by it. If a request comes through, whether it is a new feature, an enhancement, or even a bug, the request is weighed against the projects that had been selected through the pitch process. Other methodologies can hold on to a similar prioritization process, but Shape Up provides a clear way to say, “is this request more important than the projects already prioritized?” Sometimes it is and then there’s a further conversation on the impact to the projects, but either way, the process protects the engineers from interruptions that would normally take them away from the project they are one

Additionally, the six-week timeframe also provides enough time to complete full projects, whereas in two-week sprints, a request might get shoved in and distract from the project work that was in progress.

Second, teams have autonomy to decide how they work. If teams only need one in-person meeting a week, then they can decide to do that. No scrum ceremonies constraints. Sprint planning, stand ups, ticket pointing, backlog grooming - these are all potential distractions.

Third, there is a trust that is established between the business and the engineers. The engineers have clear guidance on what the priorities are because the business has decided on specific projects. Giving engineers the problem instead of the specific tickets creates genuine ownership - they're not just delivering a feature, they're solving a business need.

All this leads to massive gains in developer productivity and satisfaction. Multiple engineers over this past year have told me how much more work they are getting done. We had projects where we were able to not only tackle the business problems, but underlying technical debt that had lingered for years. One cycle we were able to remove over 100,000 lines of code.

The process also leads to more opportunities for developers to grow, whether in their leadership or technical skills. Knowledge sharing is much better, and the separation between engineering ownership is removed. 

Trust takes time to build. I would say that it took about two to three cycles for the business to see the full value of this methodology. But now, project pitches and working through them with stakeholders is a valuable part of the rhythms of the company as a whole. Anyone can bring forward a project pitch.

For example, we were approaching a significant Python end-of-life upgrade, which also resulted in a need for product engineering work because of functional requirements related to several dependencies within our application. Our platform/SRE team brought forward a pitch for the Python upgrade, presented the requirements, and relayed the importance of this work for the business. 

There are other methodologies that have processes around how priorities are determined, but none seem to be as clear cut as Shape Up. The business is making a commitment to the technology team, just as the technology team is committing to get the project done. This 2-sided trust and commitment begins to remove boundaries between organizations within the company. There's less head butting, less confusion, and more ownership.

In the eight cycles we've run we have consistently been able to deliver nearly all committed projects (~25 of them). Some went a little long into the cool-down, but some were also done earlier than expected.

Previously, interruptions, unclear expectations, and lack of focus time resulted in many projects being delayed (or worse, not feeling like they had a clear end) - and there was also never time to address the underlying tech debt. And often there was a feeling that product and engineering weren’t always aligned with what the business or stakeholders were looking for.  

Of course, there were some learnings along the way and the process is made to serve the team, not the team for the process.

One thing we learned early is that the first one to two weeks are critical for scoping. It can feel frustrating, like no progress is being made on the feature. But shaping the project to a scope that the committed team can deliver has proven to produce higher quality by the end of the cycle, and sets expectations for the business and stakeholders more clearly.

Of course, even with the best defined scope, unforeseen issues will always come up. The defined scope might have a feature that is more complicated than previously thought, tech debt might get in the way, or a bug might come up. The team’s scoping and flexibility needs to account for this.

Larger projects become a challenge if they can't be scoped down to six-week deliverables. In a purer form, a twelve-week project should be broken down to two projects where the second project may not be prioritized in the next cycle. This isn't always possible.

There may also be cases where it takes six weeks to release a feature, but we want to test its impact. It's challenging to integrate the testing follow up in the next cycle, especially if the teams are dispersed into different projects. This is a challenge we're still working on, but often we will scope the testing follow up into the cycle capacity as planned interruptions.

And, while the cool down period is good in theory, in practice it often gets co-opted by the business for small projects and little requests. Engineering's ownership of that time is limited. In one instance, we had a two-week project that ended up taking more time and affected the start of the next project in the following cycle.

Lastly, I'm not sure how well this scales. Our team is ~20 engineers. We can share information across the entire engineering organization quickly and efficiently. Once the product and engineering organization grows, larger teams within the organization would need to be responsible for their own Shape Up process and cadence. I think it can work, but there would be challenges.

One of my favorite aspects of how we've adopted Shape Up is the inclusion of business stakeholders in how we demo releases to the rest of the company. 

Often we have the business owner of the project run the demo at a monthly company-wide meeting. This does two things, first, it shows appreciation for the engineering team who worked on the project. It's one thing for them to show off what they've done, it is more meaningful when the stakeholder does it.

Second, it ties together the business investment in the cycle. At the beginning of the cycle, the business chose the priorities, then at the end, by demoing, they confirm those priorities. This idea isn't isolated to Shape Up - it can be done in whatever process you're using. It breaks down silos between engineering and other organizations in the company, provides empathy between them, and effectively shows how the project will be put into use by the people who will be using it.

Every cycle I am continuously impressed with how much we deliver on the projects we've picked up. My team went into 2025 thinking that we would be in maintenance mode, but we came out delivering on large initiatives, massive tech debt reduction, consolidation and simplification of services, and, most importantly, an engineering team reinvigorated to write great software.

Scrum certainly has its place, but teams considering a process change should absolutely take a look at Shape Up. There is no way to overstate the amount of focus, efficiency, and delivery we've seen. Software engineers want to focus on solving problems without interruption - the Shape Up process can provide that and add value to your business at the same time.

Thank you Matthew!

I've only done a partial version of this - 3-week cycles with 1-week cooldowns, skipping the proper scoping and betting. Even that partial adoption showed me how powerful the cooldown is. Once engineers get dedicated time to tackle what they know needs fixing, good luck taking it away :)