Chapter 21

Ten Key Benefits of Scrum

IN THIS CHAPTER

Improving results

Reducing risk

Making reporting easy

Ensuring that projects are rewarding

This chapter lists ten important benefits that scrum provides to organizations, teams, products, and individuals.

To take advantage of scrum benefits, you need to trust in empiricism, find out more about the scrum framework by using it, and continually inspect and adapt your implementation of scrum.

Better Quality

Projects exist to accomplish a vision or goal. Scrum provides the framework for continual feedback and exposure to make sure that quality is as high as possible. When we talk about quality, we aren’t talking only about passing a defined set of tests. Building the right product and building it well involves interactions with customers and subject-matter experts. Scrum helps ensure quality through the following practices:

• Defining and elaborating on requirements just in time so that knowledge of product features is as relevant as possible.
• Incorporating daily testing and product owner feedback into the development process, allowing the development team to address issues while they’re fresh.
• Regular and continuous improvement of scrum team output (product or service) through sprint reviews with stakeholders.
• Conducting sprint retrospectives, allowing the scrum team to continuously improve such team-specific factors as processes, tools, relationships, and work environments.
• Completing work by using the definition of done that addresses development, testing, integration, and documentation for each backlog item.
• Reducing context switching through focusing on small iterations creates less errors and allows testing within a few days of the change.

Decreased Time to Market

Scrum has been proved to deliver value to customers 30 percent to 40 percent faster than traditional methods. This decrease in time is due to the following factors:

• Earlier initiation of development due to the fact that the up-front documentation phases of waterfall projects (which typically take months) are forgone by having a dedicated product owner embedded within the scrum team to progressively elaborate requirements just in time and provide real-time clarification.
• Highest-priority requirements are separated from lower-priority items. Incrementally delivering value to the customer means that the highest-value and highest-risk requirements (see Chapters 5 and 6) can be delivered before lower-value and lower-risk requirements. You don’t need to wait until the entire project is complete before releasing anything into the market. Build only the features that will be used and deliver the most business value.
• Functionality is swarmed to completion each sprint. At the end of every sprint, scrum teams produce working product and service increments that are shippable.

Increased Return on Investment

The decrease in time to market is one key reason why scrum projects realize higher return on investment (ROI). Because revenue and other targeted benefits start coming in sooner, earlier accumulation means higher total return over time, which is a basic tenet of net present value calculations (see Chapter 14). In addition to providing time-to-market benefits, scrum increases ROI through the following:

• Regular feedback through sprint reviews directly from stakeholders (including customers) enables course corrections early, which is less costly and time-consuming than later in the process.
• Fewer costly defects due to automation and up-front testing mean less wasted work and faster deployments.
• Costs of failure are reduced. If a scrum project is going to fail, it fails earlier and faster than a waterfall project would.

Higher Customer Satisfaction

Scrum teams are committed to producing products and services that satisfy customers. Scrum enables happier project sponsors by

• Collaborating with customers as partners and keeping customers involved and engaged throughout projects.
• Having a product owner who is an expert on product requirements and customer needs. (Chapters 2 through 6 discuss the product-owner role.)
• Keeping the product backlog updated and prioritized to respond quickly to change. (You can find out about the product backlog in Chapter 3.)
• Demonstrating working functionality to internal stakeholders and customers in every sprint review. (Chapter 6 shows you how to conduct a sprint review.)
• Delivering product to customers faster and more often with every release, rather than at the end.
• Incrementally funding projects instead of requiring large up-front commitments. (Chapter 14 tells you about incremental funding of projects.)

Higher Team Morale

Working with happy people who enjoy their jobs can be satisfying and rewarding. Self-management puts decisions that would normally be made by a manager or the organization into the hands of scrum team members. Scrum improves the morale of team members in these ways:

• Being part of a self-managing and self-organizing team allows people to be creative, innovative, and acknowledged for their expertise.
• Development teams may organize their team structure around people with specific work styles and personalities. Organization around work styles provides these benefits:
  • Allows team members to work the way they want to work
  • Encourages team members to expand their skills to fit into teams that they like
  • Increases team performance because people who do good work like to work together and naturally gravitate toward one another
• Scrum teams can make decisions tailored to provide balance between team members’ professional and personal lives.
• Having a peer relationship with a business representative (product owner) on the same team aligns technical and business priorities and breaks down organizational barriers.
• Having a scrum master who serves the scrum team removes impediments and shields the development team from external interferences.
• Focusing on sustainable work practices and cadence ensures that people don’t burn out from stress or overwork.
• Working cross-functionally allows development team members to learn new skills and to grow by teaching others.
• Encouraging a servant-leader approach assists scrum teams in self-management and actively avoiding command-and-control methods.
• Providing an environment of support and trust increases people’s overall motivation and morale.
• Having face-to-face conversations helps reduce the frustration of miscommunication.
• Ultimately, scrum teams can agree on rules about how they work to get the job done.

The idea of team customization allows scrum workplaces to have more diversity. Organizations with traditional management styles tend to have monolithic teams on which everyone follows the same rules. Scrum work environments are much like a salad bowl. As salads can have ingredients with wildly different tastes that make a delicious dish, scrum projects can have people on teams with diverse strengths that make great products.

Increased Collaboration and Ownership

When scrum teams take responsibility for projects and products, they can produce great results. Scrum teams collaborate and take ownership of quality and project performance through the following practices:

