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; it’s a simple framework for clearly defining roles and organizing your actionable work so that you’re more effective in prioritizing work and more efficient in completing the work selected. Frameworks are less prescriptive than methodologies and provide appropriate amounts of flexibility for 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 tested, 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, with individuals and teams being given the freedom and tools required to get the job done. Lengthy progress reports, redundant meetings, and bloated management layers are nonexistent. If you just plain want to get the job done, scrum is the approach to use.

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, 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 scrumberg. Absolutely any project — large, small, tech, artistic, social, personal — can be productively placed within the scrum framework. 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 that we include and recommend are tried and tested — always with the clear understanding that these practices are outside of the basic scrum framework and are suggested for your consideration in your own situation.

We call this aggregation of scrum and vetted common practices the “roadmap to value.” This roadmap consists of seven stages that walk you through the vision stage of your project to the task level and back again in a continual process of inspection and adaptation. In other words, the stages help you see what you want to achieve and progressively break that vision into pieces through an efficient 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 seven stages. They show you the feasibility and 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 vision; work through planning; and then enter the cyclical world of sprints, reviews, and retrospectives.

FIGURE 1-1: The seven stages in the roadmap to value.

Scrum overview

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

Figure 1-2 shows an overview of scrum.

FIGURE 1-2: A simplified overview of the events and cycles of scrum.

The scrum process allows you to adapt quickly to changing market forces, technological constraints, regulations, new innovations, 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:

Requirement elaboration
Design
Development
Comprehensive testing
Integration
Documentation
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 requirement is accepted and therefore deemed shippable, you know that it works. Hope and guesswork are taken out of the equation and replaced by reality. You build your product increment by increment and showcase these tangible increments to stakeholders for feedback. This feedback generates new requirements 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. Don’t worry about efficiency until you figure out how to be effective. A very efficient development team working on the wrong things is a waste of time. A super-effective development 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 scrum project is, your scrum team will have similar characteristics. The sizes of development teams vary somewhat, but the roles remain the same. We discuss the specific roles in detail throughout this book. Figure 1-3 depicts a scrum team.

FIGURE 1-3: A scrum team has the development team at its core.

The heart of a scrum team is the development team — the folks who work together to create the product 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 development team can focus on developing a quality result.

Stakeholders aren’t scrum roles, but we include them in Figure 1-3 because they affect your project. Stakeholders can be internal or external. Marketing, legal, compliance team members, and especially customers are examples of stakeholders.

The scrum team itself has ultimate accountability. Team members figure out how to achieve their objectives within the environment in which they find themselves.

Governance

Scrum has three roles that are equal in status yet separate and independent in function:

Product owner: The what and the when (not how much)
Development team: The how and the how much
Scrum master: The process

Each role has a defined purpose directly designed to enhance the productivity of the team.

The creators of scrum didn’t happen devise these roles by chance, but through years of experience in working with all kinds of project teams. They saw good, bad, and ugly combinations, and found that the best results came from these three roles.

We prefer that each person in a scrum role be a full-time participant dedicated solely to the scrum team’s project. Don’t thrash your team members across several projects or use part-time players. How many major-league football teams have part-time players or those who play for several teams? None that are successful.

In scrum, no single person or role is above another. Everyone is a peer; no one is a boss or underling. We is the operative word rather than I.

Scrum framework

Scrum is a framework rather than a methodology. It provides clarity of responsibilities through roles, visibility through artifacts, and opportunities for inspection and adaptation through events. Within this structure, scrum is a container for other processes and tools that are appropriate for meeting the specific needs of a team, organization, or product.

A Scrum project has a 3-3-5 framework:

Three roles
Three artifacts
Five events

Each framework element fits within the scrum process, which is iterative and incremental. You incrementally create and improve your product, and you incrementally improve your process with this simple framework, as follows:

Roles
- Product owner
- Development team
- Scrum master
Artifacts
- Product backlog
- Sprint backlog
- Product increment
Events
- Sprint
- Sprint planning
- Daily scrum
- Sprint review
- Sprint retrospective

In the scrum world, artifacts are lists of work to be done or work products that have been done and are deemed shippable. Unlike archaeological artifacts, scrum artifacts aren’t set in stone. The scrum process requires you to continually review and assess artifacts to make sure that you’re digging in the right direction.

