Farewell Cool-Down. Hello, Ramp-Up

My previous explanation of Cool-Downs was misleading for many teams. I recently inverted the concept for my own team. The following is the announcement I posted to describe the changes we made.

Cool-down was originally introduced in Shape Up to combat an unfortunately common misconception that software development teams can sustainably run sprint after sprint after sprint, fueled by backlogs and a single planning meeting every couple of weeks.

If we were to run six-week cycles back to back, there wouldn’t be any time to breathe and think about what’s next. The end of a cycle is the worst time to meet and plan because everybody is too busy finishing projects and making last-minute decisions in order to ship on time.

Therefore, after each six-week cycle, we schedule two weeks for cool-down. This is a period with no scheduled work where we can breathe, meet as needed, and consider what to do next.

During cool-down, programmers and designers on project teams are free to work on whatever they want. After working hard to ship their six-week projects, they enjoy having time that’s under their control. They use it to fix bugs, explore new ideas, or try out new technical possibilities.

In my experience, engineering and leadership teams (including myself) reading about and considering Shape Up tend to fixate on a particular detail of this definition as the entire definition of a Cool-down.

programmers and designers on project teams are free to work on whatever they want

Because of that fixation, a proper implementation of Cool-down was left out of many teams’ adoption of Shape Up, which only amplified the desire to be allotted a “break” from the intensity of project work.

Still more worrisome, without framework-supporting organizational design such as that of Basecamp (who intentionally positions principal engineers to work out-of-cycle with product and leadership in order to get ahead of The Next Big Thing ™️), teams adopting “Shape Up” (we’re in quotes now because whatever it is isn’t shape up) become increasingly susceptible to the pressure to kick off the next project cycle before the work has been properly framed, shaped and packaged.

We’re going to solve this problem by re-introducing Cool-down as Ramp Up, clarifying its purpose, and outlining key differences between the Ramp Up and Building phases of Shape Up.

What is Ramp Up?

Ramp Up is a fixed period of time prior to the kick off of a new cycle in which the engineering, product, and leadership teams collaborate to explore new ideas, run spikes to answer technical, business and design questions, and fix bugs or change pressing but trivial details of our software.

In essence, Ramp Up is time set aside for the team to work out the details of what we might build next.

How is Ramp Up different than Building?

Once we’ve kicked off a project with the product development team, the problem that we’re solving, how we’re solving that problem, and how much time we’re investing in solving that problem is fixed. That means that each discipline is primarily responsible for executing as an individual contributor to the team while coordinating efforts, communicating progress, raising issues and making trade offs. Almost everything else is is a formality. As an example, the following are some of a Product Manager’s individual contributor roles and responsibilities during the building phase.

• Work with Customer Success to ensure our downstream systems and processes are prepared for the changes we’re imposing on the business
• Develop the high fidelity dashboards that the team will use to monitor the changes against framed business outcomes
• Share relevant materials with our Training Team as the project comes together and keep them up to date on progress with materials including designs, specifications, process diagrams, etc.

We expend quite a bit of energy during the building phase making sure that the engineering team has a distraction free environment to maximize our chances at delivering the highest quality software within the budgeted appetite. As a general heuristic, we ask that if an engagement with the engineering team is not in service to the engineering team, that it waits until a project is finished.

Ramp Up is the opposite side of the same coin. Team members should make themselves available and feel good coming together and exploring different ways of solving future problems. This is not an invitation for “product” to assign work to “engineering” without going through the rigorous framing and shaping framework that’s gotten us this far.

Finally, let’s stay intentional and continue to ask “What room are we in?”, “who should be in this room?”, “What should we do in this room?” and “What should we try to take out of this room?”