2

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?

Improve this question
4
  • 2
    Do you want the team making the most bugs to "fix" those bugs or do you want the team that has a clue "fixing" the most bugs? Which approach do you think will result in a better system? Besides, frequently it might not be possible to know whose bug it is until the problem is found. Usually by that time, the fix is already identified and it would be quite inefficient to not just get it done right then and now just to reassign to another team. Also, there is no code ownership in agile.
    – Dunk
    May 13, 2014 at 14:50
  • 2
    Bugs detected post-development are a process smell. Why aren't these bugs being detected by the developers before release? Sounds like your testing is inadequate. If you work to improve pre-release testing life will get better.
    – kevin cline
    May 13, 2014 at 15:40
  • 1
    @kevincline this goes without saying. But it's also obvious that some bugs will slip through the testing process.
    – Konrad Morawski
    May 13, 2014 at 22:08
  • 1
    Why can't you just re-assign the bug to the originating team?
    – James Anderson
    May 14, 2014 at 1:30

5 Answers 5

Reset to default
4

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.

Improve this answer
2
  • 1
    Speed: Assign the bug to whoever has the bandwidth to work on it right now - it doesn't necessarily optimize the process for speed in the long run. Just because I'm free to start working on the bug straight away doesn't mean I'll be faster than folks who can get down to it tomorrow, if they know the code better than I do.
    – Konrad Morawski
    May 13, 2014 at 22:10
  • I think that code quality is the biggest gap here. Since both teams work on the same parts of the application, the knowledge is similar. We do have a testing process, but I've to admit that it's very poor at the moment. One of the actions is to improve this process and also work to change the mindset of the teams, since the teams are still facing some problems regarding the points mentioned by @JeffO
    – Joao Franco
    May 14, 2014 at 14:00
3

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.

Improve this answer
2
  • 1
    It's not only a matter of some abstract justice. Having to fix your own bugs motivates to maintain high quality of one's code. If you cut corners just to ship on time, it's going to bite you - that's the important lesson
    – Konrad Morawski
    May 13, 2014 at 22:13
  • Somethings you said are happening here. Also the 2 teams share the same SM, but it was a recent change. Probably it's time to have a good discussions with the teams and try to find a way to change the status quo.
    – Joao Franco
    May 14, 2014 at 14:08
1

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.

Improve this answer
1

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.

Improve this answer
1
  • It's the second option. Getting the teams to communicate better with each other seems to be one of the solutions.
    – Joao Franco
    May 14, 2014 at 14:03
0

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 :)

Improve this answer
1
  • 1
    Code review most definitely does not smooth over problems between developer teams, especially if they're constantly trying to put the blame on the other team. Granted, at least talking does allow them to get it out of their system.
    – Neil
    May 13, 2014 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.