Offshore Software Development and

There are two trends that allow people to get more or less: agile development and offshore outsourcing in modern software development. Agile processes are traditionally implemented in one site, where customers and developers can meet face-to-face and communicate easily. Offshore development projects, on the other hand, are traditionally implemented as fixed-bid consulting agreements, executed either using waterfall processes or at best in iterative way. Our successful projects have employed a mix of agile techniques and organizational models. However, it is possible to use agile software development process when working with offshore teams.

Teams with Dedication

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. If you are searching for an offshore partner, consider how the selected schema will affect communications and collaboration. To build partnership or ownership relationships with off-site teams, successful companies must allow maximum transparency and integration between teams. The fewer middlemen you have, the faster the team will exchange information.

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. Large companies like Sun and SAP work this out by establishing their own branches in other countries. This makes economical sense if a 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. 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.

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.Agility, productivity, speed and shared values provided by a dedicated team model become specifically important for product development arrangements.

You should focus on human factors issues in order to get the maximum benefit of dedicated teams. 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. These motivational efforts pay for themselves as they help build dedication to your projects across the globe. 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.

The Right Tools And Practices

The well known practices must be applied to distributed teams more strictly than to local teams. 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.

In the case of 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 minimizes such difficulties and dangers.

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 Murano Software. This was a pure Microsoft .NET solution at first. We advise other software development companies to take a look at hosted or in-house WSS solutions. Then, Windows Sharepoint Services (WSS) came into the market and we utilized its base engine. 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 Share point Services is planned to have wiki among its standard features, so you have a chance to get it as a perk.

Consider the VSTS source control system. To say that it is a leap ahead SourceSafe will not be sufficient. 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. 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 forcethem to run unit tests. 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.

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. 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. And once again, we get additional benefit of having one integrated platform.

Sharing of ideas

On distributed development teams, managers must pay attention to communication practices which they sometimes omit without negative consequences in local development. Misunderstandings are normal when we work together in remote. 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 like gatherings parties etc.

Language risk

Development managers should be aware of language, cultural, and time zone barriers and must find ways to surmount these obstacles when work with offshore teams. Globalization slowly but constantly erases the cultural distinctions in the professional environment, but there are still cases when cultural differences bring confusion. 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.

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. 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. 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.

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. 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.

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.