In-Depth

Collaboration Tools Go the Distance

• By Alan R. Earls
• September 1, 2005

Talking Points
RIGHT TOOLS IN THE RIGHT PLACES

• The software change and configuration management category, which
  includes version control tools, traditionally has been key to bringing distributed
  development teams together.
• An on-demand Web service provides developers and testers with a lightweight
  environment that aims to let them focus on coding and testing rather
  than managing tools and reporting status.
• One analyst suspects the market for collaborative development products is
  less than $100 million in sales today, but could easily grow to $500 million
  within five years.
  

Guy Shaviv, VP of engineering at Virtio, a vendor of software simulations for embedded devices, could be the poster child for software development managers who oversee teams dispersed around the globe. This software everyman is in a hot seat that’s hotter than most. The company’s products are a critical element in the design and development of mobile phones and other products with embedded intelligence—a first step in a complex value chain on which hundreds of millions of dollars in sales can depend.

“Without the simulation ability that we provide, these products would take many more months to bring to market,” he says. And, by implication, if software isn’t ready and working when it is needed, the consequences can be calamitous.

Shaviv has managed to not only survive but also prosper by implementing basic management practices and by adopting tools from Rally Software Development designed to support collaborative, dispersed teams. Even with the best tools and techniques, managing a dispersed development team can be a challenge. However, the right tools and the right management techniques can make it only a little more difficult than managing a software development team under one roof.

Work here and there together
According to Gartner analyst Matt Light, distributed development teams have a history of using a very wide range of development tools for management, requirements modeling, app simulation, change and configuration, and version control. All those elements can have a role in any development process, but that role is magnified when teams are separated by time zones, language and cultural differences. Although Gartner has not done a formal market study, Light suspects the market for collaborative development products is less than $100 million in sales today, but could easily grow to $500 million within five years.

The one category that traditionally has been most important for bringing distributed development teams together is the software change and configuration management category, which includes version control tools, says Light. “If I’m working here, and you are working over there, and I make changes, you need to know which version we are at, and if either of us makes changes and it disrupts the system, we need to be able to go back out to the original version,” he explains. Software change tools take on an extra importance in distributed development.

Then there are development zones—Web-based tools that typically have some change management capability as one of their central features but also increasingly support other aspects of collaboration. “At Gartner, we call those collaborative arrangements ‘development zones,’ ” he says. Development zones may not include the software change management capability but do have other useful things for solving defects as well as for process management, whereby a formally defined process is implemented across the distributed team. “You have roles and responsibility and procedures clearly defined and collaborative development zones can help control that,” says Light. “It can even help manage assets like components.”

Rallying for the cause
Rally, one of the new companies that have flocked to the space, focuses on managing the entire software lifecycle to help integrate business and technical teams in a collaborative environment. As an on-demand Web service, Rally provides developers and testers with a lightweight environment that aims to let them focus on coding and testing rather than managing tools and reporting status. For example, it provides team members with personal home pages that can alert individual team members of priorities and commitments; updates tasks, defects and tests; and allows access to recent work products. It can also communicate handoffs, blocks and readiness to synchronize teams and allow individuals to easily move between multiple projects and products.

Shaviv says Rally has been an important factor in his success, allowing his core group, with 10 developers, to work closely with a seven-person Moscow team and a key developer in Utah. Tools alone don’t eliminate all the challenges. Overcoming the time zone barrier, for instance, remains an effort. And culture presents formidable obstacles. “What we learned is that the good engineers in Moscow are just as good as the good engineers in the U.S.” However, adds Shaviv, “After starting to work with them I discovered they had a tendency to analyze and overthink more than us—they can give you a perfect solution to the wrong problem.”

Shaviv says he adopted both Rally and an agile development methodology, at about the same time he began his relationship with the Russian team—a lifesaver for structuring such a project, it turned out.

Agile development, he explains, is the idea that you don’t try to design the whole thing up front—you design on demand and you proceed with small iterations. “You design in two-week iterations and then close the loop by doing a demo,” he explains. The discipline comes from the requirement to demonstrate working software every two weeks and everyone—engineering, management and even marketing—participates in the demos, he says.

Shaviv says Rally has supported the process by helping to define tasks then tie them directly to requirements. “By being able to do that online I have, in effect, a daily progress report on the Moscow team, and based on that we can decide on the fly whether their features will be ready for the next iteration or whether to drop it for now,” Shaviv says.

“We chose the tool that would fit in our current practices and help us automate them and make them more efficient, rather than a tool that would change the way we do things,” he adds. And, he concludes, the main benefit of the tool is the formalization of processes that were conducted manually, which means information has become more visible and less likely to be lost.

The mix always changes
Although most of his resources are based in the U.S., David Steingart, IT manager at Assurant, a specialized insurance company, faces similar challenges managing development teams at multiple locations. Those locations include Minnesota, Wisconsin and Florida, where employees focus on the maintenance and upgrade of a wide range of business systems, “as well as people working offsite, consultants and even some offshore resources,” Steingart says.

“We have a portfolio where the project mix is always changing,” he says. Usually there are several projects going on at any one time, each involving multiple locations.

