The digital transformation is accelerating. It’s critical for your business to be at the forefront of customer experience and marketing technologies.

Working with a nearshore development team can help you scale fast and build digital solutions to acquire new customers and stay on top of your competition.

At One Inside, we help large enterprises with their digital transformation in Switzerland and Europe every day. Our team is spread across several countries, with our main office located in Switzerland and teams growing in Germany and North Macedonia.

Our customers have plenty of options to build a dedicated team. They can leverage local engineers as well as embed some of our nearshore resources in their project to build a technical team for a long time period. 

Following this delivery model helps them

• avoid the struggle of the hiring process
• and enables them to focus on creating value for their company
• and growing their business with technical innovation straight away.

Today we aim to give you more details about how we work in a remote way, what our best practices are, and what you should care about if you want to build a nearshore team tomorrow. 

What is nearshore development?

Nearshore development is when a company uses the services of a remote team located in a country within the same timezone (or with minimal differences).

The advantages of nearshore development are that the off-site team will always work at the same time as your team. For physical events, this makes it  easier to catch a plane and fly a couple of hours to meet the remote team.

For instance, our Swiss customers can enjoy working with our team in North Macedonia. It’s only 2 hours from the Basel, Zurich or Geneva airports.

Companies leverage nearshore teams for different reasons:

• Cost-effectiveness: Usually the overall cost of development is reduced against local resources.
• Time to build: Hiring one great developer is time-consuming. By building a nearshore team in a few weeks, you build a team with different profiles.
• Scalability: Companies might need specific skills only for a period of time. Instead of growing their local team, they could rely on a nearshore team to benefit scaling.
• Flexibility: It’s complicated to hire people only for 25% of the time. With a nearshore team, companies can properly plan the number of resources needed. 

The right way to build a nearshore development team

The remote model

There are several ways to build a nearshore team.

• The remote team can be made of several developers working in various locations
• Or the remote team can be located at the same location

At One Inside, we are used to working with distributed teams. The favorite setup for our projects is a remote team under one roof (in North Macedonia), completed by local resources in Switzerland or Germany at the customer premise.

This model has many advantages:

• Better collaboration both between and within the remote and the local teams
• Benefits the team culture
• Hiring of new resources and scaling up of the remote team is easier

Communication and management

Communication is key for the success of any project and especially when teams are not working from the same location.

Several models can be set up to make this work. This is how we approach it at One Inside.

For most of our customers, we have a mixed team made of local and nearshore people. The local team can include a project manager and technical team leaders.

The team members (in our case located in Switzerland or Germany) are the single point of contact for all communication and project management purposes. This guarantees smooth processes and diligent gathering of customer requirements.

Nevertheless, we encourage including every member from every location in the regular technical meetings and reviews to benefit communications.

Building a great communication process and overall team spirit is key for the success of your developments.

Tools to keep people in sync

Technology is essential to enable effective communication. At One Inside, we are used to working with the classic technologies such as:

• Slack for the team day to day business
• Zoom, Skype or Teams for team meetings and presentations
• Confluence, the wiki to gather all requirements and meeting notes
• JIRA where all the tickets (bugs, tasks, improvements) are written, to work in an agile way and get an overview of the development to be done

Process and agile methodology

Following clear processes and embracing agile methodology is a crucial element for the success of your nearshore setup.

At One Inside, we have improved our process and methodology to work in an effective manner with our customers while offering AEM nearshore development.

Our approach to software development deserves a little more attention and details in the next chapters.

Agility to successfully work with a remote team

Growing up as an agile team means that we are able to constantly respond and adapt to customer’s changes. 

Our team is used to and worked seamlessly in a very collaborative environment, based on trust and experience, as well as thanks to smart and high-achieving people that excel in self-managed groups. 

As we switched to more agile ways of working, we noticed a number of benefits:

1. Team members collaborate on projects in a dynamic way
2. Agile takes less effort to make work where the team members are not co-located
3. Employees have the freedom to choose the tasks they have interest in and develop skills sets accordingly
4. Everyone works more efficiently
5. Creates a happier workplace 

