Key Principle: Start with Scrum

MORE EFFECTIVE TEAMS   The next five chapters—from this chapter, “More Effective Agile Beginnings: Scrum,” through “More Effective Individuals and Interactions”—describe issues related to individuals and how collections of individuals are combined into teams. This chapter describes the most common Agile team structure, Scrum. The other chapters discuss Agile teams in general, Agile team culture, geographically distributed teams, and the individual and interaction skills that support effective Agile work.

MORE EFFECTIVE WORK   If you’re more interested in specific work practices than team dynamics, skip to the chapters beginning with “More Effective Agile Projects” and ending with "More Effective Agile Delivery."

MORE EFFECTIVE ORGANIZATIONS   If you’re more interested in top leadership issues, skip to the chapters beginning with “More Effective Agile Leadership” and ending with “More Effective Agile Adoptions.”

The primary challenge in the software industry for the 35 years I’ve been working in it, and probably longer, has been avoiding “code-and-fix development”—writing code without forethought or planning and then debugging it until it works. This ineffective development mode results in teams spending more than half their effort correcting defects they created earlier (McConnell 2004).

In the 1980s and 1990s, developers would say they were doing structured programming, but many were really doing code-and-fix and missing all the benefits of structured programming. In the 1990s and 2000s, developers would say they were doing object-oriented programming, but many were still doing code-and-fix and suffering the consequences. In the 2000s and 2010s, developers and teams are saying they were doing Agile development, but even with decades of history to warn them, many are still doing code-and-fix. The more things change, the more they stay the same!

A challenge created by Agile development is that it is explicitly short-term-oriented and code-focused, which makes it more difficult to tell whether teams are using Agile development practices effectively or are doing code-and-fix. A wall full of sticky notes doesn’t necessarily mean a team is taking an organized, effective approach to its work. Where Sequential approaches fail in bureaucracy, Agile approaches fail in anarchy.

One part of the mission of more effective Agile is protecting against Agile theater—teams using Agile cosmetics as a cover for code-and-fix.

Scrum is a good place to start.

If you do not already have an Agile implementation—or if you have an Agile implementation that is less effective than you want it to be—I recommend that you begin at the beginning. In Agile, that means Scrum. Scrum is the most prescriptive of the common Agile approaches. It has the largest ecosystem of books, training offerings, and tools. And there’s evidence that it works. David F. Rico’s comprehensive “study of studies” analysis found that the average ROI for Scrum implementations was 580% (Rico, 2009). The State of Scrum 2017–2018 report found that 84% of Agile adoptions included Scrum (Scrum Alliance, 2017).

What is Scrum?

Scrum is a lightweight but structured and disciplined workflow management approach for teams. Scrum doesn’t dictate specific technical practices. It defines how the work will flow through a team, and it dictates some specific roles and work-coordination practices that the team will use.

Scrum basics

If you’re familiar with Scrum basics, feel free to skip this section and move on to this chapter’s “Common Failure Modes in Scrum” or, if the failure modes are also familiar, to “Success Factors in Scrum.” The most canonical description of Scrum is normally considered to be The Scrum Guide (Schwaber, 2017). My company’s experience with Scrum mostly matches what’s described in the Guide, so the following description follows the November 2017 version of the Guide, except where noted.

Scrum is often summarized as having events (also known as meetings or ceremonies), roles, and artifacts that are bound together with a set of rules.

Scrum begins, conceptually, with a “product backlog,” which is created by the Product Owner (the person responsible for requirements in Scrum). The product backlog is a set of requirements, requirements-in-progress, features, functions, stories, enhancements, and fixes that the Scrum team might possibly deliver. Rather than providing a complete list of every possible requirement, the product backlog focuses on those requirements that are most important, that are most urgent, and that offer the highest ROI (return on investment).

The Scrum team performs its work in “sprints,” which are time-based iterations of 1–4 weeks. Sprints of 1–3 weeks usually work best. We have found that risks increase with longer sprints and improvement opportunities are more limited. Two-week sprints are by far the most common.

The terminology related to cadences can be a little confusing.

“Sprint” refers to a development iteration, which is nominally on a 1–3-week cadence.

“Deployment” refers to delivery to the user or customer, which can range from hourly in an online environment to yearly or longer for software embedded in hardware devices. Development work can be organized on a 1–3-week cadence regardless of whether deliveries are measured in hours, months, or years.

The meaning of “release” varies across contexts but most often refers to a larger scope of work than a sprint—a longer length of time or a larger collection of cohesive functionality. The figure below summarizes the flow of work on a Scrum project.