I work in quality assurance of a medium-sized software development enterprise and my team's success is mainly based on the cooperation of any colleague, both inside and outside of our team.
Many coworkers are very cooperative, but often enough it is the case that colleagues

  • ignore our indication of failed and personally assigned test results,
  • ignore our enquiries about bugs in their projects or modules of their responsibility or
  • firstly respond "I will look into it." and than never report back

We're at a point where this lack of cooperation is the main show stopper in development. Management has already heard our complaints and would like to be included in resolving cooperative issues in the future.

However I don't want to report any minor thing and subtract (my) subjective assessments.
Also I want to keep a single incident rating short and with low effort.
EDIT: We do have a full-fledged issue tracking system (redmine), but try not to deaden it by creating a ticket for everything (e.g. a failing formal code style test). In enough cases we'd be putting more effort into tracking work via tickets than actually being productive. It's a hard to find balance in order to keep a high acceptance of the bug tracker.

My question is:
How can we - as a team - objectively measure (lack of) cooperation

  • as a team: any QA member (we're ~5) can contribute to any colleague's assessment
  • objectively measure: ratings are based on (collected) traceable incidents
  • (lack of) cooperation: it should be possible to both add positive and negative examples of cooperation

In terms of data privacy I want to keep all information about colleagues inhouse and won't use any tool transmitting data into the WWW.

I'd like to instantiate a system,

  • where I and my team members can dump single incidents
    (e.g. as Who | When | What | nice/problem?)
  • which can both handle cooperation as the lack thereof
  • which will merge incidents in the past time (let's say 6 months) per colleague
  • 13
    Create a ticketing system for bugs. When the bug is fixed resolve the ticket. Give managers access to this so they can follow up on long standing bugs.
    – Snowlockk
    Commented Mar 27, 2017 at 10:10
  • 14
    "When a measure becomes a target, it ceases to be a good measure." - Goodhart's law. Be very careful of measuring something like cooperation.
    – Jeutnarg
    Commented Mar 27, 2017 at 15:22
  • 5
    So you identify bugs, you report them to developers, developers ignore you. You have a formal bug tracking system, but you're not using it. Your question is, how can you track your bug reports so you can hold developers to account and identify which developers are not resolving your bug requests? What am I missing? What does it mean to 'deaden' your bug tracking system by using it to track bugs? Commented Mar 27, 2017 at 18:24
  • @TessellatingHeckler we do use the bug tracker, but rather for issues of assumed higher effort. If I spend more time tracking my work than doing it, my motivation can go down the drain.
    – hardmooth
    Commented Mar 27, 2017 at 19:58
  • 8
    When I used a bug tracker, I put every little damn thing in it. That's what it's for. Then you prioritize within that. Then it becomes a searchable tool and a tool to hold people accountable. You're talking about tracking cooperation when you could be tracking the bugs, who's responsible, dates and times, progress etc. Seems like misplaced effort to me to put your effort into tracking cooperation when the same effort can be used to actually track the bugs and learn/understand what's happening with them. In particular how prioritization is causing some items to be delayed Commented Mar 28, 2017 at 1:46

7 Answers 7


It sounds like the problem is not "lack of cooperation" but lack of accountability.

You have mentioned a couple of scenarios where, seemingly, someone on another team has clear, unambiguous responsibility for an issue. They have not handled this issue, and yet they haven't been held accountable for that. Their failure to complete a task was not highlighted, and presumably (from the fact that you're posting a question here), the blame is coming to your team.

I think the problem is probably something more fundamental with your development process, rather than a few "unhelpful" individuals. In the ideal world, you don't want a system based on people helpfully doing other teams' work. You want a way to clearly assign work to the right person and then make sure that actually happens.

Cooperation may not actually a good metric to target. When a process is broken, "helpful" people end up being the key, because they pitch in, regardless of whether it's their job. This ensures that stuff gets done, despite the problems. But helpfulness is actually a double edged sword. The most "cooperative" people can end up helping others so much that they don't get their own important tasks done. And they can also serve as sponges soaking up the work of lazy or incompetent employees. If you target cooperation, some undesirable behavior is being counted as a good thing.

It's hard to say more about the specific issues at your company without more detail about your development process. But one thing that comes to mind is that proper project/issue tracking software, properly used, ought to simply highlight these problems as a consequence of using it.

In such software, a failed test or a bug in some part of the project would lead to an issue being created with an individual's or team's name on it. This issue could subsequently be tracked, and you could use this as evidence of the problem ("As you can see, we reported this bug to the frobulator team a month ago, but they haven't even gotten back to us with a response yet...").

Software isn't the whole solution. When used properly, it gives you the evidence of what has (or hasn't) taken place. You still need people to then act on that evidence in an appropriate manner.

