Q2 - One of the things which annoys me most in the agile community is when I hear people saying things like "That's not pure agile" when what they really mean is "That's not XP, like I read about in a book". For me Agile is about getting better and XP is just one of the ways to do so - albeit, a very good way! I recall that you received a bit of flak while we were reviewing your book because the focus was on XP, but the book title indicated it was about Agile in general. In retrospect I think you made the right choice and you've explained your reasoning very well in the book. Could you share your reasoning here?
Sure. We wanted to make a book that was very practical and useful, but we didn't want to fall into the trap of watering down agile development. In my consulting work, I've seen that when people pick and choose agile practices, they usually pick the ones they like (iterations, mostly, and sometimes test-driven development) and ignore the ones they don't like (pair programming, sitting together, cross-functional teams, evolutionary design).
That's not really that surprising, is it? People only choose practices they like--big insight! But the problem is that they're leaving out essential practices without realizing what they're missing. It's okay to leave a practice out, but you have to replace it with something, and they're not. Then they have trouble with technical debt and making reliable plans, but don't know why. After all, what do pair programming and on-site customers have to do with estimating? Everything, as it turns out.
Now, we agree that each team needs a customized approach to agile development. The problem is that teams new to agile make poor customization choices. So we decided to describe a single method, with a fairly limited set of choices, that will work well for most teams. (And we describe when it won't work well.) The idea is that the team can follow the method we describe, practice it a bunch, talk about their experiences, learn from it, and then use that experience to make good customization decisions. One of my favourite aspects of the book is our inclusion of a third part, designed to be read months after the rest of the book, that talks about customizing your agile method.
Comments