Book Review: The Art of Agile Development
This entry crossposted from Goodreads.
“The Art of Agile Development” by James Shore and Shane Warden is a book that is primarily focused on explaining Agile to people who want to adopt Agile software development practices for their team. The bulk of book is divided into sections based on a categorization on agile practices. There is a chapter on practices that help with thinking, one for collaborating, one for releasing, one for planning, and one for developing. In each of these chapters, there are sections devoted to a specific practice, such as “pair programming”. The sections describe how to do the specific practice, what benefits it offers, what challenges you might face when adopting the practice, and so on. Usually it also has some frequently asked questions about the practice (with answers, of course) and some suggestions for alternatives if you have a reason to not adopt the practice.
First and foremost, I need to mention my biggest criticism of the book. It has one of the most misleading titles I have ever seen. This is *NOT* a book on Agile. It is a book on XP, one of a few different flavors of Agile. The correct title for this book is “The Art of Agile Development using XP.” This is worth mentioning for a few reasons. First of all, XP’s practices are pretty hardcore. XP’s engineering practices are all extremely useful, but most of the time when a company or team resists Agile, it’s because they are resisting a typically XP practice, such as Test-Driven Development or Pair Programming. Personally, I’m a big fan of XP’s practices, but the fact of the matter is that any team that wishes to become Agile will likely find the most resistance if they try to adopt XP, so it seems misleading to sell the book as an introduction to Agile when it is, in fact, an introduction to XP.
That said, this is an excellent book on XP. All of XP’s practices are covered in just the right amount of detail – giving you enough information that you can adopt the practice, but requiring that you do additional research about the ones that interest or challenge you the most. This allows the book to be a pretty quick read in general, which is beneficial for a team wishing to adopt XP practices soon. This level of detail does have one disadvantage, though: by staying largely in the realm of hypotheticals and ideals, I often found myself thinking that the authors were being naive and idealistic about how easy some practices were to adopt. This made me somewhat more skeptical of the book than I would have been if more detail had been offered, but ultimately I felt the level of detail was right; I did my own research online about some of the things that challenged me.
One of the most annoying aspects of the book are the “examples” that are sometimes provided. Usually these examples provide a sample conversation between stakeholders as they illustrate the effectiveness of an XP practice. These little micro-plays are so exaggerated that it often felt like reading the script to a bad company training video. After a few, I found myself skipping them.
I learned an awful lot about XP practices, particularly Pair Programming, estimation techniques, and incremental design. I felt that a number of these topics were better covered in other books, but “The Art of Agile Development” seems like it is meant to be an introduction to XP. In fact, every section generally provided a list of books that covered the section topic in more detail, so I think the book is meant to tease you by design.
I recommend this book for a team that wishes to adopt XP as quickly as possible, but I cannot reiterate enough that this should be the first, not the last, XP book you buy if you wish to become an effective XP team.
Absolutely No Machete Juggling is a blog about software, programming, computers, and me. I'm a programmer working in Colorado, mostly with Java and Ruby. 
Bryan:
I’ve always been a bit suspect of full time pair programming. I get it and have used it and still do for certain situations. Things like a particularly hard problem, dealing with a new technology that you both need to learn, or a part of the code where it pays to have more than one person know it well because of hit-by-bus-syndrome, but the idea of doing it full time 40 hours a week has always struck me as a bit unnecessary.
Maybe part of it is because I never wanted to be that close to another fat guy for that much time, particularly if we had lunch at a place that… well… lends itself to flatulence in the afternoon.
You’ve eliminated the ‘fat guy’ concern from your list of reasons not to do it though, so maybe you don’t feel the same way.
20 February 2009, 8:06 amRod:
I didn’t start full-time pairing until working here. I was very skeptical at first as well, but I’ll be honest: the quality of the code produced by the pairs is far superior to the code produced by the same people when we aren’t pairing. To be honest, I’ve seen pair programming work so well that it actually seems kind of stupid to me now to not do it.
I’ll probably write a more detailed post about pairing someday.
20 February 2009, 3:02 pmBryan:
That’s surprising. Do you literally pair up with someone for 40 hours a week? The same person every week? Do neither of you ever fart?
20 February 2009, 4:11 pmRod:
No, you pair up for tasks. So, once all of the stories for the iteration have had concrete tasks assigned to them, people pair up to do them. So a dev and I might pick a specific task and work on it together. Two other devs pick another task. My pairing partner and I sit at a big 30 inch monitor and work on the task (just that task) together. Generally when you pair one person is the “driver” and one is the “navigator” so one person is implementing code and the other is thinking of design implications, refactoring opportunities, or the “next step” for the task. If you get stuck or pause or just want to switch, you pass the keyboard to the other person and switch roles.
When doing Test-Driven Development, one of the things we do is called “ping-pong pairing”. So the other developer will write a test, then make it compile but fail. Then he passes the keyboard to me. I implement the feature just enough to make the test pass, then I write another failing test and pass it back.
When the task is done and code is checked in (at least to the local git repo if not the big svn repo), the pair breaks up. Generally tasks only have 2 hour estimates (sometimes less) so you’re only pairing for the two hours. Then you pair up with someone else to work on another task. If a task is taking longer than expected, or the pair “goes dark” (meaning they aren’t talking) then you shuffle the pairings.
Between these tasks, you might go have lunch, or take a break from coding to watch a video on youtube at your desk, or check your RSS reader for a few minutes, or go take a walk, or go downstairs and play some ping pong or foosball. We take breaks often because getting away from the code for a few minutes helps keep a fresh perspective when you come back to the task. Physical activities like walking or playing ping pong help with blood circulation, which helps your brain.
It’s also nice to have an odd number of developers, which we do. This way, one person is working without pairing. Usually this person will work on a defect instead of a story, or they’ll work on a story where everyone understands what needs to be done for that part of the code. If you don’t feel like pairing, you volunteer to be the odd man out for a task.
In an 8 hour day, I’m probably pairing somewhere between 4 and 6 hours. It’s important to have a good setup for it – big monitors, comfy chairs, no corner desks (so that the devs can be side by side at the flat desk with the monitor between them).
I see pairing work so well every day that I consider my dev career prior to Rally to have consisted mostly of wasting time. When I think back to all the code I’ve written for a job, I’m annoyed at how much less efficient I was then since I wasn’t pairing, and how much better my code and my products would have been if I had paired on them full time.
When you have a second person working with you, you find that you try harder to code well. You’re far, far less likely to be willing to apply duct tape to a problem, because someone else is working with you and he or she is more likely to object to the duct tape. If two people approve a hack and implement it, it’s almost certainly because it’s the right approach given the time constraints. If one person sitting alone decides to pursue a hack, it’s far more likely to be a situation where there is a better approach.
Two people attacking a design problem together is far, far easier than one person doing it. Your partner will think of things you don’t, and vice versa. In a non-pairing environment, you can always call someone to a whiteboard to help you work through a design issue, but when you do that you’re only calling for help when you know you need it. The times when you need help and don’t know it go unaddressed – and yet despite the fact that you need help, I guarantee that you’re coding SOMETHING and checking it in. It’s almost certain to be shitty code. The amount of time you spend trying to figure out “what’s going on here” or “why isn’t this working the way I expect” is severely reduced. I’m talking hours of debugging that literally turn into seconds.
Pairing also helps a great deal with collective code ownership. I don’t feel like there are any realms of the code that “belong” to any team member. You don’t have a situation where one person is the “expert” on a part of the codebase, since that person worked with someone else when they wrote it, and everyone likely shuffled around while it was developed. EVERYONE has seen that part of the codebase before, which means EVERYONE feels comfortable refactoring or extending it. This enables the team to perform improvements to any part of the code whenever they are working, which leads to technical debt being paid off very quickly. I often find myself shocked at how good the quality of the code is that we write and that we’ve written before. The product is ENORMOUS in code size, easily the biggest I’ve ever worked on, but there are very few areas of code that I would consider bad at all, and all of those are the earliest parts of the code that were written (and were written without pairing or TDD).
Pairing fosters a collective unity that I haven’t seen anywhere else. There are obviously issues (like you mention, when people have burritos for lunch pairing in the afternoon can be a challenge; hygiene can sometimes be a serious issue as well, especially with all the Boulder hippie-types) and challenges, and there’s no denying that you’re producing fewer lines of code per day since only half your team is coding at any one point. I don’t consider that a bad thing, though (if you have two solutions that equally solve a problem, the solution with fewer lines of code is the superior one) because the QUALITY of the code that IS produced is so, so, so much higher.
Like I said, when I leave Rally (which I don’t see happening any time soon) if the next company doesn’t do pair programming, it’s going to be a tough adjustment to me. It would be like walking into a new company and finding out that all of the developers only use vi for everything and refuse to use IDEs. Sure you get the job done, but god damn you’re being inefficient about it. When people hiss at pairing because they can’t listen to headphones or don’t want to sit next to a fat guy, it sounds to my ears EXACTLY like someone complaining about IDEs being too complicated or how great vi is. Programming alone/vi is definitely a good way to get code written, but pairing/intellij is so much more effective that I just shake my head at all the time wasted not utilizing it.
21 February 2009, 9:06 amRod:
Holy shit that was a longer comment than I expected. I think I might move that into it’s own post.
21 February 2009, 9:07 amI Love Pair-Programming » Absolutely No Machete Juggling:
[...] the comments for my review of “The Art of Agile Development” an old colleague asked me a few questions about Pair-Programming, one of the key tenants of XP [...]
21 February 2009, 9:44 am