Cooldown sprints: take a break to keep your edge

Tech is a marathon, not a sprint.

Whether you are developing a Tech product, putting together an engineering team, or even thinking about your own career, you should not sprint into it: Unfortunately, we all heard about burnout. Also, while the human brain is great at understanding complex environments, critical thinking and making valuable decisions take time: Have you ever answered too quickly to a question, only to think later “Oh, I should actually have said something else!”? Haven’t you ever heard “Sleep on it.”? This is exactly why resisting the temptation of excitement to benefit from a cooldown period is crucial!

One way or another, most Tech teams work with an Agile framework: SCRUM, Shape Up, or whatever DIY variations. As a result, most tech teams have sprints (A Sprint is a short period during which a Scrum team works to complete a defined amount of work.) and do them back-to-back. While this approach is particularly fitted for complex environments and a good driver for delivery and “getting it done”, it can fall short against complicated topics where critical thinking and experiments, hence time, are needed.

Additionally, sprint priorities are usually managed by product owners to keep focus on adding value for users. Tackling technical debts and building expertise through R&D is a common struggle within such organizations, as sprints are dedicated to delivering value iteratively and keeping velocity high, which is not always compatible with R&D and experiments, which are often unproductive in the short term.

Take a step back

The idea of cooldown sprints emerged as a way to reconcile the sprints and the marathon. If you don’t identify yourself and your company in the struggles I mentioned above, good for you, you did not fall into the trap of back-to-back sprints and delivery at all costs! But in my experience, a large majority of tech organizations need formal time organization to do so: every now and then, a cooldown period can be introduced between usual sprints. The main point is that during this cooldown period, velocity and delivery of product priorities should not be the main focus. This leaves time for activities that teams never have time to do.

Take back ownership

Team members usually know better than anyone else what they would need in order to be more efficient in the long run, to gain expertise, or to facilitate their daily work: a flaky CI has been bothering developers for a while, false positive alerts are reducing their focus, a new library or tool might be useful for some use-cases, and a legacy part of the code would benefit from an object-oriented rewrite. Cooldown sprints are a great opportunity for engineering teams to decide what they want and need to work on.

Is it worth it?

Setting up cooldown sprints obviously comes at the cost of delivery in the short term. But I have seen the benefits largely outweigh this loss in the long run.

While it can feel a bit uncomfortable at first, this is a powerful opportunity for personal and professional growth, making work more interesting and fostering innovations and new ideas. Many engineers strive for more ownership and responsibilities: they would be able to take the lead on some topics of their choice and experiment during cooldown sprints.

They might succeed and deliver new tools, practices, or knowledge within the team, enhancing efficiency overall; or they might find that their idea was irrelevant after all, in which case they would have learned about the investigated topic and led an experiment or a project anyway. Tech companies are ready to pay dearly well-trained engineers with seniority; they should not have a hard time understanding the benefits of training internally on topics relevant to the company.

In the long run, those dedicated time slots are a great tool to:

• manage technical debt (hence to maintain or increase velocity overall),
• foster expertise to stay on top of your industry (we always hear that Tech is a rapidly evolving environment),
• increase ownership and autonomy, make engineering jobs more interesting, and ultimately improve involvement and retention.

Many metrics and aspects highlighted by the SPACE framework can directly or indirectly be enhanced as a result of those cooldown sprints.

Implementing cooldown sprints

As an engineering leader, there are 3 levers to adjust to successfully implement cooldown sprints in your organization: schedule, guidance, and internal communication.

Schedule

How often your team goes into a cooldown sprint is an investment trade-off. How much of your capital goes into short-term delivery vs. long-run investments? There is no universal answer to this as it depends on the company and product maturity, amount of technical debt, pace of innovation in your domain, and teammates.

Enforcing a clear and regular schedule is critical. Without time slots properly defined in advance, chances are you will never actually perform cooldown sprints. There will always be other priorities and pressure to postpone them. Having a clear schedule will bring visibility to stakeholders about timeframes during which the team won’t be delivering so that the rest of the company’s work can be planned accordingly. Documenting this schedule is also a good way for tech leaders to discuss it with other leaders in the company, to explicitly challenge the short-term vs. long-run investment trade-off.

Guidance

Depending on your teammates’ seniority, expertise, and capacity to lead, they could feel uncomfortable suggesting relevant topics, they might not know how to take the lead and organize, or they might jump into topics you already know are not relevant or suited. While cooldowns can be used to let teammates experiment with those things, providing some guidance and mentorship can help avoid discouraging failures. Prioritization between different topics might also not be natural for some developers; you should guide them and ask the right questions so that they can figure out what matters the most to them and can impact the most their daily work.

Internal communication

While usually well received and appreciated by engineering teammates, the approach might encounter resistance from other parts of the company: you will basically announce to direct stakeholders of the engineering teams’s work that the workforce bandwidth they have access to will be reduced by 10% to 30%.

Therefore, it is crucial to clearly set expectations such as what type of work can still be prioritized (critical bugs, EPIC/high-level groomings, support escalations, etc.). Those guidelines can also evolve over time, to mitigate the brutality of the change at first, adjust along with the acceptation of the approach, and also adapt to teammates’ expectations and requests.

