Top 10 things to think about when offshoring your agile development
- Choose a partner who delivers early and frequent Business value over fat invoices
One of the hardest parts of Agile Offshoring is choosing the right partner. Finding the right partner pays back in long term. A partner must have the right mindset to understand the meaning of business value. 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 as they never get you into a win-win situation. . 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.
- Do not undermine country specific culture
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 is even worse 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 really takes long time to address problems, since they are not raised when are spotted. So in true sense making teams truly self-organizing is still a night mare in some Asian cultures. The middle managers who are enough threatened of losing their jobs by agile adoption, often play the spoil sport. Bringing and anti-authority attitude may still take time in Asian cultures to get the best out of teams.
- Strictly, 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 set of 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. Take time to assess and understand each team and their continuous performance improvement, to make meaningful decisions.
- Use highly fidelity communication equipment
Agile distributed teams, who are non-collocated, may not always get sufficient time to talk to each other. Continuous flow of Communication across the locations is the most important parameter for the success of the agile teams. Miscommunication between the locations can lead to building the wrong functionality which may jeopardize the customer satisfaction. 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. It is preferred to get multiple modes of communications were established and working early before offshoring begins. Try minimizing the document driven approach with the offshore teams.
- PO availability is vital
Product Owner’s availability to offshore teams plays vital role for teams to understand what they to work on. It is recommended that 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.
- 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 communication gap. A proxy is a person acting as a placeholder for the actual person behind the screens, 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.
- Encourage using best engineering practices
The extreme programming (in shot XP) suggests the use of best engineering practices across the global locations for teams to increase productivity.
Few examples of best engineering 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, acceptance test-driven development increases the code quality and protects the team and product from scope creep/gold plating.
- Continuous integration enables the smooth flow 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.
- Enable 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.
- 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 a 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 do with the hosts.
- Use common tools and repositories
There are several tools available in market place that increases collaboration between onsite and offshore teams. 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, Versionone may be used for creating product backlogs, sprint backlogs, burn-downs on a daily basis. 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.
Wiki could be good option for circulating common information, Wikis work well because they are simple to use, can be worked with any browser, and are simple to set up.