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.
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.
“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.
Do you know “How Outsourced Teams Bring Ideas to Life”? Watch out Jennifer Roberts, the CMO of Ekipa.co discussing on outsourcing strategies with Jijo Olassa of Verbat Technologies.
For more difficult plurals, check out this post covering https://samedaypaper.org/ research paper writing service everything from bacteria to criteria
October 1, 2015
About Prashant Thomas
Prashant act as a Delivery Head for North America and Europe in Verbat Technology, his experience dives deep in the field of commercial software architecture. He has won factory award for Certifying the FIX gateway for the OMS and factory award for developing a test automation suite for Long View Trading System in .net. Graduated in Masters of Science in Software Engineering from National University, San Diego, CA
Nowadays, enterprise software development is evolving at a fast pace. Every aspect of it is subjected to change: tactics, standards, tools, libraries, etc. Consequently, these changes bring new capabilities. As the business world becomes increasingly web-based, enterprise business applications play one of the leading roles for businesses. Below you’ll find some recent trends in enterprise software development for 2017 and beyond.
One of the things that have surprised me in the past few years is the size of the ecosystem around startups. We see the same ecosystems evolve in all the major hubs across the globe, but we lack an ecosystem for scaling up.
In my own journey the past decade, I have learned that it’s a lot easier to start up than to scale up. I’m aware that part of the problem is my personal DNA. Some people are good at starting, and some are better at scaling. However, most founders need to hang around fo
You may not have established your company. You may not have developed your product yet. But you have an idea. Moreover, you can visualize your project in works, you can imagine its results – that means that you have a vision that drives your ambitions. So what are the stages which lead to the creation of your product?(more…)