Another critical aspect of this practice is to get approval for more people across the organization over time. While the importance of technical debts, R&D, training, and refactos is often obvious for tech people, it can be challenging to understand for non-tech teammates. Frequently communicating updates about the outcomes of cooldown periods publically helps showcase the benefits of this long-term investment, and sharing new practices and ideas across the company: maybe your team learned to use a new library which capacities will inspire the Product team with a new feature that they thought was too costly before?

Return on experience: How it works at WP Media

The elephant in the room

End of 2023, Product & Engineering at WP Media reached a steady pace: we met a satisfying release cycle with WP plugin releases every sprint, and back-end services releases several times a week. Fixes for impacting issues were handled promptly while managing to implement new features from time to time, and the quality of new releases was quite good with a very low amount of defects. The teams were organized in such a way that main blockers were removed from daily work, allowing everyone to move forward.

However, we were still quite far from perfection: the cost of implementing new features was still quite important due to many inefficiencies in testing, code architecture, and deprecated tooling; and the teams suffered frequent solicitations to investigate and work around long-standing issues. Somehow, developers and QA engineers were doing their job of picking up tasks and grooming, implementing, and releasing them but this routine lacked learning, creativity, and innovation; it lacked thinking and engineering.

This is when we started to question the “back-to-back delivery sprint” approach: there was no room to get into complex investigations, with low predictability and no quick wins or immediate positive returns. Those issues we were facing were just not fitting the prioritization process of sprints and the untackled frictions were becoming our main slow-down.

To steer through turbulence

While everyone acknowledged this issue in our organization, the idea of cooldown sprints did not bring much enthusiasm outside of the engineering and tech teams: it was mostly perceived as a reduction of bandwidth and throughput of the teams. To showcase the potential benefits of the approach, I highlighted:

• results of previous activities performed within the team such as successful developer initiatives, outcomes of R&D, etc. As a leader, you should ensure some teammates can get time to tackle such topics to start building a record of valuable outcomes outside of usual product-oriented tasks. If you are hands-on, you might be able to get into it yourself to support your teams in the process.
• an actual backlog of developer initiatives and topic ideas for cooldown sprints.
• that this is a best practice gaining traction in many organizations and referenced in widely used framework (Shape Up cooldown principle). Sharing external resources such as this Simple Programmer article helps to demonstrate this is not just a whim, but a possible solution to a commonly experienced issue.

Showcasing a few already-existing results as well as a well-defined list of topics for first iterations helps to gain trust across your company: make sure to prepare it with interested team members to leverage collective intelligence and gain promoters within your teams.

Once the idea is accepted, actually planning a cooldown sprint can be challenging: there will always be priorities coming up and “good” reasons to postpone it. To overcome this challenge, make sure to agree in advance on a schedule (over a few months) with Product people (and all stakeholders) as well as rules about priorities that could take over cooldown activities (such as critical bugs for instance). At WP Media, we target a 2-weeks cooldown every two months. We set the dates in advance, and authorize ourselves to switch a cooldown sprint with the normal sprint before it, in case it better fits the schedule eventually.

To sustain acceptance of the process throughout time, and also to keep motivation up within the teams, I find it important to share outcomes and learnings of each cooldown sprint, as well as status updates for uncompleted topics for the whole company. This serves several purposes:

• facilitating knowledge-sharing within engineering teams so that everyone stays up-to-date with the latest changes and learnings;
• showcasing the productivity benefits of cooldown sprints to stakeholders;
• advocating for this way of working across the whole company so that every other teammate understands how your teams work, and maybe identify synergies during those periods (cross-team knowledge sharing, role-swapping, etc.).

Valuable outcomes

After several quarters with cooldown sprints added to our schedule, some major breakthroughs occurred within WP Media’s engineering organization. Here are some examples of topics tackled thanks to this approach and the related outcomes:

• Improvements of our best practices for plugin development, including the use of PHPStan, implementation of a library to safeguard WP filter types;
• Open-source contributions to WordPress Core and WP Launchpad, a framework for WP plugin developments we actively support;
• CI improvements: fixing flaky tests, adding linters such as eslint and flake8, or even adding CI to some repositories;
• Proof-of-concept of a Django app backed with CockroachDB to sustain high traffic and to adapt our architecture to the infrastructure we have access to: this became our standard architecture for our backend services;
• Updates of wp-rocket.me codebase to leverage High-Performance Order Storage WooCommerce mode to highly increase the website performances, previously impacted by slow database queries, especially during promo campaigns generating high traffic. To achieve this, the team had to tackle impactful topics such as adding unit & integration test capabilities to the website codebase, changing the PayPal payment system and updating many custom third-party integrations;
• Preparing talks for internal knowledge-sharing and also for conferences!

Most of those topics would have been hard to prioritize and tackle within standard sprints. But the outcomes are huge and impactful for our teams and our products.

Featured image by muntazar mansory from Pixabay.