1

I am a team lead, in a small software development. In my team, there are 5 team members. In our company test engineers and software developers interaction is very much allowed for a faster communication. There is a testing team parallel to our team for testing. No issues till this.

This is the stage of development. Next stage is bug fixing. In this stage...

A particular member ( call B ) from the testing team, is always giving biased report for a particular developer (call A). Or he will do some highlighting of the A. B is doing direct interaction, if any bug is there. Silently A is fixing that.

Due to this the A is becoming star developer. But actually, it is not so. At the same time, A is not so dull. A is having same skill set as fellow team members.

Suppose 10 bugs are found under the code written by A, only 5 bugs get posted. But the other 5 bugs are fixed by A silently. I am sure of this. I caught him multiple times. And A said that B has informed him about that bug, which is not posted officially. I warned him to take posted bugs only. But no use. They are continuing.

What I feel is like A is not creating any problem. He is just taking the advantage of situation. And B is an another team member. He is giving his report. May be they both are in syndicate.

I am worried about other team members. Though they are good, their work is not getting enough appreciation. For our manager it is looking like, they are not up-to the mark. And A is getting more bonus etc... , where as others are not getting much.

How to handle this situation officially. Condition is, I cannot change the process in company/system.

I have edited to make it more clear.

  • 1
    Get A and B around the table, and tell them what you think about it. – Gautier C Jun 16 '16 at 14:08
  • 1
    Does B have performance metrics based on how many issues he discovers and logs problems for? – JasonJ Jun 16 '16 at 15:00
  • 1
    as all others : the "problem" is that they've found a way to work better. Is that really a problem? – gazzz0x2z Jun 17 '16 at 9:55
8

What you describe so is not a problem. The problem is what you do not describe.

You describe interaction between tester and developer which gets the job done, is quick, efficient, and creates no paper overhead. This is a good thing.

Now, what you don't describe and yet what seems to be the problem is that you have a system in place which somehow links performance rewards (money/promotions/job security) to some artificial metrics, and that people are gaming this system.

How do you prevent people from gaming the system? It's simple: You don't, because you can't prevent people from gaming the system. As soon as you link metrics to rewards you tell people to focus on improving the metrics instead of creating value. And that's why you don't link metrics to rewards.

9

You seem to have metrics in place that they game.

However, a QA working with a DEV to fix bugs as fast and as effectively as possible is not a bad thing. You should care for a good, bug-free end result.

Sit down with them and explain them that their behavior is skewing your metrics. Then ask for improvements. Maybe they will agree to use your system. But maybe, your system is hindering them to work effectively towards your end goal. Remember, your end goal is not to track bugs during production of your product, your end goal is to have a minimal amount of bugs surviving.

So let them come up with a plan. With only 5 team members, you should be open for change. Who knows, maybe pair developing features with a fixed QA resource and short, non ticket-bound communication between them will do wonders for the productivity of your other 4 members, too?

  • If you think this is "not useful", feel free to leave a comment how I can improve it. – nvoigt Jun 16 '16 at 15:26
  • Not the down voter (actually upvoted) but I would guess the down vote is regarding Condition is, I cannot change the process in company/system. OP doesn't seem to be in a position to be open for change. – Myles Jun 16 '16 at 19:39
4

I am assuming as team lead you are involved in performance metrics for the team. If that's the case sit down with A, B, and Bs team lead to discuss the specific events you've seen (unreported bugs being fixed) and how they affect the organization (artificially skewed numbers). Get everyone to agree that this is a negative outcome for the organization. Once on the same page then come up with consequences if bugs being reported outside of official channels or A working on undocumented bugs is discovered again (PIP, effect on bonus, etc). If all come to an agreement on that take minutes and get everyone to sign them.

  • easy thinking, best thinking ;) – Gautier C Jun 16 '16 at 14:16
  • 3
    If these guys have noticed that it's in their interest to manipulate the data they won't admit to doing it, and will not want to follow the "correct" system. – AndreiROM Jun 16 '16 at 14:54
  • 2
    Yes, @AndreiROM is right. If you talk to them directly about it, you need to have proof that they are going around the system. Of course they will agree with you about what is best for the company, but don't expect them to follow it. – David K Jun 16 '16 at 15:27
  • @AndreiROM The have admitted it in the past "I caught him multiple times. And A said that B has informed him about that bug, which is not posted officially." Even if this is likely to prevent them from admitting it in the future, it creates a much higher cost for continuing. – Myles Jun 16 '16 at 16:03
  • What happens if they don't come to an agreement in a few minutes for the reasons the other answers have? - while skewed numbers may be bad for the organization, slow bug fixes due to a paper process are also bad (I am suggesting to improve the answer by accounting for this possibility) – user2813274 Jun 19 '16 at 14:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.