News Stay informed about the latest enterprise technology news and product updates.

Making agile software development work for distributed teams

Distributed agile software development may seem like an oxymoron, but is seeing success with the help of GlobalLogic and Velocity, its distributed agile development methodology.

Distributed agile software development may seem at odds with a methodology that has its roots in small, co-located teams. But with the realities of today's global workforce, organizations are adapting agile methodologies to meet the needs of distributed and offshore teams to leverage quality, productivity and efficiency benefits.

We felt we could develop the product faster and with higher quality given our resources using an agile method.
Bill Briner
Assistant VP of product

One such company that doesn't believe "distributed agile" is an oxymoron is GlobalLogic, a product development lifecycle services company with global delivery centers in the U.S., India, China and Ukraine that has developed a distributed agile methodology called Velocity. The majority of GlobalLogic's customers are small to medium-size software product companies.

"Working with small product companies, by necessity we had to be very agile," said Stuart Donovan, chief technology officer of GlobalLogic, headquartered in Vienna, Va. "We developed a more structured set of agile processes."

GlobalLogic Velocity includes the Velocity Method, a blueprint of processes, templates and behaviors; the Velocity Platform, GlobalLogic's implementation of best-of-breed open source and open source-derived tools for communication, tracking and configuration management; and Velocity Frameworks, reusable product frameworks that can be used with standardized architecture and technology stacks.

Still, managing distributed teams can be hard enough with time zone, language and cultural barriers, but distributed agile teams?

"There are always concerns having distributed teams, and agile seems to be somewhat at odds with that," acknowledges Bill Briner, assistant vice president of product management for, an event registration service provider in San Francisco and a GlobalLogic customer.

Yet Briner knew he wanted to use agile to develop a new product, and he also needed to outsource the development. "The company had decided to go after new markets with new products. We surveyed the market to find suitable suppliers/vendors for the development effort because we knew we couldn't do it locally -- the costs are too high," he said.

Acteva chose GlobalLogic because its business model focuses on product development vs. in-house IT projects, Briner said.

"We also knew we wanted to use an agile-based process even though we weren't using it in-house. GlobalLogic was the only one who had that baked into their DNA," he said. "We wanted to use agile primarily because Acteva runs a pretty lean ship, and time to market was critical. We felt we could develop the product faster and with higher quality given our resources using an agile method."

Donovan said that about one-third of GlobalLogic's customers are familiar with agile and execute agile. The other two-thirds understand agile and want the benefits, but they don't want the overhead of constant collaboration with teams.

"We have to educate them on not doing a lot of upfront planning, but to start developing as soon as possible and give us feedback on releases, and not specifying requirements to the nth degree," he said.

More information on agile software development
Alistair Cockburn on what's agile, what's not

Agile software development: Proving the benefits

Podcast: Discussion of agile methodologies with Venkat Subramaniam

The biggest challenge to doing distributed agile is communication, Donovan said.

"We have to make sure the team is using the same language -- that everyone understands the progression of requirements to actionable pieces of work -- and to track and collaborate on things in iteration in rapid form," he said. "When we used to do XP [Extreme Programming] in the early 2000s, we were co-located in most cases, and we could walk to the next office and ask the customer. With Velocity, the tools allow us to collaborate on individual items in an asynchronous but rapid manner."

Atlassian Software Systems' JiRA product (a workflow and tracking system built on open source components) forms the core of the Velocity Platform. Atlassian's Confluence product enables communication and collaboration through voice media, wiki, charts, reports and graphics. Test automation tools cover unit, integration, regression and load testing needs. Open source and open source-derived tools such as Subversion, Quickbuild, Fisheye and Clover are integrated with JiRA and Confluence to provide a CM and build management platform.

"We wanted the ability to deploy tools in any location so the partner can have complete control of IP, and to have them be relatively inexpensive," Donovan said.

Trust is key 
Before any tools are deployed, a GlobalLogic engagement starts with establishing trust, Donovan said.

"When adding talent to a team, especially cross-cultural, challenges occur. Our approach is to gain the trust of that partner and to spend time on shore with them in their location," he said. "We don't believe you can develop product effectively without any face time between teams. When we're establishing the relationship, we often get involved in non-core activities. As we gain the trust of the engineering group, we move to other areas."

As part of the inception process, GlobalLogic also establishes certain protocols, one of which is a communication plan. "We make sure both sides understand the touch points and how the roles communicate and what medium is used to communicate," Donovan said.

Another part of the inception process is to establish a common set of tools and connectivity points. "If they don't have collaboration tools we insist we use ours," Donovan added.

GlobalLogic also encourages a lot of back and forth travel, Donovan said.

"About 75 to 100 of our people are onshore at client locations at any point in time. We encourage partners to visit our locations with their senior and technical people every six months, for the motivation of the team and to make sure there's a good understanding of where the business is going," he said. "You can't do agile unless the team has an understanding of the big picture and business priorities. A lot of the best practices in Velocity are how to create the right mix of person-to-person, on-site communication, and distributed, asynchronous structured communication."

GlobalLogic recommends dividing work by component module rather than role, Donovan said. "In some cases you do testing in one location and development in another; the teams get into a cycle of requirements/analysis/design in one location, then hand it off," he said. "We don't recommend jumping into the deep end with a distributed agile team that is working on the same set of stories at the same time. That's something you can evolve to; but it's better to divide the work geographically and have local stand-ups."

Donovan said Velocity looks similar to Crystal, another agile development methodology, and has a longer release cycles than XP. He said the iterations are between two to three weeks, and the release cycles are two to three months.

There are some tenets of agile that don't work as well for distributed teams, Donovan said, such as distributed standup meetings, which is why GlobalLogic recommends local stand-ups and to do global stand-ups only when required. Pair programming is also very rare for distributed teams.

"The segmentation of work is different; you have to think about and plan for that. Do modules and layers, and slowly increase the breadth of involvement of distributed teams," Donovan said.

Acteva pleased with GlobalLogic
For Acteva, the methodology appears to be working so far. While GlobalLogic typically partners with its customers to extend their own teams, some customers, like Acteva, hand off the entire product development.

"They are our engineering department; they have a product manager as part of the team, he's the customer proxy," Briner said. "We provide him with use cases and requirements and spend time going over those with him. He's been here several times."

Briner is also pleased with the communication and collaboration tools GlobalLogic provided.

"We made an edict that no product requirements discussion would take place in email -- everything happens through the wiki and Velocity tools. Everything is documented in the Velocity tools," he said. "Through the tools we have total visibility into what's going on. Every time something gets updated we get notified, and we can comment, add requirements, correct things. I have a dashboard, and I can see iteration by iteration. The tool is really the project; it's how we manage."

Acteva selected GlobalLogic a year ago November, and they are just starting the 20th iteration, Briner said. GlobalLogic delivers a working version of product every two weeks. He expects the first deliverable this January.

Developing the product this way has speeded time to market, Briner said. "It has allowed us to look at things in smaller pieces. It's easier to communicate requirements, requirements are more easily understood, there is less room for error, you get to see results faster, and if you missed the mark you haven't missed it by much and it's easier to correct."

Anecdotally, Briner said the quality is better as well. "I feel we have a higher-quality product because agile is very focused on test-driven development and CI [continuous integration] types of processes," he said. "The truth will come out when we go into production."

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.