Each role, artifact, and event in scrum has a set purpose. You place your project in the scrum framework, moving through the seven stages of the roadmap to value (discussed earlier in this chapter), but the actual tools and techniques for accomplishing your goals are your own. Scrum doesn’t tell you how to achieve your goal; it merely provides a framework within which you can clearly see what you’re doing.

In concept, scrum is simple, but it can be complicated to implement. Scrum is much like getting into shape physically. In concept, you need to exercise more and take in fewer calories; in practice, the process can be complex.

Following are some common practices that complement scrum (extra elements in italics) and have produced incredible successes. Here, we’ve switched to a 5-6-7 framework:

Roles
- Product owner
- Development team
- Scrum master
- Stakeholders
- Scrum mentor
Artifacts
- Vision
- Product roadmap
- Product backlog
- Release plan
- Sprint backlog
- Product increment
Events
- Project planning
- Release planning
- Sprint
- Sprint planning
- Daily scrum
- Sprint review
- Sprint retrospective

The framework is still simple, but with additional roles, artifacts, and events designed to smooth the process. We discuss these roles, artifacts, and events in detail throughout the book.

Agile Roots

To understand scrum, it helps to dip into the broader world of agile techniques, because agile is the umbrella under which scrum resides.

Agile is a descriptor of approaches that align to the values of the Agile Manifesto and the 12 Agile Principles, which we outline in this section. Scrum is one agile approach.

For a thorough look at agile techniques, see Agile Project Management For Dummies, Second Edition, by Mark Layton and Steven Ostermiller (John Wiley & Sons, Inc.).

Three pillars of improvement

The empirical process control model sits securely on three pillars, which are common to agile and scrum:

Transparency
Inspection
Adaptation

Transparency

One distinguishing feature of agile techniques in general and scrum in particular is transparency. When channels of communication are clear and accessible, information is radiated throughout the organization. The entire organization knows what’s been done, what’s being worked on, and what’s left to work on and any impediments blocking the way. Right from the start, you produce real results that are tested and then approved or sent back for adjustments. The lag time between the start date and usable results is now days rather than months.

Transparency isn’t just about quickly seeing results. Everyone needs to look through the same lens. A framework (such as scrum) is shared, along with an agreed-on definition of done. Both observers and participants can see what’s being accomplished and interpret the results in a common language.

Inspection

As you discover in the following chapters, agile projects are broken into the smallest actionable chunks possible (commonly captured as user stories; see Chapter 3). Goals are set within fixed time frames: the sprint, the release, and the project. As each item is accomplished, it’s inspected to make sure that it works and does what the customer wants.

These inspections are done by people closest to the job — those who do the work and those who represent the customer. This process eliminates the time lag required for an outside person to complete this task, and it also means that any adjustments can be made quickly because the required knowledge is at hand.

Adaptation

If the inspection shows inaccuracies and/or inefficiencies — that is, if the feature doesn’t work right — an adaptation needs to be made. The adaptation should be made as soon as possible and before moving to the next actionable item on the to-do list. In other words, when you move on, you know that everything behind you is functioning properly.

Scrum allows inspections and adaptations to be accomplished immediately at the team and project levels in the form of reviews, retrospectives, and the daily scrum (see Chapters 6 and 7).

One Agile Manifesto

Scrum is a framework, not a by-the-numbers methodology. You still need to think and make choices. Part of the scrum framework’s benefit is that it allows you to make the decisions that are best for you, based on the reality in which you find yourself.

In 2001, 17 software and project experts agreed on four main values for their programming methodologies. These values are known as the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Manifesto © 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Even though the Agile Manifesto and principles were written by and for software experts, the values remain valid for whatever scrum project you embark upon. The Global Positioning System (GPS), for example, was designed by and for the military, but that it doesn’t mean that you can’t benefit from it when you drive to a new part of town.

For more information on the Agile Manifesto and its founders, visit http://agilemanifesto.org.

Twelve Agile Principles

The Agile Manifesto’s founders also agreed on 12 Agile Principles. Within your scrum project, you can use these principles to check that your framework is true to agile goals:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity — the art of maximizing the amount of work not done — is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The principles don’t change, but the tools and techniques to achieve them can.

Some of the principles are easier to implement than others. Consider principle 2. Maybe some parts of your company (or group or family) are open to change and new ideas. For them, scrum is natural, and they’re ready to get started. But other parts may be more resistant to change.

