Scrum & Agile Introduction: Chapter 1

What Are Scrum and Agile?

Scrum is an agile approach for developing innovative products and services. In most cases, an agile approach begins with a product backlog—a prioritized list of the features and other capabilities needed to develop a successful product. Guided by the product backlog, teams work on the most important or highest-priority items first. This ensures that if the project runs out of resources (e.g., time), the work left undone is of lower priority than the completed work.

In an agile approach like Scrum, the work itself is performed in short, timeboxed iterations, which usually last from a week to no more than a calendar month. During each iteration, a self-organizing cross-functional team does all of the work—such as designing, building, and testing—required to produce completed, working features: potentially shippable product increments.

When teams work with an agile approach like Scrum, the amount of work in the product backlog is typically more than can be completed in one iteration. So teams choose a smaller subset of work for each iteration. At the end of the iteration, the team gets feedback on the work they completed. If appropriate, they can release their potentially shippable product increment at the end of each iteration. As each iteration ends, the whole process begins anew until the project is complete.

Scrum's Origins, A Brief History

Scrum's origins date back to a 1986 Harvard Business Review paper entitled “The New New Product Development Game” (by Takeuchi and Nonaka). It gave rise to many of concepts that underlie Scrum.

Scrum is not an acronym, but rather a term borrowed from the sport of rugby, where it refers to a way of restarting a game after the ball has gone out of play. Takeuchi and Nonaka used this metaphor of a rugby approach to product development, where a cross-functional team of people works together to move the ball down the field as a unit.

The first Scrum software project took place in 1993. That project, led by Jeff Sutherland and his team at Easel Corporation, created the Scrum process for use on a software development project by combining concepts from the HBR article with concepts from object-oriented development, empirical process control, iterative and incremental development, software process and productivity research, and complex adaptive systems. Ken Schwaber published the first paper on Scrum at OOPSLA 1995, and a movement was born.

Though Scrum is most frequently used with software projects, its principles and concepts apply to many different types of work

Why Did I First Use Scrum?

I first used Scrum at Genomica Corporation (a bioinformatics company in Boulder, Colorado) in 2000. We chose Scrum for several reasons:

• Scrum works in a complex domain, where more was unknown than known.
• Scrum accomodates bleeding edge technology
• Scrum can handle the uncertainty of a brand new product
• Scrum helps teams rapidly test and eliminate/validate potential solutions
• Scrum balances upfront design with emergent design
• Scrum minimize errors by relying on cross-functional teams

Genomica Results with Scrum

Our results with Scrum were excellent. With Scrum, we required 1/10th the effort and achieved a 7x improvement in velocity. More importantly, we were able to delight our customers with the product we produced.

Can Scrum Help You?

Can Scrum help you? Well, imagine you gathered your developers and business people in a room and asked them, Are you happy with your development results? Do you deliver good value in a timely manner? What would they say?

More often than not, when teams are not using an agile approach like Scrum, the answer to both questions is a resounding no.

Companies that adopt Scrum, on the other hand, realize many benefits from Scrum:

• Delighted customers
• Improved return on investment
• Reduced costs
• Fast results
• Confidence to succeed in a complex world
• More joy (who wouldn't want that!)

You can read more about these benefits in the blog posting “Why Scrum? The 6 Very Real Benefits of Agile.”

When Not to Use Scrum

Scrum is not always the best fit for your organization. The Cynefin Framework (from David Snowden), can help you determine your current domain, and whether Scrum is a good match for your project and context:

• Complex Domain. Things are more unpredictable than they are predictable. Scrum is particularly well-suited for complex domains.
• Complicated Domain. There might be multiple correct answers, and expert diagnosis can figure it out. Scrum can certainly work in a complicated environments, but there might be expert-level approaches that are better tuned to the needs.
• Simple (Obvious) Domain. Cause and effect is obvious to everyone. Although Scrum could be used here, this is really a domain better suited to a well-defined process (perhaps something like waterfall).
• Chaotic Domain. We are in a crisis and need an immediate rapid response to re-establish some order. Scrum is not the best solution here.
• Disorder. We don't know which of the other domains we are in. Don't try to apply Scrum in this domain; instead, get out of this domain as fast as you can.

Scrum & Interrupt-Driven Work

Scrum may not be the best fit for highly interrupt-driven work. For that kind of development, I'd likely recommend another agile approach, such as Kanban, whose sweet spots are software maintenance and support.

Introduction to Agile & Scrum Summary

Scrum is not a silver bullet or a magic cure. Scrum can, however, enable you to embrace the change that accompany all complex product development efforts.

Although the Scrum framework is relatively simple, it would be a mistake to assume that Scrum is easy and painless to apply. One way to make it easier to adopt and agile process like Scrum is to get the proper training and coaching along the way. For that, consider on-site, whole team Scrum and agile training from Innolution.