Israel Gat had a great Agile Cutter Advisor recently, the Friction of Agile (registration required). He discussed the friction of agile going up in geographically distributed teams because of the dis-economies of assimilation (the space-time continuum problem, and the issue of under-funding the infrastructure of the non US-based teams).
Israel Gat had a great Agile Cutter Advisor recently, the Friction of Agile (registration required). He discussed the friction of agile going up in geographically distributed teams because of the dis-economies of assimilation (the space-time continuum problem, and the issue of under-funding the infrastructure of the non US-based teams). He had a stunning (to me) quote from a manager, when he explained what moving to agile would cost:
“Such investment will break our economical model.”
Wage cost is not the same as project cost. And, if you don’t outfit the “remote” team with the necessary infrastructure as the “headquarters” team, you can save a bundle. (Do you hear my sarcasm?) Of course, you pay for it in the cost of communication, the cost to ask a question, the overall schedule delays, and project cost. And, if the remote team are the testers and the headquarters team are the developers, well, guess what? You’ve got second class testers.
Types of Teams
In agile, we can’t afford second class testers (or second class remote teams), because the delay in acquiring information during the iteration is too high a risk. That’s Israel’s Friction of Agile bumping against the economies of scale.
If you look at the types of teams in this figure, you can see that everything above the middle line, the co-located and distributed cross-functional teams, have a shot of working well in agile, assuming they have adequate tools. Silo’d teams, and the dispersed teams have built in delays because they are not already cross-functional. Can you make them work? You can make anything work. Will they have communication delays? Yes.
But, as soon as you remove adequate tools from distributed teams, all bets are off.
If your economic model for distributed development is this: “Don’t pay people and don’t pay for their infrastructure,” I have a reply. “You can ‘save’ all you want on wages and infrastructure. You will pay for it in defects, technical debt, unhappy customers and eventual product death. Is that what you want?”
Infrastructure is inexpensive these days. I don’t understand why you would technologically handicap a team.
