Shane Warden Q2

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?

My very high level goal is to have better software and a better environment for people involved in creating and using software.  When I work on a project, I want a pleasant work experience with high morale, fulfilling work, and personal and professional satisfaction.  I think agile development helps achieve that, and I think XP is the most effective and cohesive approach within the agile universe, but if projects achieve organizational and personal success without strictly adhering to what one book or website or consultant or another says, I count that as success for the team.

What we're trying to do is achieve organizational success as well as personal success.  Jim and I tried to explain what we think is the best way for a team fairly new to agile development to start achieving that success.  Ultimately we believe that teams who follow our advice and eventually start changing the process to meet their own environments more effectively will have mastered agility, even if they end up doing certain things very differently from how they started.

We did (and do) feel very strongly that we have a responsibility to give the best advice we have, though, and we tried to do that even if it wasn't always fun or pleasant.  For example, a lot of people hate the idea of pair programming, and so I occasionally see a lot of agile advocates back away from recommending pair programming.  That's a mistake; it's a powerful practice that has many benefits you can't get in gestalt anywhere else, not to the same degree.

With that said, there are ways to make pair programming more difficult and ways to make it less difficult.  I believe we explored the discussion honestly, but our recommendation is that no matter how awkward it seems for the first few days, if you can, you should try it for at least a month and measure carefully how it affects your work.