Notes From a Tool User - An Agile Blog

When we left John and the team they were just getting the shipping features ready and were waiting to go ‘live’ with the site. This turns out to be a blessing and a curse. Its a blessing because the business is making money; a curse because with it come support issues.

John spends some of his time and energy just watching the team and their flow every day. In the first two Sprints after the release the team struggles and fails to meet its planning commitments. At first he’s OK and just says its the inevitable post-release hiccups (I don’t agree with John on this one, it’s not inevitable; I think it was a first warning sign – Editor), but when it’s clear that this is continuing into the 3rd Sprint he starts to get worried. John notices that team members are often being interrupted several times a day. Most of the interruptions are support issues.

During the Retrospective John chooses a timeline to help the team remember/discover what happened in the past two weeks. It’s worse than even John realized; team members spent most of their time on Production Support. After some more discussion they discovered there were three major classes of issue:

Issues where a team member just had to help support understand how to help the customer

Issues that required a small code change and could be made by most team members

Issues that required the specialized skills of one or two team members

Analysis

The team can do a number of things:

Choose one team member per Sprint who will become the first point of contact for support. Some issues they can deal with themselves and others they will have to find help with. NB This job should rotate so it’s not always the same person.

If there are multiple teams, in any one Sprint one team takes the support hit. This is the same strategy as the first at scale.

Wait until the day’s end before interrupting another team member for help on a support issue

Monitor the production support issues and track their effects on the team’s productivity. Example: usually in the days that follow handling a support issue the team is able to complete fewer Stories. Remember, its not just the cost of fixing the issue that needs to be tracked, but additional costs, such as deployment and multitasking cost.

Based on historical needs acknowledge in planning that there is a tax of 20-30% to be paid for support. This is my least favorite solution because it doesn’t help make the situation better; it just increases awareness of it.

No matter what, every time a support issue comes up, do a root cause analysis or use A3 Problem solving to identify the real issue and reduce the number of times it hits the team in the future. In addition, we have to help the organization see the costs of what is happening, the support calls might be what the organization needs at the moment but needs feedback as to the impact.

Update: One of my readers (Sergey Kotlov) pointed out that in some cases the frequent production support issues are of a database/admin support type and suggests that the team has missed an opportunity to provide support with tools to help. He’s absolutely right; in that case the PO might want to prioritize work to create support tools so the development team can stay focused. Thanks to Sergey for his suggestion.

in Toronto

September 9-10, 2015

in Montreal

September 28-29, 2015

in Montreal

September 30-October 1, 2015

Comments

I’ve experienced that scrum is in no way good for support teams. Typical solutions are to take away time/resources out of the sprint and allocate it to support tasks.

I think that kanban has a lot more advantages when dealing with support tasks. The whole unpredictability of support tasks, makes it hard to plan them in during sprint planning (except for assigning a bucket of time out of which you take time each new task).

Kanban works in a similar way to scrum (board, etc), but it’s main goal is to “limit work in progress” and to make sure the task flow is streamlined.

I’ve toyed with the idea of doing a scrum / kanban combo in a team I work with: 60-70% is planned sprint, 30-40% is kanban. The scrum part is what we commit to feature wise. We fill up the kanban part with “next sprint tasks” equal to the time we have there. If we don’t do them, it’s not bad, if we do, it’s a bonus. The support tasks are added to the kanban part and have precedence over the sprint tasks.

If you have a lot of issues, you do little to none of the “nice to have”/extra features. If you have not that many issues, you do more sprint work.

Kanban tells you to limit the work in progress. So (for instance) only 1-2 tasks could be active in the “in progress” column of your kanban board. This will allow you to manage your support flow, report on it, have separate fix releases based on the kanban flow, but keep the flexibility of adding time to the sprint when it’s calm.

Mark Levison

Jeroen – we’re in complete agreement I wouldn’t use stock Scrum for support teams. In the story we have a development team who’s application has gone live, they need to support the application but balance that support with ongoing development work.

The Scrum/Kanban combo you describe can work well and I probably should have called it out explicitly in the post. One small point, “if you have a lot of issues” – you need to stop and understand why you have these issues, i.e. Root Cause Analysis etc.

I have experienced similar issue. I have found similar issues as Mark found. I am trying to use one support story in and one sprint story out way. But I still found that it is not really helpful sometimes. It is more related to how support team access development team, how development team member solve the problem and lack of troubleshooting tools or guide. The first measure after realising real problem, I have tried to block direct support request from support team (Oooh, my god, I have received complains from CEO to service delivery manager). And I try to get a bug fixed properly – documentation, build tools, build more graceful error tracking tools and fix root cause of bugs + deliver result quicker. My intention is to bring wall done after a while when dev team members know how to handle such kind of requests in a proper way instead of always rushing solutions.

Mark Levison

Charlie – thanks for taking the time comment. It sounds like your thinking is good, I would caution only that we have to ensure that our optimization – stopping access to the development team – isn’t just a team level optimization. In cases like this I start by making a small change and seeing if that has the desired effect, before making a bigger change (cutting off access to the team).