11

I am an engineering manager and I manage an engineer who is responsible for a backlog with long lasting development tasks and many bugs arriving a few times a week. We work in scrum sprints but when a bug is arriving we prioritise it over the sprint items. Lately the developer is complaining that they are constantly interrupted to do bug fixing and that their role is of a support engineer and not a developer anymore because often they have to work all week on bugs while at the same time deprioritizing the development tasks. I understand their point of view. How could I solve this issue while maintaining the engineer? I could think of

a) not allowing any bugs to enter the sprints and plan them on the next sprint. Which negatively affect the business.

b) allocating more members on this team so the bugs are more evenly distributed

c) creating a different team for bug fixes

How is this usually organised in a situation where there is a constant stream of bugs arriving a few times a week?

Improve this question
6
  • 13
    Always fix bugs first, see Spolsky's classic piece: joelonsoftware.com/2000/08/09/… (point 5 is the relevant one).
    – Jack Aidley
    Commented Dec 20, 2023 at 11:32
  • 7
    I've made similar complaints myself. The demotivating part was not fixing bugs (which is development work), but rather 1) being directly exposed (and seemingly accountable) to the expectations of users who had been sold something we were not delivering, and 2) having to work around significant limitations in a product we were not really able to change. Make sure you are solving the right problem.
    – Jacob is on Codidact
    Commented Dec 20, 2023 at 11:42
  • 7
    If you have a single developer, and there are enough bugs to take all this developer's time, then you have a serious problem. You should stop development altogether until this is under control since new development will (inevitably) introduce new bugs, making it impossible to keep up.
    – JacquesB
    Commented Dec 20, 2023 at 16:14
  • 1
    @JacquesB unless that development is to redesign something to be less likely to "attract" bugs, currently the developer might just patch one small issue after another without being able to look at a bigger solution... but I guess you meant feature development?
    – Frank Hopkins
    Commented Dec 20, 2023 at 19:10
  • 2
    As to what to do - have you asked your developer? What do they think? You should consider their input.
    – sleske
    Commented Dec 21, 2023 at 14:02

6 Answers 6

Reset to default
18

Your question sounds a bit like your "team" consists of this sole engineer? If yes, the main question is why they didn't run away yet. Such a situation isn't sustainable.

Apart from the "team" size, your product seems to be a problem. If you have a constant stream of bug reports, it's most likely lacking in quality, and your first priority should be to get it into a reasonable shape. This may require more thorough analysis of the root causes of bugs, refactoring, establishing a solid suite of unit tests, etc. I don't known whether your developer would be willing to do this if they really want to develop good code and not support crappy code, but perhaps the possibility of developing good code for the buggy areas instead of fixing them with duct tape may have some appeal.

Improve this answer
11
  • 5
    A team consisting of a single developer means a bus factor of 1. They get hit by a bus (or go on vacation, or decide that there are other more interesting jobs) and then you're without a team. Not good.
    – Hans-Martin Mosner
    Commented Dec 20, 2023 at 11:50
  • 5
    @CapBarracudas Unless there is a genuine emergency, you need to stop that happening. Programmers need to be able to concentrate on what they're doing to stay productive and happy.
    – Jack Aidley
    Commented Dec 20, 2023 at 11:54
  • 11
    @CapBarracudas, imagine every morning you plan to do X, Y and Z that day, but then you get constant interruptions so that at the end of the week none of those tasks are done. How happy would you go into your weekend?
    – Bart van Ingen Schenau
    Commented Dec 20, 2023 at 13:37
  • 4
    @CapBarracudas there are a few numbers typically tossed around as to how long an interruption costs a developer to get their mind back to the state they were earlier in an attempt to quantify the cost of interruptions. They are based on some study(ies?), I don't know the quality of, but here is one article as an example that talks about it brightdevelopers.com/… google is your friend to find more, e.g. contextkeeper.io/blog/…
    – Frank Hopkins
    Commented Dec 20, 2023 at 19:14
  • 10
    @CapBarracudas not research, but illustrative: imgur.com/xvNRKIT
    – Joshua Drake
    Commented Dec 20, 2023 at 21:05
14

First of all I agree with Hans-Martin Mosner's answer.

However, in your current situation there also might be an issue with the bug fixing process. Either all bugs are emergencies that directly affect a lot of customers and need to be fixed as soon as possible or you are lacking a proper reporting and categorization process. Most bugs typically can wait at the very least a day if not days, weeks, months until they get fixed - from the level of impact speaking. While developers should aim to fix bugs fast, this should be a proper process that allows a developer to finish their current task and then with a fresh undistracted mind can aim to fix the bug.

