I’m a software coordinator who leads a Scrum team that unfortunately is generating a lot of bugs which annoys management. My manager says that the problem is a lack of individual accountability and that I should be forcing devs to repair their own bugs.

What may be some possible effects of this policy?

  • 23
    Who will be responsible for bugs left by developers that have moved on? The time-bomb type...
    – Solar Mike
    Commented Feb 7, 2020 at 21:40
  • 27
    Most bugs should be found during the testing cycle within the sprint and then fixed by the developer without need for another cycle - is the problem that they're not doing testing, or that there's an unusual amount of bugs escaping? And if a dev doesn't repair their own bugs is it just on the rest of the scrum team to do so or are these being kicked downstream for someone else to fix?
    – mxyzplk
    Commented Feb 7, 2020 at 22:11
  • 8
    I'd like to hear of a few examples of bugs.
    – gnasher729
    Commented Feb 7, 2020 at 22:11
  • 66
    Who is fixing the bugs now?
    – Helena
    Commented Feb 7, 2020 at 23:18
  • 23
    I am waiting to hear what happens when a bug is caused by improper specification on the side of the management. Commented Feb 8, 2020 at 23:01

18 Answers 18


In my experience bugs are a consequence of (in no particular order):

  1. Poorly defined or constantly changing requirements.
  2. Too much work for the amount of time provided, which leads to rushing, which leads to mistakes, and insufficient time to test and fix defects before release.
  3. Lack of peer code reviews (may be related to point 2).
  4. Insufficient QA resourcing or lack of automated testing to efficiently and effectively test for regressions.
  5. Poor morale amongst the development/QA team (probably caused by the above points).

As per the Lean methodology, ~94% of defects are caused by poor processes. Only 6% are caused by individuals.

Before punishing staff for perceived failures, have you actually done some sort of root cause analysis, using the 5 why's methodology or similar? Have you discussed the quality issues with the dev and QA teams?

  • 2
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Lilienthal
    Commented Feb 8, 2020 at 20:54
  • 18
    I like this answer, focuses on creating processes and culture of the team. What OP's manager is proposing is blaming the developer for creating an issue that the entire team (including managers) created, and their solution is to beat the developer with a stick and tell them to "Do better!".
    – Matthew
    Commented Feb 9, 2020 at 14:11
  • Points 1-2 could be seen as an individual developer's fault if the point is to make developers spend more time getting good requirements. Commented Feb 10, 2020 at 12:02
  • @user253751 The point is to reduce the ability for individuals to make errors which aren't discovered until the customer finds them. All parts of the project should have multiple eyes examining them in different ways - the Swiss cheese model of risk management. Individuals will still make mistakes, but the process is designed to find them as quickly as possible. Commented Feb 10, 2020 at 12:22

The biggest drawback is that one has a very hard time seeing one's own errors.

I remember way back in the ancient days of COBOL, a fellow student couldn't understand why his code wasn't working. In COBOL, there is NEXT SENTENCE. He put "NEXT STATEMENT" instead.

He was looking at it for fifteen minutes and couldn't figure it out, until I pointed out the obvious error.

When we write our code, we are often blind to our own mistakes, and will often see what we intended over what we did.

It's an immense waste of time.

  • 22
    I agree with this. Sometimes a fresh set of eyes can spot an error that has been eluding you a mile away.
    – JustSaying
    Commented Feb 7, 2020 at 21:28
  • 17
    At the other end of the spectrum, a bug may be due to some deep misunderstanding, and only fixable by someone with better knowledge of the application/language/framework Commented Feb 8, 2020 at 3:06
  • 7
    At the same time it can be obvious which case they missed to someone already knowing the problem space while someone else would need to get up to speed first. So this argument of wasted time can go either way. I typically consider bugs black surprise boxes that hopefully don't explode before you can find the red and blue wire - nor after you cut one.^^ Commented Feb 8, 2020 at 18:40
  • sometimes the best way to solve it is to go take a walk and stop thinking on it for a bit. Avoids having to interrupt someone else just for them to spot a misplaced semicolon (not to be confused with peer reviews).
    – Z4-tier
    Commented Feb 9, 2020 at 23:59
  • 1
    @user253751 yeah, that will happen ** eyeroll ** Commented Feb 10, 2020 at 12:05

