The lesson here is that while data is good, it cannot be obtained at the cost of productivity.

Managing Virtual and Distributed Development Groups in an Outsourced World – Part 5 of 5

In Part 4 of “Who Moved My Team,” we discussed how to ensure IP continuity on a distributed project. Today we look at techniques and metrics.

Part 5 – Techniques and Metrics

Techniques for managing virtual and distributed teams can be summed up in four key parts:


Strive to build the most complete picture you can of the entire software development process. Don’t rely on milestones or a single metric (or two). Get enough information to paint a complete picture of what’s going on behind the scenes, not just what’s coming out the door. Focus especially on developer load, time spent fixing bugs to time spent writing features, bug recidivism rates, and estimation accuracy. If the first three are going up, things are going badly, no matter how great the “progress” is perceived to be. If the estimates are inconsistent, then there’s no reason to expect that the goals set by the development team are realistic in the first place.


Assume that developers will spend zero time supporting your instrumentation. Either they won’t support it, and the data will be sketchy, made up, or skewed by their memories – or they will attack it dutifully, but it will severely hamper productivity.  Whatever you install must require virtually no action on the part of the development team to work. Things that absolutely require action on the team’s part, like change requests, should be able flow back and forth with as little required effort as possible.


You need to act on the information you have. Pay particular attention to changes. If your team’s time spent fixing defects suddenly climbs from 10% to 20%, ask yourself a) why, and b) where is the extra 10% going to come from? Ask “why” before adjusting the schedule – as Steve Maguire says, it’s better to search for the leaks than to make the team bail faster.[1] But if the leaks either can’t be found or fixed, be aware that your team will either have to work longer hours (which will decrease their overall productivity), or you’ll have to slip the schedule. The more time they spend fixing bugs, the less time they spend writing new code. It’s just that simple.

In addition to tracking the progress of a project, use this information to determine the strengths and weaknesses of your staff, or to point out problem areas of the code. Ensure that your best people are being rewarded, and that weaker ones are being trained or culled out.

Finally, don’t assume that your local manager will take care of problems you are observing. Would you make that assumption if the team were local? Local management is there to assist you, not replace you. Besides, he or she is immersed in local politics and pressures. Though they may have their finger on the pulse of the group, you have objectivity on your side, and so you frequently have insights that they don’t have. And it’s ultimately your team.

Plan for Change

Turnover is a fact of life. You need to plan for both the incremental kind and the wholesale kind. For the incremental type, make sure developers continue to cross-pollinate, and that you are actively identifying and encouraging the most important ones.   Bringing key people to the U.S. for “training” is both an excellent opportunity to make sure their knowledge is shared, and to encourage them to stay with their employer (or you) when encouraged to leave by a competitor. You want them to ask a prospective recruiter, “How many times a year will you send me to the U.S.? Can you help me establish relationships with companies there that may want to hire me?”  Paradoxically, if you’re helping them to develop their career, they’ll actually want to stay longer, not leave sooner.

For the wholesale changes, ensure that your code management tools are robust, and that they support issue-based or change-set based code views. Having a clause that lets you hire key employees (see above) in the event of termination of your agreement can be important. If you’ve done the first part well, you’ll know who they are, you will have spent time with them in the U.S., and they’ll already be thinking of this as an opportunity.

When dealing with an offshore team, it’s not necessary to just hire a good manager or partner and hope for the best – offshore software development can achieve similar levels of quality that offshore hardware manufacturing has. By appropriately applying technology and methodology to the offshore development process, managers can gain insights that rival what they could gather by being present.

Key Metrics

I identified some specific metrics targets in the preceding blog posts. But where does this information come from?  There are many tools packages out there that can help, and more are available every day. At our various client sites, we’ve used both open source and commercial tools, depending on the client’s environment and budget. The tools, and functionalities available, change rapidly so rather than list a bunch of companies and products, I’d suggest a Web search on “software development metrics,” or similar, together with the names of some tools you currently use. and the other usual suspects have some useful offerings. However, there are a few key points to keep in mind when implementing a data program.


The problem is that quantitative data is painful to obtain. I once put in place a detailed metrics-gathering program, where developers would track their estimates, their time, causes of defects, etc. I spent two weeks selling it to the development staff.  When I had 100% buy-in and commitment, we began executing the plan.

It lasted one day. That’s how long it took for developers to become overwhelmed by their tasking. It didn’t matter that the data gathering would only take 10-12 minutes on every task – no one had 10-12 minutes. One comment I heard was, “It’s noon, I’ve got one of six tasks done today, and following the plan will take over an hour for the six tasks. The bug is fixed – let it go, and let me get back to my job writing code.”

The thing is, he was right. Keeping track of data wasn’t his job. I didn’t hire him to be a bookkeeper – I hired him to write code. I know of one project where a customer was billed several thousand dollars per month to pay for the time it took people to track their time. Tasking them to do that kind of work is a waste of their time and your money.

What Works?

The lesson here is that while data is good, it cannot be obtained at the cost of productivity. Not only will productivity drop, but developers will resent it, and will often start cutting corners, like waiting until the end of the day, or week, or month, to complete their data sheets. Once this happens, the data’s out the window, because at that point it becomes as much wishful thinking as the estimates themselves were. Data acquisition must be near-painless to the development team. If it’s not, not only will it be resented, but its accuracy will be so compromised as to render it worthless. This implies that metrics must be gathered essentially automatically, with virtually no effort on the part of the staff. Tools that require developers to record when they start coding, run their first compile, begin debugging, etc. must be avoided. About the most you can hope for from developers is for them to click once on something when they start a task, on again when they finish.  If it’s more involved than that, 99 times out of 100, it just won’t work.


[1] Steve Maguire, Debugging the Development Process, Microsoft Press, pp 151ff