Our Background
RJB has employed developers in the Philippines since year 2000. Over this time period, we’ve helped cultivate one of the fastest growing talent pools in the world. The developers in the Philippines are second to none, and we hand pick the best.
Over the past 15+ years, we’ve been refining our onshore-offshore personnel logistics in the context of our Combined Agile and Waterfall SDLC. This article is a brief overview of our experience and capability. We hope you find it useful. For more information, or for advice on your reducing your development costs, don’t hesitate to get in touch.
Also, the results oriented reader can skip the preamble and jump to directly to a description of our approach, or what we like to call our personnel logistics inversion.
Location Matters
Location is incredibly important. The core arguments in this article will apply to any offshore operation. However, you really can get off on the wrong foot by choosing a poor development location.
Our offshore center is located in the heart of Makati, the premiere business district in the Philippines. This is a far cry from Eastern Europe, India, Central America, and other locations in South East Asia. Makati is major tourist destination, because it’s safe and familiar. With a 100+ year strong US relationship, the language, culture and values of our customers are the norm in the Philippines. In short, we hope you’re excited to visit us!
Our Philosophy
Offshore software development can present some cost advantage over onshore development, thereby contributing to “charging less” and being more competitive. The key is to employ offshore resources in a manner that mitigates risk, while maintaining good communication between onshore and offshore resources, particularly in the areas of changing requirements and transparency with respect to project progress. Here are some key points to remember:
Relationship of Trust – It’s critical to establish a relationship of trust between onshore and offshore resources. Like any relationship it requires work. When times are good it’s relatively easy. When times are tough – e.g. when we’re under very tight deadlines and stress levels are rising – focus on the fact that we are, in point of fact, one team. It’s at times like these when good communications and transparency come to the fore.
Don’t set yourself up for failure – Establish reasonable schedules with thoughtful deliverables, and do transparent risk analysis on a regular basis to avoid 11th hour surprises. In order to establish reasonable schedules, funnel requirements and enhancement requests through the appropriate onshore/offshore teams before making the schedule commitment to the client. To support this activity, development teams need to be able to respond quickly with estimates based on the new requirements.
Location Planning – Choose the location for development activities carefully. Some activities will naturally be more client facing – while video conferencing technology has come a long way, there may be a case for using onshore resources for requirements analysis, integration of offshore deliverables, or demonstrating a prototype of a new Feature to a customer.
Regular Meeting Times – Establish regular meeting times that take into account different time zones. Due to the geographic distribution of the team it may be necessary to adjust meeting schedules to accommodate multiple time zones.
Continuous Integration (CI) – Follow a continuous build cycle to allow frequent integration of onshore and offshore deliverables to reduce risk of incompatibilities.
Review Deliverables – Regularly review project deliverables both in terms priority as well as development status. Adopt the “Show Me” approach (e.g. demo), to avoid the 95% complete syndrome
Share a Roadmap – Having a vision of the big picture will help your team during the numerous detailed judgments they need to make while developing your software.
These are just guidelines. However, as we drill down into the specifics of our onshore-offshore model, we hold each assertion up against this recipe for success.
The Logistics Problem
Most practitioners will agree that co-located teams outperform distributed ones. The entire team, from the Project Managers to the Junior Developers, can benefit from full time co-location. Likewise, onshore stakeholders and Subject Matter Experts (SMEs) should have face time with the entire team throughout the entire SDLC. So the challenge is this: how can we bring a team together that, by the very definition of offshore software development, is distributed? Answer: We do it the old fashioned way, by increasing team cohesion and reducing coupling between teams.
The Traditional Approach
The traditional approach to personnel logistics with onshore-offshore project teams can, in our opinion, decrease team cohesion and increase coupling between teams. This is precisely the opposite of what we would like to achieve. It can be summarized as follows:
A portion of the team is stationed onshore with the customer. As customer facing resources, these folks are always the natural leaders with the strongest communication skills. Typical onshore resources include Project Managers, Lead Architects, Senior Business Analysts, etc. They are billed at onshore rates.
Requirements and architecture are managed from onshore. There is little choice on this front – the people best suited for the tasks are already stationed onshore. Again, onshore rates will apply to these deliverables.
Construction (i.e. programming) is performed at the offshore software development center. The offshore team members interact with the customer through the onshore “liaisons”.
There are some obvious implications with this approach. The team is clearly separated and production of certain deliverables will suffer based on this separation. While many customers enjoy having senior project team members on site, this draws critical expertise away from the rest of the implementation team which is located offshore.
The separation increases the communication requirements between onshore and offshore personnel resulting in increased coupling. At the same time, onshore and offshore personnel operate less efficiently due to decreased cohesion. Ideally, SMEs interact directly with feature developers. When SMEs are forced to interface with the developers through on site “liaisons”, the communication pipeline can feel more like drinking straw. There is also the issue of rates, the primary driver for offshoring in the first place. Moving the most experienced resources onshore creates a significant increase in the blended rate for a project.
The traditional approach of separating the team into onshore and offshore groups also has specific effects on team dynamics and morale. Simply stated, it can promote an “us and them” mentality, where onshore and offshore resources feel like members of separate teams. The team as a whole is much more likely to fall into “finger pointing” and other “blame game” tactics if/when communication failures lead to project set backs. This runs totally counter to the philosophy we want to promote.
RJB's Personnel Logistics Inversion
Based on our experience, the traditional approach causes more problems than it solves. It also flies in the face of 40 years of software development practices that have taught us unequivocally that we must increase cohesion and reduce coupling in order to have well designed software, and well designed teams. However, rather than “throw the baby out with the bath water”, we address these issues with a few well placed adjustments.
The Role of the Offshore Software Development Center (ODC)
Our first departure from tradition is the role of the offshore center in our SDLC. The historical notion of offshore software development centers is, essentially, as cost efficient code factories. It’s based on the invalid assumption that onshore resources are more talented than their offshore counterparts, and that solutions must be conceived onshore and shipped overseas for programming. There was perhaps a time when this held some truth, but times change.
We maintain that software should be architected, designed, developed, and tested offshore. By doing this we keep the entire implementation team in one place. We also maximize savings with low offshore rates. All that remains is to solve the communication pipeline with the customer.
Project Scoping - Senior Delivery Team Members Go Onshore
As per our Combined Agile & Waterfall SDLC, we kick the engagement off with a Project Scoping. The idea is to perform sufficient analysis to articulate high level business requirements, identify project risk areas, coordinate across the organization, and make preparations for a follow on Agile development phase. The logistics of an onshore-offshore Project Scoping work like this:
Onshore planning meetings with client executive, SME’s, and key delivery personnel (RJB Project Manager, Architect,…) to articulate objectives for the project
Nearshore or offshore analysis of project objectives that results in Findings and Recommendations, including high level schedule and costs
Onshore presentation of Findings, Recomendations, high level schedule, and costs, to the client
Note that this service offering can be provided on a stand alone basis, or as the first phase of an Application Delivery. For a more complete description of the Project Scoping service please see Project Scoping Service.
Agile Development - SMEs Go Offshore
Strap in SME’s you’re going to the Philippines – at least for a visit. See the operation, meet the people, check out Makati, and get involved with the agile development team.
There are very practical reasons to have the project SMEs rotate through the offshore center. As we stated above, the traditional approach works the other way around, where a few key offshore resources are sent onshore and often remain there for the duration of the project. Here’s our logic for inverting the paradigm:
Person on the ground – First and foremost, it feels good as a customer to have trusted staff on the ground where the action is happening. Trust relationships don’t happen overnight, and there’s nothing more reassuring than having offshore progress reports corroborated by your own people. We’ve also found it helpful in the past to have SMEs at the offshore center demo software to their co-workers onshore. Again, this reinforces development progress, by demonstrating working features in the hands of real users.
Increased Engagement – It can be difficult to engage SMEs during their day job. This isn’t a shot against the SMEs, it’s recognition that operational demands are rarely put on hold for SMEs collaborating on a project. They are basically expected to fill their regular full-time role, and still be available to answer questions. In our experience, engagement is increased by a change in schedule and environment. By getting SMEs out of their office, and by temporarily removing all (or some) of their day to day responsibilities, we can improve focus on requirements and user experience. We see similar strategies used in team building exercises – put the team in a new environment to foster creativity and engagement.
Unthrottled Communication – When SMEs rotate through the offshore center, we remove the bottle neck of communicating through onshore liaisons. This is really the only way to unleash the strength of Agile, and allow SMEs and development staff to rapidly converge on features. Ultimately, we are talking about saving time and money, and our experience shows that rework across sprints is significantly reduced with this approach.
In the traditional model, liaisons are delivery staff at the customer site. Under the inverted paradigm, the liaisons are SMEs visiting the offshore center. Whenever the liaison has to appeal to another SME for information, they are actually contacting a full-time co-worker in their own organization! They know who to speak with, when to get in touch, and how to ask the right questions. Compare this with the traditional approach of having an on onshore team lead from the delivery teaming trying to dig up business information and forward it to the offshore team.
Team Building – Our final argument for the inverted paradigm is it’s effect on team morale. Consider a scenario where pairs of SMEs are rotated through the offshore center every 2-3 weeks. Just like the traditional approach, we always have one or more liaison(s) to bridge the gap between onshore and offshore staff. However, by the end of the development phase, the inverted approach ensures that every SME has met every project team member. Compare this with the traditional approach, where only a few hand picked individuals ever meet the customers team. You don’t have to be a psychologist to realize there is no substitute for face to face meetings, team lunches, or after work get togethers. These things go a long way toward fostering the inclusive relationship we describe above.
User Acceptance Test (UAT)
As we stated in The Role of the Offshore Software Development Center (ODC), software should be architected, designed, developed, and tested offshore. That testing should include System and Integration Testing (SIT), and some witness testing by SME’s during their offshore visits. However, it’s important that some of the final testing activities are performed onshore. In particular, we want to engage end-users who will be hands-on with the new system. This involves setting up a User Acceptance Test (UAT) environment, where software that is very close to its finalized form is used and vetted by those same users. This step has the additional benefit of engaging those users and getting buy in and confidence in the new system prior to production release.
Production Release
Now that the final system is tested and accepted by both the client executive, as well as the end-users, we must co-ordinate the release of the new system into production. This co-ordination is ideally done with face-to-face meetings onshore between client staff and senior members of the offshore delivery team. It will likely also involve other client departments who may not directly be affected by the new system, but need to be aware of the deployment. Due to the number of client staff that may be involved, it makes economic sense to have a few members of the delivery team go onshore. Using this approach, senior technical delivery team members will also be on hand to resolve any last minute technical changes involved in setting up the production environment. Some senior technical specialists from the delivery team remain onshore throughout the production release until an agreed upon time where the deployment is determined to be stable. After that time, the delivery team members can return offshore, and any periodic bug fixes (if required) can be done by the offshore team.
This concludes our discussion on how onshore-offshore software development teams work together efficiently to make the most of offshore cost benefits, while delivering a quality product on-time, and on-budget. We hope you find it useful. For more information, or for advice on your reducing your development costs, don’t hesitate to get in touch.