You can't learn agile development by reading a book. But reading a few books, in parallel with training and trying out the techniques, helps a lot. These references constitute Relevance's recommended reading list for doing Agile development.
Our customers and students frequently ask us how they can learn more about how we work. We believe that Agile is not a process or method, but rather an attitude of constant reflection and improvement. Our favorite books and papers are about how to see, understand, and react to what's happening on our projects.
Almost all technical books are about particulars: particular processes, platforms, techniques, or tools. These three books, though, are about the essence: the essence of programming, projects, and people. Other books may offer more immediate, concrete recommendations for your current situation. However, these books are the foundation. If you understand them, everything else will make more sense, and you will be able to make more effective use of more specific recommendations. We don't see these three books becoming dated anytime soon.
The Pragmatic Programmer: From Journeyman to Master, by Andrew Hunt and David Thomas. If there's only one book that every working programmer should read, this is it. "PragProg," as it's known, is about the essence of programming: what programmers really do, and how to get better at it.
Agile Software Development: The Cooperative Game (Second Edition) by Alistair Cockburn. This book is an awesome exploration of how to think about process and software, and how to adapt your process to the needs of your organization and project. This book attempts to get to the bottom of how software projects work and the factors that make them succeed or fail.
Peopleware: Productive Projects and Teams (Second Edition) by Tom DeMarco and Timothy Lister. This book is aimed at software projects, but the focus is the human element: people and teams. Just as good and relevant today as when it was first published in 1987.
The Mythical Man-Month: Essays on Software Engineering (Anniversary Edition), by Fred Brooks. This is the all-time classic about software project management. It predates Agile methods by a long time, but it's still packed with wisdom and insight, including compelling analyses of some of the problems with traditional development processes.
Patterns of Enterprise Application Architecture by Martin Fowler. Yes, it's a patterns book, but don't let that scare you away. It discusses the patterns in use by Rails, Django, JEE, and the tradeoffs and reasoning behind them. Whatever architectural style you usually prefer, this book provides a valuable dose of context by explaining the situations where that style may not be appropriate, and showing you a number of useful alternatives.
Waltzing with Bears: Managing Risk on Software Projects by Tom DeMarco and Timothy Lister. Methodology failure is just one of many kinds of risk your projects face. Unfortunately, most Agile books don't give risk management the attention it deserves. This book explains how and why to take risk seriously and manage it carefully. It's an excellent primer on risk analysis and how to plan for failure. (It also includes one of our favorite quotes: "Risk management is project management for grownups.")
Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. We've known for years that a clean, expressive domain model that reflects the terminology of the problem domain makes every part of the development process easier. Eric Evans' book does a great job of explaining why that's true, and how to achieve a good domain model.
The Deadline: A Novel About Project Management by Tom DeMarco. Politics, intrigue, risk management, romance, kidnapping, schedule chicken, and spies. What more do you need to know?
I.M. Wright's Hard Code by Eric Brechner. This book deals specifically with the agile project manager role. Most importantly, it describes how to be a better manager in the "servant/master" model; rather than dictating to the team what to do, the manager sets direction and removes obstacles. That style works well in general, and especially well on an agile project. (Also, it has valuable tips on how to interact with other teams that are working on your project.)
Extreme Programming Explained: Embrace Change (Second Edition) by Kent Beck. A concise and clear explanation of traditional software methodologies and why they are broken, and why XP works and is better. The first edition is rather detailed and prescriptive, focused on developers. The second edition has a higher-level viewpoint and is a bit more relaxed.
The Buzz About Bees: Biology of a Superorganism by Jürgen Tautz. Some people are unsure about agile methods because they don't feel comfortable with the idea of emergent behavior (i.e., simple, localized rules that result in complex, apparently organized large-scale effects). This book is an excellent explanation of that idea, with many insights that apply to human organizations.
A Simple Model of Agile Software Processes –or– Extreme Programming Annealed by Glenn Vanderburg. This paper explains how a collection of focused practices, with very little overall coordination or up-front planning, can reliably lead to good results. Although the paper deals explicitly with Extreme Programming, the core idea—that agile processes consist of nested, optimized feedback loops at various scales—applies to other agile processes as well.
Agile Estimating and Planning by Mike Cohn. Agile teams still estimate costs, make plans, and set schedules. But we do it a bit differently. This book by Mike Cohn explains how an agile team sets plans, and how to change your thinking about plans and the ways that they help you.
Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. Kevlin Henney likes to say that some programmers with ten years of experience seem to have had the same year ten times. Some teams are like that, too. Experience isn't very valuable if you don't learn from it, and we've found that you can't just take that for granted. Retrospectives are wonderful for making sure you learn the right lessons from both your mistakes and your successes. This book can show you how.
Secrets of Consulting: A Guide to Giving and Getting Advice Successfully by Gerald Weinberg. Even if you're not a consultant, this book is well worth reading. It's all about how to see problems, identify solutions, and communicate successfully within an organization. It's about effecting change from a position of very little power. Who hasn't needed to do that?
The Back of the Napkin: Solving Problems and Selling Ideas with Pictures by Dan Roam. This book is about thinking visually about processes and problems. It's also a great way to learn about low-cost, high impact techniques like paper-prototyping and ad hoc data visualization.
The Passionate Programmer: Creating a Remarkable Career in Software Development by Chad Fowler. There's debate about whether agile development requires exceptional developers. But it's absolutely clear that having good developers helps a lot. Chad has written a wonderful book that can inspire you and others on your team to improve your craft and polish your skills. The entire team will benefit.
What Did You Say?: The Art of Giving and Receiving Feedback by Charles N. Seashore, Edith Whitfield Seashore, and Gerald M. Weinberg. Agile processes are all about efficient feedback, and feedback between and about people is an important part of that. But giving personal feedback is hard, and receiving it is even harder. This book can help you get better at giving feedback constructively and reacting to it positively. Unfortunately it's out of print, but of course used copies are available on Amazon or Alibris.
The resources listed here are great places to start. We also offer training on agile practices. But there's a lot of other relevant literature. In fact, as a couple of the examples here demonstrate, there's a lot we can learn about software development by reading about other fields, and even about other species. (Our friends the Pragmatic Programmers once gained valuable insights about software development by reading about training in the nursing profession and U.S. Marine Corps warfare doctrine. And we've been learning a lot lately by reading about music theory, cognition, the practice of medicine, and the history of bridge engineering.)
Furthermore, things are still changing. This bibliography will probably look very different in five years or so. (In fact, you can probably think of good resources we've missed. Tell us in the comments!) We learn new things about programming, and about software teams, every year. Sometimes it may seem like we have it all figured out, but more often we suspect that our whole industry is still fumbling in the dark, only gradually coming to understand the fundamentals of software development.
We intend to keep reading and discovering, and you should too. It takes a long time to get really good at software development, and there's always room to improve. Read at least a few books on software development each year. Also, seek out some good blogs or online magazines that discuss these topics. There is a rich and fascinating dialogue happening all the time in the community of software developers. You owe it to yourself—and your team, and your employer—to be a part of it!