Update: since you mentioned that you already have a bug tracker, a good place to focus your effort would probably be to have this used more consistently.

  • we already do have a bug tracker in use. I tend to think, we should use it for more stuff.
    – hardmooth
    Commented Mar 27, 2017 at 10:48
  • 20
    @hardmooth You should be using the ticketing system for everything that isn't right. Every system I've used has had a priority for each ticket. Without that, you have a totally ad-hoc system of emails, which isn't trackable.
    – Simon B
    Commented Mar 27, 2017 at 13:13
  • +1 if All bugs are logged, then this problem ges away. Log everything, that's why there's a "priority" field, for items not as important as others.
    – mxyzplk
    Commented Mar 27, 2017 at 14:30
  • 2
    also, by simply assigning a ticket to whoever you need action from, you can create accountability by highlighting how long people take to handle things in general, and specific tickets in particular
    – njzk2
    Commented Mar 27, 2017 at 16:53
  • Accepted as best answer: Creating (+assigning) tickets for everything we need to track and using the ticket system more consistently (and holding coworkers accountable) seems to be the most objective and pragmatic way to assure processing of reported bugs, indications from test systems as well as specific enquiries. The need to track for test indications and enquiries will be deduced from not satisfactorily answering for a defined time (ask, whait->reminder, track). A measure of sufficient cooperation can be implied from the ticketing system, but won't be a priority (as suggested).
    – hardmooth
    Commented Mar 31, 2017 at 6:10

We do have a full-fledged issue tracking system (redmine), but try not to deaden it by creating a ticket for everything (e.g. a failing formal code style test).

That's your mistake.

You don't "deaden" an issue tracking system by using it. Issue reports only make it more valuable.

Your source of some "objective" measures is in there. But it will only work if you use it.

How to objectively measure colleague cooperation

I don't understand what you expect to gain by such a measure. I doubt that there is truly an "objective" way to measure something as vague as "cooperation".

You might start by writing a formal definition of the term "cooperation", then listing as many cases as you can that indicate positive and negative cases. Perhaps you'll have a breakthrough one way or the other.

I suspect you'll find that cooperation is a subjective term. What one individual would mark as non-cooperative, another would not. And if that's the case and you really want to make this a subjective measure, then a "diary of incidents" will suffice.

  • 1
    I'd say that cooperative may or may not be subjective, but more that being cooperative may or may not be a good thing. Cooperating to fix bugs from two people's work is good. Cooperating when Lazy McNoWork asks you to write his part of the project may not be.
    – Delioth
    Commented Mar 27, 2017 at 19:12

Some metrics you can assess objectively are

  • time until first response (how long it takes to get a "I will look into it")
  • time until definitive answer (how long it takes to get an actually useful answer)

What you can not measure objectively is the actual helpfulness of a response which goes beyond "I will look into it". For example, a reply which only answers half of your questions and dodges the rest. You might not consider this a "definitive answer", but the sender might do so and see no reason to write any more unless you ask for it. What you can do in this situation is ask a followup question and track the response to the follow-up in the same way.

You should only measure time in actual business hours. Example: Your official business hours are Monday to Friday from 9am to 7pm. You send a request on Friday 6pm and get a response on Monday 10am. That's a 2 hour response time.

Many larger companies try to track all inquiries in task management software to measure such numbers automatically. If you want something from someone, you create a ticket in the software. When they respond, they do so through the same system. This allows the management to get a statistic about who responds how fast. Also, uncompleted tasks tend to look very uncomfortable in such systems. There are various products for this on the market.

However, it's not very wise to rely too much on the numbers generated from such tools. If you do, you end up doing management by numbers. Putting too much trust in numbers and not enough trust in people is a dangerous management anti-pattern.

  • 1
    The other thing these objective measures would not measure is how long it should take to solve the issue. A complex problem is going to take far more time and the person may actually be more helpful than the numbers would suggest. Objective measurement systems, in my experience, always reward the mediocre over the good or great because their work is more complex and harder to measure. Agree with @Philipp that management by numbers is a dangerous mangement anti-pattern.
    – HLGEM
    Commented Mar 27, 2017 at 13:33
"We'd be putting more effort into tracking work via tickets than actually being productive" 

This doesn't apply for your case. Being productive doesn't mean "non-stop coding for 8 hours", it means to complete the tasks, by the order of their priorities. If a developer spends 2 hours for a bug, he have to make it a case and report it.

Ask the team to prepare a daily progress report might save you some time, however your problem is more serious: Say "I will be looking to it" and not look it is not a lack of cooperation, it's irresponsibility.

Your answer for all your question is the "bug tracking system". We don't have time is not applicable, because this minimum documentation is part of the job, just like coding.


My interpretation of your post is you have a few problems:

  • How to monitor cooperation?
  • How to make individuals accountable?
  • How to promote cooperation?

But first let’s tackle why someone might respond

I’ll take a look at it

