XP: My Greatest Misses, 2000-2009
Instead of my greatest hits, this is a collection of my greatest misses: ten big mistakes that I made early in my career. I believe that I’ve learned from these mistakes. Perhaps you can relate to some of them. Perhaps you can learn from them, too.
1. XP is better—you’re stupid not to try it!
IBM Toronto Lab, 2000
Shortly after reading Extreme Programming Installed (Ann Anderson, Chet Hendrickson, Ron Jeffries), I begin tinkering with JUnit in my work. It didn’t take long after that to find sites like extremeprogramming.org, xprogramming.com, xp123.com, Ward’s Wiki and to start posting articles like Ron Jeffries’ “We’ll Try” outside my office. I spent considerable time spreading each bit of new knowledge I gained about XP as theory, usually seconds after I learned it myself. I’m sure I drove my office mate crazy.
This premature advertisement turned off many more people than I might have inspired, mostly because I was unwilling to temper my enthusiasm. It didn’t take long before people branded me a zealot, which robbed me of a tremendous amount of credibility around the office. It turns out that running up and down the halls, waving my hands and pronouncing XP as the greatest thing since sliced bread did not make for an effective strategy for bringing about change. Once I’d become an XP zealot, the natural next steps involved denigrating other ways of building software, as well as wondering aloud why people insisted on doing things “the wrong way”. This did not win friends, nor did it influence people. While I might have gained a few converts, I don’t even know how many more people I alienated. This signaled the beginning of the end for me at IBM, although it also began my development as a change agent.
2. People will want to know why you’ve improved
IBM Toronto Lab, 2000
Since my information campaign was not working, I decided to try the strong, silent approach. I figured that if I simply performed well-but-quietly, then people would soon begin to take notice and ask me for my secret. I had prepared many speeches extolling the virtues of test-driven development, incremental design, refactoring, adaptive planning… but, alas, no-one ever asked. It seems that neither extreme guarantees attention: yelling loudly and saying nothing look like they achieve the same results. I needed to learn about how to expose people to new ideas effectively, which led me to read works like Jerry Weinberg’s The Secrets of Consulting and Roger Fisher, William L. Ury, and Bruce Patton’s Getting to Yes. I took advantage of my remaining time at IBM to sign up for a course on negotiation skills that introduced me to better ways to be heard and better ways to understand the motivations of others. I learned a lot more about this about five years later.
3. I’m much more valuable teaching!
IBM Toronto Lab, 2001
It didn’t take long at all for me to see that without some help from my department, I wouldn’t reach the people I needed to reach in order to spread XP throughout IBM. It seemed quite logical to approach my manager and ask her about moving out of the full-time programmer role into a teaching role. I thought I reasoned pretty soundly: I would provide much more value to the organization if I made the other 400 programmers 5% better that I would if I even doubled my own contribution as a programmer. Obviously. Never mind that I was only 27 years old; never mind that I’d spent the previous 12 months as a raving lunatic, losing credibility with my would-be students; never mind I had no evidence that these XP practices would improve any programmer’s contribution by any measurable amount; never mind that change on the scale of 400 people poses a difficult problem even when everyone is enthusiastic about the change. Those things didn’t matter! They were wasting my talent!
Within six months, I left IBM, lured away by the promise of an XParadise governed by a trusted colleague.
4. If XP fails, we’ll never get to do it
Toyota Canada, 2002
Who could focus on the project when our entire professional future was at stake?! We spent hours and hours, the three of us pro-XP members of our brand-new team at Toyota, trying to figure out how to guarantee that XP would succeed on our project. (I now see a clue in that sentence.) We owed it to the movement: if XP succeeded here, then it would flower at Toyota, creating dozens of opportunities for other pro-XP people to find safe haven at Toyota. What better place to help XP grow and thrive than at an outpost of the very Mecca of Lean Manufacturing—the birthplace of Toyota Production System! Piece of cake.
Things started well. I shipped code my first day, which I’d never experienced before. After two weeks, when I gave my opinion at a retrospective, I told them that how I felt like I’d been working on a real team for the first time. For two months, everything went well, in spite of the fact we’d been focusing on demonstrating the power and greatness of XP, rather than completing the project. After a while, it became apparent that we’d started steamrolling other members of the team, pushing practices on them they simply didn’t like. We managed to live with the team member who would lean back in her chair, arms crossed, clearly disinterested, whenever she should have been navigating while pairing.1 We figured pairing would help the one member of the team who couldn’t write a line of Java on his own (not an exaggeration, he only knew COBOL)—the person who only joined the team because he saw it as a stepping-stone towards climbing the managerial ranks. As these real project and people problems arose, we saw it as an opportunity to showcase the effectiveness of the XP practices. Surely this would be XP’s shining moment! It will solve these problems for us!
The lesson is clear: there is no silver bullet.
5. We need to increase velocity
Toyota Canada, 2002
Several months into our XParadise project, things began to go downhill as schedule pressure mounted. Since we had promoted XP as the solution to all our problems, we knew that if we failed, XP would take much of the blame, that would put our futures as XP practitioners in peril, so we couldn’t let that happen. Looking back, this subtly shifted our thinking: we stopped looking for ways to do better and started looking for ways to look better. We considered outrageous things like multiplying our story point scale by 5 to make our progress look more impressive. It became like alchemy: bending, pouring, shaping the plan until it looked like the project might just ship on time. We tried to use velocity as an accelerator pedal, rather than as feedback about our progress or to plan to capacity. We focused on how we measure velocity to help us look faster, rather than using the information to look for other, more obvious reasons why went so slowly. Looking back, even the desire to go faster is laughable to me now. “Sooner, Not Faster”
More than anything else, we learned on this project that XP by itself solves very few interesting problems. It reminded us that every problem centers around people, and if we’d simply paid more attention to the people problems, then we could have saved a tremendous amount of energy for the project, rather than spending it on how to position the project as a poster child for the greatness of XP.
6. I don’t need facts to build an argument
Mailing Lists, 2001-2004
I love mailing lists. I spent years hanging out at Yahoo! groups like extremeprogramming, testdrivendevelopment, junit, refactoring and its cousins. In the early days, I spent a lot of time there, writing about all the things I didn’t get to do in my professional life. I considered myself a pretty logical person, so I figured that if I argued well with solid reasoning, that would suffice to influence people positively and hold the anti-XP camp at bay. Examining the archives, it took only five weeks (over the Christmas break, too, so closer to only four) to go from asking my first question to giving my first logical-sounding, unfounded, opinion-based answer. While this helped me practise answering questions, a key skill any consultant needs, it also encouraged people to perceive me as an XP zealot. Worse, even though I thought I was doing a good thing back then by focusing on reasoning well, I ignored the notion that without experience, my arguments carried little weight. That didn’t stop me from stepping outside my experience to answer questions, but I did seem to become little more than an XP fanboy, whom people perhaps ought to have ignored. Eventually I began to understand the value of sharing experience and of highlighting the differences between my experience and my opinion. This way I began to build, not erode, credibility!
7. Starve the BA; feed the programmer
Client site, 2005
Armed now with plenty of experience as a test-driven development practitioner and as a decent object-oriented designer, I began to apply my wisdom to the bigger problems of teams. I spent weeks coaching a team of superstar programmers and business analysts working from the hypothesis that if the programmers can’t deliver, it doesn’t matter what they work on. As a result, I focused all my energy and advice on the programmers: pairing, test-driven development, object-oriented design, automated delivery from day one, and most importantly, I demanded stories optimized for the programmers. I had seen programmers cling to bad habits as a result of too-big stories and I refused to make that mistake again this time. For a while, things went well: the programmers completed stories in a day, even while learning how to write tests, when to refactor, how to pair more effectively and how to communicate their progress to one another. After a few weeks, though, the lead business analyst had to speak up.
He asked me about the size of the stories: he understood the value of feeding the programmers in teeny-tiny bites in order to get valuable information about progress, but he found it increasingly difficult to keep track of all these thin slices of features. He couldn’t see how they could possibly add up to demonstrable business value. It hit me like a boot to the head: I had forgot about the Whole Team, and while I did it with noble intentions, I signaled the business analysts that they didn’t matter, further driving a wedge between them and the programmers. I thank them for bringing this up, otherwise I would have merrily gone along, pampering the programmers and letting the business analysts eat cake. Their relationship would have only worsened. By the time the programmers could delivery quickly enough for me to turn my attention to the business analysts, they might already have walked out, mentally if not physically. This experience reminded me to treat everyone well, and not just the people I identify with most.
8. Ignore the schedule, with or without the business’ permission
Client site, 2006
Kent Beck once advised us to program as though we had all the time in the world. As I understand it, he meant to advise us to keep searching for good solutions, rather than give in to cutting corners. His advice applies to designs, practices, processes, all of it: the corner you cut today will cut you tomorrow. I got to work with a team that capitulated to schedule pressure: some of the team members wanted to abandon entire practices, others wanted to abandon XP altogether, and as panic set in, I decided we should throw the clock away. Some of the team members got it, but others did not. Something I thought would unite them turned out to divide them further—wounds that I don’t believe have necessarily healed even by now [probably about 2008]. I gave in to my own fear and lack of trust towards the managers, believing they would never consent to such a thing, then hoping that the guerrilla, “stick it to the man” nature of the idea would bring the team closer together. I failed. This experience reminded me of two important ideas: first, dishonesty only takes you so far; second, if you beat a dog down for long enough, he’ll stop getting up. These team members had lived in fear of the schedule for such a long time that telling them to throw away the clock did nothing more than tell them to prepare for the next beating. Without genuine endorsement from a manager they trust, they would simply not take ignoring the schedule seriously enough to take time to learn, practice and grow. I now see it as naive to have expected them to do otherwise.
9. Just Do It My Way
Client site, 2006
It seems like a part of my personality: if you don’t complain, then I’ll interpret that as happiness. At the beginning of the courses I teach, I let the participants know that I need them to speak up when they need help, need me to slow down, need me to speed up… I simply prefer it this way. In a classroom environment, this might work only reasonably badly, but in day-to-day work, this probably doesn’t work at all. I found this out when I spent several months working with a team that didn’t respond all that well to my usual coaching style. I couldn’t put my finger on the problem, but I noticed that I’d stopped trying to work with certain members of the team, and instead gravitated to the ones that responded favorably to me. It turns out that I was making a number of them feel defensive with my straightforward style. This became apparent when they told me that we had to talk. Although I considered it progress for them to call a meeting to discuss people problems, it would have worked better if I’d been acting boorishly on purpose to prompt them to call the retrospective. No such luck. This woke me up: it reminded me to put effort into maintaining personal relationships in my work.
10. Forget the people
Everywhere, 2000-2008
Clearly, my greatest miss ever. In 2007 I realized that I had spent most of the early part of my career inadvertently, but consistently, forgetting about the people involved. I demonstrated this attitude by pushing ideas on them, believing the promise of XP over observing how people reacted to trying XP, emphasizing learning the practices over introducing what the team needs most, and perhaps most notably by assuming that everyone would feel happier if they delivered software more effectively. In the time since I started this journey, I’ve read dozens of books, worked with hundreds of people and spoken with hundreds more about the human aspect of software development. More than any other single idea, XP values people—programmers, testers, DBAs, project managers, product owners, any member of the project community. People lie at the center of software development. Using inhumane techniques to teach them humane programming seems risky and invites failure.
References
Ann Anderson, Chet Hendrickson, Ron Jeffries, Extreme Programming Installed. The first manual for how to start doing Extreme Programming.
Ron Jeffries, “We’ll Try”. A modest proposal for avoiding the classic mistake of pretending to commit to a plan that everyone secretly agrees would certainly fail. I used the opening paragraphs as the “cold open” to my first keynote talk.
Gerald M. Weinberg, The Secrets of Consulting. How to give advice effectively, including an entire chapter dissuading the reader from trying. I read this with my local book club in 2017, over 15 years after reading it for the first time. It felt as relevant in 2017 as it had in 2000.
Roger Fisher, William L. Ury, Bruce Patton, Getting to Yes. A solid introduction to what Human Resources departments would call “negotiation skills”.
Dale Emery, “Motivation”. My primary model for understanding people’s motivations.
Tim Ottinger, “Sooner, Not Faster”. Have you ever been saying something for years, then encountered someone who summarized it in three words better than you’d ever expressed it?
When I originally wrote this, “navigating” referred to not typing and having the “big picture” perspective while pairing.↩︎
I can help you profit from your software projects sooner. Or, I can help increase your chances of surviving them. I live where programming meets the business.
