Software team delivery for nearshore and offshore models – a practical approach

With remote work gaining popularity, numerous new software houses worldwide offer quick-win solutions for companies looking for software development support, either in team extension or full project support models. In this “Software Development Insights” issue, you will read how to create and deliver a successful and efficient software team for nearshore and offshore models. You will learn about a practical approach to the business process, core processes, app development, team setup, and team delivery.

Nearshore and offshore software development teams

Creating such a team properly requires a strong base with experience setting up such teams, managing them throughout the delivery phase, and ramping down once a project is implemented. Based on my knowledge of delivering such teams at DAC.digital , I can share some details and suggestions for all companies that would like to follow good practices in custom software development and nearshore or offshore team delivery.

First of all, let's describe what such teams actually are.

• Nearshore software development: When you hire a software team from a neighboring country. For example, you live in Italy but work with a team from Poland.
• Offshore software development: When you hire a software team from a different country with a different time zone. A great example could be American companies offshoring projects to Central Europe and countries like Poland, Germany, or Spain.

What are the steps involved in software development?

The process of delivering software solutions can be divided into several steps. They include such business processes as:

• initial business contact,
• discussion to understand the business needs and rationale for support,?
• signing an NDA and an initial agreement on business terms and the support model.

Then there is more technical part, including:

• project engagement,?
• team choice and team setup (if offshore/nearshore model is chosen),
• selection of tools used for cooperation (communication, licenses, hardware, infrastructure, etc.),
• kick-off meeting and knowledge transfer period,
• formal agreement and service order are developed in parallel to the abovementioned.

Last but not least, at DAC.digital , we run through the process of team ramp-up or ramp-down depending on the project and product development situation; the support is conducted mainly according to the Agile approach, with a dedicated delivery manager taking care of expectations and improved management of the team and the client itself.

When does the delivery model in software engineering start?

The process of delivering software solutions starts at the exact moment when a service seeker contacts a service provider. It is often forgotten that before the actual software development work begins, there are several steps you must consider when choosing a software provider. Let’s call this part a Business Delivery.?

The first step in the process is the business discovery call or calls with the output of such calls accepted by the client. The best way to conduct this part is by agreeing on a common ground for the project approach and setting up a timeline acceptable by both sides for the following milestones: NDA and Master agreement, communication strategy preparation,? documentation of business and software development progress and changes, business, existing systems analysis, technology analysis, dates and formats for a formal proposal, team staffing, or project kick-off and closure dates.

On top of that, you should remember to prepare the stakeholder roles, tech stack definition, and budget accordingly, with limits depending, e.g., on the time or funding plans by the investors.

Signing up framework agreement and NDA

Agreeing on a framework agreement and a Non-Disclosure agreement is sometimes lengthy. Depending on the size of organizations and their approach to legal aspects or differences in legal systems between countries (e.g., USA or Canada vs. Europe), it may take, based on our experience, between four days and up to several weeks.

Applying tools that foster better experience and force specific actions from the stakeholders (e.g., the most popular like DocuSign, HelloSign, or similar) can speed up this part and allow human error correction.

Software team communication strategy

When creating the communication strategy, two major factors should be considered: defining the form of future software team meetings and setting up communication tools that can be used and applied on both sides. The team meetings should be regular (daily or weekly), their length should be pre-agreed, and all stakeholders should be defined for weekly meetings: Product Owner, Delivery, and Business Manager. And for daily meetings: Product Owner and Scrum Master or Team Lead.

On the side of setting communication tools, it is currently not an issue to adjust to one or several globally available tools for communication and project management, like Slack or Discord for ad hoc communication, Zoom, Teams, or 谷歌 Meet for video individual or group conversations.

Additionally, a secure cloud/shared space for documentation should be prepared for the team members, and tools for task management like Jira, Asana , Trello , TFS (or, in fact, any available or requested by the customer), and time and project tracking (e.g., Harvest or Primetric) or general team reporting.

Communication is key in any software team, but it’s essential when working with a remote team. When you have onshore developers, offshore developers, senior managers working with time differences, or many companies involved in the project, you need to improve processes and measure performance regularly. One strategy that can help is to establish a communication routine between the offshore team and other departments in the home country and stick to it.?

For example, you might decide to have a daily stand-up meeting at the same time each day (mind time zone differences, though!), where everyone on the team updates one another on what they’re working on and any roadblocks they’ve hit in the entire process. You could use offshore modeling software to keep in touch throughout the day and hold periodic check-ins to ensure all offshore resources and cost savings stay on track.