but they never really do. Whilst impossible to know the exact reasons for this in every scenario, I would like to give insight from a developer’s perspective why I could see this happening for the most concerning reasons. YMMV but to me bug fixing is a career killing task. It is unappreciated maintenance work. It’s also really unenjoyable work: trolling through logs and stack traces only to find the simplest mistakes. Why would developers want to spend time doing an unappreciated irritating task with no career benefit? Sure a developer will do this for some acceptable level, but if this level is set too high that this work consumes their work life, this sort of thing can happen. The other concerning reason a developer may do this is to avoid conflict. This occurs if there is not an open culture in the workplace and a no blame culture, with management making unilateral decisions. I’ve found this is prevalent in legacy projects. There may be fundamental design issues with a project, and it may be infeasible to redo the code. In this situation, if management do not level out with developers, and establish acceptable commitments for both parties in relation to bug fixing, you will have this situation. I strongly recommend you reflect on whether or not this is the situation at your work. I worked at a company (funnily enough also used redmine), and if management had suggested I was being uncooperative after fixing countless bugs, I would have left sooner than I did. I warn you mention that word at your peril at best it will only create a wedge between you and your team, at worst a mass exodus.

Monitoring Cooperation – Even if there was software that could do this effectively it is definitely not redmine. IMHO this methodology is flawed. Whatever solution you come up with will bias developers to gravitate to loop holes, you’ll spend forever reviewing this and be back on here a year later with nothing being solved. You can assign issues to someone in redmine and judge for each issue if they've been cooperative, but I'm certain you will create more overhead and problems than it solved.

Holding Individuals Accountable – Personally I believe group accountability is vastly more important, success is because of good management and teamwork, not individuals. It should be absolutely obvious if somebody isn’t pulling their weight. This is evident in peer review code, group planning sessions, meetings, retrospectives in agile or other methodologies and much more. There should be group contracts established by the group, and the group as a whole should be pulling up others on their performance. If you alone decide how this works then you will be the one that polices it, becoming more of an authority than a leader.

Promote Cooperation – Levelling with developers, figuring out what bug fixing work is acceptable from a business view point and developer experience whilst promoting an open no blame culture is key. How about team building activities (they love this in Germany, almost every company has a day were they go out and do problem solving/adventure or other team building activities together). But if you make unilateral decisions and then expect everybody to follow them to a T or else you put an uncooperative label on them, you will just end up with either yes-men or conflict avoiders.

Final note, you catch more flies with honey. To me it sounds like you have a cultural issue than a problem with individuals. Sorry for long post I am passionate about this issue having changed jobs because of this sort of thing. (could of been this company). I really hope for your company you find a solution.

  • @dan1111 I did no claim to have a universal experience, no such thing exists. I am only trying to give a perspective and shed light on why developers don't want to fix bugs. I know there is other software for bug monitoring out there but as I said, I believe that approach leads to the blame game, and is a determinant to a no blame culture. Whilst 'possible' I am not aware of any company which is renowned for how they treat their developers fixing bugs. Like the OP they get upset if they don't fix bugs, but they aren't over the moon if you fix a bug. Commented Mar 28, 2017 at 10:38
  • Please name one. Commented Mar 28, 2017 at 12:21
  • 1
    Here, where I work, for example. This is a massive legacy project and all we do is fix or extend it. We are one of the biggest earners in the division. Some days we hate bug fixing. But it's also very rewarding, and a steady job.
    – RedSonja
    Commented Mar 28, 2017 at 12:24
  • Sorry you still don't give a name. And you suggest that bug fixing is a good career path in some cases. We are on different worlds my friend, do you live on Earth? Commented Mar 28, 2017 at 12:31
  • 1
    Thanks for the edits, I do agree that this is a quite common problem.
    – user45590
    Commented Mar 29, 2017 at 5:20

Management's goal is probably getting software released that generates sales and customer satisfaction. There are parts of this process that are entirely controlled by your group. All of you should be evaluated and hopefully rewarded for getting them done.

You've identified processes that involve your group and others. All parties involved in that piece should be evaluated and hopefully rewarded for the completion of that process. There should be no incentive for either side to do anything or fail to do what is necessary for getting this part done without there being consequences. As professional adults, I think a manager needs to put it on all parties to come up with mutually agreeable strategies.

Either some of the parties are not making the connection to the level of input required from them to get things done or they don't have the resources. Who knows, a quick meeting may discover that there is just one little thing your group could do to make this much easier for others to comply. You'll never know until you get the people together who know what's going on and management to make getting this done important. Things rarely get fixed any other way.


One way not to measure "co-operation" but to make it visible is the Kanban board (or equivalent) and the daily stand-up show-and-tell.

"This is what I did yesterday, this is what I want to do today, this is what I need, this is what's stopping me."

Here we also set priorities. the Kanban tickets are held on the board by coloured magnets, and if you have priority you get a different colour (green), and the green ones get talked about first.

If someone is dragging his feet it is obvious. Anyway, there's usually a good reason, and here that person can say what the problem is and get help.


You must log in to answer this question.

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