repeatDrive continuous improvement

Learn how to use surveys, signals, and working agreements to build a continuous improvement practice your team can own.

Continuous improvement works best when teams can drive it themselves, rather than routing everything through leadership. Surveys, signals, notifications, and working agreements are the tools for that. Leaders should make sure their teams know how to use them — and have the mandate to do so.

The process follows a cycle: make work visible, spot patterns, take action.

Make work visible

Developer surveysarrow-up-right give your team a structured way to surface friction that doesn't show up in metrics — unclear processes, lack of autonomy, poor tooling. Twice a year is a common cadence, but you set it. Results help you spot when something is off and inform which working agreements to introduce or adjust.

Pair surveys with investment distributionarrow-up-right to see how much time goes to KTLO — bugs, incidents, and maintenance. A healthy target is under 30%. If it's consistently higher, that's worth addressing.

Spot patterns

Before setting up any agreements, check what Swarmia's signalsarrow-up-right are already telling you. Signals proactively surface patterns in your team's work — too much work in progress, stale pull requests, an unexpected spike in cycle time — without you having to go looking. For each signal, Swarmia explains what happened, why it matters, and suggests next steps, such as adopting a working agreement to prevent the issue from recurring. Benchmarks help you understand whether what you're seeing is normal or an outlier compared to similar teams.

Take action

Clear norms around pull request hygiene and work in progress protect engineers from the most common sources of friction. Limiting batch size and the number of open pull requests keeps work focused and reduces context switching. Shorter cycle times and review times help changes move to production without sitting idle.

Enabling an agreement in Swarmia is just the starting point — real change requires team commitment. Discuss it with your team first: agree on what you're trying to improve and why. Start with one or two agreementsarrow-up-right so the team can build new habits before adding more.

Each working agreement can have a team notificationarrow-up-right attached. Exceptions — a pull request that exceeds the batch size limit, or a review that's taken too long — surface automatically in your team's daily digest.

Treat it as an ongoing practice

When you run your next survey, check whether changes to working agreements have had an effect. Improved results mean you're on the right track. If they didn't change, that's an equally useful signal — and a prompt to revisit and adjust.

Last updated

Was this helpful?