Agile Thinkers

Welcome to AgileThinkers

Subscribe to this blog to learn more about the Agile communities many great thinkers.

Jim Shore - Q1

Jim Shore is my first guest on the AgileThinkers blog.  He's just co-authored a wonderful book "The Art of Agile Development" along with Shane Warden.  Shane's also going to answer the questions but I'll be posting them separately.  We're going to be giving a way a copy of the book shortly.

Q1.  Hi 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?

Thank you!  I should start by recognizing my coauthor, Shane Warden.  Shane and I collaborated closely on the book, so that's part of the reason it turned out so well.  Another reason would be the sheer amount of time and effort we put into it--I put nearly a year of full-time work into it myself, and that's not counting Shane's effort or the effort of all the people at O'Reilly.  I think our open review process helped a lot, too.  We put nearly every section of the book online and we got tons of feedback--over 1200 messages were posted to the reviewer list. Our best work started as drafts that got brutal beatings.

So: blood, sweat, and tears.  You know, the usual.

As for how I personally got here... you know, it's hard to say.  I've always liked reading and writing, even though I was born a hardcore geek.  (I placed in my first programming contest at age ten or eleven.  I think I would have come in first if my program had actually loaded off the tape drive.)  I actually did better on the English portion of the SATs than the Math portion.  I also wasted a huge amount of time on Fidonet and Usenet, talking about programming and (in retrospect) being a general pain in the ass.  I could spend hours composing careful explanations of why OS/2's Worksplace Shell was better than the Windows desktop.  I expended far more effort than the topics were worth, except for two things: I had fun, and I had a lot of practice writing and seeing how my writing was received.

So that's how I learned to write.  On the software side, the really core experience was when I had an AppleSoft BASIC program dissolve on me.  Applesoft BASIC was old-school: line numbers, two-letter variables, GOTO's, the works.  When I was in high school, the complexity of one of the programs I was writing overwhelmed my capacity to keep track of it all.  The program just fell apart in my brain.  Ever since, I've been fascinated with the human side of programming: if programming is partly an exercise in making the unbelievably complex comprehensible, how do we do that?  That led me to structured programming, then OOP, then software engineering texts, then Ward's Wiki, then XP and agile development, and now to questioning what makes software successful.  Along the way, I did the same thing I did with writing: I spent hours every day just playing with the ideas, writing programs, writing about programming, and so on.  (As well as my professional experience.)

So really, the answer is that, for most of my life, I've had a pretty single-minded dedication to writing, programming, and software development.  (The word you're looking for: Nerd.)  It's amazing I ever married, let alone reproduced.

Jim Shore - 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?

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.

Shane Warden Q1

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

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.

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 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 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.