Hacker News Reader

Comment by McP | Hacker News Reader

I found that in my team that agile worked brilliantly for us at first - we were working together to create features that customers loved.

Then support queries came in for the features we developed previously. At first a couple of team members would split off and work on the existing features while the rest of us carried on working on the new hotness. As we increased the number of (quite diverse) features, the more diverse the support queries got.

Now we're basically no longer a team, but a group of individuals working in different areas, who happen to be in the same stand-up each morning.

I am actively looking to fix this problem. I'm sure this must have been discussed already but I can't find it! Any suggestions?

View on HN

We have a similar support load, but have been able to avoid that problem. I attribute this to two things: - We have a highly skilled support team that can handle pretty much everything except actually writing bug fixes - Every iteration we pull the whole team back to swarm on feature development together. They may get pulled into different historical features for support, but new development is always done as a team.

Support is still very costly for us, because the distraction of working on old features slows down new development. To combat that we're putting a lot of effort into fixing the root causes of our support issues and training our support team to handle more and more technical problems.

It depends what you mean when you say 'support queries' - I'm guessing it's more than just someone not understanding how a new feature works. Here are some possibilities for what you're experiencing:

* 'support queries' are actually bug reports: you're getting something wrong with your automated testing that's letting bugs get out into released code. Ideally you should have acceptance tests that make sure the code is doing what it should before you release it. Check what your team's criteria for 'Done' is - are they cutting corners to get things out the door?

* 'support queries' are actually missing functionality in new features: you're not getting all the requirements for the feature in the sprint where you implement it. You need to make sure the conversation with the product owner covers everything that the feature (user story) should do.

* 'support queries' are actually new feature requests: they should go in to the backlog and be prioritised along with everything else. You shouldn't let people push work into a sprint that hasn't been prioritised by the product owner.

We have a team that is made up of 1 person from each of our three teams. It rotates on a weekly basis, and that team does the bug fixes / investigations / support queries that come in.

The advantage is that disruption to a sprint is amortised to a constant instead of being a variable. The weekly rotations ensure that people who are writing bugs aren't isolated from the fixing of them - it also maintains morale, being stuck on a bug-fixing team is a bit of a gulag for devs IMO.

I think the error here is a common but artificial distinction between "existing features" and "new features".

From the point of view of a well-run Agile team, there's just work to do. It all gets managed through the same process. One queue, one team.

In my last team, we created a rule that when you finished something, you'd just pull the next card at the top of the stack. You could ask for help as needed, but it was your job to see that card through to completion. That forced us to cross-train. Which was certainly fun. But it also really helped us to make better software. It was very consistent, both on the surface and under the hood.

Reply on news.ycombinator.com