Selecting The Right Model: Dedicated Teams
If you are searching for an offshore partner, consider how the selected schema will affect communications and collaboration. Agile development processes require an open environment, tight integration among teams, sharing common goals, understanding business value, and frequent communication. The more barriers we have between engineers, customers, users, managers, and other stakeholders, the harder it is to provide a base for agile software development. The fewer middlemen you have, the faster the team will exchange information. To build partnership or ownership relationships with off-site teams, successful companies must allow maximum transparency and integration between teams.
Large companies like Sun and SAP work this out by establishing their own branches in other countries. This makes economical sense if a {sidebar id=1} company wants to have more than 100 engineers in its overseas development center. Successful small and mid-size companies overcome the costs of handling remote office set-ups by using offshore partners to provide dedicated development teams (also known as Offshore Development Centers or ODC). In these scenarios, offshore provider is not a company which delivers software code for a fixed bid. It is a company which provides to the client excellent human resources covered by reliable physical, legal and IT infrastructure. A good offshore partner must have an ability to attract and retain great people in offshore locations and take care of all of the overseas issues. It is also highly recommended that this partner is incorporated in a location with a reliable legislation system, like the United States, and has effective insurance.
To leverage the full benefits of such deals, engineers must be assigned to one client and team retention rates must be good in both companies. The offshore partner must provide transparent communications to the client on every level, including developer-to-developer communications. People must speak one language without a translator. In successful engagements we see that people in remote offices share the values and corporate culture of both companies.
Agility, productivity, speed and shared values provided by a dedicated team model become specifically important for product development arrangements. We have built this experience with clients developing their own products in different ways, such as:
- SaaS (software-as-a-service) providers
- "Web 2.0" and other start-ups
- Companies from such vertical industries as real estate, insurance or financial services which have software at the core of their services
The common trait in all of these engagements is the focus on getting the maximum productivity out of the development team, not a focus on building requirements up front and preparing RFPs for fixed bids. Close communication with their offshore dedicated teams helps the clients adapt to changing market conditions and manage tough deadlines at the same time. Maintaining the knowledge within the dedicated team is also crucial for fast and high quality product development.
To get the maximum benefit of dedicated teams you should focus on human factors issues. For example, if you want to help your offshore partner to bring the best engineering talent into your team, you should be ready to send not only bug-fix level assignments but also higher level activities, such as design or architecture. And, just as with a local team, it is extremely helpful to praise good work and show the developers that results of their work are really helpful to your business. These motivational efforts pay for themselves as they help build dedication to your projects across the globe.
Using The Right Practices And Tools
Successful software development teams employ well known practices like common coding standards, a source control server, one-click build-and-deploy scripts, continuous integration, unit testing, bug tracking, design patterns, and application blocks. These practices must be applied to distributed teams more strictly than to local teams.
For example, consider continuous integration. It can be extremely frustrating to come to work and get a broken build from the source control server, while the person responsible for this is several thousand miles away and might be asleep at the moment. What might be not as big an issue, if it were done by the guy sitting at the next table, might become a major problem in a distributed scenario. This impacts productivity and communications. Sticking to continuous integration practices and installing the corresponding server team-wide (such as Microsoft Team Foundation Server, CruiseControl.NET, CruiseControl) minimizes such risks.
At Murano Software we have internal project called "Project Portals" devoted to enhancing the communication between distributed team members and easing the access to high-level project information for project stakeholders. At first this was a pure Microsoft .NET solution. Then, Windows Sharepoint Services (WSS) came into the market and we utilized its base engine. We advise other software development companies to take a look at hosted or in-house WSS solutions.
Wikis naturally fit and help agile development in distributed teams, so we developed our own wiki for our Project Portals and integrated it into the WSS solution. The next version of Windows Sharepoint Services is planned to have wiki among its standard features, so you have a chance to get it as a perk.
Teams working on the Microsoft .NET platform are in a great position with the features provided by Visual Studio Team System (VSTS) right out of the box. These features help you to maintain a lot of best practices mentioned in the beginning of this section. Consider the VSTS source control system. To say that it is a leap ahead SourceSafe will not be sufficient. Besides the common source control features, which you usually get from the market leading software packages, with Team System you also get an opportunity to set up check-in policies. Have you ever had the frustration of checking out a build in the morning that does not compile? Now you can set up a policy which will force developers to test build the project before checking in. You can also force them to run unit tests.
Both build routines and tests merit attention. If you are familiar with NAnt or another modern build engine, you will understand the usability and flexibility of VSTS builds. What may intrigue you is the fact that VSTS has build management capabilities and reporting with the power of one integrated platform. Similarly, if you are familiar with NUnit or another modern unit testing tool, you understand the basic unit testing features of VSTS. But VSTS is also full of goodies for us. Besides basic unit testing, it includes web and load testing, test coverage, static code analysis, bug-tracking, test cases management and tracking. And once again, we get additional benefit of having one integrated platform. Add project management features, Dynamic System Initiative (DSI) diagramming tools, reporting, customizability, integration with MSF for Agile Development, available books, support, documentation and education and you will get an idea why there is a buzz around VSTS. WSS is also tightly integrated with Visual Studio Team System and you can use these features right out of the box without the need for custom development.
On our Java projects we use de facto standard open source products like Subversion, Ant, CruiseControl and JUnit combined with the same communications infrastructure we use in our .NET teams.
From an IT infrastructure point of view, our teams use a VPN to provide equal access to shared resources. The VPN environment, being less strict than a public network, also allows using such features as Windows Live Messenger's Application Sharing, Video and Voice calls, Remote Assistance, and Whiteboard.
Communication, Communication And More Communication
Working remotely, small misunderstandings quickly grow into bigger problems. On distributed development teams, managers must pay attention to communication practices which they sometimes omit without negative consequences in local development. This includes regular (daily/weekly) reports and status update meetings, which allow the team members to synchronize, discuss achievements and reveal problems. Managers should also try to build personal relationships among teams through introductory meetings, onsite visits, team-building activities, and other methods.
When working with offshore teams, development managers should be aware of language, cultural, and time zone barriers and must find ways to surmount these obstacles. Globalization slowly but constantly erases the cultural distinctions in the professional environment, but there are still cases when cultural differences bring confusion.[1] Language issues are much easier to detect, though it does not mean that they are easier to overcome. Where companies face a language barrier, it is common and highly desirable to have company-sponsored language training for employees. In most of the offshore development countries, professionals are motivated to learn English so it is usually people in offshore locations who get language training.
Time zones specifically make the process more difficult. But it turns out that in countries with mature outsourcing industries, software engineers are usually ready to adapt their working schedule to work with overseas counterparts. There are two strategies to deal with time zone differences. The first is to separate teams by activity, such as having quality assurance and product managers onsite and developers overseas. This allows developers to implement fixes and new requirements while their counterparts are sleeping and vice versa. Of course there should be overlap in working schedules (at the beginning/end of working day). The second approach is to divide projects into blocks and try to assign each block to one location, delegating as many functions as possible to this location. The second approach forces better communication, thus better serves agile development, but both of them work and sometimes there is no choice.
Pay attention to building personal connections among teams. At Murano, we start every project with introductions via Skype or MSN. Cordless phone sets, compatible with Skype or other telephony services, make VoIP calls convenient.
We also highly encourage members of distributed teams to fly and see each other occasionally. A project kick-off or some major milestone might be a good choice for such visits. If you have team of ten engineers working overseas, having several weekly trips for different team members during a year is a good compromise between travel expenses and building good interpersonal relations. International airports and flights with fewer connections, rich cultural heritage, personal security and cultural proximity of cities like St.Petersburg (Russia) are all reasons why Eastern European countries like Russia and Ukraine are growing as outsourcing destinations.
Conclusion
Choosing the right model is very important, but it does not guarantee success. For offshore agile projects, we highly recommend that at least one party has experience in agile development, preferably in a distributed environment. The lack of face-to-face communication, time, cultural, and language differences requires attention and investing additional efforts to get the desired results. But these investments are far outweighed by the benefits of having a good offshore partner, which might be summarized as "getting more for less." This positive balance would be impossible without tools, empowered by the great communications infrastructure now available globally.
[1] This important topic includes a wide range of country-specific issues, and thus is out of scope for this article.
About the Author
Andrew Filev (MCA, MVP) is Vice-President responsible for Offshore Operations in Murano Software. He establishes offshore development centers, and leads and motivates teams. An excellent communicator, Andrew fills the gap between different cultures and builds lasting partnerships with clients. Andrew has worked in St. Petersburg, Russia and is now based in Los Angeles, CA.
