The Sweeper Team and unplanned work

Unplanned work is one of the things teams often struggle with when they try to adopt agile development, without any qualifiers. The usual advice is to set aside time for unplanned work and factor it into estimates and team capacity. I’ve never seen that work, however good the team was. When we reorganized the team at the start of the year (or perhaps earlier), unplanned work was one of our biggest headaches. Most of it came from keeping production running: either handling customer problems too complex for customer support, or dealing with technical snags under the principle You build You run it. The telemetry showed that unplanned work was eating up as much as a third of our time. So we settled on the following team setup.

At Zonky we had three teams of four to six people (that size was no accident). They weren’t organized around parts of the product. They were generalist teams, also called T-shaped. An aside on splitting teams by product area: what bothers me about that setup is the uneven workload and the knowledge silos it creates. We needed the opposite. With lots of new developers, we wanted to spread knowledge of the whole application, even if it slowed development. One of the three teams would take a turn of two sprints (a month) as the Sweeper Team.

The Sweeper Team doesn’t do sprint planning. It works from the following priorities, in order (I’ve left them as they appear in our Confluence):

1. Handling production issues during business hours (8/5) (pro-actively watching the #dev-production Slack channel).

2. Handling service desk tickets see Sweeper team dashboard

3. Supporting the back office (business) teams

4. Tickets from backlog. Tickets that are explicitly designated for sweeper team are marked with sweeper_backlog

5. Supporting QA, Test and Release automation initiatives — Jenkins, Tests environments, Docker etc.

We use Service Desk as the entry point for all problems reported from outside the team. Its ticket submission interface is much friendlier than JIRA’s. Every ticket it creates goes into a Slack channel where it is picked up by the Sweeper Team. The team has a normal daily standup, so we know what is happening. If Service Desk is empty or there’s nothing to sweep (sometimes feature requests come in that deserve planning), we keep a backlog of little things it would be nice to do. If we don’t get to them, that’s fine. We’ll deal with them during bug fixing day(s), but that’s for another time. Besides, there is always plenty of work to do on automation or to help our other back office teams. Nothing motivates developers more than seeing the results of their work in action.

One absolute rule: the Sweeper Team must never be scheduled to do anything that other sprint work depends on. This is capacity you hold in reserve for whatever unplanned work comes up.

Because the sweeper role rotates, nobody particularly minds it. Some developers are happy as pigs in mud doing it. Others are glad to get back to their usual routine after a month. Rotating the whole team means we don’t have to find individual specialists to fill the rota, and we keep the habits that teams naturally develop together.

The only snag is handing over work in progress when the teams rotate. It’s simple for the outgoing sweeper team because no product work should depend on it. Sweeping tasks either go to the next team or get scheduled for the following sprint. It’s harder for the team leaving product development. For major product changes we’ve extended the sweeper team’s turn. Incidentally, when a product team can’t rotate, it’s a good sign the work isn’t being approached iteratively or in an agile way. Smaller tasks are easier to hand over and pick up. Iterative development and agile ways of working go hand in hand with feature flags, but I’ll tell you another time about LaunchDarkly, the service we use for them.