Large Team... new developer and stories added mid sprint

Paul,

The size of your Scrum team is large, but I've actually worked with larger teams, so while it isn't ideal, it can work.

While there is a proven negative impact on productivity anytime the roster of a team changes (add/subtract), I'm not sure if your organization is mature enough on their Agile path to understand this. Perhaps this is something to keep in mind for future engagement, especially if future altering of a team results in an unsuccessful sprint?

It seems your Head of Engineering still views his value as a command and control authority, which unfortunately runs counter to Scrum. It is typical to see attempts by management to try and "optimize" team members, instead of working to leverage the incredible potential of team capacity as a whole to get work done.

By isolating this new developer with hand-picked work, the Head of Engineering is delaying the need for the team to assimilate this new individual (Forming - Storming - Norming). My suggestion would be that if this new developer is not being allowed to work with the team on sprint stories, then they should not be considered part of the team yet. And under no circumstances should the spike work and the estimates from the Head of Engineering be included in the Sprint Backlog or velocity estimates. Those sizing attempts by the Head of Engineering are nothing but funny numbers anyway.

Best approach? Acknowledge that the work from the Head of Engineering has value (if it truly does), suggest that those spike stories be provided to the entire team to work on (with the blessing and prioritization of the PO), and have the entire team refine and estimate those stories so they are ready for sprint. If the Head of Engineering insists on having the "new guy" work on the spikes alone, simply inform them that the spike work will be managed and reported on separately from the team's sprint work.

Thank you for the reply!

> Seeing as there is a few things "wrong" or
> abnormal here, what would have been the best approach?

Help everyone else to see what is wrong first so they themselves can make it right.

Scrum is not being used in your organization, and the idea that there is a currently a Scrum team at all must be challenged. Training courses may help. Failing that, I'd promote a better understanding of the Scrum Guide. The scrum.org open assessments can be used to help build missing rigor.

Thanks Ian for your reply. Sounds like you see fundamental flaws in what we're doing. The argument was because of the size of our team that it was okay to create new "spikes\investigations" and assign it to the new dev came in mid sprint. There was no work that was previously planned for the sprint that could have been shared with the new dev.

I will check out the scrum guide etc cheers, but if I could ask what would you suggest\have done in this circumstance? Do you see other glaring issues (no scrum master etc)

If I observed that people thought they were following Scrum, and yet had no Scrum Master, I'd have stepped into that role myself. Understanding the organizational appetite and sponsorship for Scrum would be important to me. I wouldn't have allowed a PO to assign work to developers. I'd be keen to coach others in more appropriate practices that better implement Scrum.

From what you have described so far, there are significant and particular problems with roles and responsibilities. I recommend going through the Scrum Guide as you have suggested. After you've done that, review your own post and identify the gaps.