What would be the downsides of having a “you break it, you fix it” policy in the dev team with the goal of reducing bugs?

The downside is that you may spend a lot of time trying to chase down who introduced the bug, which in turn could lead to a "blame culture". There is a tactical way to address this situation right now and there is a longer term strategy at play.

The longer term strategy should be to reduce bugs period. Is your review process not rigorous enough? Is there not enough automated tests to cover the test scenarios? Etc. Put a plan together, execute and track your progress.

The short tactical way to address the current defects is to funnel them back into the team equally distributed across team members. Squash the mentality, if you see it, of being "above" fixing defects and only wanting to generate net new code. Addressing defects is a part of every software engineers' responsibility.


Let's back up a second.

I’m a software coordinator who leads a Scrum team

What's that? Because I can read the Scrum Guide to learn what a Scrum team is, and it tells me:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.


Development Teams have the following characteristics:

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality

I'm not seeing anything in there about software coordinators creating rules about who fixes bugs; that's not part of Scrum. Scrum says the team organizes itself and chooses the best way to accomplish their work. How does the Scrum team address problems like these? Scroll down, and the guide tells me: the Sprint Retrospective

During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of "Done", if appropriate and not in conflict with product or organizational standards.

In other words, improving quality is a team responsibility, and the team has regular sessions to plan how they'll try to do it.

Scrum is a process rather than an ironclad set of rules, and it makes sense to deviate from it based on the needs of the business and team. If you have a reason to follow a process that's different from Scrum, go for it, but at least identify the reason first. The scenario you've laid out here is directly addressed by the default Scrum process in the foundational text explaining the methodology, and you haven't explained why the team hasn't been trying it or why it hasn't worked.

So the question shouldn't be "what are the possible downsides of me imposing this rule on the team?" The question shouldn't be about imposing a rule at all. You have a quality problem, and you should have a self-organizing team that meets regularly to reflect on and improve their methodology: problem meet iterative problem-solving process. Assuming the team cares about the quality of their work—and if they don't, you have an entirely different type of problem—why not follow the Scrum process to address it?

