This article was originally posted on DZone

All software teams I have worked in over the last ten years practiced some sort of Agile, sometimes effectively, sometimes in-name-only. I discovered a lot about the value of teamwork and leadership and I increasingly side with the Agile2 movement that the original ideas expressed in the Agile manifesto on these topics are routinely misinterpreted and misapplied. Software teams are not like sports teams. Not a bit.

I don’t like any competitive sport that involves a ball, either as a spectator or participant – I have other ways to keep fit. But I appreciate the importance to keep your eyes on the ball. It is about being constantly responsive to what others around you are doing. You literally never walk alone.

I do know what that feels like, and it is not from my daily work as a developer, but from singing in classical choirs. In a choir, every singer does the best they can to match the sound of the other singers in their vocal range. The goal is to create a sonic blend where individual voices are no longer distinguishable. That takes great listening as well as singing skills. Good choirs don’t judge a new applicant by their solo skills. They don’t look for a unique voice, but a familiar one. Team members must let their individual expressions take a backseat to creating something that could never be performed by one singer. That’s what I call a team effort.

In a software team, we pull together to create a product which, although it consists of abstract bytes, is not ephemeral and temporary like a football match or a live concert is. Programming at an enterprise scale is necessarily a team effort because the work is too much for one person. We’re not in a chain gang digging a ditch or peeling shrimps, so the individual efforts must be constantly coordinated. Yet programming as a team is neither an acrobatic balancing act. The coordination lies in planning and dividing up the work and iteratively combining the various intellectual outputs. Map/Reduce, anyone?

This requires a range of different skills that reside with many people. As software grows in complexity it is no longer just about scaling up in lines of code. New disciplines emerge, like managing a cloud infrastructure. Look at the latest AWS API and you’ll agree that modern virtualization hasn’t exactly become easier on the brain. Old-school Perl/PHP web app development split into front-end and back-end development long ago, with corresponding roles and skillsets.

In practice, our tasks are therefore becoming less transferable within the team, but we still need to row the ship in the right direction. This balancing act is very different from a ball game. We don’t need to keep our eyes on the ball because there is no single ball. Comparing software development to team sports is an ill fit, as evident in the rugby analogy of Scrum, with its sprints. Building software is nothing like being in a choir, rock band, or football team. Many developers prefer tackling a tough intellectual challenge on their own rather than in pairs or in a group. This isn’t because they’re not team players, it’s because the problem at hand favors deep thought and is often atomic in nature. It makes no sense to divide it up further. Yes, there is plenty of opportunity and need for collaboration and discussion. We must pull in the same direction after all, and decisions must be made constantly. But we shouldn’t expect to work together all the time, not of ourselves and not of others.

Perhaps a big-budget film production is a better analogy for enterprise software. I recommend the making of documentaries on the extended edition DVDs of the Lord of the Rings trilogy. Sculptors, carpenters, costume designers, sound engineers, and digital effect designers all get to show off their skills and apparent love and enjoyment for the project. Nobody was fungible. They often worked on different continents. The make-up artists had no dealings with the orchestra that recorded the score. The one person who had a stake in everybody’s contribution was director Peter Jackson. It was always his call when a creative decision had to be made because you can’t make a masterpiece by committee. Your ship needs a captain.

Some final thoughts about leadership then. Agile has underestimated the importance of team leadership. Or rather, it has tacitly assumed that leadership can take care of itself. Meanwhile, it overestimates the ability and possibility of teams to be fully self-organizing. I think that the sports analogy is to blame for that. In a football team or barbershop quartet, self-organization comes naturally while you’re working. There are no other stakeholders beyond the players on the pitch or on stage. Organization becomes indispensable by itself because without it you instantly mess up. The nature of the work demands it. In software, this is quite different. Individual developers can cozy up in their man cave (especially these days while working at home) and come up with brilliant ideas, but they have to fit in the bigger picture. 

Developers are understandably averse to the cliché of the authoritarian yet ignorant pointy-haired boss. They have less of a problem accepting the benevolent dictatorship of an esteemed peer who knows her stuff. A great example from the LOTR documentaries was the design of the Gollum character. Jackson had to choose from dozens of different drawings and sculptures and by doing so scrap all the work for the ideas that didn’t make it. That takes tact, but the team must understand that some arbitrariness is all in the game. The leader who can pull that off is indeed precious.