WebMethods development across distributed teams offers many benefits but also introduces significant challenges. Some research indicates that more than 90% of communication effectiveness is determined by non-verbal cues. Communications between teams in multiple locations and multiple time zones can be challenging because in person discussions are often replaced by telephone calls and written communications. Language and cultural differences provide additional opportunities for misunderstandings. Team members also do not have the opportunity to “see” their coworkers at work and thus do not always have good visibility into what they’re delivering. The resulting misunderstandings coupled with a lack of visibility can lead to mistrust between coworkers limiting the productivity of the entire team. TEAM Server helps bridge that gap by increasing both visibility and accountability.

There are two basic ways to distribute webMethods projects across multiple teams. One is to distribute the effort across teams performing the same function (like Development or Testing) and another is to assign functional teams to a specific location.

Distributed Functional Teams

For example, let’s say your project’s development team is distributed across 2 or more regions. How do you hand off development artifacts between developers? How do developers tell each other exactly how far they got? And how do they tell each other what changes were made to the program logic?

TEAM Server gives team members the ability to manage multiple lines of code, track all changes to the program logic, and see exactly what changes are applied by each developer. This added level of visibility minimizes miscommunication and allows all developer to see exactly what changes other developers are making to the project.

Distributed Teams Organized By Function

A tightly managed and automated application development process allows distributed teams to work more confidently. TEAM Server provides a framework upon which automated processes can be built.

• Development teams can very easily hand off new builds to the QA team.

• QA teams can use promotion rules to automatically reconfigure the build for deployment to the QA environment. They can also use TEAM Server to verify that, with the exception of the new code, the current QA environment is a mirror image of the Prod Environment.

• The Administrators within the Operations team will have the same abilities as the QA team. In addition, all actions will be audited so Administrators will be able to know who, when, and what changes have been made to any of the environments.