I've written many posts over on The Tao of Management related to dealing with employee under performance. Rather than reiterate the same advice there, I wanted to take the opportunity to look at this from more of an Agile / Scrum perspective...


Scrum is about the team. The team own the sprint, the team make a commitment, the team deliver on that commitment. There is collaboration and collective ownership. But sometimes you as the Development Manager / Team Leader / Scrum Master may find that one or more team members are not performing at the expected level. To deal with this, I've found that the following techniques work well...
  • Use peer-pressure to your advantage. In a Scrum team, developers tend to swarm around stories to get them delivered. And in this type of environment it's very difficult not to get swept along with the momentum. Sit the under-performing team members next to the high performers, get them pair-programming with these individuals. Bring the pressure of team commitment to bear. There's nothing wrong with this - at the end of the day you're trying to help the person become a better developer.
  • Give people more ownership. You may want to have them start running the stand-up meetings to increase involvement, or have them run a retrospective - anything to increase involvement.
  • Understand training needs. The developer may lack the skills to perform adequately on the Scrum team. Ensuring that your team as a whole is adequately skilled to complete the sprint is vital - allow time for additional training / learning as required. Grow your team from within rather than breaking up the team dynamic by introducing new team members.
  • Ensure that you estimate for anyone on the team doing the work - not just the resident expert. That way, estimates will include a little 'slack' which means that a less-skilled or slower developer won't feel under pressure all the time. At the end of the day, Agile is about working at a sustainable pace - and that means it needs to be sustainable for all team members. You can always take on additional tasks, such as more testing of developed functionality or refactoring / elimination of technical debt, if you finish early.