Balancing Experience and new Developers

Last post 07:08 am November 4, 2014
by Anke Maerz
4 replies
Author
Messages
12:49 pm October 30, 2014

My scrum team is composed of one senior developer in a particular domain. This developer can complete work more quickly than the other less experienced developers. A couple of times recently he had completed his stories early and then jumped ahead and completed a story that was assigned to a less experience developer.

On the one hand I took it as a positive that we were getting ahead in the sprint, but on the other hand I think this short circuited the less experienced developer from getting hands on experience and also the satisfaction for doing the work himself. From that perspective I think this can be dysfunctional for the team.

My impulse is to set a ground rule that one person doesn't do work that is assigned to someone else, at least without some communication. This seems like a bit of a violation of a scrum etiquette (if there is such an concept :-) )

Are there BKMs that relate to this scenario?

04:53 pm October 30, 2014

Wouldn't this be a good opportunity to use pair-programming techniques in order to improve collaboration, and to disseminate team skills and knowledge?

01:14 pm October 31, 2014

I agree with Ian. Pair programming worked in my team. knowledge and expertise was built/spread to other members. This was the technique that I used in Resource Churns too.

04:46 pm October 31, 2014

Strongly agree with Ian - great opportunity to introduce pair programming!

Also, I would look for communication (maybe during standup?) that the experienced guy is going to be running out of work, then you can teach that the TEAM made a commit for the sprint, so he should look to help his team out on the other stories. I do mean HELP, not do it for them.

07:08 am November 4, 2014

Hi Robert,

did you ask your less experienced developers what they think about it? Because just announcing a ground rule or a new method (like pair programming) could even further short circuit them. Their opinion should be considered before stepping into action as the Development Team is meant to be self-organizing.

Independently, Ian's proposed pair programming can certainly be helpful.

Best regards,
Anke.