Who should fix bugs in a Scrum/Agile environment? [closed]

Question

In your opinion, who should fix a bug? A programmer, right? OK but really, who... let me explain.

I'm a Scrum Master across a number of Scrum projects. Scrum says 'ring-fence your resources where possible', a sentiment I whole-heartedly agree with.

Generally we integrate a certain %age of each sprint to be bug-fixing from the previous sprint(s) - all well and good.

After each Sprint we Demo and Restrospective to our clients, and promote our development code to a UAT environment (our client generally doesn't want a small bit of his project to go-live, but that's up to them - we're keeping our side of the bargain by ensuring we deploy working and testable code).

Once all sprints are complete we have a UAT phase where the client takes a thorough test of the completed software to find any last minute bugs. Now ideally these would have been caught already, but realistically there are a some that only discovered during UAT.

During this UAT phase, not all the developers are needed on the project 100% of the time, and so we like to reallocate them to other projects. However, Scrum says 'ring-fence your resources where possible'.

My problem is, I'm allocating developers to the UAT phase of one project while starting a separate Scrum project with them elsewhere. Not ideal - however, this is a commercial reality at the moment.

I can either:

1) Live with it and have developers fix their own code - and allocate some time (say, 20%) of the developer to the previous project's UAT.

2) Ensure a handover is in place and have 1 or 2 developers dedicated to bug fixing code 100% of the time.

I like 1), but it makes resourcing a real pain in the arse.

2) scares me, I feel developers won't take responsibility over the quality of their own code. I feel there's a lot to be said in ensuring developers take ownership of their own code - and asking them to fix their own bugs is a good way of ensuring quality. Noone likes fixing bugs, so I've found developers generally try and do a better job up front knowing they'll have to fix any issues that are raised anyway. However, 2) is easier to plan and resource. But 2) will take longer, as fixing a bug in someone elses code is costly in terms of time and resource. If it is a complicated fix, it may need the original developer's help anyway, and it will certainly take longer to fix by someone who isn't as familiar with that section of the code base.

What do people think?

Leahy

silly question, but isn't a UAT another sprint? IOW, you say you're delivering workable bits, but you aren't. So, it should be back on the programmer(s) who is/are responsible. – Photooffset

Just as a side note: 1. you shouldn't "retrospect to your customer", you do the retrospective inside the team, identify (and possibly solve) your problems. Retros are for the team and nobody else. 2. Your problem with who should fix bugs can be sole´ved in retrospective :) 3. Scrum master who isn't part of a team full time, full heart, is likely to be more of a mid-managerial overhead rather then be of any real help. – Sultan

I highly question Agile's effectiveness except as a way to sell courses and books. – Girardi

Answer 1

People should fix their own code. Take advantage of the fact that no one likes going back and fixing old stuff when they could be writing new stuff. If the developer responsible for the bug can be identified, make sure they are responsible for fixing the problem. This will encourage developers to be more diligent in writing clean code the first time since no one wants to be seen as the person who has to keeping fixing things they've broken. This is true during development as well when someone breaks the current build.

Update: Having said that, I wouldn't necessarily be dogmatic about it. The customer's needs come first and if the person who created the bug can't be reassigned to do the fix, you may have to assign the fix to someone else.

Boorman

+1: UAT is a testing sprint. People are allocated to supporting UAT. You need total user commitment, and you need to be as committed as the users. If the users can't put 100% effort into UAT, you're releasing too often, or the project isn't high-enough priority and should be rethought. – Leukorrhea

Take advantage of the fact that no one likes going back and fixing old stuff when they could be writing new stuff. I disagree. Due to code ownership, I feel very proud of what I write and any problems in it I will fix immediately, with gusto, and work late to ensure the problem is resolved and my code is absolutely sparkling with awesomeness. – Chromous

Nope, this won't work. It's not always immediately clear what's the root cause, and will only lead to fingerpointing: "You worked on it last." "But it was triggered by old tech debt introduced by you." "I think Ian also worked on it, right? He's on vacation." The bug should be taken by whoever is free, or, if really urgent, someone should volunteer, based on the skills. – Ringnecked

Answer 2

ScrumMasters don't allocate developer resources. ScrumMaster is a role fulfilled by someone on the Team.

