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.


Leave a Reply