Fixing bugs generated by another team

Question

I'm facing the following situation:

There are 2 different teams working on the same project using Scrum, and every now and then, bugs related to user stories developed by team "A" are being assigned to team "B". We're used to fixing bugs made by other people when they belong to the same team, but things get a bit more complicated when different teams are involved. Some of the developers don't like working this way and say that the bugs must be fixed by the ones who made them, and this is causing some conflicts between the teams.

While reading some of the similar questions I've found some interesting ones (Is fixing bugs made by other people a good approach? and also Parallel teams and scrum/agile), but they are not about the same situation, or at least I don't see them that way.

During our discussions here we got 2 possible approaches: Leave the situation as is, or determine that the bugs must be assigned to the team that developed the feature. Do you guys have any suggestions?

Answer 1

What are you trying to optimise for?

1. Code quality: This is your chance to figure out how this bug escaped from the lab in the first place. Depending on how much time you want to spend on this, you could look at performing a code review with the whole team, or root cause analysis.

   • Not just looking at the code but everything around your development and test process

     • Why didn't this get found in testing? You are using test first, right? Do you consider all the quadrants?
     • Why didn't you train your team members in this area?
     • Do you have broken processes that caused this defect or allowed it to be created and not found?

2. Team knowledge / learning: Pair an expert from the team that created the bug (expert in this area, not just anyone from that team) with someone else who does not know that area, their knowledge will spread and you will have more experts in this area.

3. Happiness of team: Try to find the solution everyone, or most people, are happy with, discuss the issue in an open and non-judgemental way with the teams and come to a consensus.

4. Speed: Assign the bug to whoever has the bandwidth to work on it right now. This can be a tough one to optimise for, who will get it done the fastest, who can start working on it now, is it better to get started or to wait for someone else. Beware this one, even when optimised efficiently, aside from possibly having a negative effect on all the other parameters mentioned here, it can lead to technical debt piling up even more. Remember: more haste, less speed.

Answer 2

bugs must be fixed by the ones who made them

Programmers looking for some sort of right and wrong in the world and not finding justice-Where's Batman when you need him! No point in upsetting people for without a reason, so let's see if there are some over-all 'company' benefits.

1. Team Work Load - at times one team will get busier than another. This happens because of members leaving or taking time off. They may have less talent. It is possible their part is just harder.
2. Accountability - This needs to be considered from a team level. Are they being lazy and creating bugs because they can just leave it to the other guy. I wouldn't assume this is happening. One day, they may have to fix your bugs.
3. Inefficient Use of Time - It takes longer to fix unfamiliar bugs. See #1 to determine whether or not one team can still do it faster than the other. Only if you can demonstrate that a disproportionate amount of time is spent fixing other team's bugs and in the long-run slows the entire project down, do you have a real argument.
4. It's just not fun. - It's true, but I wouldn't make this argument. You can state that it makes your team feel less important by being required to do more of this type of work.

Find out who has decided to do this any why. Then you can consider the pros and cons. Let them know it bothers you, but you have to compare the teams outrage to the benefits to the client and the client should win unless they are completely skewed. Sharing a scrum master between two teams could be the problem. A dedicated SM may be more territorial and protective because of the negative impact on the team.

Answer 3

With the other suggestions about it being a good chance for a code review. Would it be feasible for the person who is assigned the bug to pair with someone from the other team to fix it. The combination of people from each team will help to expand the knowledge of the code base as well as get a feel for how the other team works.

Answer 4

I can see this happening in two situations, and those situations need different ways to resolve the issue.

1. The two teams work on different areas of the overall application, they have different areas of expertise and the bugs get assigned to the wrong team because the issue appears at first glance to belong to that team.
   In that case, welcome to the world of large scale software development.

   The issue can be addressed relatively easy in this case. If you realize that, after analyzing the bug, it doesn't lie in your area of expertise, you re-assign the bug to the right team/person.
   If it happens very frequently, you could think about setting up a small team with people from both teams "A" and "B" to pre-analyze incoming issues and ensure they get assigned to the right team.

2. The teams work on the same parts of the overall application and they have overlapping areas of expertise.
   In this case, they should really be regarded as one big team and the core issue seems to be that the team members don't view it as such. In this situation, the solution should be looked for more in the area of getting teams "A" and "B" to become to regard each other as members of a bigger team.

Answer 5

I see it as an opportunity to casually code review the bug location and its surroundings, so I have never been too bothered when this happened to me.

Perhaps this could be used as a third possibility; treat the bugs as code review time, or peer debugging time. This lets you also gain an idea of the business side the other team is working with; since one team seems to be depending on the other it is always useful to share this knowledge.

Ideally this would need to evolve organically, letting the most painful problems emerge from discussion; I strongly think that this should not be mandated by management :)