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.
For most of this book, we’ve been talking about the practicalities of scrum. Although the core definition of scrum is very versatile—supporting a wide range of applications—we’ve gone into a fairly opinionated and detailed explanation of the mechanics of scrum as it can be applied in web and mobile teams. (Many of these principles and practices, however, apply just as well to other kinds of development work.)
Now that we have some shared vocabulary and concepts, in this chapter we’re going to discuss how to get a team started with scrum. We’ll go into more detail about the arguments for scrum when doing web and mobile development. We’ll discuss what scrum is best for, how it compares to the alternatives, and provide answers to some of the questions that come up when making the case for scrum and applying it in a company.
Taking Steps Toward Scrum
We’ve learned some things about scrum, and how scrum can help your web and mobile development project. The next question is how to take your team from zero to scrum. That’s going to be different for every team, and you’ll need to evaluate your own situation to determine just how ready the organization is to adopt an agile approach.
Buy-in
If your organization is currently following something like a waterfall process, the people at every stage in the cycle may be comfortable with the roles they have, and won’t be anxious to try something new. You may need to show them just how much more effective and productive the organization could be with a scrum-based process.
Executives may be concerned they’ll have less control over a team that self-organizes, and that they’ll have less input into a process that generates its own ideas. Point out to them that an agile process gives them the opportunity to shift and adjust priorities every sprint, adapting to the marketplace more effectively, while providing valuable feedback that they can use to help guide their decision-making process.
Engineering managers may be confused about what their role is in a team that manages itself, but that concern grows out of a semantic misconception about the concept of a team being self-managing. Managers are still essential to help the team allocate resources, resolve personal issues, and identify and retain talent. Managers also bring their own background and knowledge to the whole development process. Engineering managers are free to dedicate a portion of their time to hands-on work as one of the engineers on a team, but their main responsibility is securing the team’s place in the organization, making sure they have the tools and resources they need, and defending them from distractions so they can continue with their scrum process.
Designers may wonder how they’re going to fit into a scrum process, when their work doesn’t necessarily follow the same cycle as the rest of the team. Show them that scrum provides designers with increased opportunities to have more impact before decisions get made, because designers can be involved in every stage of the development, and participate from the planning stages all the way through release.
Engineers may be concerned about the change in their roles, especially if they’ve gotten used to doing one thing very well. Agile puts a greater responsibility on each engineer to play a broader role on the team, but it also opens up new opportunities for learning and growth. The stability provided to engineers by commitment to a sprint, and the confidence that the requirements they’ve agreed to won’t change until the sprint is over, may be strong selling points in an organization where interruption and chaos have been a problem.
Adopting agile isn’t a one-way conversation. The champions of scrum should listen, and learn from the concerns of the people who are going to be asked to change their approach during this process. For everybody, it’s useful to remember that scrum is always an experiment that’s just going to last for the length of the next sprint, with the opportunity at that point to revisit and change anything that doesn’t seem to be working. Sometimes the experimental nature of scrum is one of the most compelling arguments for giving it a try.
Training
Although scrum isn’t that complicated, and can be described pretty thoroughly in a book, it’s invaluable to have the team trained by someone from outside the organization who understands agile.
An objective, third-party trainer can step into an organization and see problems in a way that a person inside the organization may not be able to. A good trainer will also be able to coach people through some of the more subtle or complex aspects of the process, making sure they have a full understanding not only of what they’re doing, but why they’re doing it.
Scrum training can take one or two days for the entire team, and may be best done off-site, in a neutral place where people won’t be distracted by the day-to-day work currently going on. Don’t try to shortchange your organization by giving them less training than they need. It’s too easy to start applying the labels of scrum to a process that’s anything but agile.
Warning: Do Not Use Scrum as Simply a New Way to Describe Existing Processes
It’s a mistake to think of scrum as a new way of talking about an existing process. Scrum isn’t just a set of fancy vocabulary words. There are teams that start using scrum tools without proper training, and end up following the same broken process that hasn’t worked for them in the past, while applying labels such as “sprint” or “story,” or having hour-long daily “standup” meetings. Don’t let your team be one of these.
Getting everybody’s active and focused participation is important for the scrum training to take root. Anybody who isn’t properly trained may not understand how scrum is supposed to be applied, and that can lead to frustration and confusion that’s easily avoided with a little preparation.
The list of people to invite to the training should include some representatives of senior management, as well as all the people in the organization who are going to be participating in the rituals on a daily basis. You don’t have to get everybody in the company trained, but anybody whose role involves direct interaction with the scrum team is a likely candidate.
Staffing
It may not be necessary to hire anybody new in order to implement scrum in your organization. Most of the roles in an agile team can be filled by people who already exist in the organizational hierarchy.
A product manager may be a likely candidate for the product owner role on a scrum team. Engineers—whether junior, senior, or management—should all be considered equal on the development team for the sake of scrum, despite the differences in their ranks in the organization. Often QA engineers are also included in scrum, which provides a number of benefits in terms of redundancy, cross-training, and organizational reach.
Project managers may be the best people already working in the organization to step into the role of scrum master, with some training about the differences between the skill set involved in managing projects versus running scrum. In a pinch, any member of the development team can be trained to act as scrum master. However, a good scrum master may be the best new hire to make when implementing scrum.
Somebody who understands how scrum works, and is familiar with the issues that can arise, can smooth out the rough edges more easily than a person just getting up to speed with the process. It’s less important for a scrum master to be familiar with the type of work you’re doing than it is to have someone good at coaching people through the scrum process.
Tracking Effectiveness
Scrum is all about establishing a sustainable process that adds real value, and reviewing that process on a regular basis in order to make sure it’s producing the desired results. So why not use agile techniques to make sure scrum is working for your company?
One of the most useful techniques when implementing scrum in a new organization is to establish a baseline of productivity before scrum, and use that to measure the effectiveness of scrum. Where you establish that baseline, and how you measure it, are very subjective. Each organization has its own standards and productivity indicators.
For example, a web development team may judge itself based on the number of comparable features it’s able to add to a website. A mobile development agency may track how quickly they’re able to get from concept to implementation with a typical client. The ability to fix or address bugs may also be relevant. Ask around, and find out how the company currently judges its own performance. (You may be surprised at how little formal attention is paid to the matter.)
Before implementing scrum, pull together a representative sample of data about the performance of the organization without scrum. That way, you’ll have a comparison point to use when evaluating how effective scrum is, and reporting on it to interested parties. Keep updating the data as the team applies scrum and develops its agile abilities.
If you don’t see improvements, you can use the scrum process to raise the issue during a retrospective, and figure out what’s working, what isn’t, and how you can improve.
M. David GreenI'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.
