Scrum and Supporting Your Existing Products | #2782 - Agile software development, patterns and practices for building Microsoft .NET applications.: "Paying the bug tax, sustaining team or not?
Obviously it depends on your exact situation but I’d always choose to spread bugs across all the teams over creating an SE team. If at all possible I’d try and add these to the backlog, prioritize them accordingly and give teams time to plan to fix them in the next sprint. This is less painful that dumping them on the team to be fixed immediately. Sometimes this is unavoidable, if for example you’ve committed to a particular service level agreement around fixing bugs.
The initial pain of doing this may be large but over time the bug tax will become predictable and teams will learnt to plan for it. In the long term there are other benefits as your feature teams will have a better understanding of customer pain points and better overall knowledge of the product code (a reduction in silos).
Another alternative, which just occurred to me but I’ve not seen tried. This would be to have each feature team run periodic SE sprints. Every N’th sprint would be devoted to SE work. This theoretically has some advantages over the two approaches especially if the SE sprints were staggered across teams so there was always at least one team working on SE. I’ve not tried this. If you have I’d like to hear from you."
No comments:
Post a Comment