This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!
This excerpt is copyright 2007, 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.
Every team has a way of working—a process, or method—that it follows, 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. This is 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:
Choose a subset of Agile ideas to master. The “Choose Your Agility” chapter will help you decide.
Use as many of the corresponding practices as you can. They’re described in Parts II through IV. Agile practices are self-reinforcing, so it works best when you use them all together.
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.
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.
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.1
1This progression was inspired by Alistair Cockburn’s discussions of Shu-Ha-Ri.
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 II through IV. 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 stories 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.
If you’re helping your organization create Agile teams, or you want to convince it 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 what your organization needs to do for Agile to be successful. (See the “Invest in Agility” chapter.)
Get buy-in to trying Agile. (See the “Invest in Change” chapter.)
If you have multiple teams, decide how you’re going to scale. (See the “Scaling Agility” chapter.)
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 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.)
Ensure the team has a physical or virtual team room. (See the “Team Room” practice.)
Schedule and conduct the team’s chartering session. (See the “Planning Your Chartering Session” sidebar.)
Ask the team to review its 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 II through IV.)
When a team is ready to begin, take a deep breath and:
Have team members plan their first week. (See the “Your First Week” section.)
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 II through IV 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 the “Troubleshooting Guide” sidebar.
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.
Fast feedback. A fast, automated build will make a big difference to your quality of life, and it will open up opportunities 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 II through IV 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.