Or consider principle 6. Working face-to-face may not be possible in your project. With the Internet and globalization of workforces, you may have team members from Mumbai to Moscow to Miami. You could consider several solutions — such as Skype, Google Hangouts, and teleconferencing — but none of these solutions meets the intention of principle 6, and none is as good as face-to-face communication.

Your project is bound to have unique challenges. Don’t let a hiccup or a less-than-perfect scenario stop your project cold or cause it to limp along. Part of the fun of using scrum is working through issues to get to results. Stick with the 12 principles, and your projects will get quality results quickly.

THE MARSHMALLOW CHALLENGE

In 2010, author and speaker Tom Wujec gave a remarkable TED talk called The Marshmallow Challenge that discussed a design exercise devised by designer Peter Skillman. In this exercise, small groups of participants are given 18 minutes to build a free-standing structure with strange, minimal tools: 20 sticks of spaghetti, 1 yard of tape, 1 yard of string, and 1 marshmallow. Wujec began giving this test and studying the results. Most groups struggled to create anything high or reliable. Group members discussed options, planned a final design, and put it together only to find that because they’d left out some crucial aspect, the structure wouldn’t stand.

The groups who performed the worst were recent graduates of business schools. The groups who performed the best were kindergarteners, who consistently produced higher and more creative structures.

Wujec said that when business students work on an idea, they believe that only one “correct” solution exists, so they spend much of their time contemplating and planning for that approach. The children, however, started by playing with the tools. They learned what didn’t work and changed it; then they figured out what did work and kept it. In other words, they built prototypes all along the way.

A takeaway in the context of scrum is that humans’ natural state is inspection and adaptation. We want to do these things, but somewhere along the way, we get trained out of them. We’re taught that planning and coming up with one solution is the correct way to do things. But kindergarteners remind us that this way of thinking may be wrong.

Three platinum principles

We’ve worked with agile and scrum projects for more than a decade, consulted with dozens of companies, businesses, and not-for-profit organizations. We know how well these principles work because we’ve seen their value as we assisted in their implementation.

Here are three additional principles that have consistently improved the performance of the teams we’ve helped:

Resist formality.
Think and act as a team.
Visualize rather than write.

These principles can be applied to any project, not just software development. Part of the beauty of agile techniques is that you can use them for anything.

Resist formality

Have you ever seen a knockout presentation and wondered how much time someone spent putting it together? Don’t even think about doing that for a scrum project. You can scribble it on a flip chart, stick it on a wall where people will look at it, and then get back to creating value. If discussion is required, walk over to the concerned parties and have the discussion. Each iteration of the design process takes very little time to visualize. Focus your valuable time and effort on the product instead of stylized presentations.

Atos Origin produced independent research showing that the average corporate employee spends 40 percent of his or her working day on internal emails that add no business value whatsoever, which means the real work week doesn’t start until Wednesday.

Pageantry is too often mistaken for professionalism and progress. In scrum projects, you’re encouraged to communicate immediately, directly, and informally whenever you have a question and to work closely with your team members to increase efficiency and save time.

Avoid these unproductive traps:

Fancy, time-consuming presentations
Long and/or unfocused meetings
Tomes of documentation
Excessive effort justifying progress

Emphasize these productivity builders:

Be barely sufficient. In all things, the work should be barely sufficient to accomplish the goal. (Don’t mistake sufficiency for mediocrity. Sufficient is sufficient; more is wasteful, and problems often arise in that bloat. See Agile Principle 10 earlier in this chapter.)
Communicate frequently with all parties to reduce the need for extensive updates.
Communicate simply and directly. If you can speak to someone face to face, do so.

Figure out the simplest way to get what you need, always with the goal of delivering the highest-quality product.

Before long, your projects will evolve a scrum culture. As people become educated in the process and see the improved results, their buy-in for being barely sufficient will increase. So, bear through any initial pushback with education, patience, and consistency.

Think and act as a team

The heart of scrum is working as a team. The scrum team environment can at first be unsettling, however, because U.S. corporate culture encourages the mindset of the individual (“How well can I succeed in this environment so that I stand out and get the next promotion?”).

In scrum, the project survives or dies at the team level. By using each individual’s talent on a team, you take the project from average to hyperproductive. As Aristotle said, “The whole is greater than the sum of its parts.”

