How to objectively measure colleague cooperation

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

"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.

Answer 5

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.

Answer 6

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.

Answer 7

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.