Like

Welcome On Mobius

Mobius was created by professionnal coders and passionate people.

We made all the best only for you, to enjoy great features and design quality. Mobius was build in order to reach a pixel perfect layout.

Mobius includes exclusive features such as the Themeone Slider, Themeone Shorcode Generator and Mobius Grid Generator.

Our Skills

WordPress90%
Design/Graphics75%
HTML/CSS/jQuery100%
Support/Updates80%

Outsourcing IT: Do’s and Don’ts of building offshore teams for integration development projects

By Muhammad Omer 2 years ago1 Comment

Deloitte is bullish on IT outsourcing. The consulting giant conducted 2014 Global Outsourcing and Insourcing Survey and reported that “companies have begun to segment their IT environments and pursue a ‘portfolio approach” by benefiting from the capabilities of smaller, specialized service providers”. However, hiring good developers offshore/nearshore is expensive, hard to get and even harder to retain.

Offshore partners can help the onshore companies to build teams for product development, technical support, and maintenance.

Since integration projects are different from application development projects, practice leads can leverage the skills of the offshore team. Integration projects usually have a very well defined systems interface.

While most applications require frequent people interaction (hence a justification for onsite resources), integration deals with connecting systems. Systems don’t change their mind very often so a clear scope can be carved out in most cases. Other benefits include:  

  • 24/7 EDI project and services delivery
  • Team flexibility (easier expansion and contraction of offshore teams)

However, exercise caution before embarking on building your offshore team.

There are certain weak spots in managing offshore teams. The weak spots of offshore development come from culture and distance rather than competence. Both should be addressed by adopting best practices of offshore team building. Project managers can adopt a systematic, gradual and balanced approach to building an offshore development team which is culturally sensitive and knows how to offset the distance issues.  

Here are some do’s and don’ts that we recommend based on our 15 years of experience in setting up offshore teams. There are other resources that may help in building knowledge regarding building remote teams. The resources are listed at the end of the article.  

Do’s

Approach

  • Make sure the project has well-defined requirements and has been well designed (which is why many mainframe development projects are often outsourced)
  • Treat the offshore team development as an extension to your main office. Treat it as a partnership. It means that partners are not available off-the-shelf and you’ll have to invest some time in identifying and qualifying good offshore resources
  • Hire small: Induct offshore team members incrementally rather than hiring a team in a big-bang fashion just because you can afford it. This will also help in onboarding and initial ramp up of the new team.  

Risk management

  • Try offshore development with small and relatively low-risk PoC (Proof-of-Concept) or a prototype.
  • Use a small assignment/exercise to move through the learning curve with a lower degree of risk than a large engagement

 

Communication

  • Strategy: Define a communication strategy for your offshore development project. ///conference calls, chat tools, video conferencing, application sharing tools, e-mail, and a repository.
  • Mode of communication: In agile development methodology, face-to-face communication and physical proximity are necessary. Since, face-to-face communication is not possible in offshore team building, regularly scheduled conference calls, emails, and chat sessions should be arranged for managing offshore team
  • Calendar: All team members of the offshore and onshore team directly engaged in the project should ensure that they add a second-time-zone to their Outlook/Google calendars. It will help in scheduling meetings with the offshore team.
  • Follow-up: Detailed issues should be assigned to individuals to be followed-up offline. Issues and tasks should be documented and entered into a tool, which can be accessed by the entire project team at any time.
  • Business context communication: Requirements are technical specifications of what needs to be done, it misses the WHY part of a project. The why often makes a big difference in doing the what properly. It helps communicate the important & unimportant tidbits to the offshore team
  • Flush-out conflicts and problems within onshore and offshore team
  • Develop working relationships: Aim is to develop a decent personal relationship with the offshore team as great teams need non-work (informal) communication also
  • Use daily meetings and cross-shore stand-ups initially, then as the  level of trust increases, you can switch to daily meetings only
  • The document repository should support versioning of artifacts and provide a check-in/check-out feature
  • There will be ongoing challenges which will have to be worked through and overcome. This is where a smart and trustworthy offshore team lead really helps
  • Treat people nicely
  • Each developer has typically a different set of motivations. Differentiate between people who are interested in building the product or maintaining it
  • Have full visibility over daily progress of the offshore team, this will allow you to have more confidence in your hiring decision about the offshore resources
  • Prevent knowledge loss
  • Have at least one/two hours overlap for your teams to be able to communicate in real time
  • Choose a strong offshore leader who is capable of fixing minor problems at his/her own
  • Set Up regular team meetings
  • Set and communicate mutual expectations
  • Share your vision | They will go out of their way to help you succeed if they feel they are an equal part of your team

