Great teams are rare
Posted on August 20, 2007
Filed Under Uncategorized | Leave a Comment
I read this really interesting article on ‘Da Q‘ that talked about ’The Secret Sauce of Highly Productive Software Development‘ being learning. Basically, if you don’t make time to learn, agile (or non agile) teams will always be just-average teams and never reach the dizzy heights of being a high performing team.
This got me thinking. I’ve been fortunate enough to have been a member of a couple of high performing teams over my last two decades of software development. However, the best performing team I have been a member of is my football team between the ages 11 and 16. Looking back at this team now, I can see clearly why I have never been able to reach the same level of performance within a software development team.
Friends, not associates. As a football team we were first and foremost friends. More than that, we were something of a clique. We saw each other before school in the playground, at school during lessons, break and lunch, and after school at clubs. We shared girlfriends. We loved and hated the same TV programs (Miami Vice, Starsky and Hutch, V). We loved our clothes (Farahs, Adidas, La Coste). We were known to each our parents for better and for worse. We were always together like some kind of extended family. This was translated onto the pitch, where one referee was quoted as saying, “they never stop talking, shouting, arguing or laughing, they gave me a headache”. One referee actually told us to shut up and play football! However, as a comprehensive (read as a deprived) school back then, we lost one game.
Personal Safety. Anyone in the team, could say anything to anyone without comeback. You could speak your mind both on and off the pitch. The number of software projects that I’ve been on where you just couldn’t do this still scares me. It is a clear route to failure.
Team Cohesion. A team needs time to gel. It needs to find its own rhythm. A three month project where a team is formed and broken up does not give enough time for you to get to know each others little quirks. You need a few of these projects to get to know how Bob likes to work? What offends Bob? What does Bob like to do? Is he a morning person? And so on. Although I don’t think all team members need to friends, I think that if they are it helps. My best software achievements to date have been in teams where I have considered the other members to be my friends.
Practice and Feedback. The players and reserves gave us a total team size of 14 kids. Every Monday morning we’d number off. Numbering off is where the team would collectively agree who was the best player, second best, third best, and so on, right down to poor old number 14. This was quite important because when we picked two teams that would play against each other, the best and second best player were never allowed on the same team. So two random people would pick and what you’d get were two evenly matched teams everytime we wanted to play a game of football. We would play (i.e. practice) and criticize (i.e. feedback) each other continually. The better you played, the more likely next week you’d go up a rank. Ranking was everything. It leaked into our social lives as well because we would queue up at clubs, at dinner time, based upon our rank. Now I’m not saying explicit ranking would be good thing within a commercial software development team setting, but implicitly this does happen. I’d bet my last dollar that you have a fair idea of how your technical abilities compares with your peers. You just don’t voice it. However, back in my youth it was an incredible driving force to climb the football ranking ladder by knowing exactly how your team mates perceived you.
Leadership. The best team member is not necessarily the leader. I was captain of the football team for 4 of the 5 years. My highest ever rank was 3. But I was nominated captain because my team was typically the winning team. I don’t like to lose, so I always stepped up the game (or took someone out who was stepping up their game 
).
So what has this got to do with software development teams. Well, I think honest communication, whether its feedback, advice or criticism, within a team is essential. Moreover, it’s important that the giver and receiver of understand each other. However, this is rarely the case. When you have this I don’t think there are many problems you can’t overcome. But without it, even the simplest things become difficult.
To date, I think the agile approach is the best tool we have for creating great teams that can deliver better software faster. However, a lot of the challenges not technical ones, but people-oriented ones.
Sigh, why don’t you ever realise you’re a part of a dream team until you’ve left it….
Comments
Leave a Reply