I have no idea how to address this problem, but I suspect nobody should know better than the team themselves. If they think a "you break it, you fix it" policy will help, they can discuss that during a retrospective and agree to try it out for themselves. But there are probably any number of other things they'll want to explore and try as part of the retrospective process. They might:

  • Spend some time examining and classifying the types of bugs they fix to understand patterns behind how they happen. This might include understanding why the bugs "annoy" management: what business impact do the bugs have?
  • Change the definition of "bug," if management is reacting to reported bug counts rather than the actual quality of the software as used by end users (a QA team can be sufficiently motivated to produce a large volume of bug reports, but that's not always inherently connected to quality)
  • Re-examine the definition of "done" (if "done" includes "has passed QA," the person working on an item will naturally be the one to fix bugs found during QA, because they're not done with the item yet)
  • Improve automated testing practices or create a new test suite. Implement or improve a CI system
  • Change their development practices around things like code review, pair programming, and code style
  • Change policies around deployments, the use of staging and test environments, feature flags, and related mechanisms related to when buggy code is shipped
  • Educate themselves about ways to improve quality; read articles and books about relevant best practices and testing techniques
  • Add instrumentation, logging, exception handling, or perhaps adopt or build new tools, whatever is appropriate to make it easier to identify and diagnose bugs
  • Identify bug-prone areas of the code for refactoring
  • Need more QA resources or need the existing resources to try new things
  • Realize the bugs are actually misunderstandings about the product requirements or specifications and that better coordination is needed with the Product Owner
  • Identify potential management problems, such as the work environment, pressure for quantity over quality, a poorly-performing team member, etc...

Or dozens of other possibilities. I certainly don't know which ones are right for the team, but I do know that Scrum says the team is the right unit to examine the problem for themselves, choose some improvements to try for the next sprint, re-examine how it's going in their retrospective, and then do it all over again.

However, keep in mind that many efforts to improve quality will impact the pace of the work, especially when initiatives are new. The team may even decide they need to pause development entirely for a period to do something like improve automated testing coverage. That's where the last bit of the section on retrospectives comes in: the team changes its processes "if appropriate and not in conflict with product or organizational standards." Ultimately, management sets these standards. The team could almost surely improve quality dramatically by adopting the practices used to develop safety-critical software, but if your business is, say, running an e-commerce site and not developing an avionics suite, that decision will inevitably conflict with the organizational standard that changes need to happen more quickly. So it's going to be up to management to adjust its expectations in light of this new focus on quality. Remember that you can't beat the iron triangle: improved quality isn't free. If quality is suffering because the team is being pressured to do too much work too quickly, management's standards will have to change if they want higher quality.

  • 18
    I feel the very important "take on less work despite outside pressure so high quality features can be delivered" is missing from your list. It's sadly a very common cause for bugs.
    – Erik
    Commented Feb 8, 2020 at 8:32
  • 5
    @Erik Good point. I hinted at that in the last bullet with "pressure for quantity over quality," but it deserved a section of its own. Commented Feb 8, 2020 at 9:12
  • 6
    100% this... you're not doing Scrum and whatever abomination you are doing is probably what's screwing your team's output.
    – Dancrumb
    Commented Feb 8, 2020 at 17:16
  • 12
    Nothing says anybody has to use Scrum, but if you say you're doing Scrum and then describe a process that's clearly not Scrum, that's usually a red flag. Commented Feb 9, 2020 at 6:07
  • 1
    @Dancrumb this (and in a lesser way the answer itself) sounds very judgemental. Many practitioners of scrum will tell you, that trying to implement it is like trying to create a "spherical horse in vacuum". There are always business reasons people amend scrum process to fit their needs. This often is ill-advised, but calling it "abomination" is rude and uncalled for. A person came for help, and all you,Dancrumb, telling them "it's all your own fault" and using words "abomination" and "screwing" is not constructive and not helping. Commented Feb 9, 2020 at 19:34

Assigning blame in this manner is very likely to cause loss of morale and the emergence of extremely dysfunctional behaviours such as:

  • developers refusing to work on code written by others
  • developers refusing to work on old code
  • developers refusing to work on high-risk code or features
  • inflated estimates;
  • reduced cooperation;
  • ....

The rise of a blame culture will almost inevitably convince your best developers to find a new job.

Said that, I would question the assumption that the root cause of these bugs is lack of professionalism, because this is very rarely the case. In my opinion investing in your development process (CI/CD, QA, reviews, etc...) would be a better strategy than blaming individuals.

  • 5
    even if it is the devs fault, that is often a result of a lack of knowledge/training in how to reduce the annoyance of doing manual testing or to write easily auto-testable code. Even when it's a character "fault", there are typically ways to help motivate or mitigate the problem within the team (e.g. automatic test pipelines, code reviews, have a lead that suggest good structures, have a dedicated QA person etc.). Blaming rarely helps, identifying the problem source might however help. Commented Feb 8, 2020 at 17:32

Your manager is misguided and taking you along on a misguided journey.

You break it-you fix it mentality places weight on assigning blame and dishing out punishment. What you’ll get will be “It’s not my code, it’s your darn requirements.”, or “You gave my method garbage data, garbage in-garbage out” or “The database is slow, my code is just fine”... you get the idea. Even if you get the “offender”, how do you ensure that he actually fixed the bug and not created more?

You will want to look into mature software development best practices for answers. Examples would be:

  • Agile
  • Automated tests
  • Daily standups
  • CI/CD

There’s more but the list above should get you started on a path to improving your software quality.

  • "Agile" shouldn't be an issue, considering that it's ostensibly a SCRUM team. On the other hand, they've got a "software coordinator", which (as Zach Lipton points out) is not a role in SCRUM.
    – MSalters
    Commented Feb 10, 2020 at 7:53

This isn't an issue of individual accountability lacking. This is an issue of the logistics framework allowing a large amount of bugs to leave your area. Or in short: What's Your Test Plan?

I've been dev-ringleader over three projects the last few years. The first had unit tests and a small number of integration tests built in to it. I could make a few clicks and verify everything was working within the code while making additions/changes. Because of this, very few bugs ever saw the light of day. The third had unit/integration testing built into the deployment process itself, and while we're not quite to the client testing phase, I'm pretty confident that there's not going to be a lot of bug appearances.

But the second? No unit tests. No integration tests. Just some manual testing of 'whatever we changed'. Care to guess how many bugs we were running into? I had to assign one of them off their regular tasks to develop an integration test suite retroactively in order to clamp down on relatively bad quality code we were putting out.

The mean answer is... this is your fault. You're the Software Coordinator, yet you're allowing your squad of devs to work in an environment with insufficient bug-catching. Where's the focus on unit tests? Integration tests? User Acceptance Testing? Etc.


Another big drawback I see is about code ownership.

In a scrum team, it's important that the entire team feels responsible for the entire product. This policy also means that if developer A caused a bug, developer B won't fix it, thus making sure he won't feel responsible for that code. This is likely to lead to an increased bus factor and friction within the team.

Instead, the entire code base should be the responsibility of the entire team. Therefore, if there are too many bugs, any solution should be implemented at the level of the team. Of course, if a limited number of team members does a poor job writing unit tests (for example) then that will need to be addressed. However, that's a discussion internal to the team. To the outside word, there should be a team, not a collection of developers (unless we're talking about a performance review, of course).


If a dev deploys something and it comes back in the same week, then the original dev is best placed to fix it. - I have found this works well.

However, if it has been more than a few months you can't really do this. The original dev will be focusing on another project, and breaking that focus isn't good. I worked for a company that tried 'you broke it, you fix it' and it led to a very toxic work environment with a terrible blame culture. It didn't reduce bugs, it just reduced productivity.

Those that avoid accountability now, will just find another way to do it. Literally had devs swear blind they had never worked on a project despite the repository history.

You need to find out why they aren't taking responsibility, and why work is coming back with bugs?

  • Are they happy with salary
  • Are timescales realistic
  • Is workload too high
  • Are processes clear
  • Do you have a QA department
  • Are you rewarding them for hard work

Find a way to give them ownership of their projects. I found that teams work well, having each job require at least 2 devs. They plan and work on the job together, becoming accountable to each other. If bugs happen it goes back to that team and they work on it together. Once they take ownership they wont want their software to have bugs in it.

I also found that devs took more ownership when we removed time logging, made budgets hidden and just gave them a deadline.


Your problem is that your developers produce code that is later found to be buggy, and that to a degree that your manager feels is too much.

There's always a possibility that you have a team manager who is just incompetent - in that case, that team member should not be the one fixing the bugs. That team member should be removed. But say that is excluded as a reason.

Here's what I've found what happens with agile development done wrong: You have tasks, you assign points, someone "performs" the task - but only to the point where they can say the task has been performed, not to the point where it is solid, maintainable, handling border cases and errors, and is bug free. You may be underestimating how many points should be assigned to a task, because you don't include the time needed to handle the task in a bug-free way.

That way you get developers who look highly efficient and produce buggy code. Worst case you have one or two developers who produce quality with no bugs, but take more time to perform a task, and are considered slow or lazy. When in reality they produce more useful work per hour worked.

So what you need to do is leave enough time to do the job properly in the first place. Because doing it properly in the first time is a lot, lot cheaper then doing a half-arsed job, and waiting for either QA or customers to find the bug, report it back, fix it, then QA has to review it again. Lots of time wasted.

(I have also seen software misbehaving for reasons that the developer absolutely couldn't know. In that case, the most experienced developer should fix it.)


The biggest issue I can see is that you probably won't reduce the bug count by any significance, but you will increase the pressure and stress on individual developers.

What you need to look at is why and how these bugs are occurring and getting through to production.

First up, communication. Do your developers talk to each other as they work on tasks? Do you talk about architecture and solutions in your scrum/sprint planning? Or does your team just agree to a bunch of stories at the start of the sprint and then work separately with just the morning standups?

Try to encourage pair programming - this will help with information flow, and should have a direct impact on big count. It doesn't need to be a full time thing - but you should try for at least 25-50% of the time. It might seem counterintuitive (two devs on one task!) but it can speed up development time with the information flow, and reduce bugs.

And document - make sure work is properly scoped in a way that covers potential side effects and impact. Also try to score stories and tasks such that they are as small as possible. Small changes have less side effects, and are easier to review (more on that later).

Next up is process. Automated testing and continuous integration is a must in modern software development, and has a pretty low bar for implementing these days.

Have your developers run a linter before they push code to catch silly mistakes like missing semi-colons. Get a static analysis tool to help identify issues with loops and conditionals and so on.

Agree to a coding style - having a standard style helps decrease bugs by ensuring things like all if blocks should be braced even if they're just a one liner (making it is harder to accidentally add a line of code that should also be in that conditional - a famous Apple bug), or switch statements must have a default. Have a tool that tests that style and automate it.

Implement automated testing. Try and do as small a unit as you can in these tests, but don't slavishly aim for 100% coverage. Sometimes a feature test is better than heavily mocking an MVC framework, for example. Testable code is also usually better structured and easier to change safely. Use tools that let your developers quickly and easily test what they're working on, without needing to run the full suite all the time.

Automate all your testing so that changes are tested by your developers before they push, and also on your repo after they push. Github, Bitbucket, and Gitlab all have CI pipelines to help with this.

Make sure your developers are rebasing their branches from master regularly (or at least before opening a pull/merge request) so that they can test their code against the latest master.

Have code reviews. Again, tested, documented, and tightly scoped work will make this easy. Larger changes should be reviewed as a pair between the reviewer and the original developer. I've heard of places that have a six-eyeballs rule - so, it a feature is developed as a pair, then a third person must review it. If a feature is solo developed, then it must be reviewed by two people.

A lot of this may seem like it would slow development down, but having good processes in place will reduce bugs, and will speed up development.

If the odd bug or two still gets through, look at what may have broken down in your process and try to change it. If it turns out that a particular developer is bucking the process, then hold them individually accountable. But until that point, bugs are the whole team's problem.

  • I'll tell your manager that the problem is having procedures that encourage committing code that isn't (yet) ready for committing.
    – gnasher729
    Commented Feb 9, 2020 at 20:03
  • @gnasher729 which particular procedure encourages that? And the goal is to reduce the number of bugs making it to QA/Production, anyway. Sure, I'd prefer it if a developer never committed a bug to their feature branch, but I'd also like my developers to not be afraid of making a mistake, too.
    – HorusKol
    Commented Feb 10, 2020 at 1:51

Assume you add a feature and rely on an existing function in the code, that was working quite fine until now.

Your code breaks, but it breaks because the function does not do what it should do. It worked for the existing code, but it does not handle edge cases, that are needed for your code.
Someone else wrote a unit test for it that does not test the edge case either.

Who is to blame?

  • You added a feature that broke the code base
  • Someone added a unit test that does not correctly check if the function does what the description says it should do
  • Someone else wrote the actual function that is not handling all cases
  • Maybe even yet another person wrote the documentation, that claims the function should be able to handle the edge cases that do not work as they should

Do you really want all these people to argue who is to blame?

And you may now be in the right place to rewrite this function. Why should you wait for some other person to fix this? You may even need to iterate this, as the fix may not fix everything and you need to ask them again to fix the remaining problems.


Stages of the software development life cyle as defined by the Agile Model:

  1. Analysis
  2. Design
  3. Implementation
  4. Testing
  5. Deployment
  6. Maintenance

Your problem appears to lie between stage 3 and 6. To reduce bugs in production you have to ensure the following:

  1. Each developer writes unit tests for each class (code) they create / change (see Test Driven Development approach)
  2. Each pull request is tech reviewed by a different developer within the team.
  3. The developer gives the tester on the team a demo of the working code before the piece of work is passed onto the testing stage.
  4. Ensure you have a dedicated tester to test the new code before it gets merged into master / production. This would involve (Regression, Automated, Manual testing phases).
  5. Ensure you have multiple environments (Test, Automated Test, pre-production environment) with each environment getting closer to production.

A "you break it, you fix it" approach won't solve anything as it addresses the effect rather than the cause. Moreover a blame approach would just lower the morale of the team and jeopardize the project. The problem is always lack of a clearly structured and defined processes.


The main drawback would be developers actively trying to hide bugs (theirs and their colleagues'). The end result would be more obscure bugs, very well hidden.

This looks like a scenario straight out of the original freakonomics book. Go read it :-).

This wouldn't happen intentionally. It simply would happen that developers who code in a way where their bugs are harder to find get more time to code. Whereas good developers whose testing is readily available would be constantly stopped. Coding obscure bugs unintentionally ends up being incentivized.

  • 1
    That doesn't sound like "bugs"( unintended mistakes), it sounds more like intentional sabotage. Management wouldn't be complaining about bugs unless customers were finding them. Commented Feb 7, 2020 at 21:21
  • That depends. With good tests and a good QA process, developers who introduce hard-to-find bugs would have to spend more time finding and fixing them.
    – Igor G
    Commented Feb 7, 2020 at 22:07
  • 1
    "Scrum team that unfortunately is generating a lot of bugs which annoys management." Clearly, they don't have good tests and a good QA. Otherwise, there'd be no annoyance.
    – Jeffrey
    Commented Feb 7, 2020 at 22:12

The answer of @jeffrey is good, but I disagree in one thing: this is not the worst what can happen.

The worst thing what can happen is that developers will tip-toe around difficult code parts even more than before. They will artificially introduce boundaries just to protect them from the start from responsibility. The result will be that function complexity will be reduced beyond the reasonable point and it will result in separate functions and switch orgies which exactly cover the user stories (and yes, there are thing which are inherently bug prone). And nobody will do any non-trivial code cleanup or refactoring.

Bug are results of processes and team structures. No simple rule (an thisone would even be counterproductive) can change that.


If someone drives your car into a ditch, are they really the right person to trust to get it out?

Lets suppose for a minute that management is right, and for some reason the developers on this one team are much more apt to create bugs when they change code than the rest of the company's developers. Its not the nature of the tasks they work on (the most likely cause usually), its not some failing in management or requirements (the next most likely cause), its them.

Are those really the people you want fixing all the bugs? Eventually (in theory) you'd end up with your entire company's codebase dominated by code written by its most bug-prone developers. Sloppy code is orders of magnitude more difficult to maintain.

Perhaps instead it would be better to call in your better developers fix the problems, sort of like a technical commando squad. Then (and this part is very important), they write up what went wrong and instruct the weaker developers how to avoid this issue in the future. They need to learn better, or there's no way they can improve.


One thing I have not seen mentioned here is that this strategy calcifies the code. Presumably the code of the different developers must interact. Say that one developer introduces a bug that is best fixed by refactoring another person's code.

What happens then? The other developer will oppose changing his code as then the bug becomes his problem. Over time, your codebase architecture becomes decided by age/precedence not engineering.

  • 1
    It's also entirely possible that one person's code is relying upon a library to work as documented, and that the library works as documented in all cases that were relevant before, but doesn't work in a case where it really should, and which the new code relies upon. The person best qualified to fix the problem should be the author of the library, even if the problems with the library were only revealed as a consequence of changes to the client code.
    – supercat
    Commented Feb 8, 2020 at 19:16
  • @supercat simplest solution for the original programmer is to edit the documentation. That technically fixes his bug... Commented Feb 8, 2020 at 19:18
  • That would depend upon whether a function that performs only in cases where the original works would "make sense". If one has a function, for example, which will work if the number of items in a linked list is anything other than a multiple of 23 that isn't also a multiple of either 3 or 2, would it make more sense to document that restriction, or fix the code to handle those cases as well, if doing the latter wouldn't be difficult?
    – supercat
    Commented Feb 8, 2020 at 20:07

One point not made elsewhere is that non-trivial bugs are not simply attributable to one simple programming mistake. Typical example: you invoke a method (in "someone else's code", if you have such a concept) passing a zero-length array, and the code breaks because it wasn't expecting a zero-length array. Whose bug is it? Don't even waste time arguing about it, it's completely unproductive. Just decide between you whether to change the called code so it handles this input, or to change the calling code so it doesn't supply this input, and then decide who's going to make the change. Never even think of discussing whose fault it is.

You must log in to answer this question.

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