45

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

Improve this question
4
  • 5
    Do you have any idea why a lot of their code just before leaving was buggy? "reasonable explanations" can help a lot here. For example, if they were rushing to try to get finished on a big chunk of work before departure, then that would provide a fair amount of explanation.
    – Ben Barden
    May 7, 2019 at 13:46
  • @BenBarden rushing to finish before departure is a fair assumption, albeit I didn't keep that close an eye their progress
    – user1821961
    May 7, 2019 at 21:07
  • 2
    Were you assigned to fix the bugs/overall quality, or are you taking that on yourself? If you were assigned, presumably your manager (who is really the only person that matters) already knows where the bugs came from and why you are working on them.
    – GreySage
    May 8, 2019 at 23:19
  • @GreySage I've assumed I would be taking care of it as we have small teams.
    – user1821961
    May 14, 2019 at 13:49

5 Answers 5

Reset to default
133

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.

Improve this answer
15
  • 23
    @Gherman you are finished when QA either doesn't find any bugs (rare), or when any bugs they find are not urgent/big enough to warrant fixing "now". Done usually means the software meets all requirements, and is functional enough to pass some level of quality testing (level of quality depends on target audience, type of software, etc).
    – Bleh
    May 7, 2019 at 16:30
  • 11
    >no need to mention where this bug comes from. Nobody cares. The organization I work with cares about this more than anything else - why do bugs exist in the first place (lack of feature definition, lack of domain understanding, lack of exploratory testing etc.) Just felt it was worth mentioning that it's organization dependent - some organizations very much care where the bugs came from (sometimes more than what the bug itself was).
    – user2152081
    May 7, 2019 at 16:48
  • 1
    @Gherman When leave the job, or the product reaches end-of-life. But then you're starting all over again with the next.
    – Ed Plunkett
    May 7, 2019 at 18:17
  • 3
    If there's an employee who creates lots of bugs, he may be degrading the development process, and that should be handled by management. But if the bugs are from an ex-employee, there's not much that can be done about them other than trying to fix them.
    – Barmar
    May 7, 2019 at 20:44
  • 8
    OP appears a bit concerned b/c s/he doesn't want others to think s/he is the person that originated the bugs. In that respect, I think a response that says "Sorry, that code was already present when I started working on it and I'm still familiarizing myself with the code-base" would be a reasonable response that can help OP note that there's a subset of those bugs that weren't caused by OP.
    – code_dredd
    May 7, 2019 at 22:26
32

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.

Improve this answer
1
  • This is excellent, let the team/manager draw their own conclusions. It doesn't reflect on you because you came into it after it was already 'coded', and have to ramp up.
    – Paul
    May 8, 2019 at 13:28
18

  • 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.

Improve this answer
3
  • 4
    I like this one, just talk about the code and the bugs, blame the code "I found it didn't do this" "I'm improving this..."
    – rogerdpack
    May 7, 2019 at 17:17
  • 1
    "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." If they're now responsible for feature X, and there are problems with feature X, then people could quite easily assume that they're the reason there are problems with feature X. They may not know, or remember, that somebody else was previously responsible for feature X, and they may not know when the issues were introduced to the code.
    – Anthony Grist
    May 8, 2019 at 12:09
  • 2
    @AnthonyGrist Then, you need a better manager. I certainly don't want my manager to "forget" about it. Also note, this in context of a stand-up meeting, so the team (agile) is small (2~7, ideally) and cohesive.
    – Sourav Ghosh
    May 8, 2019 at 12:15
4

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.

Improve this answer
2
  • 1
    I don't see any mention of Scrum specifically in the question. However, the points you make should be applicable to any agile process. And #3 (don't shoot the messenger) is especially important to any organization / team / whatever that aspires to be something more than dysfunctional.
    – David
    May 8, 2019 at 22:44
  • 1
    It wasn't. It was just inferred from the tags.
    – Daniel
    May 8, 2019 at 23:12
3

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .