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? George Dinwiddie: When I left corporate employment for the life of a consultant, I looked around for places to learn how to be more persuasive. One of those places was the Amplifying Your Effectiveness Conference (AYE). I was a pretty good engineer, but probably a bit below average in people skills. And, one of the big reasons for going solo as a consultant was to take charge of my own career development.
Boy, was that an eye-opening conference for me! I can't come close to listing all the things I learned there and in the subsequent opportunities I've encountered since first attending AYE. Instead of learning how to be persuasive, I instead learned how to observe and understand. It turns out that it's very hard to get people to do something when they don't see any value in it, but they're quite likely [to do it] when that value is visible from their point of view. It's just hard to make that value visible without understanding their point of view.
I also learned to look at groups of humans from the systems thinking angle. Persistent behavior in groups is an indication that something in the system is rewarding that behavior. This realization gives us tools to make better choices—choices that result in a system that gives the results we want. For example, a manager wanting programmers to adopt technical practices that might give higher productivity or a lower defect rate won't change the status quo just by saying she wants them to do so. Instead, she might look for what makes these practices more desirable from their point of view and what other influences are inhibiting learning and the use of these practices. It may be that pushing hard for more productivity is inhibiting the team from taking time to learn new things.
All of the agile methods lean heavily on teamwork to get things done. The method descriptions don't often call that out explicitly, but they put practices in place that enhance the collaboration and interdependencies of small groups of people. I've found that teams that start with an effort to build a "real team" out of a work group tend to succeed much more easily with an agile adoption. Groups that avoid changing the way they relate within the group tend to find little value in their agile attempts.
Don Gray: What's the difference between faux and real teams?
George Dinwiddie: You can look at this difference in several ways. One is in terms of results. Real teams tend to get more done than faux teams. That's because they make good use of everyone’s talents. Everyone contributes what he can, and everyone helps his teammates be able to contribute more.
It's also because real teams are more aware of how their work fits together. There's not a lot of wasted effort on solo work that goes in the wrong direction. That's not to say there's no conflict on a real team. To an outsider, it sometimes looks like there's more conflict. It's out in the open, where it can be readily dealt with by the team members. It's collaborative conflict, even when there's a strong difference of opinion. The conflict is resolved in tiny steps, without anyone going a long way down a path that doesn't fit with the rest of the team.
On faux teams, the conflict may be overt and insolvable, but in corporate environments it's more often hidden and unreachable. The individuals may not be clear or may not agree on the group's purpose. Some individuals likely feel excluded from the real decision making. People may be cautious about revealing their thoughts and feelings because they don't trust that they'll be well received.
Members of a real team know why they're on the team. The share the goals of the team and care about them. They understand who is taking what role, even if the roles are changing fluidly. They trust their teammates and commit—either explicitly or implicitly—to work together in a mutually beneficial fashion.
