Breaking Up The Team

What would happen if midway through the the NFL season last year, the Pittsburgh Steelers, standing at 6 and 2 and leading the AFC North, had decided that their football season was over and disbanded the team? Or what if they decided to move Big Ben to the training squad because he was a prime performer and the training squad wasn’t really performing very well? What, you say? This would never happen?

No of course this would never happen for a variety of reasons not the least of which is that a team doesn’t just disband. A team doesn’t take their best performers and move them onto another project because that project is sucking wind. A team may lose a player here and there due to injury or trade or retirement but there is a sense of continuity to a team that exists above and beyond the sum of the team’s parts. A team has common, long-term goals like “winning tonight’s game”, “winning the division” and “keeping our superstars with the team”. Successful teams of all types typically have a common culture and no divas. Or at least the divas are under something resembling control. Even on NBA teams, where there are often divas of extraordinary divahood, winning rarely comes consistently unless the rest of the team buys into both the system and the superstar. Conversely, on bad teams, you may have one of the greatest players ever (see: Kevin Garnett pre-Boston Celtics) and still lose all the time.

This is true of all kinds of teams. Without some semblance of stability, culture, direction and goal, teams fail. In fact, they often implode. And yet, we in the software industry continue to call groups of people “teams” when they are at best, loosely grouped collections of individuals with similar skillsets working temporarily on a common project and at worst, highly dysfunctional trapeze artists who would like nothing better than to cut down the safety net and install 2 ounces of extra weight in the left side of their fellow coders balance bar. Project teams are not teams.

This is one of the gorillas in the room of current software methodology. We talk about software teams as if they want nothing more than to succeed when in fact, oftentimes, they could care less and may even have motives to foster failure. Of course, you could argue that we come up with methodologies to standardize these poor teams. But then someone might call you a cynic.

Granted, there are teams like this in the sports world but they don’t typically stay teams very long. They are broken up, sent away and rebuilt with the goal of having a real team. But in software, dysfunctional teams may stay together for office political reasons and completely successful teams may be disbanded in an effort to spread the success around, ignoring the fact that the team may have been successful because they were a team. We continue to treat software teams as if they are completely different from any other type of team we have ever encountered in reality.

As long as we keep trying to treat the symptoms of the disease instead of the actual disease, we’ll continue to have an industry that languishes. Stability is the critical component of the long term success of a software development team. Doing anything that undermines that stability contributes to the continued failures in software development that we keep trying to cure with a new methodology. A solid, stable, professional team can write software using any methodology. It’s only because we refuse that stability that we have to have silver bullet methodologies to try to cure so many of the symptoms of the disease.