1. Choose a partner who delivers early and frequent business value
One of the hardest parts of Agile Offshoring is choosing the right partner, but investing the time to choose the right partner pays dividends for years to come. A partner must have the right mindset to understand the meaning of business value. If you have conversations with a potential partner and they never once mention delivering value. Pause. Take a step back. And proceed with caution.
Partners who love to collaborate on daily basis to understand the end customer’s priority and capable of absorbing fast changing business conditions and translate the same into working software may be best suited. Avoid getting into T&M and fixed bid contracts since they almost never turn out well for either party. In case you don’t find a partner whom you are looking for, get into outcome based contacts, where the dollars billed are proportional to the outcome delivered.
2. Remember The Cultural Context
When I give training classes to companies who either have a large offshore contingent or a significant South Indian Expat employee base, I ask the same question, “How many of my South Asian colleagues have received any kind of North American cultural training?” Usually, some hands go up. Then I ask a different question, “How many of my North American colleagues have received any kind of South Asian cultural training?” Usually no hands go up and the look of realization starts to cross peoples’ faces. A Cultural change may make or break new products. Indeed, this could be a major reason why several organizations have problems adopting agile methods.
Many companies operate with a command and control model which assumes that seniors make all the decisions and people below execute them. To make agile methods work, there needs to be much more autonomy, freedom and decision making given to the teams which do the actual work. This problem can be compounded when you choose a partner based out of Asia.
There are few environments where people are often discouraged from asking questions, talking about problems openly, warning about unfeasible deadlines, or proposing alternatives to perceived instructions from superiors. This makes addressing problems very time consuming, since they are not raised when are spotted. So in the truest sense making teams truly self-organizing is still a nightmare in some Asian cultures. Middle managers, who are getting pressure from Sr. Management, push this pressure downward to their direct reports. When we start talking about self-managing teams and middle managers as people developers and coaches, this could be viewed as a destabilizing anti-authority attitude. It will still take time in Asian cultures to get the best out of teams.
3. No Big Bangs
Big bangs always lead to explosions, so it is advisable to start small and progress gradually towards scaling to next levels. Changing multiple variables simultaneously, without doing proper due diligence, could invite quick disaster. It may inevitably leads to more stress, confusion, frustration and finger pointing. Do not dump everything at once on offshore, unless you are sure that it working for you.
4. Use high-fidelity communication techniques
Agile distributed teams, who are non-collocated, may not always get sufficient time to talk to each other. Continuous flow of communication across locations is the most important parameter for the success of agile teams. Miscommunication between the locations leads to all manner of waste and headache. Invest in engaging teams in several small and frequent powerful conversations, across the locations. A high fidelity in house video conferencing is a best way to replace face-to-face communication.
Other options that can be looked upon are tools that facilitate instant messaging
- Webex sessions
- Screen sharing
- Desktop/laptop video conferencing tools like Skype, Google Hangouts.
Get multiple modes of communications were established and working early before offshoring begins. Try minimizing the document driven approach with the offshore teams.
5. Ensure Your Product Owner is Available and Engaged
The Product Owner’s availability to offshore teams plays vital role for teams to understand what they to work on. The product owner should spend as much time as possible in the same room as the rest of the Scrum team. Remote product owners should be on-site at least for the release planning, the review, and the retrospective meetings. There are several recurring issues with distant product owners, including mistrust, miscommunication, misalignment, slow progress and lot of email communication.
6. Promote “ONE TEAM” behavior
In most of the distributed teams, the teams located in either geography often behave as different teams. There is often lack of trust and miscommunication surface between them. They also tend to throw at each other to cover up mistakes. Offshore team members must gain the trust and understanding to make their own decisions, instead of waiting for the onsite team. Promoting ONE team behavior is a great challenge for the management. ` Few techniques that are worth experimenting are
- Create Proxies for PO and ScrumMaster to avoid a communication gap. A proxy is a person acting as a placeholder for the actual person behind the scenes, who shows up when needed.
- Establish working agreements with the WHOLE team.
- Create Definition of Done and Definition of ready with the WHOLE team
- Have all scrum ceremonies with WHOLE team.
- Communicate the customer feedback with ENTIRE team.
- Make one product backlog for ENTIRE team.
- Try to mitigate the time zone differences through negotiations
- Do not create development and testing teams separately at onsite and offshore, instead encourage everyone do a bit of both.
7. Encourage Excellence in Engineering Practices
XP practices across the global locations for to increase productivity. A few examples of useful XP practices are:
- Pair programming strengthens the behavior of collective code (shared code) ownership across the team. It also mitigates the risk of attrition or key personnel loss in the team.
- Encouraging test-driven development and acceptance test-driven development increases the code quality and protects the team and product from scope creep/gold plating.
- Continuous integration enables the smooth integration of software development across the geographic locations. The customer may also try his hands on the latest work developed and correct any misunderstandings of the requirements.
- Continuous refactoring and deployment reduces the technical debt and increases the customer satisfaction.
- Code reviews, Test Automation and exploratory testing increases test coverage and code quality.
8. Enable a Continuous Feedback Loop with the End Customer
Often requirements are seen as bullet points which the developers have to implement. The importance of feedback loop is often forgotten, since the offshore teams are not connected with the end customers. On an agile project, if customer and development team work together more frequently, it will help each other to spot the difference of understanding instantly. Moreover, due to less rework, it is easy and cost effective to change a system that was partially developed. It is advisable that remote/offshore teams demo the software to the end customer to increase collaboration between developers and customers.
9. Invest in short visits
Investing in short and frequent visits for events like release planning play an important role to increase good personal relationships among the teams. These visits which can be of minimum 2-4 weeks also help teams to maintain the relationships and trust which need to be in place for remote communication to work effectively. The problems which may cause lasting damage to the project can be repaired easily with the human touch involved during these short visits. Dinners and sightseeing can often be the most useful activity that the visitors can do with the hosts.
10. Use common collaboration tools and repositories
There are several tools available in market place that increases collaboration between onsite and offshore teams. Make sure you have proper source control. Creating a robust repository for both teams to share their source code like SVN is a good way to start. Both teams can also record all their specifications, test cases and other design artifacts. Both teams may also share a combined task wall during their daily standup. Commercial tools like Rally and VersionOne may be used for creating product backlogs, sprint backlogs, and burn down charts.
Several free tools for defect tracking like Bugzilla may be evaluated. Unit testing tools like Junit, cyclomatic code complexity tool like SONAR are few good options for teams to understand their technical debt. To help circulate common information, Wikis work well because they are simple to use, can be worked with any browser, and are simple to set up.