In a previous post, I wrote about how teams struggle with the same problems over and over. In this post I add a few more common mistakes and how to address them.

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

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:

ScrumMaster What did you accomplish since yesterday?
Developer I completed coding CRUD for categories.
ScrumMaster Great.  And everything passed unit testing?
Developer I didn’t do any unit testing.  I’ll do it after I finished coding my stuff for this Sprint.
ScrumMaster Excuse me? Then you didn’t complete CRUD for categories since it’s not unit tested.
Developer Yes it’s completed.  I planned the unit testing as different task.
ScrumMaster Whoa! Are you telling me that unit testing is somehow a separate activity from writing the code?
Developer Yes!
ScrumMaster I see.  So, in this Sprint you committed to delivering eight features.  Your plan, then, is to code the eight features first and then unit test all of them at the end, In the meantime, you won’t be able to release anything to QA, right?  Do you think that’s right?  Or would you release your code without unit testing?
Developer No, that would be a waste of time for QA.  They should wait until I am done unit testing before they start to automate test cases.
ScrumMaster OK.  But then, by the time you get feed back for your first line of code it will be really late, towards the end of the Spring, right?  By then we’ll have to get ready for deployment and you won’t have time to fix the bugs we are going to find, etc, etc, etc.
Developer OK.  Alright.  I got it.  From now on I’ll do the unit test as part of the code. One without the other means that the work is still incomplete.

Quality is QA’s Responsibility, Not Mine

Another excerpt from a real life conversation,

ScrumMaster dialogue
Developer dialogue
ScrumMaster Hey, I noticed that in the last Sprint, your defect density is really high.  Did you realize that?  Why do you think that’s so?
Developer I’m not sure. I just focused on writing code to match the stories.
ScrumMaster That’s good.  BTW, are you doing any testing before releasing to QA?
Developer No, testing is QA’s job, not mine.  Once they find problems with my code, I fix the problems as they tell me.
ScrumMaster But that doesn’t that mean that when you get started with your next cool feature, you’ll have to take a break to fix the problems that QA finds with your earlier code?
Developer Yes, that happens and it’s a pain.  Sometimes I don’t ever remember the code all that well and it’s hard to debug.
ScrumMaster So… wouldn’t it be more efficient, and satisfying, to test the code right as you write it.  Otherwise, you’re doing work over again and making your previous work worthless.
Developer OK.  I see.  I’d better test my code before releasing it since quality is also my responsibility, not just coding.