Skip to main content

Balancing Experience and new Developers

Last post 07:08 am November 4, 2014 by Anke Maerz
4 replies
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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.