Chapter 1

The Basics of Scrum

IN THIS CHAPTER

Seeing essential scrum principles

Identifying scrum values and structure

Scrum is an exposure framework based on empiricism, meaning people who employ the scrum framework gain knowledge from real-life experience and make decisions based on that experience. It’s a way of organizing your work — releasing a new smartphone, coordinating your daughter’s fifth-grade birthday party, or exposing whether your approach is generating intended results. If you need to get something done, scrum provides a structure for increased efficiency and more effective results.

Within scrum, common sense reigns. You focus on what can be done today with an eye toward breaking future work into manageable pieces. You can immediately see how well your effort is working, and when you find inefficiencies in your approach, scrum enables you to act on them by making adjustments with clarity and speed.

Although empirical process controls go back to the beginning of time in the arts, its modern-day usage stems from computer modeling. For example, in sculpting, you chisel away, check the results, make any adaptations necessary, and chisel away some more. The empirical exposure model means observing or experiencing actual results rather than simulating them based on research or a mathematical formula and then making decisions based on these experiences. In scrum, you break your work into actionable chunks, observing your results every step of the way. This approach allows you to immediately make the necessary changes to stay on track.

The Bird’s-Eye Basics

Scrum isn’t a methodology; it’s a new way of thinking. It isn’t a paint-by-numbers approach in which you end up with a product or outcome; it’s a simple framework for clearly defining accountabilities and organizing your actionable work so that you’re more effective in prioritizing and more efficient in completing the work selected. Frameworks are less prescriptive than methodologies and provide appropriate flexibility for the processes, structures, and tools that complement them. When this approach is used, you can clearly observe and adopt complementary methods and practices and quickly determine whether you’re making real, tangible progress. You create usable results within weeks, days, or (in some cases) hours.

Like the process of building a house brick by brick, scrum is an iterative, incremental approach. It gives you early empirical evidence of performance and quality. Roles are distinct and self-ruling, and individuals and teams are given the required autonomy and tools to get the job done. Lengthy progress reports, redundant meetings, and bloated management layers are nonexistent. Scrum is the approach to use if you just want to get the job done.

Scrum is a term that comes from the rough-and-tumble game of rugby. Huddles, or scrums, are formed with the forwards from one side interlocking their arms with their heads down and pushing against the forwards from the opposing team, who are also interlocking arms with their heads down. The ball is then thrown into the midst of this tightly condensed group of athletes. Although each team member plays a unique position, all team members play both attacking and defending roles and work together to move the ball down the field of play. Like rugby, scrum relies on talented people with varying responsibilities and domains working closely together in teams toward a common goal.

We want to emphasize — and have written two-thirds of this book on — an overlooked concept of scrum: its amazing versatility. People who know about scrum commonly think that it’s customized for software, information technology (IT), or tech use, but that’s just the tip of the iceberg. Applications for using scrum can be found everywhere, including large, small, tech, artistic, social, and even personal use. In Chapters 8 through 18, we show you how. Be forewarned! Scrum is such an addictive framework that you’ll be using it to coach your kid’s soccer team, plan your neighborhood watch, and even ratchet up your exercise routine.

Roadmap to value

Throughout this book, we discuss techniques some expert scrum practitioners apply as common practice extensions to scrum. These techniques complement, not replace, the scrum framework. We point out the differences when they occur. All the common practices we include and recommend are tried and tested — always with a clear understanding these practices are outside the basic scrum framework and are suggested for consideration in your own situations.

We call this aggregation of scrum and vetted common practices the “roadmap to value.” This roadmap consists of seven elements that walk you through the goal of your product to the task level and back again in a continual, iterative, and incremental process of inspection and adaptation. In other words, the roadmap to value helps you see what you want to achieve and progressively break that goal into pieces through an iterative cycle that leads to real results every day, week, and month.

You know that billion-dollar idea that’s been lurking in the back of your head for years? Follow the roadmap to value. It will show you the feasibility or fallacy of your idea and where to make your improvements — step by step, piece by piece.

Figure 1-1 shows a holistic view of the roadmap to value. This figure shows that you begin with the product goal; work through planning; and then enter the cyclical world of sprints, reviews, and retrospectives.

Scrum overview

The scrum process is simple and circular, with constant and transparent elements of inspection and adaptation. First, a deliberately ordered to-do list — called a product backlog — is created and maintained. Then top-priority items are selected for a fixed, regular period — called a sprint — during which the scrum team strives for a predetermined and mutually agreed upon sprint goal.

Figure 1-2 shows a scrum overview.

The scrum process allows you to adapt quickly to changing market forces, technological constraints, regulations, new innovations, family preferences, and almost anything else you can think of. The key is the ongoing process of working on the highest-priority items to completion. Each of the highest-priority items gets fully developed and tested through the following steps:

1. Requirement elaboration
2. Design
3. Development
4. Comprehensive testing
5. Integration
6. Documentation
7. Approval

The seven steps to fully build the scope of each requirement are performed for every item. Every requirement taken on during a sprint, no matter how small or large, is fully built, tested, and approved or rejected. When a backlog item is approved and deemed “releasable,” you know it works. Hope and guesswork are taken out of the equation and replaced by reality. You showcase these tangible results to stakeholders for feedback. This feedback generates new items that are placed in the product backlog and prioritized against existing known work.

What’s more important: efficiency or effectiveness? Hands down, it’s effectiveness — working on the right thing at the right time. Don’t worry about efficiency until you figure out how to be effective. A very efficient team working on the wrong things is a waste of time. A super-effective team, however, can easily learn efficiency. Always work on the right things first. As economist and management author Peter F. Drucker said, “There is nothing so useless as doing efficiently that which should not be done at all.”

The scrum cycle is run again and again. The constant flow of feedback and emphasis on developing only the highest-priority items helps you reflect what your customers are looking for, deliver it to them faster, and deliver it with higher quality.

Scrum teams

No matter what the scope of your product is, your scrum team will have similar characteristics. The sizes of teams vary somewhat, but the roles or accountabilities remain the same. We discuss the specific accountabilities in detail throughout this book. Figure 1-3 depicts a scrum team.

The developers are the heart of a scrum team — the folks who work together to create the product, service, or solution itself. They work directly with a product owner and scrum master, who align business and development priorities for the organization and eliminate distractions so that the developers can focus on “developing” a quality result.

Don’t get hung up on the term “developer,” thinking it refers to software development. Developers on a scrum team are simply the people with the skills needed to take an idea and “develop” it into something of value for the customer. Someone who writes software code is just one example of a scrum developer. There are many other skills a developer on a scrum team may possess, such as testing, writing, configuring, molding, waxing, teaching, designing, and so on. The word “developer” is used throughout this book to...