Quick Summary: Periodic Downtime is an Agile Non-Issue, and Part of a Sustainable Cadence with Sufficient Slack
It doesn't really matter what the developers do during this downtime because unless the downtime is something that happens every Sprint, it's just the cost of doing business the way you're doing it. Agile budgeting should be done based on expected full-team iterations* rather than on individual person-hours associated with piece-work, so this is a total non-issue unless it's a chronic problem with your ScrumBut implementation or estimation practices.
*Example: 7 people at 40 hours a week for each 2-week Sprint is 560 person-hours per Sprint. You're either routinely (e.g. more often than not) delivering a Sprint Goal worth that per-Sprint cost, or the Product Owner, project, or client can choose to "fail early." If you're not thinking in terms of per-Sprint increments or validated learning, and are focused instead on 100% utilization, you're not just doing ScrumBut: you're doing agility wrong.
That said, there's always something useful for team members to do. I provide a very large (but by no means exhaustive) list of such things in the following section. Just keep in mind the goal is for the activities to be useful for both the individual team members and the team as a whole, not just busy-work to sweep the sequential nature of your testing process under the rug.
Analysis and Recommendations
There's nothing left to swarm at this point. What are some activities that don't threaten the committed increment, but provide value to the overall team/release/project that Developers could do?
Scrum isn't about swarming; it's about whole-team ownership of goals and the predictable delivery of incremental value. The framework is pretty non-prescriptive, and doesn't even require common agile practices like test-first development. While you're not really doing Scrum, I don't think that's your real issue here. I think you're experiencing an X/Y problem because you're thinking in terms of "doing all the things" rather than focusing on continuous improvement.
In particular, there is always some sort of project debt that can be paid down or paid forward. Some ideas to consider include:
- Cross-training to improve the T-shape of your Development Team members, such as:
- having software developers and testers teach each other tools and techniques;
- having UX/UI people learn more about how these things are implemented in the project's language;
- having front-end developers learn more about about back-end development, or vice versa;
- having Development Team members learn more about business analysis or requirements-gathering; or
- having database developers learn more about the object-relational mappers (ORMs) the team leverages, or having them teach the developers SQL tricks that the ORM doesn't handle for them.
- Paying down technical debt in the form of:
- more Backlog Refinement;
- spending time on all those great ideas brought up in Sprint Retrospectives but that no one has time for when Sprints lack sufficient slack;
- technical refactorings;
- code reviews;
- exploring seldom-touched or seldom-reviewed areas of the code base;
- writing additional unit tests; or
- updating developer laptops, software, and libraries.
- Assessing your architectural runway for:
- possible improvements to your CI/CD pipelines;
- capacity planning for upcoming requirements; or
- tools, processes, and systems that would improve the team's productivity.
- Learning spikes, such as:
- process spikes (e.g. "Let's try mob programming and see how that works for us!");
- educational activities related to Scrum, team tools, the problem domain, or new language features;
- demoing that shiny new IDE someone started using, but that no one else knows much about yet; or
- show-and-tell where the developers get to show each other the most useful tweaks they've made or plugins they've added to their nvim, emacs, or RubyMine environments.
- Potentially-useful side projects (think Google's now-defunct "20% time" policy) such as:
- building devcontainers;
- replacing crufty or bloated linters with something the team likes better;
- building a wiki for the project;
- or anything else that has potential value for the team, project, or organization.
- Even "just learning something new" is often beneficial because stagnant developers either stagnate or leave. When you keep your team too busy to explore, learn, or work on professional development under the 100% utilization fallacy or its many variations, the organization eventually pays the price.
In short, it really doesn't matter what the team does with slack time so long as it isn't excessive. All projects require slack; the trick is to right-size the amount of slack you have, and to do something constructive with excess slack.
If you take only only two things away from this entire post, memorize the following points:
- Avoid creating busy work to reduce the visibility or transparency of your sequential testing process. Scrum (and agility in general) are about creating transparency, visibility, and predictability. Anything that reduces those OKRs is an anti-pattern.
- Reward, don't punish, a team for being efficient or delivering faster than planned. Success is based on outcomes, not time or effort expended, so regardless of what your organization may think piling more work on people because they finished faster than expected is the exact opposite of how to create or keep 10x teams or high-performing individuals.
Slack is essential to effective processes (see pretty much all of queuing theory). If your process creates excessive slack (however you choose to define that) then fix the process; don't hide the problem or disincentivize your team to deliver ahead of schedule.