First thought... who decides which resources get the glory of working on the sprint team that creates and delivers features and business value each sprint vs. the hazing of working on the support team that fixes the crap. I really hope that if you decide it is necessary to split into these two groups, you at least flip flop the assignment or slowly rotate resources between teams to make it feel like one big team. Otherwise, the supporters will only be mad at the creators and you will fall into the typical us/them developer/QA turf war.
A sub-question was posted on how to handle "critical" issues. It was stated, these are the things that are more important than anything the sprint currently being worked. Several points here:
- If these critical issues are bugs or defects, and they happen often... then it's time to have some courage and discipline and go upstream and ask difficult questions. WHY are these things happening, and HOW can they be reduced in frequency? Instead of adapting to handle them, go to the source and stop them. If you can't because "they" are a different group under different management, then you aren't in an agile organization.
- If they don't happen very often, then this is a simple answer. Let the product owner decide whether the item is more important than items currently in the sprint. If it is, then it should be estimated and should displace a set of stories that are lower priority and of equal cumulative value.
- Work one week sprints. As a support team, you need the ability to be more flexible. Shorter sprints allow for quicker reaction and re-prioritization. Also, work can't stagnate without being noticed. Deployment is quicker (although you might deploy daily and not wait for the sprint end).
- Think about applying Kanban. Loosen the strict requirements of scrum and use Kanban to drive how many things you have in flight at a time. Use iterations as a measurement and assessment tool, and use Kanban to drive priority and work. Walking the board will put the daily focus on priorities.
I've done the support team. We tracked progress in issues, knowing that some are large and some are small, because it should all pretty much wash in the end. Really big bugs became features, and we tried to not let people "bug" features as a way of getting their stories in. We averaged 20+ issues closed a week. Not to bad, eh?
ReplyDeleteIf you have separate teams, absolutely rotate between teams. Maybe even randomize the team membership each sprint (odds are you'll have the people you want, or the support people will drag in the developers they need). We did peg a developer to bug fixes when his feature ended up having a lot of spread, so that he could get it resolved. We intended to move him back to regular development when it shook out. I was gone before, and don't know if it happened.
Triage rule: Production failures first (keep $$ flowing), then failures in the release candidate (keep QA/test/demo going), then non-critical production bugs, then trivialities.
We never got to trivialities.
I like the idea of having only one team, and making bugs fight with features for development time, but not everyone sees it that way. It's a management decision. Reducing new development to close bugs is a choice, and reducing production support in order to get more features is one too.
There is a very healthy follow-up comment thread on LinkedIn here
ReplyDeleteIt is great. for oneof the idea I always add two additional questions:
ReplyDelete1. " Is this issue more important then my current development?"
2. "If yes, Have you agreed with the responsible to chnage my work?" (If the support request is related to other project than the currect one.)