Individual accountability

Why was someone given a part to fail with, and why was the problem discovered so late that the Sprint Goal was jeopardized? What might this say about the Developers' collective focus, and their ability to monitor their own progress?

Why was someone given a part to fail with -- the team distributes and assign the work themselves, this person thought he could deliver on time and there was no risk

why was the problem discovered so late that the Sprint Goal was jeopardized? -- in these instances this has been due stories being underestimated, and certainly there was lack of prompt communication

What might this say about the Developers' collective focus, and their ability to monitor their own progress? -- clearly there's room for improvement 

A Scrum Team is defined as "a cohesive unit of professionals".

The Developers, among themselves, are accountable for "holding each other accountable as professionals". If a Developer realizes that they are struggling or need help, I would expect them to ask for the help they need. The Daily Scrum allows the Developers to evaluate the progress made so far and create an actionable plan for the next work day. It is an opportunity to identify these impediments for the rest of the team to solve. However, I wouldn't necessarily expect a Developer to wait for the next Daily Scrum - bringing up issues earlier is often better.

If there is an overall problem with someone having problems and not raising those as impediments, the Sprint Retrospective is a good place for the team to have those conversations, figure out what the issues and their root causes are, and plan to solve them.

Hi Thomas, thanks for answering. How repeated occurrences with the same person are handled if after retrospective feedback is shared etc.? Somewhere else I read that performance issues should be brought to the manager if actions from the retrospective fail to address the issue.

Hi Thomas, thanks for answering. How repeated occurrences with the same person are handled if after retrospective feedback is shared etc.? Somewhere else I read that performance issues should be brought to the manager if actions from the retrospective fail to address the issue.

I'd agree with involving the manager. People-related functions are typically outside of the Scrum framework. If these performance issues are an impediment that the team can't resolve, then involving someone who can resolve them is the next step.

I agree with Thomas that a manager might need to be involved.  But there was something you said in an earlier post that bears some discussion.

in these instances this has been due stories being underestimated, and certainly there was lack of prompt communication

How does the team do the estimation?  Is it a team activity? If so, then this could be a bigger issue than just one person not being able to complete work. It could be a team problem of not being able to properly identify work and complete it as a team.

In the teams that I have been involved with, this is something that happens often.  An estimate is made based upon the information available at the time of the estimate.  As work begins, new information is usually discovered. The team will then plan their work so that the new information is taken into account.

If the team is estimating as a group, then they need to react as a group to the new information. It could be that the work needs to be re-evaluated, split into multiple parts and spread out among other people.  If one person is not able to do all of the work, others should help. If someone finishes some work, before pulling in new work, they should help others complete work in progress.  The concept is to complete work in progress before starting any new work. As a Scrum Master, this is the conversation I would bring up at the next Sprint Retrospective.  Have the Developers come up with some ideas of alternative ways to work and experiment with a few of them. I always try to let the team handle issues themselves before I involve any "management". But that doesn't always work.

Good thoughts there Daniel, thanks.