An Experiment in Scotch

What would hap­pen if mid­way through the the NFL sea­son last year, the Pitts­burgh Steel­ers, stand­ing at 6 and 2 and lead­ing the AFC North, had decided that their foot­ball sea­son was over and dis­banded the team? Or what if they decided to move Big Ben to the train­ing squad because he was a prime per­former and the train­ing squad wasn’t really per­form­ing very well? What, you say? This would never happen?

No of course this would never hap­pen for a vari­ety of rea­sons not the least of which is that a team doesn’t just dis­band. A team doesn’t take their best per­form­ers and move them onto another project because that project is suck­ing wind. A team may lose a player here and there due to injury or trade or retire­ment but there is a sense of con­ti­nu­ity to a team that exists above and beyond the sum of the team’s parts. A team has com­mon, long-term goals like “win­ning tonight’s game”, “win­ning the divi­sion” and “keep­ing our super­stars with the team”. Suc­cess­ful teams of all types typ­i­cally have a com­mon cul­ture and no divas. Or at least the divas are under some­thing resem­bling con­trol. Even on NBA teams, where there are often divas of extra­or­di­nary diva­hood, win­ning rarely comes con­sis­tently unless the rest of the team buys into both the sys­tem and the super­star. Con­versely, on bad teams, you may have one of the great­est play­ers ever (see: Kevin Gar­nett pre-Boston Celtics) and still lose all the time.

This is true of all kinds of teams. With­out some sem­blance of sta­bil­ity, cul­ture, direc­tion and goal, teams fail. In fact, they often implode. And yet, we in the soft­ware indus­try con­tinue to call groups of peo­ple “teams” when they are at best, loosely grouped col­lec­tions of indi­vid­u­als with sim­i­lar skillsets work­ing tem­porar­ily on a com­mon project and at worst, highly dys­func­tional trapeze artists who would like noth­ing bet­ter than to cut down the safety net and install 2 ounces of extra weight in the left side of their fel­low coders bal­ance bar. Project teams are not teams.

This is one of the goril­las in the room of cur­rent soft­ware method­ol­ogy. We talk about soft­ware teams as if they want noth­ing more than to suc­ceed when in fact, often­times, they could care less and may even have motives to fos­ter fail­ure. Of course, you could argue that we come up with method­olo­gies to stan­dard­ize these poor teams. But then some­one might call you a cynic.

Granted, there are teams like this in the sports world but they don’t typ­i­cally stay teams very long. They are bro­ken up, sent away and rebuilt with the goal of hav­ing a real team. But in soft­ware, dys­func­tional teams may stay together for office polit­i­cal rea­sons and com­pletely suc­cess­ful teams may be dis­banded in an effort to spread the suc­cess around, ignor­ing the fact that the team may have been suc­cess­ful because they were a team. We con­tinue to treat soft­ware teams as if they are com­pletely dif­fer­ent from any other type of team we have ever encoun­tered in reality.

As long as we keep try­ing to treat the symp­toms of the dis­ease instead of the actual dis­ease, we’ll con­tinue to have an indus­try that lan­guishes. Sta­bil­ity is the crit­i­cal com­po­nent of the long term suc­cess of a soft­ware devel­op­ment team. Doing any­thing that under­mines that sta­bil­ity con­tributes to the con­tin­ued fail­ures in soft­ware devel­op­ment that we keep try­ing to cure with a new method­ol­ogy. A solid, sta­ble, pro­fes­sional team can write soft­ware using any method­ol­ogy. It’s only because we refuse that sta­bil­ity that we have to have sil­ver bul­let method­olo­gies to try to cure so many of the symp­toms of the disease.