Roles and Responsibilities in Scrum
I want to make explicit what was only implied in Myth: The Product Backlog is Maintained Exclusively by the Product Owner – that every action and every issue in a Sprint is the responsibility of the whole Scrum team. That being said, at the very least there will be a Product Owner, a Scrum Master, and one or more developers who will be responsible for one or more aspects of the eventual product. This responsibility is not of the “You must approach high wizard Fladnag with respect, so maybe they will let you check in yet another Sendmail config fix.” No, it’s like the sign on President Harry A. Truman’s desk - “The Buck Stops Here.”
In the ideal Scrum team, everyone shares in the responsibility for everything. Going back to the original post, the Product Backlog is not locked away by one person – the Product Owner – but is accessible by all team members to view and edit as they see fit with the Product Owner as the final arbiter of what goes where in the Product Backlog (or even if it belongs in the backlog at all).
Similarly, if the Scrum team needs facilitation but the Scrum Master is unable to provide that facilitation, the team is not stuck forever in that state – one of the other members could perform that facilitation. As a final example, if a developer cannot go forward with the code they are working on, another developer can step in to help so progress on that code the continues.
If you come from a background other than Scrum – especially one of the more command-and-control, top-down environments rather than an Agile environment– this adjustment can be a huge break with the past. Additionally (and unfortunately), you may end up working in a SINA environment (Scrum In Name Only), where despite the team’s best efforts to work in the Scrum Way, the Product Owner (quite possibly the reporting manager of the developers) dictates who does what and for how long with every single item on the Sprint Backlog.
The foundational lesson here is that as a member of a Scrum team, you are not bound by the rigid, hierarchical, military-inspired team development methods that have dominated development since WW II or before. Instead, everyone has a part to play, a voice that needs to be heard for things that are going right and things that are going wrong, and the responsibility to help the Scrum Team work together to build the best products for your customers no matter what part of the product you are currently working on.