The SWAT team in Scrum

The Special Unit for Software Errors

When a complete software development team works together on a new project, such as the creation of a new online shop, the project work today is in many cases organised agilely with Scrum. The entire team works together towards one goal, namely to complete the new software in such a way that users and customers can derive maximum business value from it. If everything goes well, the new shop will soon be able to go live. And since special attention was paid to software quality during the agile development process, the software runs absolutely error-free. The team can concentrate on the next project in peace …

A beautiful dream so far. Unfortunately, reality often looks different. And so the development team has to take care of user requests and bugfixing from now on. At the same time, there are usually many new requirements in the pipeline that are to be implemented immediately after the go-live. The question of how these two aspects can be reconciled is a headache for many development teams.

Support requests simply in the backlog?

In the implementation phase, the product backlog, which contains the epics and user stories for the application to be developed, shows the team the way. For each sprint, a sprint backlog is created, from which the team members can draw self-organised user stories and technical tasks for editing. A Kanban board, ideally a physical board (e.g. a magnetic board or pinboard) or a large screen in the team room, is used to control the workflow and track progress.

But how do error messages and customer inquiries fit into the perfect world of a product and sprint backlog? Unfortunately, these requests are often time-critical and, above all, unpredictable in terms of processing effort. What looks at first glance like a minor malfunction in productive operation or a minor flaw in the user interface can make a big splash in the source code. A good example of this type of malfunction are performance deficits or concurrency problems. Since it is difficult, if not impossible, to estimate the analysis and correction effort in advance, the team cannot schedule this work as part of regular sprint planning.

Context changes slow down development progress

In addition, support requests usually do not follow the sprint rhythm, but suddenly emerge in the middle of a sprint. Error analysis and troubleshooting keeps developers torn out of implementing new features. The frequent context changes cost time and make the team inefficient. I have already experienced in many software projects that the team only reacts to the needs of day-to-day operations. The implementation of new stories falls by the wayside. Sprint goals are no longer achieved and the burndown in the sprint is virtually non-existent due to a lot of scope changes.

Time buffers and dedicated operational teams

It is often recommended to provide a time buffer in the sprint for support requests and other “optional” tasks. A common benchmark here is 20% of the total productive development time. It should be noted that even with a 40-hour week, the productive development time is never actually 8 hours a day, but lower. In my experience it is helpful to assume 6 hours of productive development time.

At least with regard to the sprint goal and the burndown chart, such a time buffer can be a good way to relax the situation. However, developers are still torn out of their current jobs by support calls, emails, or new tickets.

Alternatively, I’ve also seen the production support being transferred to a dedicated development team. This team had the task of only taking care of day-to-day operations. In my experience, however, this is a rather unfavorable solution. Due to the ongoing project business, there is usually little time available for the transfer of know-how between the implementation team and the day-to-day operations team. The developers in the operational team often feel left alone when the colleagues in the implementation team have too little time to support them due to the next project phase. Some members of the operating team even see themselves degraded to second-class developers, according to the motto: “We weren’t allowed to have a say in the implementation, but now we have to pay for their design decisions”. Employee motivation works differently.

Special operations command for software errors

In order to tackle these difficulties, as a Scrum Master I used a somewhat different approach in a project, which proved to be successful there. The team was divided into two mini teams: Some of the developers take care of the ongoing support. This part of the team was jokingly named SWAT-Team (Special Weapons and Tactics) by us, inspired by the special task forces of the police. The developers in the SWAT team are responsible for quickly taking action in the event of a production disruption. The other developers are responsible for implementing new features.

Weapons are not used in the SWAT team despite the military sounding name – except of course for the debugger, log viewer and other troubleshooting tools. The SWAT team consists of at least two developers, depending on the size of the project. One developer is the primary contact person for the users and the first-level support, the second colleague is available as backup and reviewer. The colleagues who do not belong to the SWAT team are only available in exceptional cases for unplanned queries and routine activities. For example, if a developer becomes ill or there are critical errors in the live system that require the help of colleagues.

If there are not enough requests for the SWAT team in a sprint, it should be able to access a reserve pool of tasks. Therefore, the product owner should make sure that the product backlog always contains more items than fit into a sprint.

Increased motivation through rotation

And in order to avoid a two-tier society in the team, the members of the SWAT team change after every two-week sprint. The first SWAT contact person is again dedicated to feature development and the second colleague becomes the first contact person. A colleague from feature development moves up as a backup.

On the one hand, this has the advantage that knowledge about new features and problems is distributed more evenly across the team during day-to-day operations. Knowledge islands, which exist in most software development teams, are thus slowly dissolved. In this way, the SWAT team system is also used for risk management, since it is easier to compensate for the loss of colleagues over time.

On the other hand, it promotes motivation in the team. My experience is that most developers prefer to develop new features in peace and quiet and often see day-to-day operations as a necessary evil. It seems more fair to the team members if the task, which is perceived as rather unpleasant, rotates at regular intervals.

The rotation of tasks can also make it easier to train new colleagues. Ideally, the SWAT team should be composed in such a way that experienced developers work together with less experienced developers.

Bottom line

The question of how software operations and software development can be harmonised will eventually have to be answered by all development teams. So-called SWAT teams, in which a part of the team rotates in a sprint rhythm and is responsible for support, can be an approach to bring the two closer together. This also benefits users and customers. For their needs, there is a contact person who is available at all times for the duration of the sprint and who can take care of their concerns in peace. And the quality of the features completed in parallel will also be higher in most cases due to the concentrated and uninterrupted work on them.

Notes:

Kathrin Herrmann has published more articles in the t2informatik Blog, including

t2informatik develops and modernises software as a service provider. Click here to learn more.