Who should fix bugs in a Scrum/Agile environment?

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?

Answer 1

Hi,

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

Answer 2

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.

Answer 3

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!

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

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?

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.