• Having the development team, the product owner, and the scrum master work closely together on a daily basis
• Conducting sprint planning meetings, allowing the development team to organize its work around informed business priorities
• Having daily scrum meetings in which development team members organize around work completed, future work, and roadblocks
• Conducting sprint reviews, in which the product owner outlines his prioritization decisions and the development team can demonstrate and discuss the product directly with stakeholders
• Conducting sprint retrospectives, allowing scrum team members to review past work and recommend better practices with every sprint
• Working in a co-located environment, allowing for instant communication and collaboration among development team members, the product owner, and the scrum master
• Making decisions by consensus, using techniques such as estimation poker and the fist of five

You can find out how development teams estimate effort for requirements, decompose requirements, and gain team consensus in Chapter 4. You can discover more about sprint planning and daily scrum meetings in Chapter 5. For more information about sprint reviews and retrospectives, check out Chapter 6.

More Relevant Metrics

The metrics that scrum teams use to estimate time and cost, measure project performance, and make project decisions are often more relevant, more visible, and more accurate than metrics of traditional projects. On scrum projects, metrics are more relevant because

• Those who will be doing the work, and no one else, provide effort estimates for project requirements.
• Timelines and budgets are based on each development team’s actual performance and capabilities.
• Using relative estimates, rather than hours or days, tailors estimated effort to an individual development team’s knowledge and capabilities.
• In less than one minute a day, developers can update the burndown chart, providing daily visibility of how the development team is progressing toward a sprint goal.
• At the end of every sprint, a product owner can compare the project’s actual cost (AC) plus the opportunity cost of future projects (OC) against the value that the current project is returning (V) to know when to terminate a project and begin a new one. You don’t need to wait until the end of a project to know what its value is. (See Chapter 5 for more on AC + OC > V as a termination trigger.)

You may notice that velocity is missing from this list. Velocity (a measure of development speed, as detailed in Chapter 4) is a postsprint fact, not a goal. It’s a metric, but only for the individual scrum team. Scrum teams can use this input to determine the amount of work that they can accomplish in future sprints, but it works only when it’s tailored to an individual team. The velocity of Team A has no bearing on the velocity of Team B. Also, velocity is great for measurement and trending, but it doesn’t work as a control mechanism. Trying to make a development team meet a certain velocity number only disrupts team performance and thwarts self-management.

If you’re interested in finding out more about relative estimating, check out Chapter 4. Chapter 22 shows you ten key metrics for scrum projects.

Improved Progress Visibility and Exposure

On scrum projects, every member of the project team (which includes the scrum team and stakeholders) has the opportunity to know how the project is going at any given time. Transparency and visibility make scrum an exposure model to help the project team accurately identify issues and more accurately predict how things will go as the project progresses. Scrum projects can provide a high level of progress visibility through the following:

• Placing a high value on open, honest communication among the scrum team, stakeholders, customers, and anyone else within an organization who wants to know about a project.
• Daily scrums that provide daily insight into the development team’s immediate progress and roadblocks.
• Daily scrums around task boards that enable developers to self-organize and identify the highest-priority tasks for the day.
• Using the information from daily scrum meetings, sprint burndown charts, and task boards to track progress for individual sprints.
• Using sprint retrospectives to identify what’s working well and what’s not to make action plans for improvement.
• Demonstrating accomplishments in sprint reviews. Anyone within an organization may attend a sprint review, even members of other scrum teams.

Improved project visibility can lead to greater project control and predictability, as described in the following sections.

Increased Project Control

Scrum teams have numerous opportunities to control project performance and make corrections as needed because of the following practices:

• Adjusting priorities throughout the project at each sprint interval rather than at major milestones allows the organization to have fixed-time and fixed-price projects while accommodating change.
• Embracing change allows the project team to react to outside factors such as market demand.
• Daily scrum coordination allows the scrum team to quickly address issues as they arise and swarm together to get requirements to done.
• Daily updates to sprint backlogs mean that sprint burndown charts accurately reflect sprint progress, giving the scrum team the opportunity to make changes the moment it sees problems.
• Face-to-face conversations remove roadblocks to communication and issue resolution.
• Sprint reviews let project stakeholders see working products and provide product owners the feedback they need to ensure that the project stays on track.
• Sprint retrospectives enable the scrum team to make informed course adjustments at the end of every sprint to enhance product quality, increase development team performance, and refine project processes.

The many opportunities to inspect and adapt throughout scrum projects allow all members of the project team — development team, product owner, scrum master, and stakeholders — to exercise control and ultimately create better products.

Reduced Risk

Scrum helps mitigate the risk of absolute project failure — spending large amounts of time and money with no return on investment — by delivering tangible product early and forcing scrum teams to fail early if they’re going to fail at all through the following practices:

• Having the highest-risk items done first provides the longest runway to work through issues or fail early and inexpensively.
• Developing in sprints, ensuring a short time between initial project investment and either failing fast or validating that a product or an approach will work.
• Having a working product increment starting with the very first sprint, so that even if a project gets terminated, the highest-value and highest-risk requirements have been developed and could be delivered to the customer if desired.
• Developing requirements to the definition of done in each sprint so that project sponsors have completed, usable features, regardless of what may happen with the project in the future.
• Providing constant feedback on products and processes through
  • Daily scrum meetings and constant development team communication through co-location
  • Regular clarification about requirements and review and acceptance of features by the product owner
  • Sprint reviews, with stakeholder and customer input, about completed product features
  • Sprint retrospectives, in which the development team discusses process improvement
  • Releases, in which the end user can see and react to new features on a regular basis