Technical management of work

  • Put everyone on a single code base
  • Continuous integration: Use a continuous integration platform. but requires good build discipline.
  • Offshore developers should strive not to break the build. If it happens they should fix it immediately” This approach requires very good connectivity on the part of the offshore team.
  • Clustered code repository: To offset the problems such as network glitches, and lines being down, optimize the source control operations by minimizing dependencies.
  • Use a source code control system that handles remote working very well
  • Use build environment duplication   

 

Tools

  • Use tools such as JIRA and Confluence as both have good OOTB integration with Microsoft SharePoint
  • Create an easily accessible data repository and collaboration site
  • Use Application Sharing tools such as Show my PC or Cross Loop
  • Use remote desktop software for screen sharing
  • Pick up a good issue tracking system (my preference is Jira)
  • Invest in necessary technology — Have your offshore rooms equipped with LCD displays, microphones, and HD cameras
  • Use Greenshot, Jing, and Snagit for screen captures.
  • Use Yammer, Slack or Dropbox for communication and file-sharing infrastructure.
  • Setup tools for requirements management, source code, and defect tracking.
  • Use Skype and Google Hangouts to remain in constant touch with the clients/offshore team in the overlapping hours

 

Work process

  • Ask the offshore team lead or partner that whether they use traditional, agile or mixed practices.
  • Have your development sprints scheduled for one or two weeks.
  • Minimize inter-team dependencies so that offshore team can add significant value.  
  • Share information generously with your offshore partner/resource, people want to be part of bigger picture.
  • Use short iterations of 1-2 weeks: learn how to do one-week iterations comfortably with a distributed/remote team
  • Plan the iterations through iteration planning meeting (IPM)
  • Make an effort in growing the business knowledge of the offshore partner.
  • Use documentation for detailed requirements and video conferencing for sharing a broad picture of projects.
  • Use daily meetings and other agile practices that can help you and the offshore team quickly and efficiently share important information

 

Don’ts

  • Do not bring too many people in your team in a short time.
  • Do not push the offshore team to deliver features/iterations quickly because they will treat your business as just another client/job
  • Do not let the code behind the product become spaghetti
  • Do not assign maintenance tasks to the creative talent. There are maintenance, integrations and other things that are no fun for creators.
  • Do not withhold business perspective of the project: You need to make your engineers understand that they’re not only creating your product but also creating your business. That will make them stay for years.
  • Do not let your project will be a training ground for all the new engineers. Ensure you have an experienced team/partner at the offshore end.
  • Do not delay the setting up of expectations. Set expectations at the time of project kick start or monthly client meetings on the project
  • Do not leave holiday planning on the last minute
  • Do not approve of the passive agreement by offshore teams: this may be the sign of an impending problem
  • Do not limit yourself to task-oriented communication only. Talk local politics, happenings and other interests that add more value in the lives of offshore team

 

Resources

Real World Offshore Development Practices by Byran Campbell

Build An Offshore Development Team That Won’t Suck by TechCrunch

Using an Agile Software Process with Offshore Development by Martin Flower

Internationally Agile by Matt Simons

My recipe for offshore agile team management  by InterSog

Categories:
  Biztalk, Blog, Integration
this post was shared 0 times
 000
About

 Muhammad Omer

  (140 articles)

Muhammad Omer is the founding partner at Allied Consultants. Areas of interest for him are entreprenuership in organizations, IT Management, Integration and Business Intelligence.

One Comment

Leave a Reply

Your email address will not be published.