Economics, Models, and Money

[article]
Summary:

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

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.

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!