Outsourcing Via Distributed Agile Teams

The prospect of practicing agile in a geographically distributed landscape is fraught with challenges, but is not without opportunities. By definition, a distributed development team (sometimes referred to as remote teams or outsourced teams) consists of teams collaborating on a common project separated by cultures, time zones and distance.

The potential advantages of distributed development are

• Access to a larger pool of skilled labor
• Lower development cost
• Quicker time to market.
• Global presence
• Virtual organization

Conversely, its disadvantages are

• Communication: When you’re not face-to-face you are unable to observe body language which embodies a lot of valuable communication cues.
• Temporal: Finding common working times, increasing the communication challenges. To counteract these challenges, teams often find that they need to create more documentation than they normally would otherwise.
• Cultural: Different work ethics, commitment, holidays etc.
• Scope Creep: Scrum allows requirements to be flexible and if tasks are not well defined; it will lead to scope creep and incorrect effort estimates. In a distributed environment this can be a volatile combination.
• Effort: Consider how a distributed team with a team of developers in India (possibly with a scrum master) comes to terms on effort estimation with a product owner situated in another country, with different ideas about appropriate time and effort to be dedicated to a project.

It might seem as though the disadvantages outweigh the merits of a distributed agile development, but these challenges are by no means an absolute deterrent to successfully bringing projects to completion in an distributed agile development framework.

The 2014 Software Development at Scale Survey (Ambler, “Software Development at Scale:”) found that 39% of teams are (mostly) co-located, 23% of teams were near-located, and 38% of teams were far located.  Note that this survey only asked about development team members, not whether stakeholders were also physically present in the same location.

 

Previous surveys have found that it is rather rare for stakeholders to also be co-located with the development team, the implication being that 39% is a very optimistic estimate for how co-located agile teams are.

The 2012 Agility at Scale survey (AMbler, “Software Development at Scale:”) found that organizations are successful (the green bars) at all levels of geographic distribution. It also indicates that some organizations are failing (the red bars) at each level of geographic distribution. The implication of this study is that teams can fail or succeed regardless of how geographically distributed they are.

 

Teams co-locate because it maximizes their ability to communicate in person. Working in the same room is core to all agile methodologies, including scrum. As Ken Schwaber, author of The Enterprise and Scrum, said, “The best communication is face to face, with communications occurring through facial expression, body language, intonation and words. When a white board is thrown in and the teams work out design as a group, the communication bandwidth absolutely sizzles.”

Given that communication is such a significant part of the efforts involved in delivering software, why then are distributed teams so prevalent? The answer speaks to the reality of doing business today: a company’s need to have a global presence, to access global talent and to develop outsourced options. Although co-locating your team is the recommended, optimal approach for implementing agile processes, many teams are unable to do so for critical business reasons and must learn to follow agile principles and practices in a distributed environment.

All projects require some documentation. On agile projects, however, documents are useful only if they’re barely sufficient to serve the design, delivery, and deployment of a working product in the most direct, unceremonious way. When you work on an agile project, you concentrate on the documents necessary to support product development. Agile approaches dramatically simplify the administrative paperwork relating to time, cost control, scope control, or reporting.

As Martin Fowler puts it adequately,

“Agile methods downplay documentation from the observation that a large part of documentation effort is wasted. Documentation, however, becomes more important with offshore development since the face to face communication is reduced.”

Mat Simons of ThoughtWorks clarifies this further:

“Documentation must be created to serve a specific purpose, and after it has served that purpose you’ll all probably have more important things to do than keep updating the documents. It may seem counter-intuitive, but it’s often better to produce fresh documentation the next time when it is clearly required. A side benefit of starting over each time you need to document part of your project is that it’s great incentive to keep your documentation efficient!”

While documentation lends an important facet to communication, by itself it is not enough. Documentation needs to be augmented by formal modes of communication that enable teams to stay updated on team progress – easier said than done. One common pitfall that befalls communication among team members  lack of trust. In some cases, this comes from previous bad experiences, or those of others.

Teams often under commit or pad their estimates, due to fear of being responsible or blamed for failure. This is important because normal business behavior is very uncomfortable for most eastern cultures. People are often discouraged from asking questions, talking about problems, warning about unfeasible deadlines, or proposing alternatives to perceived instructions from superiors. A polite acceptance is important indicator that something is not being discussed. Therefore we must foster an environment of trust, such that the team can explore the causes of a mistake without finger-pointing.

As a stakeholder or product owner it is imperative to know in what direction the product development is headed. No amount of documentation or trust can allay their fears on progress. In distributed environments it is important to meet their expectations by producing a credible and working software product at the end of the release cycle (sprint). On projects using agile management, the only way to measure whether you are truly done with a product requirement is to produce the working product feature associated with that requirement. For software products, working software means the software meets what’s called the definition of done: at the very least, developed, tested, integrated, and documented. On an agile project,  if you’re 75 percent done, you have working product features for 75 percent of your project requirements — the highest-priority 75 percent of requirements. As it turns out integrating regularly and frequently assures the possibility of a working product at all times. Not only does it make the stakeholders confident of their partnership, but it also helps the product to evolve by helping the product owners to refine the requirement.

Driving down the cost of development is a cohesive effort that can only be met by a “one team effort”. In a traditional waterfall model, development is incremental, in contrast Agile by nature is iterative driven. Scrum’s early advocates were inspired by empirical inspect and adapt feedback loops to cope with complexity and risk. Scrum emphasizes decision making from real-world results rather than speculation. Time is divided into short work cadences, known as sprints, typically one week or two weeks long. The product is kept in a potentially shippable (properly integrated and tested) state at all times. This allows the business drivers to pull back or cut funding at any time without adversely negating their investment. 

Last but not least (and the most important) is the subject of negotiating contracts in an agile outsourced project. Agile outsourcing differs from traditional waterfall delivery methods in that the latter is defined by a fixed scope (requirements) while the former is defined by fixed time and cost (labour). The scope for traditional projects factors in  maintaining the risk register, project status reports, earned value report etc. In agile, scope is narrowed down to the business value delivered and working features. The size of the project is an estimation based on story size, points etc. based on mutually agreed parameters. It is possible to draw up an agile contract with a single Statement of Work (when requirements are clear) or a single contract with multiple SOW’s when requirements are not very clear (Only the objectives and goals are defined or partial requirements are available), with the first SOW aimed at delivering a working prototype or fulfilling the partial requirement.

 

Therefore contracts generally use the vocabulary of size delivered rather than scope delivered.

The future of business in a global economy lies in ideas that can be realized and marketed quickly. Outsourcing via a distributed Agile framework makes it possible for these ideas to come to fruition because now they can be supported by an effective, affordable developer community. That being said, making outsourcing successful also depends on factors such as the ability to respond quickly to changing market conditions, the ability to service unforeseen demand and access just-in-time talent, the ability to invest in critical research and development and tap high demand, low supply talent to deliver innovative products and services in a timely manner.