Steingart says his initial efforts at managing dispersed teams relied on Word documents and Excel spreadsheets and communications. “Even though there may be documentation passing back and forth, the biggest issue is still how to keep everyone on the same page,” he says. “Spreadsheets and Word documents can do it, but they are very prone to disconnects in terms of who has the most current information and whether everyone is seeing the same information,” he adds.

Steingart says what’s been most helpful are the IBM Rational tools Assurant recently adopted: IBM Rational RequisitePro for requirements management; IBM Rational Rose Enterprise for visual modeling of business processes; IBM Rational ClearQuest for defect tracking and workflow management; IBM Rational TestManager for management of test plans and assets; and IBM Rational Robot for automated functional and regression testing.

The development team also used IBM Rational Unified Process to complement its established software development process by providing how-to guidance for development activities throughout all phases of the project. “Now we have a central repository for requirements information and tracking defects, and everyone has remote access to all the same information, which is key,” he says.

The IBM Rational tools also provided support for geographically distributed development because Web browser access to requirements is available in Rational RequisitePro and to defects in Rational ClearQuest, which ensures that everyone on the team has convenient, secure access to the same, up-to-date project information.

Steingart says: “The Web interfaces to Rational RequisitePro and Rational ClearQuest have been a big help because they make it easy for distributed locations to get access to all our data. Distance is almost immaterial nowadays, but what does matter is getting the needed information to all your locations. The Web interfaces allow us to have the same information everywhere, no matter where they happen to be….We are starting to do more outsourcing and we are finding that these tools help control project information regardless of project organization.”

“Before we adopted these tools, all of this was mostly done by spreadsheet with a line for each defect, a description and a listing of who owns the defect,” Steingart says. “But that’s very difficult to manage because you really don’t know who is working on what. With a central repository you know what issues are open and what issues are closed, and at any point you know where you are with regard to requirements, tests and defects.”

Steingart says, although he hasn’t conducted a formal ROI study, he is convinced his team is more efficient because now, “We all know what the score is. We’ve got all kinds of projects, and we do a lot of Web development for client facing applications that are used by agents,” he says. Those projects are big, costing hundreds of thousands of dollars or more, and some of the newest projects involve .NET and mainframe development. “Which platform is being used doesn’t matter because usually the projects use them all, but the tools don’t care what kind of development you are doing,” Steingart says. “It is more about the data you are collecting rather than the platforms you are working on.”

A one-man team that’s everywhere
New Mexico Technology Group has a major development contract with the U.S. Army for communications software. Judy Mills of NewTec has adopted Alexsys Team 2 software to manage software developers nationwide. Alexsys Team 2 software is designed to achieve time and cost savings and on-time project delivery using a company’s existing processes. The product focuses on helping management balance individual workloads and document a project’s entire history.

Mills says that NewTec started with 20 Alexsys Team 2 licenses and now has more than 80 developers across the nation using it to manage their workloads, including work requests and change requests.

CM II certified, Mills is configuration manager for NewTec, and is in charge of running the development group. Mills uses Alexsys Team 2 to track her developers’ progress, manage the tasks associated with completing projects and report to her management. Her off-site developers log into Alexsys Team 2 via Team Web to manage their own workloads.

Mills says she discovered Alexsys Team 2 in 2000 when NewTec won the contract with the Army. She looked at many off-the-shelf products to manage her team—considering product requirements, testing and anomalies. She settled on Team 2 because it could be modified and could work with the processes already in place at NewTec. In addition, NewTec has expanded its use of Alexsys Team 2 to manage the distribution of their software—version documentation, for example—as well as to log and track help desk requests through the entire software lifecycle.

Before implementing Team 2, “I was a one-man team and was tracking these items using forms in Microsoft Word,” says Mills. It was taking many hours of each day just to keep these forms updated as changes were being made at all work sites, including Ft. Lewis, Wash., Ft. Hood, Texas, and Severna Park, Md.

“By selecting and implementing Alexsys Team 2, this saved me and my company a minimum of six hours per day, and the cost of Alexsys Team 2 was less than the cost of my labor for doing this job,” Mills says. What’s more, she adds, Alexsys Team 2 was easily modifiable to fit the configuration management process she previously documented and implemented. In addition, the tool allowed off-site personnel to enter and update their own work requests in Alexsys via Alexsys TeamWeb. “This saves me many hours of follow-up on the status of the work requests, which was another cost saving in labor,” she explains.

Secondly, by using the Source Off Site product, off-site personnel are able to submit/reserve/replace source code files into the CM baseline at Ft. Huachuca, “which allows CM to control all the product source code that we develop and maintain,” she explains. Mills says she uses Visual Source Safe as her version control product. “VSS is not the best product, but it is included as part of the MSDN package that all of our developers use—and it’s virtually free,” she adds.

“We also control our software release baselines and documentation in VSS, which allows us to know exactly what is in every product release that we produce,” she says. Mills says using SOS has resolved many problems, including overwriting code, submitting the wrong files and accidentally eliminating newly created files. It also saves time expended to troubleshoot CM software build problems.

“I have never computed the cost savings by using SOS, but I know it has saved us approximately two to three days work per CM build,” she adds.