That aside, the Product Owner is the "on the Team project manager", and should be fighting to secure the resources that are needed to stablize the product into production.

Engineering practices have to be improved so that the Team(s) are approaching zero bugs. "Bugs" that live past the end of a Sprint have to go on the Product Backlog to be prioritized by the the Product Owner.

Adigranth

+1 for clarifying Scrum Master role. If ex-manager calls him self a Scrum Master... beware ;) – Stephi

Thanks zvolkov...that's one of my mini-missions :) – Adigranth

@drivendev - can you explain your answer in more detail? re: The difference between a manager, project manager and SrumMaster. And is the ScrumMaster a code-slinger, or? (maybe I should make this its own question?) – Carchemish

Metro Smurf, check out this great blog entry from a professional CSM trainer: blogs.danube.com/who-is-the-project-manager-in-scrum Should the SM be a code-slinger? If that's part of the skillset that they bring to the Team then 'yes'. – Adigranth

+1 for three great points, too bad I can only mark ya up by 1. I especially like the use of the word "fighting". Too many product owners don't understand the full extent of their role. – Concinnous

!Metro Smurf: Yes -- make your question a separate question. – Leukorrhea

Answer 3

This is a very interesting topic, project management is vital and the apprpriate allocation of resources is essential.

One point I would raise is that having dedicated bug fixers may increase the quality of the code. If I was developing code that had my name against it that I knew other people were responsible for I would do everything I coudl to make sure it was good code.

Perhaps a combination approach is required.. You could take a couple of developers on any project - a different pair on each project - and make them resposible for the bug fixing phase outlining that responsibility up front. That way they can ensure they are up to speed as the project goes along as well as a handover at the end. Your resource allocation is easier and the client gets top notch support.

Just a slightly different way of looking at it.

Cheers Nathan

Photopia

Working forever as a full time maintenance programmer is (IMHO) seriously boring and demoralizing. I believe it also breeds laziness and poor practices. The people I know who say they enjoy that kind of work are usually minimal-effort types with no regard for maintaining code quality. I can't imagine how using full time bug fixers could possibly improve quality. – Botheration

Can you imagine being the Development Manager in an company and having to say to the CIO..."our code is so bad I'd like an additional 250k per year in our budget to hire a pair of full time bug fixers"? – Adigranth

These are valid points but were to programmers make 125k per annum? Certainly not where I work :) I must admit I've always worked in an environment where I was responsible for my own code. The bonus of increased quality from 'peer pressure' comes through peer review. So, as I said in my original comment pick 2 on each project, a different 2 on each project and give the responsibility to them. – Photopia

@nathj07: direct pay isn't the sum of the compensation package. A programmer making $75k might very well cost the company $125k per year due to little things like insurance, computer, software, phone, desk, etc.... Also, every area is different in terms of available talent, cost of living, etc. – Saleable

Answer 4

Your team should NOT be starting new project work until the current one ships. I think most scrum practitioners would argue that there is no place in scrum for UAT (as it was done in waterfall). What you are looking for is called a stabilization sprint and is your last sprint right before go-live. The WHOLE team works on it. Stuff that gets done during this time includes last minute bugs, GUI beautification tweaks, roll-out documentation, help guides, operations training, and long lunches. It is also potentially a great time for the team to learn something new on their own without the "pressure" of delivering backlog items or to unwind a little before starting something new. Based on your customer's UAT timeframe expectations; if it tends to be on the longer side; you might also put off non-customer facing tasks to this sprint such as log monitoring, server setup scripting, maintenance screens, or other misc tool building.

Whatever you do, don't do any work outside of the Sprint boundaries. It is a slippery slope into waterfall-esque scheduling oblivion.

Concinnous

+1: You can call it "UAT" if it makes your users happy. But UAT/Stablilization is a proper sprint like other development sprints. Everyone's involved. – Leukorrhea

Answer 5

I think bugs should be fixed by the original developer. Making developers to fix bugs in code that was written by someone else could take a lot more time and moreover could make them demotivated since fixing bugs is not that very exiting.

Argentiferous

Answer 6

I really don't like option 2) because:

• It gives people the feeling that the job has been done while it hasn't (it's not DONE, there are bugs),
• I think people should be responsible for the code they wrote, not others,
• I don't think that "bug fixer" is a job, you are not respecting people when doing this.

