How to deal with a person with low quality output in the team



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



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



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2