AoAD2 Chapter 3: 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.

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, 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. 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.

When you decide to follow an Agile method, it’s tempting to only use the practices that are similar to what you’re already doing and ignore the ones that are different. Avoid this temptation! The practices that are the least familiar are often the ones that involve the biggest change in philosophy. They’re the ones that your teams need the most, if they’re really going to be Agile.

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

So, although it’s tempting to customize your Agile method from the beginning, it’s best to start out 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 how to improve, observe what happens, and repeat.

The Road to Mastery

The core thesis of this book is that mastering the art of Agile development requires real-world experience using a specific, well-defined Agile method. The majority of this book—parts two through four—is dedicated to that purpose. It’s a curated set of Agile practices that have been proven in the real world.1

1The practices in this book are primarily based on Extreme Programming, but I’ve also taken inspiration from a wide corpus of Agile ideas. The main influences are Scrum, Kanban, Lean Software Development, the DevOps movement, and Lean Startup.

To master the art of Agile development—or simply to use Agile practices to be more successful—follow these steps:

  1. Choose an Agile method, such as the one in this book. Use as many of its practices as you can. Agile practices are self-reinforcing, so it works best when you use them all together.

  2. 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.

  3. 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.

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

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

2This 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 team, launching new teams, or improving the 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. The “Practices by Another Name” table can help you map the terminology your team uses to the terms used in this book. The “Practices by Skill Set” table will help you understand which practices are relevant to your skills.

Launching Agile Teams

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 the “Choose Your Agility” chapter.)

  • Determine which investments your organization will need to make. (See the “Invest in Agility” chapter.)

  • Get management buy-in to making those investments. (See the “Invest in Change” chapter.)

Next, create an environment where Agile will thrive:

  • Work with management to decide on an initial “best guess” purpose for each team. (See the “Establish a Learning-Friendly Purpose for Each Team” section. If you have multiple teams, see the “Scaling Agility” chapter.)

  • Determine who will be on each team and who their coaches will be. (See the “Choose or Create Agile Teams” section and the “Choose Agile Coaches” section.)

  • Get team member and stakeholder buy-in. (See the “Invest in Change” chapter.)

  • Make the investments. (See the “Invest in Agility” chapter.)

In the weeks leading up to a team trying Agile:

  • Identify at least one person who will act as the team’s product manager. (See the “Whole Team” practice.)

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

  • Confirm that the team has everyone they need to fulfill their purpose. (See the “Whole Team” practice.)

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

  • Schedule and conduct the team’s chartering session, with attention to logistics such as venue, travel, facilitation, and attendance. (See the “Planning Your Chartering Session” sidebar, the “Purpose” practice, the “Context” practice, and the “Alignment” practice.)

  • 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. See the “Practices by Skill Set” table to cross-reference people’s skills to the practices they need to know.)

When a team is ready to begin, they’ll take a deep breath and start applying the practices! Their first activity will be to plan their first week. See the “Task Planning” practice for details.

Improving Existing Agile Teams

If you’re interested in fine-tuning your team’s existing approach, skip ahead to parts 2-4 and read the practices that interest you.

If you want to make bigger improvements, continue reading with the next chapter. The process is similar to launching new Agile teams: Choose the zones that work for your organization, get people on board, make investments, and follow the road to mastery.

If Agile isn’t working for your organization, check out the “Troubleshooting Guide” sidebar, and consider “rebooting” your teams by following the “Launching Agile Teams” checklists.

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 the “Task Planning” practice). Use the planning game (see the “The Planning Game” practice) and your team’s measured capacity (see the “Capacity” practice) 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 the “Task Planning” practice). In this case, you may also benefit from daily stand-up meetings (see the “Stand Up Meetings” practice) and regular stakeholder demos (see the “Stakeholder Demos” practice). As time goes on, consider using index cards for planning and a big chart to show upcoming work, as described in the “Visual Planning” practice.

  • Retrospectives. Frequent retrospectives (see the “Retrospectives” practice) are an excellent way for your team to adapt and improve its process. The other practices in the “Improvement” chapter 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 the “Zero Friction” practice 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 the “Continuous Integration” practice for details.

  • Test-driven development. Although test-driven development (see the “Test-Driven Development” practice) 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 the topic of the next chapter.

Table 1. Practices by another name

Name You HeardName in This BookFound In
40-Hour WeekEnergized WorkThe “Energized Work” practice
BacklogRelease PlanThe “Visual Planning” practice
Backlog ItemsStoriesThe “Stories” practice
Daily ScrumStand-Up MeetingsThe “Stand-Up Meetings” practice
Daily Stand-UpStand-Up MeetingsThe “Stand-Up Meetings” practice
Definition of Done"Done Done"The “Done Done” practice
Ensemble ProgrammingMob ProgrammingThe “Mob Programming” practice
Iteration DemoStakeholder DemoThe “Stakeholder Demos” practice
Post-MortemsRetrospectivesThe “Retrospectives” practice
Product BacklogRelease PlanThe “Visual Planning” practice
Product OwnerProduct ManagerThe “Whole Team” practice
Program BacklogRelease PlanThe “Visual Planning” practice
Scrum MasterCoachThe “Whole Team” practice
Scrum TeamWhole TeamThe “Whole Team” practice
Sit TogetherTeam RoomThe “Team Room” practice
Sprint BacklogIteration PlanThe “Task Planning” practice
Sprint PlanningThe Planning GameThe “The Planning Game” practice
Sprint ReviewStakeholder DemoThe “Stakeholder Demos” practice
SprintsIterationsThe “Task Planning” practice
Sustainable PaceEnergized WorkThe “Energized Work” practice
Test-First ProgrammingTest-Driven DevelopmentThe “Test-Driven Development” practice
User StoriesStoriesThe “Stories” practice
VisionPurposeThe “Purpose” practice

Table 2. Practices by skill set

PracticeCustomer SkillsDevelopment SkillsCoaching Skills
Teamwork
Whole Team
Team Room
Safety
Purpose
Context
Alignment
Energized Work
Planning
Adaptive Planning
Visual Planning
The Planning Game
Stories
Incremental Requirements
Real Customer Involvement
Ownership
Visual Tracking
Capacity
Stand-Up Meetings
“Done Done”
Customer Examples
Informative Workspace
Accountability
Trust
Forecasting
Roadmaps
Stakeholder Demos
Reporting
Documentation
Improvement
Retrospectives
Team Dynamics
Circles and Soup
Collaboration
Collective Code Ownership
Pair Programming
Mob Programming
Development
Zero Friction
Test-Driven Development
Refactoring
Spike Solutions
Performance Optimization
Design
Simple Design
Reflective Design
Continuous Design
Evolutionary Design
Evolutionary Architecture
DevOps
Build for Production
Trunk-Based Development
Feature Toggles
Continuous Integration
Continuous Deployment
Quality
Slack
Customer Review
Ubiquitous Language
Exploratory Testing
Root-Cause Analysis
Sharpen the Saw
No Bugs
Optimizing
Autonomy
Discovery
Experimentation

XXX Add footer to above table: ✓ = Study this practice carefully. • = You could be involved with this practice.

XXX Update both tables when final set of practices is complete. Current entries are rough drafts and should be thought through more carefully.

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.