How to manage software outsourcing in a staff augmentation model


In a staff augmentation model, developers internally and remotely are working on the same project, and usually the same code base.  When the model is implemented well, communication is efficient resulting in good productivity and a healthy team relationship.  However, if the model is not implemented properly, there can be significant communication overhead, resulting in loss of productivity. It often manifests as long meetings, frustrating code reviews and code merges, or worse, when the project manager or stakeholder refuses to mark the feature as “complete”.

I’d like to suggest an implementation approach to staff augmentation that is effective in not only minimizing communication overhead, but also increasing quality and productivity, and making happier teams.

Let’s say you are planning your next release with four new features (or feature enhancements) and five defect fixes.  Think of each new feature as a vertical set of activities: estimations, architecture, coding, unit-testing, integration, code reviews, etc.  Use the same concept for each defect, with its corresponding set of activities.

Often, project managers who are new to staff augmentation will divide the activities of a feature across teams.  For example, estimations and architecture are assigned internally. Coding, unit-testing, and integration are assigned to the remote team. Then again code reviews are done internally.  The result of this approach is lots of communication overhead, and it’s easy to see why.  The more the baton is a passed from one team to another, the more communication is needed to assure that all the right information is relayed.  This approach leaves plenty room for miscommunication and misunderstanding.  It results in longer meetings, loss of productivity, and often-unnecessary frustrations.

Now consider an alternative approach: giving each team whole verticals, a full set of activities associated with one feature or defect.  For example, for your development cycle, you assign two features to your internal team. The remote team can take the other two features, and some of the defects.  The baton stays put.  You’ve consolidated the vertical effort, and reduced communication overhead.

Consider how much more engaged the remote team would be if they were involved from the planning stages in, for example, the estimation process?  Developers who code should also be the developers who estimate.  How about the architecture?  If your internal leads are nervous about the prospect of handing over design responsibility, consider asking the remote team to write up a design approach document that your internal architect can review, and make adjustments if needed.  I call it a “Technical Perspective”. Engagement is a powerful way to increase productivity and engender happy employees.

Making people accountable is key to managing effectively. If you’re slicing up feature activities across teams, how do your employees know what they are accountable for? How will they know whether they succeeded or failed?  The estimations were wrong, but they were done by one team, while the coding was done by another.  The design turned out to be too simple, missing important considerations, but the remote team went ahead and coded it anyway.  See the accountability problem?

If needed, add checkpoints along the way. For example, have your internal team do spot-check code reviews, after the remote team has done the obligatory full-code review.  For the architecture, I’ve mentioned design approach documents.  Don’t fear letting go of what you today believe must be handled internally.

If you’re running an agile development process, segmenting the whole vertical activity stack into teams is much more apparent. Completing a user story involves too many dynamic activities, making it cumbersome to divide across teams.  I suggest you begin by engaging your remote team in the Iteration Planning Meetings.  I will cover staff augmentation using agile in a future article.

I hope you have enough confidence in your remote team to give them more autonomy.  If you’re thinking they can’t take on the full-set of activities all at once, then migrate activities slowly, one at a time.  This is also a good tactic for overcoming internal team resistance.

There are, of course, certain foundations to a successful staff augmentation implementation.  A mature and willing internal team, with management that is closely engaged in the process, is critical.  The remote team must be very disciplined, impeccably managed, and they must possess strong development talent.

Leave a Comment