Collaboration Schemes
Ben Jones is the Director of Research for The Standards Company LLC. He mentioned to me in passing that an interesting phenomenon was occurring within the confines of the company that he recognized in a book Extreme Programming, one of the pocket guides from O’Reilly.* He specifically pointed out a chapter titled “Developer Practices,” specifically “Developer Practice 2: Pair Programming.” The premise of this subsection of the book is that learning increases when working in pairs on a common goal, and that such learning can spread quickly to the rest of the staff when new partnerships are formed. Although the book is aimed primarily at programmers, learning is learning (which just goes to show that we can all learn a great deal from those working in disciplines outside our own fields).
Program in pairs. When you start a task, ask another developer to work with you. Pairs generally work together for just one task, perhaps an entire afternoon, and then form other pairs with new partners. This spreads the knowledge of the system throughout the whole team.
But there is more to it than that.
The person with the keyboard –- the driver –- focuses on the details of the task. He thinks tactically. The other person –- the navigator –- keeps the entire project in mind, ensuring that the task fits into the project as a whole and keeping track of the team’s guidelines. She thinks strategically. Both roles are important, and both roles are fluid. When inspiration strikes you, drive. Your partner will navigate. Change roles as necessary.
Our collaborative teams are not quite as systematic. But maybe they should be. Regardless of whether you are computer programming or analyzing student assignments (and The Standards Company does plenty of both), the pair-programming structure appears to be a highly effective way to bring new staff members up to speed and to invigorate all staff members towards innovation. We are going to give pair programming a hard look over the next few weeks and judge its efficacy. Stay tuned.
All excerpts are from Extreme Programming Pocket Guide, O’Reilly & Associates: 2003.
* Not everyone is completely enamored with the concept of extreme programming. Here is computer guru Don Knuth: “With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term “extreme programming” sounds like exactly the wrong way to go…with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me.