The most important thing is to be clear about what you need from your team members and what they need from you and to be communicative when there are delays or issues so you run only efficient processes.

Project analysis and software delivery risk management

A crucial part of the Business Delivery for team extension models is to analyze the existing documentation of the project or product to be developed. During the project analysis, the client should provide as much information as possible about the project, product description, or any other documentation already prepared.

It is also possible that there is no documentation, and the project analysis must end with a written document with findings. During the analysis part, which should take up to several working days in most cases, the service provider gathers data about the business context (general overview of the project), organizes a team, including the delivery part (assembling the team, distributing roles, creating a backlog and information evaluation) and analysis team.

The analysis team may consist of UX and UI experts for product development approach and design, Architects and DevOps for software architecture assessment, workload evaluation, and available technologies, business and system analysts to support backlog creation and definition of certain business cases.

Offshore and nearshore team extensions

The result of the Business Delivery part should allow for thorough preparation of the Service Delivery approach, depending on the model of support available or requested by the customer.?

Currently, the most common framework to provide software services is team extension with various modifications (offshore teams and nearshore teams, single-engineer augmentation, or team leasing), fixed price, and fixed time projects where a service provider takes full responsibility for the project or product development and mixed model when there is an estimated cap of hours or budget to develop, for example.

Proof of Concept, MVP, or full product

In the case of product development, the analysis results should include team formation strategy, roles distribution across the team, backlog creation, and evaluation, including the UX/UI approach, architecture, technologies analysis, stories, and case definition.

On top of that, before the project commences, the delivery manager, together with the project manager or product manager (either on the service delivery side or the client’s side), should assess the possible workload per each task or story (to be reviewed after the initial two or three sprints with, e.g., the real velocity of the team delivering the services) or risks.

Proof of concept (PoC) is essential in this step of the offshore delivery model process because it allows you to test your assumptions about the project before you invest too much time and money into it. This translates into efficient business processes. A PoC can help you determine whether a proposed solution, e.g., BPM software, is feasible, identify potential problems and solutions early on, and get feedback from users or stakeholders. It can also help you make a business case for the project and secure funding for an offshore model or new technology development.

If you’re unsure whether a project is worth pursuing or don’t know how to start, a PoC can be a great way to get started with a new process and an extra warranty for its low costs.

How to kick off an IT project?

Once the proposal is discussed, negotiated, agreed upon, and the frame agreement and service order are signed, the project usually kicks off with a face-to-face or remote ‘zero’ meeting. Such meetings can include scope and backlog discussion for the initial two or three sprints, project management method (or project handling), risk management, reporting, roles, responsibilities, and the definition of done.?

Additionally, software development best practices like unit tests, pull requests and peer code review, automated continuous integration, and continuous delivery, automation of integration tests, or multiple server configuration (e.g., environments, user acceptance, testing) should be agreed upon before the project kicks off.

A successful project also includes other aspects of the daily work of the software development team, such as time zones, cultural differences, and effective communication models. Be sure to consider legacy systems as an essential aspect of the project. Thinking advance will ensure customer satisfaction, cost-effective cooperation, cost reduction (in other words, cost benefits at its finest), sound business process, and efficient onshore software development.

Seven simple software development best practices

During the software team or software product delivery, it is also vital to remember software development best practices like:

1. Keeping things simple and pragmatic.?
2. Delivering working software frequently.?
3. Having in place sustainable development and improving code continuously (code refactoring).
4. Keeping continuous attention to technical excellence and good design.
5. Following standards and conventions.
6. Use code analysis tools.?
7. Staying openminded.

What is a project completion checklist?

A project completion checklist is essential because it can help ensure that a project is completed on time and within budget so all cost savings are obeyed. It can also help identify potential problems or issues that may have arisen during the project, in existing processes, delivery models, or with offshore developers, for example.

Addressing potential problems or issues can help prevent them from becoming actual problems, thus causing project schedule delays or increased costs for process improvement.

Summary

The abovementioned practices are based on the experience of the software development teams supporting customers at DAC.digital . We are a company embedded in research and development projects, owning in-house products built from scratch and providing custom software development for customers from Europe and the Americas.?

So, I feel I can share such knowledge so that future customers and software product builders have concrete information on the approach and expectations they should take toward the service providers they seek. I hope these informations will be helpful for all who seek excellence in software and product development.

If my article interests you, and you want to know more about how we deliver projects, contact DAC.digital ! We can help you with every step of the digital product development process. Whether you’re working on an MVP, a PoC, or a complete product, our team will focus on your goals to ensure the project is delivered on time and within budget.