Usually when I am new on a software development team I wonder who might be a good pair programming partner. I also think about how to get to pairing quickly and stay in that mode. In this blog I will describe a simple model that I use when I reason and think about this.
Thinking & acting
If you plot the activities you engage in over the course of a day on a horizontal line where the far left is thinking and the far right is acting, it might look something like this.
Some activities require more thinking, more creativity and more reflecting whereas others are more routine like and straight forward. With practice some of the activities can be pushed towards the right as you internalize the knowledge, but some activities never change and remain purely thinking or acting. Let’s call this categorization ‘activity type’.
Collaboration & cooperation
Another dimension of our work is how we interact with others. We help each other learn, we move furniture together or perhaps participate in bi-weekly retrospective meetings. At some point or antoher we are more or less forced to interact. These modes I refer to as collaborative or cooperative. The difference between the two usually calls for some explanation since these modes are often confused or generally not understood at all. Lets start by catergorizing them as ‘interaction modes’.
The two interaction modes, Cooperation and collaboration, differs from each other in the same way a relay swim team differs from a rowing team. On the swim team you build upon each team members previous effort, whereas on the rowing team you are dependent on the efforts of the rest of the team during the whole race.
Real time collaboration
One of my favorite ways of collaborating is pair work — especially when I work with software development. It boosts my productivity but it also gives me a chance to see how other people learn, think and act.
Pairing is also a great vehicle for ideas, culture and knowledge sharing. And when it works, there is nothing like it.
Hopefully you have also experienced great teamwork at one point or another and maybe you can even recall a situation which can be described as a state of teamwork flow. The pairing was smooth, conversations took place and things you couldn’t accomplish on your own comes out of the collaboration, and it is the coolest thing you have ever experienced.
A Bumpy ride
Then again, there are these other situations when it just felt awkward, nothing worked and it felt like you were working solo but sat together. Much like trying to work on public transportation. Noisy, unpredictable and quite a bumpy ride.
Groups of people that work together usually strives for that elusive flow and how you interact with colleagues as you try to complete tasks during a day have a big effect on both the outcome and the way to the result. Some people prefer pairing on difficult tasks, some prefer prototyping alone to validate something while others have conversations. In short, different situations call for different modes of interaction as well as different types of activities.
A simple model
Even if pairing was very easy to get to and even if thinking together was equally easy there are times when it’s not the perfect interaction mode and something else is more suitable.
In order to reason more easily about this, I’ve combined the ‘activity type’ and ‘interaction mode’ in a diagram. Take a look at the picture and note how four squares emerge.
I refer to this simple model as the Developer Exchange Model, as it is about exchanges between individuals on a team or in a group setting.