My Foreword to “The Art of Agile Development”

When we wrote the Manifesto for Agile Software Development, our supporters were a small minority trying to change an industry. Now, twenty years later, “agile” is mainstream. But I write “agile” in scare quotes for a reason—lots of people say they are doing agile software development, indeed most genuinely believe that, but their actions bear little resemblance to the vision we shared two decades ago.

The truth is that working in an Agile way requires a web of interconnected practices spanning both the management and the technical execution of software development work. Many of these practices, particularly the technical ones, are not well understood or widely taught. Consequently, too many languish with a distorted view of what can be such an effective way to build software products.

James Shore was one of the early pioneers, riding the trail of Extreme Programming, a central pillar of the Agile movement. His first edition of this book was a favorite of mine: a handbook for teams to show them what they needed to know to execute an agile process properly. He later went on to work with Diana Larsen to create the Agile Fluency Model—a model that captured their experiences of the different ways people can develop their skill in using Agile approaches. In this model, a simple application of project management techniques, often referred to as a basic Scrum approach, provides some value by focusing on customer needs but lacks the technical skills you need to unlock the high productivity and reliability that many teams accomplish.

That point of view rightly drives the structure of this book, which puts the bulk of its weight on how to focus on value and how to deliver that value reliably. Focusing On Value means understanding the importance of potent teamwork, developing skills in adaptive planning, and close collaboration with the customers and users of the resulting software. Delivering Reliably concentrates on essential technical practices for testing, refactoring, design, and collaborative development. It recognizes the often counterintuitive notion that building software with a high internal quality decreases cost and increases the speed of getting code delivered. Combined with a DevOps culture and continuous delivery, this allows a high frequency of features to be rapidly put into production, which itself enables teams to learn more about what is valuable by observing how the software is used in practice.

I was fortunate 20 years ago to find a home at Thoughtworks, where our teams use these kinds of skills to help our clients build new software products and displace old legacies. Like James, we’ve found that Extreme Programming provided a firm foundation for our work, and we’ve applied these techniques with great success in the last two decades. I’m thus really happy to see that James has applied another decade of his coaching experience to revise his book. The result is a sound bedrock for learning these skills that have helped us so much. Like anything worthwhile, it will take time, and there will be frustration along the way. But this guidebook can help you through that journey—moving away from barren ceremonies to the vigor that we felt when James and I first used these techniques all those years ago.

---