-1

I have a person in my team with average experience that always does the task exactly as requested as output but with low quality.

I noticed this more than one time on short periods -weeks- and every time I clarify to him the importance of quality and how this really saves us from future integration bugs.

To overcome this, I tried to hold meetings whenever we are starting new work and I am making sure that details/to-do are always documented so that it can be like a check list for him and the rest of the team.
And honestly, this helped a little. But the low quality still there.

whenever something new comes up he simply ignores fixing the issue. And it is only fixed when I found it while I review it or by luck!

I am still encouraging him to understand, but auditing the work and the very small details kills my time sometimes.

  • The statements "exactly as requested" and "low quality" would imply you're getting exactly what you're asking for. This would imply he's the only one not wasting time on going beyond the original ask. Also Not sure how the tags are relevant here. – Dave Hillier Nov 16 '19 at 12:57
2

Since you added the Agile tag, I will answer from that perspective. In Extreme Programming (with "peer programming") and some implementations of Scrum or Kanban, teams will require a quality sign-off from a peer on the team before the requirement or "user story" can be considered for final acceptance. This puts what I call "positive peer pressure" to work, so you don't have to be the "bad cop" all the time!

Another tool is "Acceptance Criteria." In some Agile methods, the user story includes a statement that provides the high-level specifications the deliverable must meet to be accepted. Repetitive specifications, like "No defects," can also be added to a "Definition of Done" applying to all stories. This helps both the peer and the final "accepter" (customer, project manager, Product Owner, etc.) because they can point to that as the reason they "must" reject the item, since otherwise they look bad.

To put this together in a sequence using Kanban:

  1. The accepter and team agree on the Acceptance Criteria for each story and overall Definition of Done.
  2. The person draws that from the top of the list, moves it into a column labelled (for example) "Working."
  3. When he or she is finished, they move it into a "Check" column.
  4. When a peer is free, they check it and if the specs aren't met, push it back to "Working" and notifies the first person (there are other ways to to handle this I won't go into here).
  5. If/when it passes the "Check" phase, it goes into an "Accept" column for the accepter to consider, which may lead to a rejection again.

Please note that I have used these methods for hardware design and testing teams as well as software teams.

| improve this answer | |
  • Thanks for your reply, in fact yes we have the acceptance criteria.. but may be we need to stress on what is really a defect or potential defect mean. However, you mentioned in the flow that story will be tested/validated by a free peer. I don't know if you mean by this a person responsible for QA and validating or this part of the development team. As how you organize this and not creating context conflict? (And just to mention, i have no availability for some one fully allocated for testing.. i wish but i can't) – amr007 Nov 5 '19 at 8:50
  • I think that is a good idea about better defining a defect! Based on evidence out of the big-data project at CA Agile Central (still "Rally" at the time), it is good you do not have a dedicated tester. Teams where developers shared testing duties actually performed better. Not sure what you mean by "context confict," but in my method a fellow developer takes a task in the user story during Sprint Planning to check functionality against the acceptance criteria and look for bugs. – The Radical Agilist Nov 6 '19 at 19:55
  • Looks interesting .. i will try it – amr007 Nov 7 '19 at 22:34
2

There are already several good answers mentioning use of tools like PIP, peer review, and TDD, but I’ll mention one thing that strikes me. In your question you state

I have a person in my team with average experience that always do the task exactly as requested as output but with low quality.

But if he did it exactly as requested, you wouldn’t be asking the question here. It sounds like you and your team don’t have a universal definition of done and/or standard for acceptance. I’d work to make this very clear to the whole team. This will help the top performers correct the lower performers when they submit something against this definition and boost morale overall. It should have a side affect of fixing your problem with the individual as well. This method will be complemented by the formal methods mentioned in other answers.

| improve this answer | |
  • Unfortunately you are correct.. after review i can say that is part of the problem – amr007 Nov 7 '19 at 22:54
1

There have already been good answers to this question, but you may also want to consider using a test driven development (TDD) approach.

For example, have the developer first write automated tests that validate the acceptance criteria on the user story. Only once those tests are written do they proceed to the implementation.

This approach has several advantages:

  • It will help the developer to learn a quality-first approach
  • It will provide you with automated regression tests
  • The process of writing the tests often helps the developer with the implementation design
| improve this answer | |
0

There are a lot of drivers that can cause or contribute to an individual's performance, one of them being that he can be simply a low performer intrinsically. Once you have ruled out the various external drivers to performance as the cause or contributor to his performance, than focus on his tasks with measurable expectations and use a formal Performance Improvement Plan type document to measure his progress or lack thereof. The PIP typically has very objective criteria and a timeline in which to meet those criteria.

Since this is a project management site, the PIP would be of a rather short duration versus what you might have more in an operations setting. If he fails to meet his PIP, then move to replace.

| improve this answer | |

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.