A Brief Introduction to Scrum

Share this article

scrumthumb

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.

If you picked up this book to learn about applying scrum to your web or mobile development team, you may already be familiar with the terms scrum and agile. Perhaps you received this book from your company, or maybe you’ve been tasked with implementing an agile process in your own organization. Whatever the reason, it’s always useful to start with a clear, shared definition of the relevant terms.

Scrum is one of several techniques for managing product development organizations, lumped under the broad category of agile software development. Agile approaches are designed to support iterative, flexible, and sustainable methods for running a product engineering organization.

Among the various agile techniques, scrum is particularly well suited to the types of organizations that develop products such as websites and mobile software. The focus on developing cohesive, modular, measurable features that can be estimated relatively, tracked easily, and that may need to adapt quickly to changing market conditions makes scrum particularly appropriate for these types of projects.

Scrum encourages teams to work in a focused way for a limited period of time on a clearly defined set of features, understanding that the next set of features they may be asked to work on could be unpredictable because of changes in the marketplace, feedback from customers, or any number of factors. Scrum allows teams to develop an improved ability to estimate how much effort it will take to produce a new feature in a relative way, based on the work involved in features they’ve developed before. And scrum creates the opportunity for a team to reflect on the process and improve it regularly, bringing everybody’s feedback into play.

Warning: Don’t Confuse Merely Applying Scrum Terms with Actually Using Scrum

A familiar anti-pattern in non-agile organizations looking to mask their process problems is using the terminology of scrum as a labeling system on top of their waterfall techniques and tools. That can create confusion, and even negative associations among people who have seen these terms used incorrectly, and who mistakenly believe they’ve seen scrum in action.

As we go through this book, you’re going to find out more about how scrum functions. You’re going to be introduced to all of the aspects of scrum, including its rituals, its artifacts, and the roles that it creates for the people in an organization. We’re going to introduce you to a team of people working in a scrum environment, and show you how they adopted scrum in the first place, and how they adapted to it.

Before we get there, it’s worthwhile taking a moment to position scrum in its historical context. After all, scrum isn’t the only way to organize product development. Scrum came into existence right around the time that web development emerged on the engineering landscape, and it flourished as mobile technology became part of our daily lives. If you consider how scrum works, where it came from, and how we apply it, I think you’ll see that there might be a reason for that.

Note: Scrum’s Odd Vocabulary

The vocabulary of scrum is distinctive, and may sound odd. That’s intentional. Scrum uses terms such as ritual, artifact, and story to make it clear that these concepts are different from related ideas that may be encountered in other project management approaches.

A Brief History of Scrum

The original concept for scrum came out of Japan, introduced in 1986 as part of The New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka. They applied the concept of a scrum, taken from the team game rugby, to describe cross-functional team organization based around moving forward in a layered approach.

Their concepts were codified as the Scrum Methodology at a joint presentation in 1995 by Ken Schwaber and Jeff Sutherland, based on their personal experiences applying the concepts in their own organizations. This work inspired the 2001 book, Agile Software Development with Scrum, written by Schwaber and Mike Beedle.

At the time, the most prevalent approach for software development was called the waterfall model. Under the waterfall model, product development happens in stages, leading sequentially from requirements through design, implementation, and release. Until the 1990s, most software development was targeted at packaged software delivery for desktop computers. Such products had long development and release cycles. While waterfall is well-suited to products that have a long development trajectory, it doesn’t adapt well to situations where the product needs to change constantly in response to changing conditions.

In the mid-to-late 1990s, new publishing models emerged involving electronic media and the Internet. To support these, software development organizations had to incorporate more flexibility to adapt to changing browsers, tight media deadlines, and a variety of platforms with different requirements. Soon after that, the development of large monolithic software applications that lived on desktop computers gave way to smaller, more nimble apps that were delivered through mobile devices. A different approach was needed for developing these.

It isn’t a coincidence that agile approaches became codified, and quickly became popular, just as the marketplace was shifting from desktop software to web and mobile software.

Comparing Scrum and Waterfall

The slow cycle of waterfall development may still be appropriate in a world of hardware development, or even in gaming. These industries rely on long, stable markets, where many of the decisions are either repetitive, constrained by external resources, or need to be made far in advance because of the massive scale and expense of development.

Web and mobile technology moves too fast for a waterfall approach. By the time you’re done developing a solution to one problem and gathering feedback from users, the technology has already moved on, and you may have a very small window of opportunity to capitalize on your solution.

ch1-02

In a waterfall approach, the ideas for what needs to be developed may come from customers, from the executives, from market research, or from the imagination of people making the decisions and setting the budgets. Those ideas are passed on to product managers, who create a long product roadmap. They establish and collect requirements, write out classic product requirement documents, and then pass those requirements on to designers to create prototypes as wireframes and mockups. Those prototypes are passed on to an engineering team that implements those ideas, and produces a product that can finally be released to the marketplace. Until that product is released and put in the hands of customers, no feedback into the process is generated.