From an example of a current agile based setup, we would like to provide insights on how we successfully collaborate together in such a setup: Key for our success was here to use the scrum methodology.

To be able to respond dynamically to changing requirements of modern software ecosystems, we established a self-organized team to be able to perform successfully.

This includes following some standards of Scrum such as:

• Daily Meetings
• Kick-off meetings (every second week)
• Sprint refinements (occasionally the whole team is included)
• Having sprints with no fixed length (2-3 weeks or a month)

Our Software Development Life Cycle (SDLC) consists of two main phases in our described example :

1. Design phase
2. Development phase that combines coding, testing and rollouts

We’ll go more into depth about these phases later.

The design phase

First, a complete analysis of what will be developed is made. This is an opportunity to discuss potential problems that can originate from business, the QA team, or from the designer itself. 

The second step is brainstorming.

The brainstorm is performed on a MIRO board and includes Business and Marketing departments. When this phase is completed and there is a solid idea about the prototype, our designer starts preparing the design according to the requirements. 

Once everything is designed, and the design is approved by the Project Manager and the Head of Development, the development phase can begin.

Development approach

After the approval of the design –and this approval is important because at that point everything that can not be implemented in the application is filtered out — the development phase starts. 

The developers now have a clear picture about what needs to be done. The designs are then received in the Zeplin design tool. This enables the developers to implement a pixel perfect design. 

A decision about what tools should be used needs to be made. For example, the IDE – is a personal choice, but it can happen that all  devs are using the same IDE because of the supported extensions, which helps them write better code and to follow their code conventions. 

Next, a meeting with the development team to discuss what to start developing follows. Agile sprint planning is used here. 

This allows us to effectively plan our work so we can streamline our processes and meet our deadlines. All the tasks to be developed in the sprint are refined, moved to the sprint backlog, and the sprint length is determined. 

The developers estimate the time needed to complete each task they are assigned. 

In summary, the developers do the following:

• Receive the design (previously approved) in Zeplin design tool 
• Choose the IDE tools 
• Tasks are being assigned to developers
• Confirm work capacity
• Build deliverables

When the sprint backlog is ready and everyone on the team agrees on it, the sprint can be finalized and confirmed by the Project Owner and the Scrum Master/Head of Development. This means that the team agrees on their workload and the sprint can begin. 

After the sprint has begun, the scrum team will meet daily and answer the following questions:

• What did you do yesterday?
• What will you be working on today?
• Are you facing any blockers?

This meeting ensures everyone on the team is aware of the progress and aligned with each other.

As we move through a sprint, we may need to add or remove tasks based on the progress of the project. After the sprint has been completed and deliverables have been approved, the project owner will present the completed work to the stakeholders.

Our QA process

While static testing, we do a design analysis, focused on the functionalities and clearance of the requirements. This is something we do in order to identify errors and features that are missing from the design, as well as to ensure the design is not incomplete. 

We know that the earlier bugs are found, the better. After static testing is done, the QA team starts writing test cases. This happens in parallel with the development phase. When the test cases are ready, and the features are developed at least to a point that they are testable, the test cases are executed. 

If bugs are found, they are reported and assigned to developers to be fixed. When bugs are fixed and ready to be retested, the QA team retests them. If they are fixed, they are set to done. 

If they are not fixed, they go back to the developers. At the end of the sprint, where there are no bugs left for retesting, a regression test is done. This ensures that there are no parts that were previously affected by the bug fixes. 

This cycle repeats in every sprint. With every new release, a smoke test is done to make sure the build that we have is stable. 

In a nutshell, our QA process involves:

• Inspection of all requirements
• Having a clear vision on what needs to be tested
• Making decisions about how the testing should be applied
• Develop and execute test cases and report defects

To recap

At One Inside, we believe that agile methodology is perfect for remote teams. It creates a more responsive and efficient organisation, which ultimately improves business performance and overall customer satisfaction. 

The key to success is having the right mindset as well as solid processes and communication between all remote workers.

Next time you need to scale your technical team, consider how the teams will work together.

Katerina Krstovska

QA Engineer