The Art of Agile Development

The Art of Agile Development

The Art of Agile Development offers clear explanations of agile and extreme programming (XP) practices. At the same time, this book feels like it’s written out of order. Throughout the book, terms are used with the promise to define them later on. The reading experience is similar to a traffic jam: start, stop, start, stop. The authors are kind enough to provide page references in most cases, so the reader doesn’t have to refer to the index at each “defined later” moment. Perhaps paper is the wrong medium for this material. A hypertext version would be more reader-friendly.

That complaint aside, the authors do an excellent job of examining agile processes from both the technical (developer) and customer (business) perspectives. Sometimes technical writers feel the need to “dumb down” material for the suits. I didn’t get that impression here. Objections to radical ideas such as pair programming are addressed head-on. Clearly, the authors have dealt with these arguments in the real world.

The two most compelling topics for me: stories and technical debt. Customers tell developers what the software should do through stories. Each story is a one or two-line description written in customer-centric terms. The authors suggest writing stories on 3″ × 5″ index cards (one story per card) for easier discussion and prioritization. Lay the cards out on a large table, or a Post-It memo board. Argue Communicate with the customer. Achieve two-way understanding.

Technical debt is analogous to financial debt. Financial debt is incurred when we intend to pay for things later. The longer we take to pay, the more interest we pay. Technical debt is incurred when we intend to fix things later – all of the temporary patches that we create from time to time. The longer we wait to design/code things correctly, the further we fall in technical debt.

Even XP veterans (which I am not) will find value in the metaphors provided throughout the book. For example, how does a developer explain to management (or clients) that the team needs slack in time estimates? The authors offer this metaphor:

Imagine that the power cable for your workstation is just barely long enough to reach the wall receptacle. You can plug it in if you stretch it taut, but the slightest vibration will cause the plug to pop out of the wall and the power to go off. You’ll lose everything you were working on.

In this situation, I would move the computer closer to the outlet so that it could handle some minor bumps. Then I would tape the cord to the floor so people couldn’t trip over it.

Project plans are also too important to be disrupted by the lightest provocation. Like the power cord, they need slack.

Very visual. Well put. Overall, The Art of Agile Development is a worthy read.