Managing outsourced teams. Balancing innovation with predictability.

Administrator — Tue, 19 Dec 2006 21:05:23 +0000

In the old days, when people talked about remote engineering teams, the first image the came to mind was a group of engineers in India that would use BBS to download the source code produced during the day in the US, then worked on the project and send back the source code to the US. This process created an illusion of parallelism. People would work regular ours in both offices and still be able to produce code up to 24 hours per day.

Then the Internet boom came along and the telecommunication market was operating with the assumption that the demand for Internet bandwidth would continue to grow indefinitely. At the same time, the need for engineering talent increased rapidly. This need, was addressed initially by importing brains and in a second phase by the explosive creation of remote engineering teams everywhere.

The so called “offshore teams” offered access to engineering talent with promises of substantial cost savings. The main force that kept these teams together was the hope to convert company stock options into cash. In many ways, if you had a team, it was relatively easy to keep it together. Today most organizations have to assume that the engineering team will be distributed geographically. However the old “two work shift” model is not as effective when we use more dynamic engineer life cycle models like Agile and RUP.

Suddenly, the time zone difference that allowed India to flourish as the Mecca for remote teams becomes a serious limitation when iteration is possible and desired.In normal market conditions engineering organizations can benefit of a more comprehensive long term engineering planning regarding managing remote teams. In this context, let’s define the problem. Nowadays, cost reduction is the prominent factor that motivates having an offshore engineering team.

In order to reduce cost we have to avoid turnover and plan for long term relationships. We also must manage risk by reducing the financial impact in the event of turnover. We need to have a consistent metric to evaluate performance of these remote engineers. On top of all of this, it’s important to realize that there is an additional constraint imposed by the limited communication channel between these two points either by distance or by time zone difference. We could restate this objective goal in a more condensed form like:

“Our goal is to reduce cost by creating less expensive engineering operations that will be managed remotely across a limited communication channel”.

Let’s now list the key factors to be managed:

Communication efficiency
Intellectual property risk
Turnover risk
Consistent metrics

There are two classical approaches in creating remote engineering organizations: “Assembly Line” and “Extended Team”.

1. “Assembly Line”

System requirements will be created in great detail and sent to the remote office that will assemble the software artifacts according with the specifications defined. This approach focuses on risk control and consistency by creating a very formal and predictable communication channel with the remote team. It also uses objective metrics to assess performance.It is the simplest model to configure and the most time consuming to maintain.

It requires impeccable requirements prepared by experienced professionals on the more expensive side of the fence. It can potentially create finger pointing situations where the implementers argue that the spec was wrong while the other side argues that the requirements were not followed.

2. “Extended Team”

Functional requirements will be defined and sent to the remote team that will come up with a system requirement document and/or prototype to be approved by main office.This approach values collaboration and long term relationship with the provider by changing the type of information that needs to flow through the channel and also by creating a more trusted environment.

This adjustment is made by communicating guidelines instead of rules and letting the provider derive the rules and be part of the group that innovates.

If the remote team is has similar capabilities when compared with the local team, Risk can be also reduced by having a backup organization operating remotely. On the other hand it Intellectual property risk have to be managed in order to keep the “company jewels” safe. This approach creates a more sustainable model for the remote team since there is a career path on the remote side.

Based on my experience managing high tech offshore/outsourced projects in the last fourteen years, I believe that the best way to go about this problem is to create a remote engineering organization is by starting on the “Assembly Line” mode and transitioning to the “Extended Team” mode as soon you feel confident on the capacity of the remote team.

Got Architecture?

Administrator — Wed, 18 Oct 2006 12:10:37 +0000

Any architecture should guide and constrain, imposing the best ideas and lessons learned on designers and developers.
But try to wield too much power, and we will encounter resistance. Wield too little, and we make no contribution.
An interest approach to solve this dilemma is called minimalist architecture. Following this guideline we should sort out your highest-priority architectural requirements, and then do the least we possibly can to achieve them.
Keeping the number of architecture decisions as small as possible, while ensuring that the technical staff meets key system priorities.
This idea sounds, like many other propositions in the software industry appear easier to apply than they really are.

However, architectural decisions are those that must be made from an overall system perspective. Essentially, these decisions identify the system’s key structural elements, the externally visible properties of these elements, and their relationships. Ultimately they define the architecturally significant requirements.
If you can achieve the requirement by deferring the decision to a lower level, it is not architecturally significant, and the decision is not an architectural decision at that level of scope.
That’s another misconception about software architecture. In general we use to think that architecture exists only on the high level realms and that the software architects are the only ones making architectural decisions. At any level of abstractions architectural decisions are being made to address the balance between assumptions and requirements at that level.
If we let the people that are closer the problem have more freedom in solving it then there is innovation happening every where on the stack.
The key is to make sure that at any level we set as fewer constraints as we can but not fewer than we need to fulfill the requirements at that level. When that balance is achieved there is more flexibility on the system that allows full participation of the staff.
For example, if the system under consideration is an individual application, we should defer any decisions that component designers or implementers can make to them.
These decisions should not become part of the architecture. If the architecture’s scope is a family of applications (or a product line), then you should defer any decision that relates to only a single application (or product). Such a decision belongs at the level of the application architecture and is not part of the application family’s architecture.

resilience.org Blog

Managing outsourced teams. Balancing innovation with predictability.

Got Architecture?