So option 1) has my preference (but please stop talking about resources and resourcing).

Finally, a little quote:

If you have separate test and fix cycles, you're testing too late. --M. Poppendieck

Yes, I know, it's easier to say than to do... but nevertheless, she's damn right.

Tripody

Answer 7

I vote for #2. As a developer I hate context switching and that's what you essentially impose with #1. As for the code ownership issue, having developers own pieces of code is an anti-pattern. Strive for shared ownership: introduce pairing, rotation etc.

To second @kevindtimm's comment, UAT is just another sprint. Perhaps w/ less developers.

On the other hand, the core of Agile Software manifesto is to deliver business value incrementally, so ideally you're supposed to push to PROD at the end of each sprint. If so then shouldn't UAT be part of every single sprint. Isn't that what the Demo is for?

Stephi

+1 for code ownership as an anti-pattern, though I support option 1, broadly defined. Someone from the original team should fix it, but not necessarily the developer or developers that coded it in the first place. Unless the code is pristine and beautifully factored, the costs of bringing strangers in to fix the code would just be too high. – Belisle

Code ownership != responsibility. You can still be responsible for creating and, subsequently, fixing a bug even if you have shared code ownership. Shared ownership doesn't mean that it's not my code, but rather that everyone can say that it is my code. – Boorman

Answer 8

I am a lead developer in a Scrum driven team. The way that we tend to work it in my organisation is this:

Before the starts of a sprint each developer will be allocated a percentage of how productive we think they are going to be during the sprint. For example a more skilled more experienced developer will probably be able to be productive 70-80% of his total time during the sprint. This gives time for unexpected meetings, bug fixes. I will come onto the bug fixes in a moment. We will get the estimates for all the tasks signed off and then plan the developers work.

Going into the sprint the developer will carry out his planned work and complete his own testing. If Possible as each block of work is completed another testing phase will take place either by the Scrum leader or the product owner (project manager) just to make sure that there isn’t anything glaringly obvious that needs to be looked at. Anything that comes up in this testing phase goes straight back to the developer that wrote it to complete in the sprint. The way we see it is that the team has effectively committed to completing the tasks given to us at the beginning of a sprint so we needs to complete them one way or another.

If an urgent bug comes into the team and it has to be done right this minute then myself and the scrum leader will take a view on whether or not it it is possible to get it done without effecting the planned work depending on how well we are doing. I.E. if we are half a day ahead of schedule and the estimate on the bug is half a day we will do it without changing the planned work. If that’s not possible we go back to the product owner who decides what it is that has to be pulled out of the sprint.

If a non urgent bug is assigned to the team part way through a sprint then the product owner give it a priority and it will remain in our pot. When the product owner then comes up with our next set of objectives he will prioritise the bugs and the project work together and these will become our planned items for the next sprint.

The thing to note is that it doesn’t matter which project the bug came from. Everything has a priority and that is what needs to be managed. After all you only have a certain development resource. When it comes to which developer does it that depends on several things. you don't always know exactly whose code introduced the bug. Especially if it’s from a very old project. If the same developer can fix it then there is obviously a time benefit there but that exact developer might not be available. The way that we try and work it is that any developer should be able to work on any given task. In the real world this isn't always possible but that that is always our end goal.

I realise that I have been beating around the bush here but in answer to your question about who should do the bug fix in short this is what I would say:

• If the bug is identified during the same sprint that the work was being done then send it back to the original developer.
• If its urgent then it has to go to the best person to do the task because it needs to done as fast as possible. That might not be the person that originally wrote the code it might be someone with more experience.
• If you have prioritised and planned the bug then you should also have time to work out who is the best man to do the job. This would be based on the other work that needed doing, the availability of developers and your general judgment.

With regards to handovers these should be fairly minimal. At the end of the day your developers should be writing code in a way which makes it clear, clean and obvious to any developer that has a task to revisit it. It is part of my job to make sure the developers on the team are doing this basically.

I hope that this helps :)

Maintenance

Answer 9

Part of this falls onto the Product Owner to prioritize if some bugs are more important than some cards to my mind. If the PO is, "Fix these bugs NOW," then there should be bug fixes moved up to the top of the list. If there are numerous high priority bugs then it may be worth having a stabilization sprint where bugs are fixed and no new functionality gets done. I'd be tempted to ask the PO how much time they want spent on bugs though I'm not sure how practical that is.

