AoAD2 Chapter: How to Be Agile

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

Revised: July 12, 2021

How to Be Agile

How do you get from Agile’s conglomeration of ideas to actual, functioning Agile teams?

Practice. Lots and lots of practice.

Practicing Agile

Every team has a way of working—a process, or method—that they follow, even if it isn’t formally written down. The method reflects an underlying philosophy of software development, although that philosophy is rarely articulated, and isn’t necessarily self-consistent.

To be Agile, you need to change your process to reflect the Agile philosophy.

To be Agile, you need to change your process to reflect the Agile philosophy. It’s both easier and harder than it sounds. It’s easy because, in most cases, you can start with one of the many off-the-shelf Agile methods, such as the one in this book. It’s hard because you need to change your way of working, and that involves changing a lot of habits.

The Agile community calls those habits practices. Most of this book is dedicated to them. They’re things like planning sessions, automated builds, and stakeholder demos. Most have been around for decades. Agile methods combine them in unique ways, accentuating those parts that support the Agile philosophy, discarding the rest, and mixing in a few new ideas. The result is a lean, powerful, self-reinforcing package.

Agile practices often perform double- and triple-duty, solving multiple problems simultaneously and supporting each other in clever and surprising ways. You won’t truly understand how an Agile method works until you’ve seen it in action for a while.

As a result, although it’s tempting to customize your Agile method from the beginning, it’s best to start with a by-the-book approach. The practices that are the least familiar are the ones that are most tempting to cut, but they’re the ones you need most, if you’re really going to be Agile. They’re the ones that involve the biggest change in philosophy.

The Road to Mastery

Mastering the art of Agile development requires real-world experience using a specific, well-defined Agile method. Start with a by-the-book approach. Put it into practice—the whole thing—and spend several months refining your usage and understanding why it works. Then customize. Choose one of the rough edges, make an educated guess about what happens, and repeat.

This book is dedicated to that purpose. It’s a curated set of Agile practices that have been proven in the real world. To use it to master the art of Agile development—or simply to use Agile practices to be more successful—follow these steps:

  1. Choose a subset of Agile ideas to master. Chapter “Choose Your Agility” will help you decide.

  2. Use as many of the corresponding practices as you can. They’re described in parts 2-4. Agile practices are self-reinforcing, so it works best when you use them all together.

  3. Apply the practices rigorously and consistently. If a practice doesn’t work, try following the method more closely. Teams new to Agile often underapply the practices. Expect to take two or three months to start feeling comfortable with the practices and another two to six months for them to become second nature.

  4. As you become confident you’re applying the practices correctly—again, give it several months—start experimenting with changes. The practices in this book each include a discussion of why the practice works and how it can be changed. Every time you make a change, observe what happens and make further improvements.

  5. There is no last step. Agile software development is an ongoing process of learning and improvement. Never stop practicing, experimenting, and evolving.

Figure “Road to Mastery” illustrates the process. First, follow the rules; then break the rules; and finally, leave the rules behind.1

1This progression was inspired by Alistair Cockburn’s discussions of Shu-Ha-Ri, such as in [Cockburn 2001] (pp. 17-18).

A diagram with three sections, labelled “Follow the Rules (Apprentice),” “Break the Rules (Journeyman),” and “Ignore the Rules (Master).” Each section has double-headed arrows indicated that it’s possible to travel between each section. In the “Follow the Rules” section, a small flow chart starts by saying “Pick a method,” then shows an endless loop from “Follow it thoughtfully and rigorously” to “Reflect on your experiences” to “Study the method further” (and then back to “Follow it thoughtfully and rigorously”). In the “Break the Rules” section, a flow chart shows an endless loop from “Observe results. What could be better?

Figure 1. The road to mastery

How to Begin

Your first steps depend on what you want to accomplish. Are you joining an existing Agile team, introducing Agile to one or more teams, or improving the Agile teams you already have?

Joining an Agile Team

If you’re planning to join an existing Agile team, or just want to know more about how Agile works in practice, you can skip ahead to parts 2-4. Each part starts with a “day in the life” story that describes what Agile can look like. Every Agile team is different, so the team you join won’t be exactly the same, but the material in parts 2-4 will give you an idea of what to expect.

