The Scrum Contract (Part 2)
The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.
Establishing Work Boundaries
Trust is a large component of scrum, and by extension, a large component of working in any type of team environment. We all rely on each other to fulfill our obligations, and support the team process.
But human beings are naturally curious. Any time there’s confusion about what other people are working on, there’s always a tendency to want to ask questions and explore. Everybody has opinions about what everybody else is doing, and that’s the nature of working together on a team. That curiosity is healthy.
However, it’s important to remember that people need the space to carry out their work as they see fit. Part of having a role in a group process means allowing other people to have their roles as well. When it comes to scrum for web and mobile development, this means allowing the engineers to work in an uninterrupted way on the stories they have agreed to complete during the sprint. This is part of the self-managing nature of scrum, and it allows for a high degree of individual flexibility, as long as productivity is maintained.
Note: Everyone Needs to Respect the Scrum Roles
This level of respect for the scrum roles needs to extend beyond the limits of the team, or even the engineering organization, in order to provide the needed stability to support an effective scrum process. It’s the responsibility of both management and the scrum master to communicate the value of scrum to other people in the company who may have an impact on the expectations applied to the scrum team, including senior management.
On a scrum team, all individuals are expected to fulfill the obligations of their roles, and they rely on each other to do the same in order for the entire process to work. In cases where that process may be breaking down, scrum provides the opportunity for anyone on the team to question how the team is working together at the end of each sprint during the retrospective.
The conversations during a retrospective may sometimes need to dig into the details of individual behavior, which is always a sensitive topic. It’s important for the scrum master to allow these conversations to take place when they’re relevant to the team as a whole, but to defend individuals from personal attack.
When you work in a team, you can’t expect the work you’re doing to exist in a vacuum. You need to understand that other people are going to have to touch your work, and that the work they’re doing is based on what you do and how you do it. It’s a shared context. Sometimes the way you work will have a bearing on the rest of the team, and you need to be willing to allow that to be discussed.
Everybody on the team needs to be able to trust the scrum master to defend their interests. And everybody on the team needs to be able to trust each other to fulfill their obligations. Scrum creates room for that trust to grow, and provides opportunities to demonstrate the value of that trust.
Honoring Reflective Iteration
One of the most valuable components of scrum is the fact that it adapts constantly as the team, the project, and the context change. No project has a completely predictable trajectory, and this is particularly true of projects in the web and mobile space. So much is changing constantly—not only in the context of the marketplace but also within the teams working on a project—that the ability to adapt quickly is critical.
On a regular basis, scrum takes the time to look at itself and see how well it’s performing. Taking advantage of the retrospective, the team has the opportunity to step back from what it’s doing and think about how it’s doing. Retrospectives not only take the temperature of the team, they provide an opportunity for everybody to share compliments and criticisms about how things have been going, and agree to make adjustments.
Since retrospectives happen every sprint, anything decided at one retrospective is subject to reconsideration at the next retrospective. Any change the team agrees to make in a retrospective should be considered an experiment. You can think of them as tests to be trialed the same way new features on a website or mobile application often are—being evaluated based on real application. It’s a mistake for people on the team to think that agreeing to try something at a retrospective means the team has changed its policies permanently.
For example, the team may have noticed that holding daily standups first thing in the morning means that sometimes important people aren’t present to share and learn from their colleagues. At the retrospective, somebody may propose moving the time of the standup to immediately before lunch, because everybody is more likely to be present and there’s a good chance their flow won’t be interrupted at that time. If there’s general agreement, the team can agree to try this for a sprint, and then discuss it at the next retrospective to see if the new time actually works for everybody, or if they need to adjust further.
The results of an experiment don’t have to be positive in order for it to be successful. That’s the nature of the scientific method. If people like a change, they can agree to make it permanent—until somebody brings up a good reason to change it at a later retrospective. If people don’t like a change, they have the opportunity to bring that up at the next retrospective, and potentially stop the experiment from going forward.
Reflective iteration allows well-functioning teams to continue functioning and improving, and allows teams with problems to recognize and adjust for those problems. Everything about the process is subject to group agreement. And because there’s always another retrospective coming up, there will always be another chance to revisit any decision and shift directions if something’s not working.
Adhering to Shared Definitions
Scrum encourages people to work together rather than alone. In order for that to be productive and not oppressive, people need to agree to shared definitions about the context in which they work. Without a common vocabulary that everybody can agree to, teams would be impossible to manage, and scrum would be of very little use.
Scrum defines a number of new terms for an organization, such as sprint, story, artifact, etc. Part of the value of this is that each organization gets the opportunity to take those new terms and use them in the way that’s most effective for them. This doesn’t mean breaking from the core standards of scrum, but it does mean coming to a conscious agreement about how each team chooses to operate internally within those definitions.
The vocabulary we’re discussing is unique to each team. While shared concepts such as stories, standups, and points may be familiar across all scrum teams, how each team writes a story, how each team manages its stand up, and how each team chooses to assign points are all subjective and constantly evolving properties of that individual team.
For example, one of the things that every team needs to define for itself is the concept of done. One of the artifacts of scrum is a definition of done, in which the team can agree to the standards a story needs to meet in order to move from development to acceptance. Unless everybody has a clear understanding of what it takes for a story to be done, there may be disagreement about how to work on a story, and what needs to happen at each stage of the process.
Scrum doesn’t attempt to define done for the team, but scrum expects the team to create and share their own definition of done that everybody can agree to. Scrum provides loose guidelines, and allows a great deal of flexibility for the team to define their own standards, so they can discover their own path to sustainable productivity.
Working on a scrum team requires willingness. Everybody needs to be willing to take on the roles required of them to keep the team productive, to be transparent about the work they’re doing, to respect the boundaries that define everybody’s roles, to work together to iterate and improve the process regularly, and to agree to share definitions for how everybody will work together.
With these concepts in mind, in the next chapter we’re going to take a look at a particular team working on a particular project. It’s the same team we met before, from the WithKittens.com site, but now they’re starting to work as part of a scrum team. We’re going to show how new stories for that site develop from ideas in the product backlog, and how the team goes about evaluating those stories to see if they make sense, and how much effort they’ll take.