An Agile Bookshelf: 10 Must-Read Books

I did my best to select books I believe have something to offer for both those already doing agile software development and those who are curious about agile but remain skeptical. I'd like to think that even if you think "Agile" is a useless buzzword, you'll find something useful in each of these books. Quite simply, they are books that have changed the way I think about software development and how I practice it.

Without further ado (and in no particular order):

Agile Software Development: Principles, Patterns, and Practices
by Robert C. Martin

This book is more about good object-oriented design as it is about agile development practices. In fact, Martin is done with his overview of agile practices by page 84 (out of a total of 524 pages.) The rest of the book focuses on fundamental principles of OO design (using the definition of design from Jack Reeves' classic essay "What Is Software Design?".) This book confirmed my suspicions that there was a strong relationship between good OO design and agile practices. Good OO design gives your software the flexibility it needs to enable rapid response to change. Agile practices (particularly Test Driven Development) give you the feedback you need to keep your design clean... if you have the discipline to do it.

This book is best suited to developers who already have a few years of practical experience and a good understanding of the basics of object orientation. It will solidify your understanding of good OO practice, provide a few new insights, and give you a vocabulary to talk about both. I consider it a must-read for any serious professional working in an OO language.

Working Effectively With Legacy Code
by Michael Feathers

"Is your code easy to change? Can you get nearly instantaneous feedback when you do change it? Do you understand it? If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts."

So begins the back cover of this book. Feathers throws out the traditional (and vague) definition of legacy code and replaces it with this one: code without tests. Without tests, you don't know whether your software is getting better or worse when you make changes. Without rapid feedback after changes, quality suffers and time is wasted in tracking down defects further down the line (when it's much more expensive).

I meet lots of people who are curious about unit testing, but don't know where to get started with their current (untested) project. Feathers explains a number of techniques to get you existing code base under tests as safely and painlessly as possible. If you're interested in developer testing but feeling overwhelmed, or just wondering how to tame a big, messy code base, this is the book for you.

Test-Driven Development: By Example
by Kent Beck

When you get into the habit of writing a test before writing the code that will make it pass, some very interesting things start to happen. Beyond the benefits you get from unit testing after coding (a growing suite of regression tests, confidence your code works, etc.) you get several new benefits: better design (because you're forced to pay attention to it earlier in the process), tests that are more readable and less fragile, and a lot less time spent manually testing and debugging.

You also start spending a lot less time writing unnecessary code, since your tests are derived from actual requirements, and you don't write code unless you need it to make a test pass. The tests act as unambiguous, executable requirements. You've connected the dots between vague requirements and working code.

This book is an an hands-on tutorial of how to develop software test-first. If you're curious about test-first development, this is a great book to get you started.

Refactoring: Improving the Design of Existing Code
by Martin Fowler

No one gets design perfect on their first guess. You will always have a firmer understanding of the needs of your design after getting feedback from reality than you did at the beginning of a project. Besides that, the needs placed on the design will almost always change over time, so even if you guessed right, your design is going to change. If you don't make an explicit effort to change it, it will degrade over time as hacks are put in place to work around the current design in order to get new features in place.

The best way to change design is to consciously evolve it over time. Keep it clean; improve it a little bit every time you add a feature, and you won't hit that dead end where it's impossible to add new features and a total rewrite is the only option. This book shows you how to do that. It explains the link between good tests and refactoring, lists the 'code smells' you should keep an eye out for that may be a sign that your design isn't optimal, and gives some advice about which refactorings are most appropriate in each situation. This book is a must-read for anyone who is interested in software maintainability.

Agile Estimating and Planning
by Mike Cohn

This book takes the guesswork out of software estimation. In it, Cohn outlines an empirical estimation process; that is, one based on evidence rather than predictions. Rather than just take a best guess at the beginning of a project (when we have the least information of any point in the project's lifetime), he uses early measurements of the work capacity (or 'velocity', in agile terms) of the team to determine the real pace at which the team can deliver working software. This gives management critical information early (allowing them to adjust scope to meet a given deadline, or adjust the deadline to meet a given scope). This puts an end to the trap customers, management, and developers so often find themselves in: not realizing until very near the deadline that you're way off schedule.

If you've ever been surprised by a schedule slip, or want more predictability in your software development process, read this book.

The Goal
by Eliyahu Goldratt

This is the business novel about The Theory of Constraints, a set of principles for continuously improving operational efficiency. Although the specific example in the book is industrial, the principles also apply to software development.

The book is a fun and easy read, but contains a number of dramatic insights into what productivity really is, how it can be related to everyday tasks, and how it can be improved. I don't want to elaborate and ruin the story for you. I'll just say this: I can practically guarantee you will discover unnoticed inefficiencies in your software development process after reading this book.

Fearless Change: Patterns for Introducing New Ideas
by Mary Lynn Manns and Linda Rising

Very few software professionals work alone. So chances are, if you have a brilliant idea about how to work more effectively (agile or otherwise), you're going to need to convince others to do it too. Usually, the higher-leverage the idea is, the more people you need to convince. Unfortunately, people often instinctively resist change, and most of us don't have a natural gift for making people more comfortable with it. That's where this book comes in.

This book is about introducing new ideas to established organizations. The first half of the book explains the nature of the task, your role as a change agent, and the challenges you'll face. The second half is a catalog of patterns you can use to face those challenges.

Introducing new ideas to an any large organization is never easy. If you've ever thought of a more effective way to work, but had trouble convincing others to adopt it, this book can help.

Waltzing with Bears: Managing Risk on Software Projects
by Tom DeMarco and Timothy Lister

Risk management is possibly the only element of management that cannot be delegated; at the very least you have to manage the risks of delegating risk management. Neglecting sound risk management principles and practices can be an extremely costly mistake. Unfortunately, risk management is done extremely poorly, or not done at all, in many development organizations.

In this book, DeMarco and Lister explain why risk management is so important, why it is often done so poorly, and how to do it effectively. It's short and conversational, but packed with valuable ideas. I recommend this to anyone who doesn't want another late, over-budget, or otherwise failed project on their resume.

Crucial Conversations
by Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler

A 'crucial conversation' is any conversation in which opinions vary, stakes are high, and emotions run strong. They have long lasting effects. They can transform relationships, both for the good and the bad. They are the most important conversations we have, and have long-lasting effects. Unfortunately, most of us handle crucial conversations poorly.

In this book, the authors provide tools for getting better results from crucial conversations. They explain how to recognize when a conversation turns crucial, how to focus on your real goals (rather than your transient emotional goals, like your sudden urge to prove the other person wrong), how to curb your own defensive/aggressive reactions, how to share information without making others defensive, and how to create conditions of safety that allow the other party to share information freely.

Unless you work by yourself, you need these skills to work effectively. (And they're handy skills to have for your life outside work, too.)

Peopleware
by Tom DeMarco and Timothy Lister

This book questions the application of standard management theory to knowledge workers. They show how this misapplication causes many of the problems perennially faced by managers of software professionals, and outline some new management principles specific to knowledge workers, backed by years of research from the authors' work with dozens of software organizations. Even better, they point out where management is missing out on opportunities not just to avoid problems, but to actively develop highly effective, productive teams.

Peopleware is a short read full of interesting ideas. Chances are you'll strongly disagree with some of the ideas in this book, consider some of the others common sense, and pick up a half dozen new insights along the way. I'd recommend this not just to managers at all levels, but to anyone who works on a team as well.