After reading the stories, skip around to the practices that interest you. Each is written to be a standalone reference. If your team uses a practice that isn’t in the table of contents, check the index—it may be under a different name.

Introducing Agile

If you’re helping your organization create Agile teams, or you want to convince them to do so, the remaining chapters in Part I will help you get started. Use the following checklists to stay organized.

First, make sure Agile is a good fit for your company:

  • Choose an approach to Agile that your organization can support. (See chapter “Choose Your Agility”.)

  • Determine what your organization needs to do for Agile to be successful. (See chapter “Invest in Agility”.)

  • Get buy-in to trying Agile. (See chapter “Invest in Change”.)

  • If you have multiple teams, decide how you’re going to scale. (See chapter “Scaling Agility”.)

In the weeks leading up to a team trying Agile:

  • Determine who the team’s coach or coaches will be, and identify at least one person who will act as the team’s product manager. (See “Whole Team” on page XX.)

  • Have the team’s product manager meet with the team’s executive sponsor and key stakeholders to create a draft purpose. (See “Purpose” on page XX.)

  • Ensure the team has a physical or virtual team room. (See “Team Room” on page XX.)

  • Schedule and conduct the team’s chartering session. (See “Planning Your Chartering Session” on page XX.)

  • Ask the team to review their new practices. Provide copies of this book for people to study on their own, suggest that they try some practices in their current work, and consider providing training for practices that seem challenging. (The practices are described in parts 2-4.)

When a team is ready to begin, take a deep breath and:

  • Have them plan their first week. (See “Your First Week” on page XX.)

Improving Existing Agile Teams

If you already have Agile teams and you want them to be better, your approach depends on what kinds of improvements you want to make.

If you’re interested in fine-tuning your team’s existing process, skip ahead to parts 2-4 and read the practices that interest you. If you want to make bigger improvements, the process is the same as introducing Agile to a team, except you can focus just on the things you want to change. Use the “Introducing Agile” checklists as a guide.

If Agile isn’t working for your organization, check out “Troubleshooting Guide” on page XX.

Applying Individual Agile Practices

Agile works best when you go all in, but if that’s not an option, you may be able to add some Agile practices to your existing process. These are good places to start:

  • Daily planning. If you struggle with frequent interruptions, try adopting day-long iterations (see “Task Planning” on page XX). Use the planning game (see “The Planning Game” on page XX) and your team’s measured capacity (see “Capacity” on page XX) to conduct a joint planning session at the beginning of each day, then defer all interruptions until the next day’s planning meeting. Be sure to have people estimate their own tasks.

  • Iterations. If you aren’t interrupted frequently, but you still want to improve your planning, try using weekly iterations (see “Task Planning” on page XX). In this case, you may also benefit from daily stand-up meetings (see “Stand-Up Meetings” on page XX) and regular stakeholder demos (see “Stakeholder Demos” on page XX). As time goes on, consider using index cards for planning and a big chart to show upcoming work, as described in “Visual Planning” on page XX.

  • Retrospectives. Frequent retrospectives (see “Retrospectives” on page XX) are an excellent way for your team to adapt and improve its process. The other practices in chapter “Improvement” may be helpful, too.

  • Ten-minute build. A fast, automated build will make a big difference to your quality of life, and it will open up improvements for other improvements as well. See “Zero Friction” on page XX for more.

  • Continuous integration. Continuous integration—the practice, not the tool—not only decreases integration problems, it also drives improvements to your build and tests. See “Continuous Integration” on page XX for details.

  • Test-driven development. Although test-driven development (see “Test-Driven Development” on page XX) isn’t as easy to adopt as the other practices, it’s very powerful. Test-driven development is the basis for reducing bugs, increasing development speed, improving your ability to refactor, and decreasing technical debt. It can take some time to master, so be patient.

Other practices in parts 2-4 could be useful, too. Agile practices have a lot of dependencies on each other, so be sure to pay attention to the “Allies” blocks and the “Prerequisites” section of each practice.

Don’t be disappointed if you have trouble applying individual practices. It’s faster and easier to choose a coherent subset and go all in. That’s what we’ll look at next.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.