Starting scrum can feel a little uncertain. There are questions about how it's going to affect the way we work and the way we interact. There are questions about how scrum itself interacts with the hierarchy of the organization. And as we saw in Chapter Two, some people come into scrum with preconceived notions that can limit the potential of scrum.

In later chapters, we're going to do some troubleshooting around problems that can come up for scrum teams. But in this chapter, we're going to discuss what it means to agree to participate actively in the scrum process. Scrum can't work to its full potential without real people participating. Scrum relies on everyone to fulfill the responsibilities of their roles, and scrum makes those roles as lightweight and easy to support as possible.

I like to call this the scrum contract. Unlike the artifacts we've discussed before, this isn't a physical contract. It's a mindset that's useful for people to adopt when approaching something like scrum. It doesn't require setting aside healthy skepticism, but it does call for replacing preconceived notions with open-mindedness.

The scrum contract revolves around several key concepts:

Some of these concepts are familiar to anybody who has ever tried to work effectively on a team. Some of them apply specifically to the way scrum works. All of them rely on a willingness to work together toward a shared goal.

As we saw in Chapter 3, scrum defines a number of roles for people to take on. These roles serve a purpose in the context of scrum, and everyone needs to understand them regardless of how they relate to a person's position or title in an organization. Scrum isn't about replacing the organizational hierarchy. In fact, scrum tries to be as independent of the organizational hierarchy as possible.

Scrum expects people to be able to distinguish between their job and their role in the scrum process. This doesn't mean that scrum releases you from the obligations of your job. What scrum provides is an alternate view onto the work you're doing. When you assume a role in the scrum project, you're agreeing to participate actively in a shared process to facilitate the work everybody's doing.

Part of assuming a role in the scrum team means being willing to act with your colleagues as an equal around issues that arise during scrum rituals. Anybody participating in scrum should feel free to share their opinions around the project and process, even when those opinions go against the mainstream, or challenge the authority of somebody with a higher position in the organizational hierarchy. When a conflict occurs, it's the responsibility of the scrum master to help mediate and facilitate the conversation.

More fundamentally, participating in scrum assumes a willingness to be part of a team. The roles and rituals of scrum are set up so that everybody has an opportunity, and an obligation, to participate. A member of the team who doesn't share opinions and ideas is letting the rest of the team down. As a member of a scrum team, regardless of your position in the company, your goal is to help support the process for everybody. And because the groups are small and intimate, and the rules of participation are clearly defined, scrum provides a safe space for shy people to experiment with expressing themselves.

Because of the distinction between typical company meetings and scrum rituals, there may be some confusion from time to time about how people are expected to behave. The scrum master should be the ultimate arbiter when questions like this come up. It's up to each team to define for itself what the most useful standards of behavior are, and to enforce them appropriately.

Ultimately it comes down to respect for your colleagues, for the process, and for your place in the process. If you have questions, or you think something isn't working, there's always an opportunity to raise these at the retrospective. Don't miss your chance to participate actively.

For scrum to work effectively, everybody on the team needs to be willing to let other people know what they're working on at all stages of the process. Some call this transparency. It allows everybody to know what everybody else is working on, so that everybody can have a larger sense of the status of the project, and how they can help.

Transparency serves a number of purposes. Part of the value of scrum is that it makes a lot of information about the status of the project visible to anybody in the company, so the people working on the project don't have to be interrupted. By reserving a very short, very clearly defined period of time for the team to update each other on a daily basis, scrum avoids the need for each engineer to face the possibility of interruptions from people who just want to find out what they're working on.

Transparency also allows people outside the engineering team to track the status of issues that may be particularly important to them. Scrum defines sprints in such a way that they cannot be interrupted by new stories, but clients and other people around the organization frequently have changes they want to introduce, and they may see these changes as urgent. The transparency of scrum allows them to see at a glance exactly what the team is working on now, and why those things are prioritized way they are.

The transparency supported by scrum isn't about micromanagement. One of the advantages of scrum is its ability to create as much unmanaged time as possible for the individuals on the team to manage themselves. Nobody knows better than the engineer working on a story what's going to be needed to get that story completed. Scrum provides daily standups as touchpoints for transparency, so that engineers can share valuable insights as they update the team on their status, and then work with minimal interruptions.

Scrum assumes that everybody involved in the process has made the conscious choice to work on a team in the first place. Working together on a team means letting everybody know what you're doing, and being willing to share information and resources. One of the reasons scrum works so well for web and mobile development is that, for the type of work involved in these types of projects, working together toward a shared goal is usually more productive than isolating individuals and trying to coordinate what they produce after the fact.

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.

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.

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.

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.