Here’s an example. Imagine the developer finishes a feature at eleven o’clock on Thursday morning. If the tester were sitting next to the developer, the tester could start work around lunchtime, depending on what else the tester was doing. However, if the tester is in a time zone eight hours away from the developer, the tester doesn’t even know the developer is done with the feature until the tester arrives at work the next morning.
Now, what if the developer has made a mistake? Sometimes developers do. If the tester is in the same room or on the same floor as the developer, the tester can let the developer know while the code is fresh in the developer’s mind. The developer may not have started anything else.
However, with a remote tester, the developer has started some other feature. The developer now has a context switch. If the developer has made a mistake, the developer will incur a cost to return to the original feature. Or the developer might decide to finish the current feature to decrease the context switching and increase the cost of delay for the testers.
It is possible the tester doesn’t receive an answer until late Friday. That’s a significant time delay.
You can show this time delay on a value stream map. In fact, if your management is considering offshoring anything, you should. They should understand the cost of delay.
Cost of Delay Affects Any Project, Agile or Not
I’ve used developers and testers as the examples here, but you might have the developers and testers together and have the product management be remote. I’ve seen ScrumMasters be remote from their teams—something I don’t understand at all.
Any time you have a necessary role remote from the team, you incur delay in the project. That delay has a cost.
Maybe your project isn’t driven by cost. Maybe it’s not driven by schedule. If not, why is your management so keen on offshoring?
Offshoring Provides You Access to Talent and Other Cultures
A client of mine once said, “There are smart people all over the world. Why shouldn’t I use them on projects?”
He was right.
The best way to employ them is to use those smart people as feature teams, where you can provide the requirements to those smart people and answer questions for them. They will innovate in ways you cannot even imagine.
But as for one person on your team who is more than eight hours away? Or even more than four hours away? Explain to your management that wage cost could make your project much more expensive.
Read more of Johanna's management myth columns here:
- The Myth of 100% Utilization
- Only the 'Expert' Can Perform This Work
- We Must Treat Everyone the Same Way
- I Don't Need One-on-ones
- We Must Have an Objective Ranking System
- I Can Save Everyone
- I Am Too Valuable to Take a Vacation
- I Can Still Do Significant Technical Work
- We Have No Time for Training
- I Can Measure the Work by the Time People Spend at Work
- The Team Needs a Cheerleader!
- I Must Promote the Best Technical Person to Be a Manager
- I Must Never Admit My Mistakes
- I Must Always Have a Solution to the Problem
- I Need People to Work Overtime
- I Know How Long the Work Should Take
- I Must Solve the Team’s Problem for Them
- I Can Move People Like Chess Pieces
- Management Doesn’t Look Difficult From the Outside, So It Must Be Easy
- I Can Compare Teams (and It’s Valuable to Do So)
- It’s Always Cheaper to Hire People Where the Wages Are Less Expensive
- If You’re Not Typing, You’re Not Working
- You Can Manage Any Number of People as a Manager
- People Don’t Need External Credit
- Performance Reviews Are Usefult
- It's Fine to Micromanage
- We Can Take Hiring Shortcuts
- I Can Standardize How Other People Work
- I Can Concentrate on the Run
- I Am More Valuable than Other People
- I Don’t Have to Make the Difficult Choices
- I Can Treat People as Interchangeable Resources