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

Question

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.

Answer 1

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.

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

Answer 3

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

Answer 4

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.