Scrum Master Accountability

In Scrum, the Development Team are accountable for the successful delivery of each Sprint Increment. No one single developer is ever individually accountable for that.

There is no “delivery manager” role in Scrum to be held accountable for anything concerning development, or to be held accountable to.

The Development Team are accountable for establishing practices which assure transparency over their progress towards the Sprint Goal. That transparency should allow them to replan their work each and every day. No one individual developer can ever be accountable for the deferring of risk to the last day or for the consequences of doing so.

Developers are individually accountable for their part in collaborative practice, such as commitment to team goals, the raising of impediments to the Scrum Master, or the calling of a Scrum so the team can focus on problems in a timely manner.

I'm going to assume that you mean "Product Owner" when you say "Product Delivery Manager", as Ian said; there is no product delivery manager in scrum.

Obviously there are tons of other questions that need to be asked to get to the true answer but were I in that interview and that was posed to me I would answer:

1. Development Team (See Ian's comment as it explains it perfectly)

2. Scrum Master 

     2a. In the scrum guide in the Artifact Transparency section it states that the SM must work with the Dev Team and PO to coach them on how to get complete transparency. A developer may see a backlog item and see it as perfectly transparent but the PO may see the same item and be completely confused on the item. The SM is responsible for ensuring transparency, if transparency is lacking we must look at the SM. 

3. Scrum Master

     3a. While the developer should have mentioned it as soon they found out it wasn't going to be completed, once the SM found out; the SM should have made it known to the PO. 

I think it is safe to say that this scenario needs a lot more than just a simple 1 word answer to resolve their problems but a lot of times in interviews they don't want you to solve problems as much as answering the question at face value. Had the question been posed as "How would you solve this problem?" that would indicate the interviewer wanted a detailed answer to resolve the issue. By them saying "In 1 word, give us your answer", they are not looking for resolution so much as an answer given at the face value of the scenario. 

 Thank you guys for the detailed explanation here on accountability. It certainly helped me a lot in my understanding.

 Ian Mitchell and Curtis Slough appreciate taking time out to give your opinions on this matter. As mentioned, there cannot be one word answer to this problem, it has to be introspected and resolved with the team. 

Agree with both Ian's and Curtis' responses.

The Development Team has complete autonomy to manage their sprint forecast and meet their Sprint Goal.   They may decide to distribute work on an individual basis, but accountability for the work always rests with the entire Development Team, and not a single member of the Development Team.

That being said, the interview question posed only raises additional questions for me:

1. How is the Development Team conducting their Daily Scrum?   
2. Why does the SM learn of the impediment so late in the sprint?   
3. Does the rest of the Dev Team also learn of the situation 1 day before sprint end?
4. How does the Dev Team member not communicate their issue with the rest of the team?   Is this outright deceit, or a problem with how the team is working together?
5. Why does the PO find out about the impediment so late in the sprint?   Have they attended the Daily Scrum to listen to the Dev Team discuss sprint items?   What information radiators are available to the PO for them to understand sprint health?
6. Why would the sprint fail because of one missed sprint item?   Sprints fail when Sprint Goals are not reached, not when one item doesn't meet DoD.   Did the Sprint Goal only include one item?   If this was such a critical story, why was it allowed to be worked on by a single Development Team member, and so late in the sprint?   What was the priority of the sprint item that failed?

So many questions that need to be asked in order to get more clarification on what the interviewer is really asking.   I have learned as a Scrum Master that replying to questions with questions is far more effective than stating an answer.

I read Timothy's comment and chuckled because those questions went through my head when I was typing my response. I had to fight myself from mentioning them because I wanted to ask the specific answer posed; which was incredibly hard haha.

Interesting challenge...having to answer those three questions in a single word.

The single word I suggest the interviewers were looking for is Transparency.

It is the job of the Scrum Master to ensure artifact transparency, and the Scrum Master is accountable for the Scrum Process.  What I mean is, the Scrum Master is responsible to help everyone involved understand Empiricism.  That is, if information is transparent, then we can all inspect efficiently and adapt effectively.

In the story you've shared, it is clear that a team member struggled with a Product Backlog Item and rather than make the problem known to others, they remained silent until the end of the day.  In an environment where openness and courage are valued, that developer would have announced the problem early so that everyone involved might have had opportunity to adapt and solve the challenge together.

I agree with everything that Ian, Curtis, Timothy and David have said. I do want to emphasize one thing that Timothy called out and elaborate.  Why is this a failed sprint?  Not completing one item doesn't make a sprint failed unless the Sprint Goal was not obtained.  And even then, if the incomplete story was due to information found during the course of the work (as you indicate), I would think it was a pretty successful sprint. You said that the developer didn't realize until the day before.  That is some new found information uncovered at the end of the sprint.  How could anyone avoid that?

If I had been in the interview I would have told the interviewer that no one was at fault unless it was completely avoided in the Sprint Review and Retrospectives.  This is only a failure if the team does not learn from what happened. I'm sure there were probably some "signs" that the developer was struggling. Find those and learn how to anticipate them for the future. 

Transparency is part of this problem.  Inspect and Adapt are also in the mix.  Agile principles at their finest.  And let's not forget 3 of the Scrum values, Courage, Commitment and Respect which are in play here also. 

I totally agree with Daniel's comment on failure. One of my teams is currently on a run of having not achieved its Sprint Goals for a few Sprints, and the underlying issue is that there's a long term technical refactor project, with work that has been completed but not released, and another issue we had was that the definition of "Done" did not actually exist until a few weeks ago. We're trying to get out of this difficult situation by releasing what we have, but only if it's "Done".

The team went into the previous Sprint with a large amount of untested work in progress (and therefore high uncertainty), and came out of the Sprint having not achieved the goal, but I would say the Sprint was not a failure, because during the course of the Sprint, the team identified a large number of bugs that were the legacy of this long term project, and has much greater confidence of being able to release within the next Sprint.

I know this is a problematic situation that Scrum should not allow to happen in the first place, but given where we are, having not achieved the goal that time, it didn't feel like failure.

@Simon, I believe the context you described would be a worthy topic to examine.

For the sake of this thread I posted it here: https://www.scrum.org/forum/scrum-forum/25795/legacy-project