Scrum is not a methodology. Scrum is a process, but of a non-repeatable kind. Scrum is a framework of rules, roles and principles that helps people and organizations emerge their real process, specific and fitting to their time and context. Scrum is a light and simple base that wraps existing product development practices or renders them superfluous. From a ScrumAnd perspective ('Yes, we do Scrum. And...'), the benefits of Scrum will be greater when complemented by improved or revised engineering, product management, people and organizational practices. Changing the core design of Scrum, not even playing the game by its base rules, will cover up problems and limit the benefit of any additions, possibly make it even useless.
Less known and probably under-highlighted, but therefore not less important, are the core Scrum Values upon which the framework is based.
Although not invented as a part of Scrum, or exclusive to Scrum, these values give direction to our work, our behavior and our actions. In a Scrum context the decisions we take, the steps we take, the way we play Scrum, the practices we add to Scrum, the activities we surround Scrum with should re-enforce these values, not diminish or undermine them.
I have found it very useful to bring these more out in the open, as a way to assess the added value of our actions and activities. It's even a great help in thinking about applying the Scrum framework itself. It is possible to do Scrum as if it was a methodology; organize the meetings, instruct all players on every possible detail for every possible action within the framework. But is the framework then being used for what it's designed for? Won't it leave the individual, the team and the organization with limited improvements? A good illustration is how I've observed some teams doing their Daily Scrum. Everybody answers the 3 questions (Done? Planned? Impediments?), in a slightly spontaneous way or -worst case- when asked for by a Scrum Master-pretend. But does the team use the meeting to share information, to collaborate in replanning their work for that day, making sure they don't get out of line with one another for more than 24 hours, to get the most out of the Sprint, in moving forward to the Sprint goal? Or do they talk to the board instead of to each other? Do they only use the meeting to make sure that the board holds all their microtasks so their work is logged?
Here's some detailed view on the values, and how they can guide our actions and behavior in a Scrum context:
CommitmentThere is a widely spread misinterpretation of the word commitment in a Scrum context. This originates mainly from the past expectation of Scrum for teams to 'commit' to the Sprint Goal and the selected Product Backlog items. Upon the old, industrial thinking (that ruled software development for too many years) this was wrongly turned into the expectation that all scope would be delivered, no matter. 'Commitment' was wrongly turned into a hard-coded contract although it was always intended as an indication that the team would do the maximum possible effort in the Sprint and be completely transparent about progress. And in the complex, creative and highly unpredictable world of software development a commitment on scope is impossible anyhow.
And the definition of the word, according to Oxford Dictionaries, describes exactly how it was originally intended in Scrum:
So, commitment is about dedication and applies to the actions, the effort, not the final result.
Yet, in the Scrum Guide we replaced commitment as a result of the Sprint Planning with forecast. Because of the relationship with scope it helps getting explicitly rid of the wrong interpretation. And fortunately 'forecast' greatly aligns with the empirical nature of Scrum too.
Still, commitment is and remains a core value of Scrum.
We commit to the team. Commit to quality. Commit to collaborate. Commit to learn. Commit to do the best we can, every day again. Commit to the Sprint Goal. Commit to be professional. Commit to self-organize. Commit to excellence. Commit to the agile principles. Commit to create working software. Commit to look for improvements. Commit to the Definition of Done. Commit to the Scrum framework. Commit to focus on Value. Commit to finish work. Commit to inspect & adapt. Commit to transparency. Commit to challenge the status-quo.