Shane Warden - Q6

Q6.  How did you two work together when writing?  Are you geographically close?  Oh, and how did the two of you meet?  And how and when did you decide to write a book together?

We both live in the Portland, Oregon metro area, somewhere between 25 and 40 minutes by car, depending on traffic.  It was easy to get together in person if we needed to, but usually we ended up in the same place for other reasons (hanging out with the guys on Thursday nights, for example).

We spent a couple of weeks coming up with a really great outline as part of the book proposal process, and then did it again when it was clear that the book needed to change dramatically from our original vision.  That gave us several small sections for each chapter, and we divided those between us equally, where Jim would write the first draft and then I'd edit it, and vice versa.  Occasionally we spent an afternoon in person making notes and plans for more complex sessions.  For example, we took a couple of days to spread notecards around my living room to figure out the third section of the book when we realized again that our original approach wasn't quite right.

We originally met... well, Jim's girlfriend at the time (now wife) called my roommate (at the time) to invite him to Jim's 30th birthday party a few years ago.  I tagged along.  Somehow he found out that I was a programmer and I found out that he was a consultant and programmer and that was a few months before I started working on the XP Pocket Guide.  He seemed like a perfect candidate to review it.
A couple of years after that, he had the idea of revising the pocket guide.  I resisted for a while, but it eventually made sense, at least until we looked at the outline and said "This isn't a pocket guide anymore."

Shane Warden - Q5

Q5: Can you tell me something odd, unexpected or just plain fascinating?  Something your friends know ...

Jim knows this, but not everyone does.  My undergraduate work was in music, specifically performance, with a smattering of history and almost zero mathematics or science.  It's not that I hate either math or science (I don't), but I decided against studying engineering the year before college and went the other direction to the arts and things you can't prove with the empirical method.

Once in a while I do wish that I'd taken a compilers class though.

Shane Warden Q4

Q4 - What has been your least satisfying Agile experience?

My last full-time software development job before I wrote the first book was underwhelming.  I had a couple of great co-workers, but our development process was... ambitious and underwhelming at the same time.  We used a mixture of Scrum and XP where we dutifully broke up all of our work into stories and engineering tasks, estimated the necessary work, let our tests drive our design and refactoring, and did pretty well at all of the development practices.  (I wish we'd paired more, but....)

The problem was that it was a very small consulting shop with lots of different small customers to satisfy, so we'd work on multiple projects every week. We did have a single grand project to work on, but only when we had had enough billable work for the month for us to spend time on a new product. Mostly we lacked a grand cohesive vision for our work, at least one that could predict what we should work on at a high-level on a weekly basis.

It wasn't an unpleasant experience -- I do remember favorably the experience of customizing a F/OSS point of sale system to the point where our largest customer could use it successfully in a month's time -- but it was unsatisfying because we had to spend so much time just staying in business that we didn't have as many opportunities to succeed at our business. Despite that, our software quality improved dramatically and we were able to meet the needs of our customers much better, thanks in part to much better development practices.

Shane Warden Q3

Q3 - What has been your most satisfying Agile experience?

I think this story's in the book, near the end.  A good friend of mine has been skeptical about agile development and testing and pair programming for many years.  She's actually a great reviewer of drafts and manuscripts because she's honest and analytical and asks good questions.

We sat down a couple of years ago to try pair programming for the first time. She had said "I don't think I'm ever going to understand this deeply unless I do this with someone who already knows how."  We spent a couple of hours ping-ponging back and forth, where I'd write a couple of lines of a test case and she'd write a couple of lines of code to make the test pass, then talk
about any refactorings, and then she'd write a test and I'd write some code. She didn't care for that at all.  She kept saying that it felt like we weren't making any progress, like we were taking baby steps and doing screechingly obvious things.

I won't say that that project was much of a success; we managed to get in about 90 minutes of pairing and could have gone another hour or two to start seeing really great results, but when she went back to work the next week, a handful of other people suddenly asked her to show them how pairing worked, and she had some experience to draw on.

Maybe you want a more successful experience.  I have to say that every time someone asks me to write some code and hands me a failing test, I feel plenty proud.

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.

Shane Warden Q1

Shane Warden is co-author of "The Art of Agile Development" and author of the Extreme Programming Pocket Guide (and others).

Q1- My first question is the same as I asked Jim,  I'm really enjoying your book.  I honestly think it is the best agile book I've read - and I've read a  good few of them.  Good job!  Can you tell me a bit about yourself - both personally and professionally?  What got you to the point where you could produce such a wonderful book?

Like Jim, I started programming when I was very young.  I must have been six or seven years old when I saw my first minicomputer, and I sat down, opened the manual, and typed the first program I came to.  (For some reason I ignored the line numbers in the book and typed the program directly, which didn't exactly work.  I suppose some of us learn to debug early.)

For a long time, nothing happened.  My undergraduate degree is in music, but I realized that I wanted something with more stable job prospects, so I returned to technology after I graduated.

During a stint as a system administrator as the dot com era heated up, I rediscovered programming and spent a lot of time reading the source code of free software projects, trying to improve my skills and discovering that successful projects had development processes very different from those I was seeing in our corporate IT group.  When I read the first XP book, I realized that there were important commonalities I'd seen in both, as well as practices that were missing (in particular, refactoring and test-driven development).

Through the next phase of my career (consultant, writer, software developer) I continued to explore the ideas of agility especially as they related to software quality.  I wrote a lot of tests, test frameworks, test tutorials, and testing advice, and I started to see how adopting even just one or two practices improved software development.  I also saw first-hand how adopting just one or two practices without considering their context made it difficult to succeed in software development.  (In particular, the lack of stakeholder support can doom almost any project.)

I wrote the XP Pocket Guide for O'Reilly, and in the year of research and writing (and admittedly arguing with Jim occasionally about how strict or lenient to be and how people were likely to pick and choose what they wanted to do) I really understood how everything fit together.  If you look at the Art of Agile Development, you'll notice that almost every practice we discuss has one or more contraindications.  Sometimes you really can't practice the practice precisely the way we recommend, and that's fine -- but you need something besides a tremendous amount of luck to fill in the gaps left behind.