So unless all your bugs are emergencies (and then you really should invest a few weeks/months in improving the quality of your application), you should ensure that:

  • the developer has tasks that are taking them at most a day to do typically
  • bugs are documented and categorized by someone else and the developer is only disturbed for emergency bugs that need immediate fixing
  • the bugs are planned in for the next day and the developer then can pick them up instead of working on something else (and obviously you acknowledge then that some regular sprint items won't be done this sprint)

And yes, Kanban would seem more natural if you have a lot of fluctuation like with regularly incoming bugs (credit to Philipp Kendall's answer). Alternatively you can try to represent them with a bug fixing ticket in the sprint or reduce the sprint size by a day per week, such that bug fixing is a process outside of the scrum process. If you are agile then you have all the freedom in the world to adjust your process such that it works for your situation.

Improve this answer
2
  • 5
    I like this answer the best. Not every bug is an emergency. Someone needs to prioritize bugs along with the customer so they know the trade-off: fix the bug or get a shiny new bike. Pushing the decision to the customer makes them aware of these issues. Once the distractions start affecting the bottom line, you'll get pressure to stabilize the product. This gives you leverage to slow down the release schedule so you can more thoroughly test things. Again, give the customer a choice: stabilize the product or accept monetary losses. Profit always seems to win.
    – Greg Burghardt
    Commented Dec 20, 2023 at 21:02
  • 3
    One other alternative to consider with bugs not being an emergency: How many of them can wait a sprint? If your bugs can wait a couple of weeks, then you can plan them into the next sprint as normal, but high priority backlog items.
    – user1937198
    Commented Dec 20, 2023 at 21:26
13

It sounds like you are trapped in a loop of rushing the dev work, which then has bugs, which then causes you to rush the dev work.

Break the cycle by doing fewer, but better tested releases. Stop doing new features until you have a release with no new bugs reported for a month.

Don't release new features until they have been extensively tested.

Don't add new features to a version that's come back from testing with bugs. Just fix the bugs on that version and re-release it.

Plan you release and what features will be in it far in advance. allow time for testing and bug fixes.

Only when you have achieved a stable bug free release and a good testing methodology can you attempt to speed up the feature development.

Improve this answer
1
  • ... and @cap-barracudas's company should hire more developpers: instead of 1, at least 4 (more is better), so that when one is in vacation there is at least 2 available for bug fixes and 1 for new dev. They have "multiple bugs, several times a week" : this in itself probably needs 1 or 2 devs dedicated to bug fixes. Additionnally, additionnal devs eyes make more bugs shallow and easier to spot & fix
    – Olivier Dulac
    Commented Dec 21, 2023 at 17:38
8

You have apparently not considered option D: stop doing Scrum.

It sounds like your work is much more suited to something like Kanban rather than Scrum, so you should do that.

Improve this answer
4
  • Yeah, I was researching that right now. It seems this should be the case. But even in Kanban, you should not stop a task in progress and do another, right? Just change the top of the backlog? Or you can freely do context switching?
    – Cap Barracudas
    Commented Dec 20, 2023 at 11:19
  • 18
    If you don't have enough people to work on all the bugs coming in, that's a different problem and not one a different development methodology can solve...
    – Philip Kendall
    Commented Dec 20, 2023 at 11:21
  • 7
    It sounds like they aren't doing Scrum already.
    – Simon B
    Commented Dec 20, 2023 at 14:55
  • 2
    while that would make the management bit more clearly reflect the requirements, I don't think it would solve the developers issue, it would just stare him more into the face ;) (but it would at least reflect the fact that bugs apparently cannot wait a week)
    – Frank Hopkins
    Commented Dec 20, 2023 at 19:17
5

One step is to set up everyone’s development environment so that bug fixes can be made without disturbing ongoing development. For example, I always have three folders that are checked out from git. Work in the first, bug fixes in the second, experimenting in the third. So to fix a bug, I just check out the latest version from git.

If you have bugs that need to be fixed right now then you need to interrupt current work. That’s bugs that cost the company money if they are not fixed right now.

Any other bugs you prioritise, and anyone finishing a task picks up the next item from the bug list without asking anyone. Maybe take the second highest bug if it’s more in your area of expertise but no new development tasks until all bugs are worked on. If someone doesn’t want to pull their weight fixing bugs then you have a word with them.

Improve this answer
1

Lately the developer is complaining that they are constantly interrupted to do bug fixing and that their role is of a support engineer and not a developer anymore because often they have to work all week on bugs while at the same time deprioritizing the development tasks.

There are two complaints here. Interruptions due to a bug and needing to fix bugs.

Option A addresses only interruptions but amount of bugs would remain same.

Option B on its own doesn't fix either problem. The way it's described, it would reduce both complaints by half but if frequency is high enough that wouldn't change anything.

Option C addresses both complaints but doesn't seem realistic or efficient to me. There shouldn't be so many bug reports that you can have full time developer(s) fixing them and never run out of work to do.

Mix of options B and C can address both complaints while remaining efficient. Bring in another developer or whole team who's priority would be fixing bugs but when they're done with current bugs they can take feature development tasks. This would remove fixing bugs and interruptions from current developer and it would not leave bugfix team with nothing to do once they clear their bug log.

Improve this answer

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