The Value of the Scrum Values
The Value of the Scrum Values
What is the value of Scrum, and the values that Scrum teams must possess? A DZone MVB and Scrum whiz answers these questions.
Join the DZone community and get the full member experience.Join For Free
Definition: A set of fundamental qualities of behavior underpinning the Scrum framework.
A set of essential traits emerging as groups of people enact Scrum.
The House of Scrum
The house of Scrum is a warm house. It’s a house where people are W E L C O M E.
The house of Scrum is an inclusive house of warm, open and collaborative relationships. In the house of Scrum people from varying backgrounds, with different skills, talents, and personalities work, learn, and improve together.
The house of Scrum is a great and energizing place where work thrives on the combined, creative intelligence of self-organizing people. More than the rules and roles of Scrum, people are the key to Scrum. In the house of Scrum people employ empiricism to optimize the value of their work.
The Scrum framework is designed to help people devise their proper solutions, given their specific context and unique challenges. Behavior is the key to unleashing the potential of Scrum. Values drive behavior. The rules and roles described in the Scrum Guide are grounded in the values and principles expressed in the Manifesto for Agile Software Development, and in the core Scrum Values. Ultimately, the Scrum framework can only be fully comprehended when seen as an expression of these combined values and principles.
The inhabitants of the house of Scrum exhibit the core Scrum Values: commitment, focus, openness, respect, and courage. Although not invented as a part of Scrum, or exclusive to Scrum, these values give direction to our work, our behavior, and our actions. 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 re-enforce these values, not diminish or undermine them.
There 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 (scope). 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 what it takes. This contradicts the unpredictable nature of creative work and it is a false interpretation of ‘commitment’ as a hard-coded contract. Yet, it was always intended as an indication that the team would give their maximum possible effort in the Sprint and be completely transparent about progress.
The definition of the word, according to Oxford Dictionaries, describes exactly how it was originally intended in Scrum. Commitment is about dedication and applies to the actions and the effort, not the final result.
The Scrum Guide was adjusted to reflect the true meaning of ‘commitment’ and the unpredictable nature of complex work. We replaced commitment as a result of the Sprint Planning with ‘forecast.’
Still, commitment is and remains a core value of Scrum.
We commit to the team. Commit to quality. Commit to collaborate. Commit to learning. Commit to doing the best we can, every day again. Commit to the Sprint Goal. Commit to act professionally. Commit to self-organize. Commit to excellence. Commit to the Agile principles. Commit to creating a working version of the product by the end of a Sprint, each Sprint. Commit to looking for improvements. Commit to the definition of Done. Commit to the Scrum framework. Commit to focusing on Value. Commit to finishing work. Commit to inspect and adapt. Commit to transparency. Commit to challenge the status-quo.
An iterative-incremental approach like Scrum and the time-boxing of Scrum allow us to focus, radically. We focus on what’s most important now without being bothered by considerations of what at some point in time might possibly stand a chance at becoming important. We focus on what we know now and YAGNI (You Ain’t Gonna Need It) helps in retaining that focus. We focus on the nearest deadline, as the future is highly uncertain and we want to learn from the present to gain experience for future work. We focus on the work to get things Done. We focus on the simplest thing that might possibly work. We focus on the work at hand, one piece at a time, one product at a time. We remove unwanted distractions. We maximize the work not done. We focus on the Sprint Goal.
The empiricism of Scrum requires transparency, openness. We want to inspect reality in order to make sensible adaptations. We are open about our work, our progress, our learning and our problems. We are open for people, for working with people; acknowledging people to be people, and not resources, robots or replaceable pieces of machinery. We are open to collaborate across disciplines and skills and to learn from other disciplines and skills, acquire new disciplines and skills. We are open to collaborating with stakeholders and the wider environment. Open in sharing feedback and learning from one another. Open to change in the organization and as the world in which it operates changes unpredictably, unexpectedly and constantly.
We show respect for people, their experience, their personal history and their personal background. We respect diversity and promote it (it makes us stronger). We respect different opinions (we might learn from it). We show respect for our sponsors by not building features that nobody will use. We show respect by not wasting money on things that are not valuable or might never be implemented or used. We show respect for users by fixing their problems. We respect the Scrum framework. We respect our wider environment by not behaving as an isolated pocket of Scrum. We respect each other’s skills, expertise, and insights. We respect the accountabilities of Scrum.
We show courage in not building stuff that nobody wants. We show courage in removing dead code, code for features that nobody is using. Courage in admitting requirements will never be perfect and that no plan can capture reality and complexity. Courage to consider change as a source of inspiration and innovation. Courage to not deliver undone versions of a product. Courage in sharing all information (transparency) that might help the team, the product, and the organization. Courage in admitting that nobody is perfect. Courage to change direction. Courage to share risks and benefits. Courage to promote Scrum and empiricism as the best fit for complexity. Courage to let go of the feint certainties of the past. We show courage to support the Scrum Values.
Published at DZone with permission of Gunther Verheyen , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.