Team Productivity vs Individual Productivity
I’ve been reading Neal Ford’s The Productive Programmer (my review) which is a book all about improving your productivity as an individual developer.
It got me thinking that there are also ways that we can make teams more productive so that they are actually teams and not just a group of individuals who happen to work with each other.
I’ve had the opportunity of working under some great Tech Leads who have helped create an environment where teams can perform to their maximum. I’ve noticed some recurring themes in both those teams.
In his book Neal talks about getting into a state called ‘Flow’ when programming. This is a state where you are totally focused on what you’re working on and are able to be extremely productive.
When looking at Team Productivity one of the key factors behind how well the team performs is how well the team communicates. There are several ways that we can ensure that this is done effectively.
It seems obvious but teams operate optimally when they are all working in the same physical space. Whether this be having an area of the office just for the team or using a conference room, communication is at its best when it’s easy to do.
In particular if the desk layout is such that it is easy for people to pair with each other on a problem or ask questions without having to move very far then we have a good setup.
We need to keep the size of the team appropriate to the size of the work and the time in which it needs to be completed.
The smaller the team and therefore the smaller the number of lines of communication the more effective a team can be. Of course we need to ensure that we have enough people on the team to complete the work required.
At an extreme we learn from Brook’s Law that adding people to a team probably won’t make it go faster. This is also true when working out the initial size of the team - if the team is too big then the number of lines of communication becomes increasingly big and effective communication becomes difficult.
Even if you have the other two it won’t matter unless a safe environment can be generated for people in the team to interact.
This means that people can feel free to ask questions to others in the team without being made to feel inferior.
People not communicating properly with each other is one of the biggest reason time is wasted on projects - reinventing solutions to problems that another team member has solved is a complete waste of time.
To given an example - on one project i wanted to work out how to unit test a Windows web service that we had written. I searched Google a bit but couldn’t work it out. Luckily I was able to ask one of my more senior colleagues how to do it and he pointed me towards the Gateway pattern which allowed me to solve the problem straight away.
He didn’t make me feel like I was stupid for not knowing how to solve the problem, but explained some options for how he would solve it and pointed me towards a book where I could read more about the solution.
How do we get the balance?
Individual productivity is defined as reaching the state of Flow in The Productive Programmer. In this state by definition you are working alone and not communicating with other team members. Team productivity on the other hand requires constant communication to make it work.
My colleague Jon Pither describes some of the issues he has noticed with pair programming with regards to this.
Psychologists refer to zone as ‘flow’. Daniel Coleman - author of Emotional Intelligence - describes flow as being “emotional intelligence at its best… the ultimate in harnessing the emotions in the service of performance and learning”. ... Pair programming is a not stress free activity...Being in a “pair” you are constantly required to explain your intricate thought processes to another person. ... We need to appreciate that developers are humans, and sadly are not perfect coding punching-out machines. Pair-programming introduces an emotional burden on the developer.
While I agree with Jon that pair programming is a completely different proposition to working alone, I’m not as qualified as him to comment as I’ve spent most of my professional life pair programming.
Certainly within an agile team there will be tasks which can be done individually and maybe these are the times individuals can use to achieve the fulfillment that being in a state of flow provides.
In terms of pure productivity I wonder whether there is such a thing as Pair Flow or Team Flow which would describe the state where a pair or team is working in an optimal state.
There needs to be a balance between a pair actually getting things done but also providing help to other pairs when the need arises.
I have noticed that one way this works fairly successfully is that if another pair needs help then only one person in the pair goes to help while the other can continue working. Although you lose the benefit of having both people at the keyboard since it’s only for a short period of time I think it’s acceptable.
For me personally I find it more enjoyable to work with others all the time even though I may not get into the state of flow although I appreciate that others may have different opinions on this matter.