How do you create this team culture? The scrum framework itself emphasizes teamwork. Physical space, common goals, and collective ownership all scream “team.” Add the following practices to your scrum framework:

Eliminate work titles. No one owns areas of development; status is established by skills and contribution.
Pair team members to enhance cross-functionality and front-load quality assurance. Then frequently switch the pairings.
Always report team metrics, not individual or pairing metrics.

Visualize rather than write

On the whole, people are visual; they think pictorially and remember pictorially. Most kids like pictures — visual illustrations of text. Adults are no different. We’re likely to start reading a magazine by flipping through its images and then going back to read any articles that piqued our interest.

Pictures, diagrams, and graphs relay information instantly. Written reports require reader buy-in, which drops as the reports grow.

Twitter was interested in studying the effectiveness of tweets with photos versus those that were text only. It conducted a study using SHIFT Media Manager and came up with some interesting results. Users engaged five times more frequently when tweets included photos as opposed to text-only tweets. And the rate of retweets and replies with photos was doubled. However, the cost per engagement of photo tweets was half that of text-only tweets (Shift Newsroom, January 17, 2014).

When possible, encourage your team to present information visually, even if that means sketching a diagram on a whiteboard. If anybody doesn’t understand the diagram, he or she can ask about it. Changes can be made right there and then. Also, with current technology, simple graphs, charts, and models are at your fingertips.

The Five Scrum Values

Scrum is founded on five values that each member of the team uses to guide his or her decision-making:

Commitment
Focus
Openness
Respect
Courage

These values aren’t rocket science. Instead, they fall into that familiar category of common sense. Yet they’re critical to the successful implementation of scrum, so they deserve discussion here.

In the following sections, we look at each of these values more closely to show how vital they are within scrum projects.

Commitment

Scrum team members must be committed to success, and they must be willing to create realistic goals and stick to them. Everyone must participate. A scrum project is an “all in” situation in which everyone is part of a team, and everyone works together to meet the team’s commitments. Fortunately, the scrum model ensures that you have the authority and freedom to do just that.

At the core of scrum is an event called a sprint, which we cover in Chapter 5. A sprint requires clear goals set within fixed timeboxes. In this model, you break those goals into the smallest chunks of work possible so that you know what you’re getting into. You know what’s realistic, so you can set appropriate goals and meet your commitments.

Focus

Part of the magic of scrum is that it’s built around the concept of focus. Focus on a few things at a time. You will have a clear role and clear goals within that role. Your job is to use your role to contribute to achieving the goal. Every day, team members know what to focus on for that day to be successful, which is liberating.

You made your goals and commitments earlier. Focus on those goals and nothing else.

Don’t worry; contribute your best; be happy.

Openness

Everything in your project, and everyone else’s project, is transparent and available for inspection and improvement. The goals and progress of anyone involved in the project — you, your boss, your employees, your in-laws — are open and visible. Gone are the days of six-months-down-the-road surprises.

Fortunately, the basis of scrum is the agile pillars of empiricism: transparency, inspection, and adaptation. Information radiators (big, visible charts) and real-time intelligence allow for unfettered action. Most people aren’t used to this level of exposure. But after it catches on in your organization, they won’t have things any other way.

Respect

Each team member is selected for his or her strengths. Along with these strengths come weaknesses and opportunities to learn and grow. The golden rule within scrum is that each participant must respect everyone else.

Harmony is created by the synchronization of roles, which creates a development rhythm as the project progresses. If one person is out of tune for a bit, it’s in your best interest to help that person, because all team members are held accountable as a team.

People want to do good work; it’s in our wiring. If you seek the positive, you’ll find the positive. Likewise, if you seek the negative, you’ll find the negative. Respect is the burning ember of positivity.

Courage

Scrum is about change and honesty, and every idea you have will get challenged in a scrum model. No procedure is justified because you’ve always done things a certain way. Say goodbye to procedures you’ve done by habit and say hello to a process that’s built on what the team finds to be successful. Jacob Bronowski could have been speaking about the scrum model when he said

It is important that students bring a certain ragamuffin, barefoot irreverence to their studies; they are not here to worship what is known, but to question it.

Fiefdoms will be challenged. Rules will be tested. Routines will be broken. Improvements will happen. Change can be hard. Change takes courage.

Scrum takes courage.

The Basics of Scrum