The idea of having maintenance developers is nice but have you considered where there may be some pain in having to merge code changes from what maintenance does and what those developing new functionality do? Yeah, this is merely stepping on toes but I have had some painful merges where a day was spent with 2 developers trying to promote code due to so many changes between a test and dev environment.

May I suggest the idea of another developer fixing the bug so that someone else picks up how something was coded? Having multiple people work on some feature can help promote collective ownership rather than individual ownership of the code. Another part is that sometimes someone else may have an easier time with a bug because they have fixed that kind of bug before though this can also lead to a dependency that should be checked regularly.

Disoperation

Answer 10

Why not capture a backlog item called "bug debt", and have the team estimate it each iteration. That item will be used to hold some developer's time to fix it (as in #1).

I'm also a little concerned about the bugs that appear in UAT. Would it be possible to have some of those testing folks on the teams to catch them earlier? This kind of thing is very common in projects where it's thrown over the fence from group to group. The only way I have seen that works is to integrate those other groups into the teams and rethink the testing strategies. Then, UAT does what you want it to do... capture usability issues and requirements. You're right they won't go away completely, but they will be minimized.

Footwear

Answer 11

I think people should fix their own code as well. Why waste all the time with handovers?

It might be worth doing UATs as and when each feature is complete; so the "testers" working along side the "developers" testing functionality as they go. The testers should be able to run through the UAT criteria.

If there are more issues within the UAT with the stake holders, then they are change requests or the acceptance criteria is probably ambiguous in the first place!

Sixgun

Answer 12

I've generally followed option 1. Often because resources go to other projects. If you do root cause analysis by discussing how bugs were created, there's a small side effect of public embarrassment. If you've instilled any sense of ownership on a project, your developers should be more than a bit embarrassed if their code is displaying a higher percentage of bugs than others or what is reasonable.

I typically find that in these cases, most developers are actually frustrated if their too busy to fix their old bugs. They don't like it when somebody else has to clean up their mistakes.

Instilling a sense of ownership and pride are critical. If you haven't done that, you are always counting on the threat of punishment to get them to do the right things.

Sikes

Answer 13

Always try to have the original developer fix their own bugs, IMHO. This part is easy. If you've got a few developers who behave unprofessionally and shirk their duty to produce high quality software, give them the boot. If the problem is cultural, read "Fearless Change" by Linda Rising and get to work in your SM role as change agent. I'm right there with you, so this isn't me just beating you over the head; I'm doing the same thing at my job :).

However, you've got bigger problems.

You're a Scrum Master allocating resources? Yikes. The Scrum guide calls the SM to

...[serve] the Development Team in several ways, including:

Coaching the Development Team in self-organization...

I understand we all don't have the ideal organization within which to practice Scrum; however, this should gnaw at you daily until it is improved. The Scrum gude puts it simply:

Development Teams are structured and empowered by the organization to organize and manage their own work.

**Second, stop saying resources. Just stop it. Resources are coal, wood, and natural gas. People are not resources.**

Third, this UAT is a big impediment to the Scrum team. If I'm understanding you correctly, the client has a giant, red button they can press and completely blow up "Done" work by saying, "You've got to fix this before it's finished." Any Scrum Teams subjected to this no longer have velocity, forecasts etc. These things all measure "Done" and potentially "Done" work; they depend on "Done" software that is potentially shippable. Heres how the Scrum guide describes the Product Increment:

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.

You can improve this UAT situation in several ways:

• Convert the client's UAT to a simple feedback loop i.e. feature requests come out of the UAT, not notifications of incomplete software.
• Get their UAT testers to work alongside the Developers during the Sprint and make sure the work is "Done."
• Do not take work into a Sprint unless a UAT person is available to validate the work is fit for purpose.

I realize none of these will seem "commercially" plausable, but you're the SM. If no one else in the whole organization is saying these things, you have always got to be willing to.

I realize this sounds like a kick in the pants, but you need to year it from someone. This is a bit like the old shoe / glass bottle scenario from (wow) 10 years ago now.

Please feel free to reach out to me if you want to explore this further. I'm a fellow Scrum Master, and would be happy to help you work through this tough scenario.

Jadda