Secrets of Handling Support in an Agile Team

Heads-up: I’ve recently started looking more closely into Lean and Kanban. Expect more posts like this one.

Typemock is a unique company. Developers’ work is similar to our customers’ work. And so, since day one, the developers have also been doing support work.

Support calls have their own life cycle. That’s why they are usually handled by a separate organization within a company. But at Typemock, the same development skills are needed for both product development and support.

Support calls come from different sources (email, forum, twitter or directly from sales). They are then reproduced and analyzed (understanding the problem may include rounds of communication with the customer).  And finally, there is a solution, a patch or a workaround.

You can’t estimate how much work and time it takes to complete a support call. You can’t estimate how many calls will enter in an iteration. If there are too many, this can clog up an entire iteration.

So how do you consume the support activities within an agile team?

At first, we’ve reserved a specific amount of time inside the iteration for support. Based on measurements, we knew the average capacity needed to handle calls,

But that’s not enough – the nature of incoming calls is disruptive. In order to maintain premium support level, we can’t delay handling them.  We could be prioritizing tasks as they come, but imagine how wasteful that would be.

In Lean terms, this means wreaking havoc on the value flow through the system.

Reserving capacity is not enough. So the dev team dedicates one developer per iteration for support work. The developer handles all support tasks.

Every iteration another developer assumes this role. The benefits are:

• We hold great support as a value. To instill this value, all developers do support work.
• Support work is tiring. The support person starts feeling like an outsider within the dev team. To keep up energy and motivation, duration of the support duty is limited.
• Apart from development skills, support work develops communication skills and also some sales skills. Everyone can and should improve.
• Dealing with bugs enhances the knowledge of parts of the products, some usually are not touched during regular development. This kind of knowledge is dispersed in the team due to the rotation.

We get the benefit of focused support and uninterrupted development. All the developers experience support work, but are not seperated from the rest of the team.

And it doesn’t stop there. Next time I’ll talk about how support work is implemented through a Kanban system.