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 aspects of the eventual product. This responsibility is not of the “You must approach high wizard Fladnarg with respect, so maybe they will let you check in your custom Instagram API fix.” No, it is like the sign that was on U.S. President Harry A. Truman’s desk - “The Buck Stops Here.”
In an 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 whether 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 facilitation-needed state – one of the other members could perform that facilitation. As a final example, if a developer cannot make progress with the code they are working on, another developer can step in to help so progress on that code can continue.
If you come from a background other than Scrum – especially one of the more command-and-control, top-down methodologies rather than Agile – 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, someone (possibly not even a member of the Scrum Team) 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, and the responsibility to help the Scrum Team work together to build the best products for your customers.