In this installment of our continuing conversations between software experts, Don Gray talks to George Dinwiddie about his work in the agile community—both before and after it got its name—and how agile approaches affect teams.
I met George in the Software Development Forum when CompuServe was the way for technical people to communicate. Scrum hadn't been defined, and the Agile Manifesto wouldn't exist for another eight years. Based on his long-standing reputation in the agile community, I wanted to touch base with him and learn how he got started in agile, what he's observed about teams, and what makes a real team.
Don Gray: George, you're well known in the agile community and have been for a long time. What first attracted you to agile?
George Dinwiddie: It was a joke. I'd been reading Ward Cunningham’s Portland Pattern Repository to learn more about design patterns, and I kept seeing this noise about Extreme Programming (XP). One morning, in conversation with some friends, I used that term as the punchline for a joke. One of my friends asked, "Extreme Programming—what does that mean?" I had to admit I didn't know, but I could find out. So, I went back to Ward’s wiki to learn more.
Don Gray: So, what did you learn?
George Dinwiddie: I learned that the general flow of XP development was comfortably familiar to me. It's a process of building what you know you want and using that to explore what else you want. It's a process of growing the software, rather than planning it all out and then merely typing it in. It felt very much like the way I worked when I worked on solo projects.
The business of writing tests first was alien to me. How could you do that? How can you test something that doesn’t exist? So, I tried a three-day experiment with that and learned that not only could I drive my design with tests, but also it focused my work and I got more done. And, I liked it.
I was less successful at convincing my project lead, though, so I did "XP for One" for a couple years in an ad-hoc shop. That experience made me pretty good at test-driven development in Java.
It also made me feel like I was missing out on something important. The people I conversed with on the XP mailing list were mostly working on teams, and it sounded like great stuff. I thought back to a tightly knit development team I'd been on once, and thought it would be great to re-create that feeling using XP. (This was before the Snowbird gathering developed the term "agile" for software development.)
Don Gray: I'd like to hear a little bit more about that team. What do you remember the team doing? What were you trying to re-create?
George Dinwiddie: That team was in a startup company. The development team (hardware and software) was somewhat neglected by management, so we took it on ourselves to self-organize. Most of us would go to lunch together and piece together bits we'd overheard so we could know the current direction of the company. Many development strategy decisions were made over half-price hamburgers. We started having an afternoon tea-time (and invited management back to engineering to join us), where we shared where we were with our work and coordinated who was doing what. That daily coordination was a powerful thing. It made me feel like I was accomplishing something big—the whole project, rather than just the module I was writing at the time. We also brought up issues that bothered us and brainstormed solutions. For example, one engineer tended to keep a number of files checked out for a long time, checking them back into RCS right before a release. We started a series of Lunch ‘n Learns with version control usage being the first topic. Things went much more smoothly with frequent integration of the code.
Don Gray: In the years you've been working with agile methods, what have you noticed about teams? What skills have you developed? Where did you learn about them?