An article from Cutter.com published today speaks of the association of the word “team” with athletics and competition, such that the psychological preference implied is to win at all costs. It suggests using the term “Ensemble” (as in the theatrical sense) rather than “team”, because it conveys a sense of a group for whom the whole takes priority over any single part. The basis is that it is impossible for actors _not_ to collaborate.

Collaboration should be natural and we do need to explore the causes that prevent it from happening. The theme has bothered me for a while but I think the terminology is not the primary culprit. I can offer some candidates I’ve been watching over the years:

1. Lack of common purpose
2. Setting individual targets (aka local optimization)
3. Focus on accountability rather than results

The most severe case of these I’ve observed was a team where each individual developer had a project to own, manage and deliver. This was aggravated by a bunch of Romans working to get CMMI Level 2 certification for the team (which they did). While observing this situation, a token release was done because nothing had been produced in nine months and there was a need “to be seen to be making progress”. The individual accountability, pressure and stress levels were so high that developers would not even talk to those sitting next to them for fear of being dragged into someone else’s problems. Everyone looked at the guy who had been wrestling with the hardest project for the last 6+ months, and all were glad they were not him. There was no pairing, since any time spent helping others would be at the expense of your own project and management would perceive the offending pair to be chit-chatting.

There was an “uprising”. It had been brewing for a few weeks and took place on the day that the CMMI certificate was put up on the wall.

The developers pooled all their work together and discussed which were the most important projects. Sure enough, the hardest project was also unanimously perceived to be the most important. Everyone started to work on that.

This required a strong commitment from every developer to hold ranks when presenting this new behavior to managers and clients. Sure enough, managers tried to pick developers our one by one and asked about progress on each individual project. Clients didn’t care. Being traders, they welcomed the volatility because it only increased the likelihood of something being delivered!

Suddenly there was common purpose, team targets (and volunteering – no task assignment was tolerated), and focus on prioritized results. The team delivered the most important project five weeks later, simultaneously progressing on the next two most important ones and all the while pairing with increasing promiscuity. After a few months and a few projects under their belts, the team never again generated a line of code that wasn’t test-driven and paired (or in threes!)

Was this a transformation from Roman to Greek methods, fending off Barbarians in the process? Probably not 100% but your post made me remember all this so in my mind, it was. I hope this makes you less sad about the choices that exist.