For the first half of this book, we’ve talked about scrum in the abstract. We discussed what it is, and how it works. We’ve broken it down into its roles, rituals, and artifacts. But scrum isn’t just about the details. Scrum is about the people.
In the next section, we’re going to see scrum in action. We’re going to take a look at how web and mobile development teams work with the various features of scrum. And we’re going to start with the team we’ve already been introduced to.
The Beginner’s Mind
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:
- Respecting Roles
- Embracing Transparency
- Maintaining Boundaries
- Iterating Hopefully
- Sharing Definitions
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.
Respecting Scrum Roles
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.
I've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.