Otdfbt

A former employee in good standing has changed jobs. Unfortunately a lot of their work just prior to leaving did not satisfy some acceptance criteria found by QA, and had other bugs. I'm picking up the slack in fixing them. I expect some of it to not be trivial for me to begin fixing (due to my skill/knowledge being lower), and to have to work through this for a while, and what is the best way I should talk about this during daily stand ups?

My goals are

1. not to make it sound like I'm speaking badly about the code or the former employee that left, whose work I'm fixing.


2. to try not to make myself look bad as I'm going to be busy fixing something that didn't pass muster (I think it looks bad when you push things that are found to have issues when tested), for at least a single sprint, wherein I may not be contributing as much to the new work we've pulled in.
   
   
   • not to sound like I'm trying to deflect responsibility for fixing it, but certainly I wouldn't want to be mistaken for the source of these issues.
   
   

Edit: To clarify the tickets bounced our QA process as they didn't satisfy all the acceptance criteria within them and some other bugs were found, so perhaps saying they only had bugs isn't precise. (The code's already merged in behind a feature flag though.)

You are worrying about nothing. Software has bugs, that is inevitable, and everyone knows it. QA finds bugs, hopefully puts them into a bug tracking system, and you take one bug from the bug tracker, fix it, then the next one and so on until you are finished.

There is no need to mention where this bug comes from. Nobody cares. If someone asks you why there are so many bugs, you say “because QA is doing a good job”. If anyone actually complains, ask here again and tell us about their complaint.

In the stand up, you should just state the facts:

• Yesterday, I worked on bug #532 about the widgets being the wrong colour. Completed that and it's ready for the next deployment.


• Today, I'm going to work on bug #536 about the crash when trying to order more widgets.


• Potentially blocked because I don't understand the interactions with the back-end ordering service. Who can I talk to about that?

Anything else is out of scope for the stand up. Beyond that, someone (your team lead, your manager, whoever assigns you work) has asked you to work on these issues so they already know where they've come from and why you're not contributing new features to the sprint. Let them worry about that.

• 
  

  
  

  1) Don't make it sound like I'm speaking badly about the code or the former employee that left, who's work I'm fixing.

  
  

  
  
  

  Well, you talk about the problems in the code, without mentioning the why (or whom) part, bugs are there and they need to be fixed - that's it.

  
  


• 
  

  
  

  2) Try not to make myself look bad as I'm going to be busy fixing something that didn't pass muster (I think it looks bad when you push things that are found to have issues when tested ), for at least a single sprint, wherein I may not be contributing as much to the new work we've pulled in.

  
  

  
  
  

  Not your job to worry about the assignment. Once you're assigned something, only thing you should bother whether you're completing (or at least making progress) your assignments as expected or not. Why you are working on something, is almost always above your pay-grade.

  
  


• 
  

  
  

  2.5) Not sound like I'm trying to deflect responsibility for fixing it, but certainly I wouldn't want to be mistaken for the source of these issues.

  
  

  
  
  

  Why do you think this way? Code is written by someone else, QA check has been done by some other one, you're the one fixing it. No one will think you as the source of problem here.

  
  

So, finally, to answer:

what is the best way I should talk about this during daily stand ups?

Just the same way if the bugs would have been found from someone else's code who's still working in the team. A bug is found, you're assigned to fix it, state the progress you made yesterday and state the plan for today; also mention if you need any help from the team to get over any obstacle you have. You're done.

There are some underlying concepts of Scrum that are not being effectively honored in the situation you describe that are leading to the concern you have.

1) The whole team is meant to own the completion of work. A particular feature is only done once it is implemented, tested, and potentially releasable to the standard of the definition of done. You mention old work vs newly committed work, but this is committed work that the team has not finished. You are helping the team complete this work. This should definite not reflect badly on you nor should it be viewed as old work.

2) Development in Scrum is adaptive. Often times we need to refactor or "fix" things not because we screwed up before but because things have changed since then. This is normal.

3) We are human beings and perfect mastery of any skill is impossible. Scrum requires us to strive to be a team who can identify mistakes and improve how we work without it being a personal attack, not be a team that avoids those conversations. If you feel like saying that you are fixing a mistake someone made is considered bad, that's really a deep psychological safety challenge in the team that very much needs to be addressed.

Just report to the company bug tracker and your superior what is the current status of the code by telling the simple truth and without hiding anything.

When filling the bug tracker, try to avoid mentioning the former dev's name as much as possible and also avoid adjectives (bad, poor, shitty...). Just focus on facts.

Have a meeting with your superior and or the team explaining the situation and the needed resources to go through the whole fixing: maybe you need a few more weeks, maybe another dev is needed, maybe a training for you etc. Your superior knows you and your strengths so if a bug needs some knowledge you don't have, he shouldn't blame you.