Cool-Downs in Shape Up — Some Practical Guidance
I write about Product Development, Engineering, and Thought over on Long Pressed.
When we switched our teams from JIRA and Scrum to Basecamp and Shape Up, one of the primary concerns from the engineering team could be summarized as, “If everything is now a project, what do we do about bugs and tech debt?”. I reached out to RJS on this topic and he told me they take a conservationist approach to their code. Leave the land better than you found it. While this is sound advice, it still left everyone with a bit of wanting. What I hadn’t realized though, we weren’t integrating a key component of Shape Up, the cool-down.
What is a Cool-Down?
Besides a few references here and there, the following is the entirety of the explanation of a cool-down in Shape Up.
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.
So the cool-down is a time period after a cycle ends where the core team of engineers and designers can work on whatever they want. The only real rule of cool-down is that everyone chooses their own work and they need to be ready to start the next cycle on schedule. The cool-down is analogous to tapering and/or recovery in the health and fitness world. It’s a great time for engineers and designers to work on bugs they’re interested in, do discovery and prototyping of their own, and maybe lend some time to product managers to help finalize the next cycle’s pitches.
What isn’t a Cool-Down?
Cool-down is absolutely not a safety net for failing to ship a project on time during a cycle. Letting cycle work spill over into the cool-down period can be damaging in all sorts of ways, such as developing dangerous thinking like, “we really have 5 weeks, not 4”. It really is meant to give the teams room to think and act at a higher level.
It’s also not Google’s “20 Percent Rule”. The work being done in cool-down should still be relevant to our product strategy and current or upcoming product portfolio.
How long should we make each Cool-Down?
There’s not much room in Shape Up for wild cycle lengths so a 1 week cool-down for every 4 week cycle or a 2 week cool-down for every 6 week cycle seems reasonable. The recovery time needs to match the expectation of energy output for the cycle. If you’re going to have 8 week cycles but only have a 1 week cool-down period then the team better be allowed to spend it at the beach instead!
What’s your practical advice?
Alright, here’s how we’re actually doing cool-down in Basecamp today. I mostly work out-of-cycle doing things like shaping, product strategy, helping sales, talking to customers, prototyping ideas, etc. During that time, I’m constantly coming up with all sorts of stuff that I don’t normally share with the team because it would be distracting and we have a strict “no backlog” rule. This stuff consists of ideas, bugs, customer feedback, observations, etc. At the same time, everyone else probably has their own lists of stuff somewhere that they’re keeping a secret because of said “no backlog” rule. So here’s what we do.
At the start of each cool-down period I will open a new Basecamp project. I’ll curate an “inspirational” todo list for this project for everyone to see what I’ve been thinking about. I’ll also create a list specific for the cool-down. The cool-down is kicked off with a simple readme attached as a note to the list.
README: This is a list that I use to track things that come up as potential needs in that aren’t planned as projects right now. The point of this list is simply to inspire what the engineering and design teams choose to work on during cool-down periods.
It’s important to understand that when I mean “inspire” I don’t mean “choose from the list”. I mean “look at how I’ve expanded the bounds of my thinking about the product, now that you’re not constrained by a project, you can do the same”. The only expectation is that the team tracks what they decide to do during the cool-down period, and that they’re pencils down at the start of the next cycle. When the next cycle starts, I kick everyone off the Basecamp project, move the list back to my own personal team, and archive the cool-down project.
What has the team actually decided to work on?
Here’s a great example to tie the importance of the cool-down back to the original concern regarding “bugs and tech-debt”.
One of our apps was stuck on an older version of Electron because of a native Windows dependency for SQLite 3 and our build process depended on pre-built binaries being available upstream. The older version was preventing a native spell check from working properly and we have people getting M1 Macs now so we needed local development support on ARM computers. One team member chose to take on this task and move our Electron Windows Build to AppVeyor.
If you enjoyed this post, you can follow me or we continue the discussion over on Twitter.