ch1-01

In an agile organization, guiding objectives and key performance indicators guide the process, but the team manages itself to meet those objectives. A product owner maintains the overall vision, and works with the scrum master to make sure that everyone on the team is clear about the objectives and how they’ll be measured. The input of the designers and the engineers is included at every stage in this process. Features are conceived and formulated into stories when the team is ready to work on them. No idea gets locked into a static product timeline.

The value to a company of hiring its own team of designers and engineers is that these people can bring their design thinking and their current technical knowledge to the table for the benefit of the organization’s own objectives. Designers should be evaluating the user experience and figuring out the best solutions to real customers’ problems, not decorating bad ideas to make them functional.

Getting engineers involved in ideation allows them to pull in the latest technology as early as possible, since they’re in the best position to know what’s technically feasible. The sooner the designers and engineers are brought into the planning process, the more agile development will be.

Scrum allows the full resources of the team to be applied when and where they can do the most good, and to work together in a sustainable and productive way. Instead of waiting until the entire cycle has completed before any data can be fed back into the system, ideas are generated at every stage, and encouraged to bubble to the surface at the end of each sprint. Total participation of the team in every stage of the process allows these ideas to feed into the objectives, and support the vision of the organization.

Warning: Mixing Scrum With Waterfall

ch1-03

While some organizations may claim to follow scrum, many of them actually follow a modified waterfall approach, using scrum techniques only for development. The rest of the organization structures itself around long-lived product timelines with static objectives. While that may be an improvement over pure waterfall, in that it allows the engineers to iterate and improve their process, it doesn’t take full advantage of the potential of scrum. Isolating scrum inside the development loop without inviting the learnings of the team into the planning and market testing process is a waste of resources, and a wasted opportunity.

Mixing a little scrum into an otherwise waterfall organization is usually not a good idea, since it can draw attention to the fundamental conflicts between the different approaches, and foster friction.

Frequently Asked Questions about Scrum

What is the role of a Scrum Master in a Scrum team?

The Scrum Master is a key role in a Scrum team. They act as a facilitator for the team and the product owner. Rather than manage the team, the Scrum Master works to assist both the team and product owner in the following ways: remove obstacles that are impeding the team’s progress, help the team become self-organizing, protect the team from outside distractions, ensure that the Scrum process is being followed, and help the team follow the Scrum practices and rules.

How does Scrum differ from traditional project management?

Traditional project management often involves a linear approach where the project scope is defined at the beginning and changes are minimally accommodated. On the other hand, Scrum embraces changes and allows for flexibility. It is an iterative and incremental approach that encourages feedback and allows for regular refinement of the project.

What is a Scrum Sprint and how long does it typically last?

A Scrum Sprint is a time-boxed period during which specific work has to be completed and made ready for review. Sprints typically last between one week to one month, with two weeks being the most common duration.

How is a product backlog used in Scrum?

The product backlog is a prioritized list of features, functions, requirements, enhancements, and fixes that need to be done in a project. It is the single source of requirements for any changes to be made to the product. The product owner is responsible for the product backlog, including its content, availability, and ordering.

What is the purpose of a daily Scrum meeting?

The daily Scrum meeting, also known as the daily stand-up, is a short meeting (usually 15 minutes) held to ensure the team is in sync on what was done the previous day, what is planned for the current day, and identify any blockers or issues.

How is the Scrum of Scrums technique useful?

The Scrum of Scrums is a technique used to scale Scrum up to large groups. In this method, multiple Scrum teams work together on a project. Each daily Scrum within a sub-team ends by designating one member as “ambassador” to participate in a daily meeting with ambassadors from other teams, called the Scrum of Scrums.

What is a burndown chart in Scrum?

A burndown chart is a graphical representation of work left to do versus time. It is a powerful tool to visualize the work completed by the team and the work remaining, helping to manage the progress of the project.

How does Scrum improve product development process?

Scrum improves product development by allowing for rapid feedback and adjustment. It promotes transparency, inspection, and adaptation, which can lead to a better product that meets the customer’s needs and expectations.

What is the role of a Product Owner in Scrum?

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. They manage the product backlog and ensure that everyone understands the items in the Product Backlog to the level needed.

How does Scrum manage changes in requirements?

In Scrum, changes in requirements are welcomed, even late in development. Scrum harnesses change for the customer’s competitive advantage. It allows the team to learn and adjust to the evolving business needs.

M. David GreenM. David Green
View Author

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.

Agilebook excerptproject managementscrum
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week