In a previous post feels I wrote about how teams struggle with the same problems over and over again. This post adds a few more common mistakes to this list how to address them.

In a previous Déjà Vu post, the list of common mistakes included,

• Poor Communications
• Bug Creep
• What Do You Mean By "Done"?
• QA Is Not Part of the Team
• Writing Code without Stories

To these, I now want to add,

• No Decision Made about Poor Performers
• Wrong Approach to Unit Testing
• Quality is QA’s Responsibility, Not Mine

No Decision Made about Poor Performers

In most development teams, developers end up as friends.  This is really good, but it has its dark side.  In particular, if there is a poor performer in the team, the team’s loyalty will drive them to either hide the facts or avoid facing the situation altogether.

The team would rather work longer hours than really fix the problem.  They’ll work at night and weekends to complete or clean up the crappy code or complete missing or useless unit tests.

Unfortunately, the team ends up paying for this,

• The team’s performance goes down, impacting its velocity and delivery cycle.
• Even though they may not say anything, folks end up resenting the poor performer and this impacts the team’s morale.
• Hiding what’s going on consumes a lot of time and effort that rest of the team has to make up for.
• The poor performer does not get the necessary feedback on a timely basis and doesn’t get a chance to correct the situation, get more training, etc.
• Most often this feedback comes up way after the fact, the next time that a new team is put together and people make it clear that they’d rather not work with the poor performer again.
• This is the worst situation for everybody: the poor performer does not get the feedback on time, when something can be done about it and the team puts up with the poor results and the consequences.

As with any other  bad habit, the first step is to recognize that there is a problem and then start doing something about it.

Identify the Problem

This might come from different sources:

• Somebody in the team has the courage to point out the problem.
• Team performance stats will show enough of an anomaly to warrant attention (e.g., recurring Sprint slips, higher bug count than normal, etc).
• In the worst case, the client will identify the problem and request a change immediately.
• At code reviews.
• Team time stats will show some people putting in a lot of extra time (to clean up) or significantly less time than expected.
• Contributions to production code (i.e., as recorded in your source control tool).

The Scrum Master has a key role to play in identifying these problems.

Meet with the Team

Once it is clear that you have a problem, have the team meet to discuss the problem.  The discussion must be oriented to,

• Understand the behavior.
• Analyze the impact of the behavior.
• Define the changes needed, any remedial actions (e.g., training) and a timeline for when the changes must take effect.
• Define the consequences.
• Provide very clear feedback to the poor performer to make sure that he/she understands the what, why, how and when of the situation.
• Keep track of progress.
• Here’s the hard one: take action if things don’t improve.  You defined the consequences, now you must act on them.

Performance Indicators

Dealing with poor performance in a fair an unbiased way can be pretty difficult.  It is tremendously helpful to track performance indicators that everyone can self-administer.  Some recommended indicators are,

• Productivity
• Defects density
• Adoption of best practices
• On-time delivery
• Deviation from plan/estimates

These are a good balance to “gut feel,” which is, nevertheless, not to be ignored.  If you can easily answer the question, “who do I not really want in my team?” then that’s a good indicator that’s something is not right.  Otherwise, you should be able to answer that questions easily, when everybody work is vital for the project and contributing at their best.

Wrong Approach to Unit Testing

Here’s an actual conversation from a daily meeting:

Quality is QA's Responsibility, Not Mine

Another excerpt from a real life conversation,