Capping IT Off

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:

Commitment

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 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.

Focus

An iterative-incremental approach like Scrum and the time-boxing of Scrum allow us to focus. We focus on what’s most important now without being bothered by considerations of what at some point in time might stand a chance to become important. We focus on what we know now and YAGNI (You Ain’t Gonna Need It) helps retaining that focus. We focus on what’s most nearby in time 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.

Openness

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. But we are also open for people, and working with people; acknowledging people to be people, and not resources, robots or replaceable pieces of machinery as software development -after all- is still the work of humans. We are open to collaborate across disciplines and skills. We are open to collaborate with stakeholders and the wider environment. Open in sharing feedback and learn from one another. Open for change as the organization and the world it operates in change unpredictably, unexpectedly and constantly.

Respect

We show respect for people, their experience and their personal background. We respect diversity (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 being 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 island in the world. We respect each other's skills, expertise and insights. We respect the accountabilities of the Scrum roles.

Courage

We show courage in not building stuff that nobody wants. 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 software. Courage in sharing all possible information (transparency) that might help the team 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 to deal with complexity. Courage to let go of the feint certainties of the past. We show courage to support the Scrum Values.