Elevate the status of agreements in Scrum
Core Scrum introduced the idea that the Definition of Done is not an artifact, but an agreement among the stakeholders, which can change (become robuster) over the course of development. There are other agreements in Scrum, for example the selected product backlog is the result of sequencing by the PO and the Dev Teams forecast of what it can accomplish. Or if the team cannot meet its forecast, it should fail on scope (deliver less than forecast), rather than do overtime or prolong the sprint.
Other agreements are not core to scrum, serve to improve the performance of the team, e.g. definition of ready or team charters ("working agreements"). Perhaps even the VIsion or the Sprint Goal can best be seen as agreements, whereas now their status is a bit vague.
I believe there is an interesting litmus test for changes to Scrum, which help you decide whether your change is a good change or not:
1) Does your change cause you to inspect and adapt more frequently than the reference implementation?
2) Is the change the result of an agreement between among the Scrum Team or between the Team and its stakeholders to improve effectiveness?
I believe if the answer to both questions is yes, then the team has effectively inspected and adapted the process. So by treating agreements as a fully valued part of Scrum, you show the teams the way to become even more awesome!
Peter Stevens commented
I see what daniel is saying. I think a working agreement is something that is lightweight. Good until we change our minds. This is why I'd like to see it referenced in the Scrum guide, so that we have guidance on the importance on agreements as a way to effect change, which discouraging that they become artifacts that have petrified!
Daniel Wilhite commented
I can agree with what you say in principles and as a tool for facilitating high performing teams. But I disagree with this being part of the Scrum Guide. It starts to make it be less of a framework and more of a methodology when you add more "governance" to it. Adding more formalized agreements to the description is starting to dictate more and more of how you work.
As a framework, Scrum allows for individual organizations to adapt what ever process they choose. If an organization would like to formalize additional agreements and it will benefit them, the they should do it. But having the agreements that you mentioned added to the Scrum Guide would actually make the Scrum practices we have in place at my current company become "Scrum, but". I really like the way the current guide errs on the lighter side.
Karol Grodzicki commented
That's a good idea ;) BTW, some effects of retrospectives could also be treated as even less formal agreements.