Follow up question from here:
How to efficiently manage a Scrum team when one member is much less productive?
One of my developers is having trouble estimating his work. For the past few weeks he has committed to work, and once stuck in is not able to complete it. Burn down charts then goes out of whack.
My other developer in the team is also concerned that he is not performing.
Approaches I have taken so far:
- Using daily stand ups to deal with the impediment. I have been giving the slow developer tips; get the easy tasks out of the way then do the hard ones.
I have even explicitly asked him on 2 -3 occasions if he will complete the task in time. His attitude has been 'yeah I will do', but then on the day tell me he can't complete it.
- I have asked the developer if he needs the other resource to step in and help him. He would always say no.
I am now starting to run out of ideas on how to deal with the slow developer. I am starting to think that he does not care about respecting the burn down charts, and is carrying the attitude that it will be done, when it is done.
EDIT:
I am encouraging the team to become more cross functional. In this instance that would not have helped anyway, because the task in question has to be completed by the person who started it. Otherwise we will have too many cooks spoiling the broth.
I have also educated the developer about the business objectives, and the team velocity is what is being tracked etc Developers agree that this is the right way to deliver work, fast developer is thriving, slow one isn't.
get the easy tasks out of the way then do the hard ones.
Do you really think that is a good idea? Personally, I start the hard tasks early and use the easy tasks to "take a break" when I start getting stuck and am waiting on others to help. At least some of your tips are probably causing more harm than good for the team.the task in question has to be completed by the person who started it
. Why? On the contrary, swarming on a problem is totally fine, and in this instance, getting two team members to colab together can a) highlight reasons why your guy isn't up to speed, b) allows him to learn and c) improves overall quality in most cases.In this instance that would not have helped anyway
: did you try? Or are you able to see into the future?Otherwise we will have too many cooks spoiling the broth
. Devs peer program for a reason. You seem to be 100% convinced on quite a few things that you have incorrect