Why and when to use Shape Up on your team?
Introduction
The method created at Basecamp describes a product development process used to shape, bet and build meaningful products, helping to address risks and unknowns at every stage of the development.
“The method aims to better define and prioritize projects before handing off to teams to build and ship.” (Product Plan — What is the Shape Up?)
The main difficulties the process aims to avoid are the feeling of the project goes on and on without an end in sight, lack of time to think strategically about the product we build and time-consuming micromanagement.
One of the benefits of using Shape Up is the team is able to think more deeply about the right problems much earlier in the development process and, with a deadline defined and not negotiable, the team must work efficiently within the given timeframe — it leads to prioritizing what is core to the project and define what is unnecessary. Other advantage is the autonomy of the team: they are free to develop their own solutions based on the in-depth directions supplied at the start of the cycle in addition to being responsible for managing tasks, defining goals, achieving them successfully and shipping the product on time.
The process is divided into three main phases
- Shaping — the team should do a pre-work on projects before considering them to schedule, understanding the problem the new feature is trying to solve. The goal is defining an idea of solution that is not too vague and not too concrete, giving space for the team do solve the details with only one focus.
- Betting — before starting the cycle, the team evolves the main stakeholders and together choose what they will commit with to do in a non-negotiable timebox. Shape Up proposes timebox of six or three weeks — “it is long enough to finish something meaningful and still short enough to see the end from the beginning”.
- Building the product — it is where the team discover what they should do and build it: they define the tasks, make adjustments to scope and get down to the business of doing their best work to ship the new feature/product on time.
In between cycles there is a period named cool-down. The cool-down period should have no schedule, the team meet as needed and usually it is used to fix bugs, solve minor technical debts and explore new ideas and approaches.
While the team focus on building the solution, leaders can focus on shaping better projects capable of offering a meaningful value to the company and users.
Source: Basecamp Shape Up web book
QuintoAndar’s case
At QuintoAndar, we used Shape Up to accomplish a major delivery, which was the focus of our team for a semester. By concentrating efforts on just one focus, the team was able to deliver significant, robust functionality in a short period of time.
The feature deliveries were divided into incremental versions, and the entire delivery was planned in advance. As a result, regardless of the version we were working on, we had a clear understanding of our progress and, in the face of unforeseen events, we were able to refer back to the planning and adjust deadlines.
Each version was estimated for a specific development cycle (building), which allowed us to have more than one well-defined focus for each cycle, and more than one cooldown cycle. During each cooldown, each functionality was reviewed, tested, and improved, ensuring more solid deliveries and making the process more stable and ready for large-scale environments.
The specific case was the redesign of one of QuintoAndar’s most accessed pages. In each cycle, we reserved time for a battery of tests with a smaller number of users, where we identified and mapped the main issues. The most critical problems were resolved before the release, while finer adjustments were made in parallel with the development of the next increment or other team demands.
The Importance of the Cooldown Week
Shape Up operates with cycles of focus and cooldown weeks. One of the main issues we faced before implementing Shape Up was dealing with technical debt that was never prioritized and unexpected challenges that arose during task development. In the first case, we tended to prioritize deliveries over addressing technical debt, which meant we never had a moment to tackle these problems. As a result, they either resurfaced later for resolution or piled up in the backlog. In the second case, we experienced frequent delays in deliveries because we didn’t allocate time to review functionalities and address errors.
These issues were effectively addressed with the implementation of cooldown weeks: during this period, our focus shifted to polishing functionalities, resolving issues found in newly released products, and implementing improvements.
Additionally, the cooldown weeks provided us with the opportunity to handle tasks that were outside the scope of our initial planning but still fell under our team’s responsibility, such as maintenance and enhancements in other applications within QuintoAndar.
Ultimately, technical debt was significantly reduced, and our deliveries became much more consistent.
Shape Up in Relation to Team Focus
One of the factors that contribute to a team’s success is their ability to follow a plan and have a single, big goal in mind. Objectives can be quite broad, and often it’s necessary to implement a focus to achieve that objective, given the many ways to approach it.
In our planning, we aimed to deliver a complete redesign of a crucial page for QuintoAndar’s business. As part of a squad with a broader mission (ensuring a great brand experience for QuintoAndar’s Top of the Funnel products) and with the responsibility of maintaining multiple applications with quality, it was necessary to establish a focus to ensure the delivery of the redesign and prevent being diverted by external demands that didn’t align with the main objective.
To make this possible, we made some decisions: the team’s focus was solely on delivering the redesign of the important existing page, and other demands were reprioritized and negotiated to avoid affecting the focus. External demands unrelated to our focus were scheduled for the aforementioned cooldown weeks, and during each development sprint week, a squad member was assigned to give special attention to these demands (internally dubbed “Ops Week” — operational week), ensuring consistency in deliveries.
In the end, we managed to stick to the plan and deliver something of significant impact for the business in a short amount of time, with the effort of all team members engaged in a single objective.
Articles
Product Plan — What is the Shape Up?
Book Report: 5 Key Takeaways from Shape Up by Basecamp’s Ryan Singer
