Collaboration Tools Go the Distance
- By Alan R. Earls
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
“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
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
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,”
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
“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.
By John K. Waters
Software configuration management
By Linda L. Briggs
Cross the trough
By Venkates V. Swaminathan