I had the pleasure of appearing on the Ruby Rogues podcast this week talking about how Pivotal Labs does Extreme Programing (XP). Accompanying me was ex-pivot Josh Susser, James Edward Gray, Avdi Grimm, and Charles Max Wood. I had more fun recording it than I would have imagined and the pivots here have enjoyed listening to it, I hope you will too!
I asked my pair on my first day here at Pivotal.
That’s on purpose. A user story is a promise to have a conversation. When we start a story, we’ll have a discussion with the client to fill in the details.
Ok. So we’ll just ping them on Skype or something?
No. They’re sitting at the desk right over there.
The Onsite Customer
In XP, the onsite customer is a domain expert that is part of the development team. Their responsibility is to answer questions, resolve disputes, and set small-scale priorities .
In past projects, contacting a client involved emails, IMs, or phone calls. My stories needed detailed descriptions. Description-less stories risked building the wrong thing. So I labeled them “blocked”, and project velocity suffered.
Benefits of having an Onsite Customer
In my current project, having an onsite customer has made a huge impact.
Eliminating story descriptions has simplified iteration planning meetings. Just write down a short title and move on. Discuss the details later.
Constant client communication has helped avoid misunderstandings. Not once has a pair built the wrong thing. Developer time isn’t wasted.
Delivered stories rarely go untested for longer than an hour. A quicker turnaround has shortened system feedback time.
Get Serious About Succeeding
An onsite customer was one XP practice that was missing from my past projects. What client would be willing to give up one of their full-time employees? After four weeks of working on a team with an onsite customer, to me, the answer is clear: a client that wants their product to succeed.
 Kent Beck, Extreme Programming Explained: Embrace Change (Addison-Wesley Professional, 2000), 60.
Pair programming is the subject of endless discussion and debate. How often should we pair — 25%, 50%, 75%, or even 100% of our development day? Should we pair on remedial tasks as well as feature development? What about infrastructure work or research? Is pair programming valuable at all, or should we kick that hippie kumbaya crap to the curb, put on our headphones, and get some real work done?
Personally, I’m somewhere in the 95%-pairing range. Simple stories and bug fixes have a way of becoming complicated (or implemented sloppily) when soloing. Infrastructure is a notoriously siloed realm and spreading that knowledge around can only help everyone. Investigating production database issues, estimating stories, writing CSS, chopping up images using Fireworks — share the love!
So what is the last 5% for? Futzing.
I’m “futzing around” when I’m not doing anything important, maybe even wasting time, at least from a pure productivity perspective. Interestingly, while I’m not implementing features or fixing bugs, I’m expanding my mind. I’m learning in a way that is not conducive to pair programming or any interaction at all with other people: I’m exercising my personal way of learning that that is unique to me. Here’s an example:
On my current project, we’re using very advanced, powerful CSS selectors that blow my mind. While I understand what we are implementing and can see the immediate affect upon the application, it is impossible for me to grok the enormity of these techniques even though my pair is a master and great teacher. I’m learning, but not necessarily understanding. Collectively we are not in a teaching mode, we’re in a cranking-out-awesome-stuff mode. Now, I am not suggesting that we are hacking or moving too fast to learn — on the contrary, we are both learning much, and I often ask my pair to slow down and explain what the hell
.div:first-child:not(.row) + .row is doing. Our joint mission, though, is to get stuff done, not to explore every CSS pseudo selector. I’ll futz around with that later.
When I’m learning something new, especially when it’s complicated, I eventually need to futz with it by myself, with nobody looking over my shoulder. I need to flip all of the switches, break it, fix it, break it again the same way, fix it, throw in a little salt and pepper and try again. I need to try every parameter individually, then try to combine them. I need to hack and not feel bad about it. I need to do stupid stuff that could never possibly work because, even if I’m told such, I need to try it myself. Finally, I need to do this for 30 minutes until the “ah ha!” moment hits me and all of the tumblers fall into place in my mind.
Why don’t I do this with a pair? Because I must be in the driver’s seat the entire time with no consideration for pair programming etiquette: talking things through, taking turns, letting my pair try his ideas — no way. I need those brain cycles to figure this stuff out, to make the mental connections that are shorting out. I don’t know what I don’t know, and I need to find out for myself, in my own dumb way, by futzing around and making mistakes. Finally, I need to more than learn: I need to understand. When I’m done, I will use that new understanding during the other 95% of my development time to help my team build the best products we possibly can, and encourage them to futz around a bit on their own, too.