Scale your business with an agile nearshore development team

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

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:

The right way to build a nearshore development team

The remote model

There are several ways to build a nearshore team.

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:

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.

One Inside Team communication

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:

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:

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:

One Inside’s agile project approach

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:

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:

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

Katerina Krstovska

QA Engineer

Would you like to receive the next article?

Subscribe to our newsletter and we will send you our next article.