Agile Projects at Offshore
When the work piles up and the costs mount, shifting a portion of the work to outside teams, especially ones that can be hired at a reduced rate, may seem like a good idea and that's where offshore outsourcing and offshore development came in picture
However, what starts out as a well-intentioned shifting of a project can turn out to be a nightmare.
The Model
Most software companies use outsourcing at offshore not because they want to lay people off but because they have too many concurrent projects and not enough staff to support them. Management looks at the options and decides that outsourcing is their best solution. What they might not final product, and the company’s bottom line. consider or understand is what that could mean for the teams, the code, the
Outsourcing and offshoring are challenging using any framework, but when you add agile practices such as pairing, core team hours, and daily scrums, offshoring an agile project quickly becomes a complicated and somewhat expensive endeavor.
Consider the True Costs
When it comes to cost, it’s tempting to look only at the per-hour cost per person. If a developer in your country costs $100 per hour and an overseas developer costs $20 per hour, it appears much cheaper to use an overseas team. management must factor in the hidden costs of offshoring. These include transition costs, increased overhead, long-term retention, managing the work, and making sure the overseas team follows the development practices/processes that are valuable to the local team.
Transition Costs
One big hidden cost of outsourcing is transition ,it will cost time and money to get the new team up to speed. People need to get together to transition effectively, which means bringing some or all the remote team into a central office to work with the original team. And it’s not just a one-time knowledge dump. Getting the new team to understand a system in depth involves having at least some of the new team members travel to pair with the old team members. It is best to have people cycle back and forth meaning have some of the local team travel to the remote site and have some of the remote team spend time at the local team’s location. Depending on the size of your project, the knowledge transfer can take weeks, months, or even a year
Increased Overhead
Outsourced projects have built-in communication challenges that take away from available productive time. people on outsourced projects spend at least an extra hour every day on additional meetings, email, and phone calls, as teams struggle through cultural and language barriers. This increased overhead must be factored into the overall project cost.
Long-Term Retention
Overseas teams tend to have high turnover rates. Once trained, people understand they are more valuable and will often leave for a better paying job. Turnover rates might increase for your local teams as well. The longer the transition time, the more difficult it will be for your local team members to stay engaged with the project
Cultural Challenges and Managing the Work
Cultural challenges also come into play as you attempt to work together. In Succeeding with Agile, Mike Cohn suggests that teams create coherence—or “stick together” [COHN] (called group cohesion in the social sciences). To demonstrate the difficulties of understanding other cultures, Cohn relates how Geert Hofstede from IBM identified “five key dimensions along which cultures varied” [Hofstede as cited in Cohn, p. 359]. The data is illuminating and reveals what most people know already. Chinese teams are less likely to challenge authority in a public forum. American teams are more likely to call it like they see it. Indian teams might say yes when they really mean, “I hear what you are saying but don’t agree.” Overcoming cultural obstacles takes time, training, and patience, which ultimately means more cost to the project.
Development Practices
You also need to decide how you want to work with the offshore teams. You might choose to use work package deliverables, where each team builds a set of features on its own. Or you might choose to work around the globe, where the code moves from site to site to site. These added complexities make having standard engineering practices such as continuous integration and test-driven development (TDD) even more critical to your success. Training teams that don’t already use these practices takes time and money.
Dealing with Reality
If your company is considering outsourcing, show them the list of hidden costs described in this article
Budget and Cost
When estimating the budget for an outsourced project, lets only consider the best- and worst-case scenarios
Your first input is the total project budget. The budget might be an external number if you are soliciting a bid. Or it might be an internal number if you have a fixed cost you are trying to hit either in terms of loaded costs of a team or actual funds that you have to manage
List the broad cost categories in one column. In the example in Table, the first cost item I list is vendor selection. If you already have a vendor, that cost wouldn’t apply to your project. From there, I list what percentage (variable) of that item in the budget is usually spent on that category. For example, the best-case scenario for vendor selection is 0.5 percent; in the worst-case scenario, the percentage goes up to 1.5 percent. I do this for each potential hidden cost item.
The percentage variables I list are based on my experience. I suggest you start with your own data and, if needed, look at industry trends. For example, if you have a big team, your travel variable could be significantly higher than that shown in Table. Some costs, such as bugs and turnover, are harder to estimate, as you’d need to have some idea of the quality you will receive back from the offshore team and what their turnover is likely to be. That’s why it’s important to continue to track these costs over time, so that you not only can demonstrate the real cost of outsourcing but also can create a better estimate for the next project
Keys to Success
Choose the Right Offshore Team There are two dimensions to choosing the right offshore team: hiring agile teams and going north/south
Hire Agile Teams
When you outsource an agile project, hire a team that is already agile. Otherwise, you’ll spend a great deal of time and money trying to educate the outsourced team on agile practices and principles, which might be very foreign to the team’s own company culture. And don’t depend on a line item in a marketing presentation that says, “We’re agile.” Go watch the team in action. See how the team members work, and make sure their idea of being agile is consistent with your local team’s philosophy. And most important, talk to former clients. This effort often gives you an idea of how agile the outsourced team really is.
Go North/South
If you’re going to go offshore, try to choose a team within three time zones of your local teams. This usually means going north/south instead of east/west. If you are in the United Kingdom, outsource to Portugal, Spain, an African nation, or maybe even Eastern Europe. If you are based in North America, look to South America. North/south really saves on the late-night conference calls and the time lost waiting for answers. When time zones are a factor, quick questions that could be answered in five minutes in a shared team space could potentially derail the project for a day.
Allocate the Work in the Least Painful Way
The best approach when allocating the work is to give the offshore team independence by providing them with a complete feature or feature set to work on and build end to end. It’s also the most expensive option, mainly because stakeholders and customers (or product owners) will have to travel and spend significant amounts of time working offshore with the team
Stick with the Scrum Framework
When you outsource work, don’t abandon the Scrum practices that have been successful for your co-located team. While it might be more difficult to coordinate these activities, they are essential for long-term success
Sprint Reviews
Keep sprint reviews live via videoconferencing. Don’t demo via email. Schedule a time for a demo, and then alternate which team has to have the awkward time. Use a staggered approach as with the daily scrums. For one sprint, the review is at 9 p.m. on a Friday, and for the next sprint, it’s at 9 a.m. on a Friday. Yes, people will complain, especially the stakeholders. Kindly remind them their support is needed, that the team deals with this daily, and that this is the best way to deal with the reality of outsourced projects.
Retrospectives
Don’t skimp on retrospectives. In fact, they might be the most important tool you have to build a cohesive team. You still need to alternate the times and have at least 30 to 60 minutes of overlapping retrospective time. You might also choose to have each team do a local retrospective, using group time to review what was discussed and to determine how to remove the identified impediments/issues.
Build a One-Team Culture
Start the project with an in-person kick-off meeting with the entire worldwide team (don’t forget to add this expense to your growing list of software costs). You need to plan team-building activities and regular visits. You should also bring offshore people to the central office, and vice versa, on a rotational basis to build team cohesion. At these joint meetings, work toward building a common development environment and codebase. This helps with packing and unpacking the code
Keep in Constant Contact with Technology
Things I insist on with offshore teams are a dedicated uplink, such as an “always on” phone line, instant messaging or video portal. The uplink allows a live connection between teams throughout the day. If someone in Seattle has a question for the team in Brazil, she need only pick up the handset and ask the question. It mimics rolling back in your chair and shouting out the question to the local team. It’s quick, it’s easy, and it’s always on. The webcam is another must-have. Each team should be able to see the other team’s members. If you need to talk to one another, it’s easy to see which people are at their desks and to talk to them instantly.
Be Prepared to Travel
Travel is imperative when outsourcing work. If your company has not allocated a travel budget, don’t do outsourcing. It will never work. Frequent in-person meetings are the only way to establish a true team environment and build trust among team members
Never Offshore When …
There are certain times when a company should not offshore a project, no matter how careful the attempt.
- Don’t outsource the first release of complex, high-technology-risk projects.
- Don’t outsource if your local team struggles with development practices (TDD, continuous integration, refactoring) or is undisciplined.
- Don’t outsource without corporate support for the travel budget and technologies necessary for success.
- Don’t outsource with an offshore agile company if you have no experience with agile yourself. You can’t succeed with an offshore agile project if you have yet to do an onshore agile project.
So, based on above points take wise decision on to offshore outsourcing and offshore development
References
[COHN] Cohn, Mike. 2010. Succeeding with Agile. Upper Saddle River, NJ: Addison Wesley
The Scrum Field Guide by Mitch Lacey
[GUNNERSON] Gunnerson, Eric. 2006. “ScrumBut.” http://blogs.msdn.com/b/ericgu/archive/2006/10/13/scrumbut.aspx (accessed 3 April 2015). [OVERBY] Overby, Stephanie. 2003. “Offshore Outsourcing the Money: Moving Jobs Overseas Can Be a Much More Expensive Proposition than You May Think.” CIO Magazine 16(22): 1. [ROTTMAN] Rottman, Joseph, and Mary Lacity. 2006. “Proven Practices for Effectively Offshoring IT Work.” IT Sloan Management Review 47(3): 56–63. [YU] Yu, Larry. 2006. “Behind the Cost-Savings Advantage.” MIT Sloan Management Review 47(2): 8.
Comments
Post a Comment