Agile Zone is brought to you in partnership with:

Gil Zilberfeld has been in software since childhood, writing BASIC programs on his trusty Sinclair ZX81. With more than twenty years of developing commercial software, he has vast experience in software methodology and practices. Gil is an agile consultant, applying agile principles over the last decade. From automated testing to exploratory testing, design practices to team collaboration, scrum to kanban, and lean startup methods – he’s done it all. He is still learning from his successes and failures. Gil speaks frequently in international conferences about unit testing, TDD, agile practices and communication. He is the author of "Everyday Unit Testing", blogs at http://www.gilzilberfeld.com and in his spare time he shoots zombies, for fun. Gil is a DZone MVB and is not an employee of DZone and has posted 65 posts at DZone. You can read more from them at their website. View Full User Profile

Secrets of Handling Support in an Agile Team

08.27.2013
| 4354 views |
  • submit to reddit

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.


Published at DZone with permission of Gil Zilberfeld, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)