Agile Zone is brought to you in partnership with:

Johanna Rothman helps managers and teams solve problems and deliver products. Her most recent book is Manage your Project Portfolio: Increase Your Capacity and Finish More Projects. You can read her blogs and other writings at Johanna is a DZone MVB and is not an employee of DZone and has posted 126 posts at DZone. You can read more from them at their website. View Full User Profile

Economics, Models, and Money

  • submit to reddit

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

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.



Published at DZone with permission of Johanna Rothman, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Robert Craft replied on Thu, 2012/01/26 - 6:09am

“Infrastructure is inexpensive these days. I don’t understand why you would technologically handicap a team.” Infrastructure is often handled by a separate organization, who get measured solely on cost-containment, not on the synergistic success or failure of the dev teams that have to use their services.

Spring Security

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.