Blocking-release defect - how the team should handle that?
Dear forum,
I have a mature Scrum team part of my engineering group. This team is self-organized, and there is no line-manager assigned for this team. The team went a long way in their agile journey – they pick up their own PBIs, estimate them, and implement then with a team ownership.
In the last retrospective meeting, they raised an item: “the traditional team leader used to handle crises cases – when blocking-release defect arrived towards the release date, the team leader was responsible to choose a specific person, stop him/her from what they are doing, assign them the critical defect, and make sure the defect is fixed ASAP. Today, when the PO prioritizes defect as critical to be fixed (sometimes needs to be fixed within the same day), we feel the traditional team leader role is missing, as we didn’t come up with a good procedure to handle that situation”.
Before I approach the team and start asking powerful questions, so they will come up with a procedure that suites their needs, I wanted to ask the forum which procedures your teams came up with for handling “critical-defect fix-in-the-same-day cases”.
Have the PO and team been discussing this together? Is it worth the wait for the customer if this critical issues blocks other items to be created/released are done at a (I'm presuming) slightly later point in time?
How about the Bradley Bug Chart?
If they are truly self-organized and self-managed then I wonder why this even came up? To me that is actually an indicator that they still have work to do. If they can self-manage on the "routine" they should be able to identify what to do with the special cases.
My teams treat these kind of things as they would any kind of blocking issue encountered while doing a Sprint Backlog item. It is brought to the team, the team then discusses and reacts. The work being done is discussed during the Daily Scrum because it could have the potential of putting the Sprint Goal at risk. There have been times the entire team dropped everything to work on an item as they felt that was the most efficient way to get it done. Other times, 1 person will pull away and work on the item. It is entirely up to the Development Team to determine and it is usually done on a case-by-case basis. I have used the Bradley Bug Chart as an example to the teams for a starting point in finding their own methods. It works pretty well even if you decide to use it as your process but as with everything you should make sure that it fits well into your organization.
Thanks for the feedback. The team is following Bradly chart more or less. I was talking about mid-sprint critical defect that comes from outside of the team (from external independent testing team, from alpha environment, from production, etc).
I agree with Daniel that they are not fully self-organized – I guess self-organization is a scale, not a black-white thing. Daniel’s example is what I was looking for. I won’t copy-paste it, but rather let the team self-organize around a solution. Thanks.