Software team delivery for nearshore and offshore models – practical approach

With remote work gaining popularity, there are numerous new software houses appearing all over the world that offer quick-win solutions for companies looking for software development support, either in the team extension or full project support models. In this article, 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 needs, however, a strong base with previous experience in setting up such teams, managing them throughout the delivery phase, and ramping down once a project is implemented. Based on our previous experience in delivering such teams at DAC.digital we can share some details and suggestions for all companies which would like to follow good practices in custom software development and nearshore or offshore team delivery.

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 NDA and initial agreement on business terms and model of support.

Then there is more technical part including:

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

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

When the delivery model in software engineering starts?

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 starts there are several steps we have to take into account when choosing a software provider. Let’s call this part a Business Delivery.

The very 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, preparation of communication strategy, documenting business and software development progress and changes, business, existing systems analysis, and technology analysis, dates and formats for a formal proposal, team staffing, or project kick-off and closure dates. On top of that, we should remember to prepare accordingly the stakeholder roles, tech stack definition, and budget with limits depending e.g. on the time or founding plans by the investors.

Signing up framework agreement and NDA

Agreeing on a framework agreement and a Non-Disclosure Agreement sometimes is a lengthy process itself. 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 take up to several weeks. Applying tools that foster better experience and force certain actions from the stakeholders (e.g. the most popular like DocuSign, HelloSign, or similar) can speed up this part and allow for human error correction.

Software team communication strategy

When creating the communication strategy, two major factors should be taken into account: defining the form of the future software team meetings and setting up communication tools that can be used and applied on both sides. The team meetings should be regular (e.g. daily or weekly), their length should be pre-agreed and all stakeholders should be defined e.g. 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 used for both communication and project management, like Slack or Discord for ad hoc communication, Zoom, Teams, or Google 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 especially important when you’re 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 on a regular basis. One strategy that can help is to establish a communication routine between offshore team and other departments in the home country, and to 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 model software to keep in touch throughout the day, and hold periodic check-ins to make sure all offshore resources and cost savings are staying 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 in the Business Delivery for team extension models is to analyze properly existing documentation of the project or product to be developed. During the project analysis part, the client should provide as much information as possible with the project or 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 assessment of software architecture, 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

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 cases 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 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. real velocity of the team delivering the services) or risks.

Proof of concept (PoC) is important in this step of 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 offshore model or new technology development.

If you’re not sure whether a project is worth pursuing, or if you 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 frame agreement and service order signed, the project kicks off usually with a face-to-face or remote ‘zero’ meeting. Such meetings can include topics like scope and backlog discussion for the initial two or three sprints, method of project management (or project handling), risk management, reporting, roles and responsibilities, 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.

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

9 simple software development best practices

During the software team or software product delivery it is also important to remember about software development best practices like keeping things simple and pragmatic, delivering working software frequently, having in place sustainable development and improving code continuously (code refactoring), keeping continuous attention to technical excellence and good design, following standards and conventions, use code analysis tools and staying openminded.

There are many reasons why keeping things simple and pragmatic in software is important. Complexity breeds confusion and errors. The more complex something is, the more opportunities there are for things to go wrong. Keeping things simple makes it easier for people to understand and use your software, which leads to fewer mistakes and a higher level of usability. Also, complexity slows down onshore development time and increases costs. The more complex a system is, the longer it takes to develop and the more it costs to maintain a good business process. And that may impact software team delivery for nearshore offshore models. Keeping things simple ensures that your software is easy to build and doesn’t require a lot of time or money to keep running smoothly and make onshore development successful.

It’s crucial for business processes to continuously improve code because it helps to ensure that the software remains stable and efficient. By regularly reviewing and updating the code, you can catch errors, optimize the code for performance, and address any other issues that may have arisen since the code was last written. This not only helps to ensure that the software goes through process improvement but also makes it easier to troubleshoot and fix problems if they do occur.

What is a project completion checklist?

Once the project is concluded, the delivery manager or project manager should remember about project closure best practices like validating the initial plan vs. the end output, output assessment, preparing the “lessons learned” document, and recommendations for the client and the team delivering software solutions with some conclusions for the future.

A project completion checklist is important 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 to identify any potential problems or issues that may have arisen during the course of the project, in existing processes, delivery model, or with offshore developers, for example. By addressing any such potential problems or issues, it can help to prevent them from becoming actual problems and thus causing delays in the project schedule or increased costs valid for process improvement.

Summary

The abovementioned practices are based on hands-on experience of the software development teams supporting customers at DAC.digital. As 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 we feel we can share such knowledge so the future customers and software product builders have concrete information on the approach and expectations they should take towards service providers they look for. We hope this information will be helpful and beneficial for all who seek excellence in software and product development.

If you enjoyed this article, you’re more than welcome to check our other publications on our blog. We share lots of business insights and technological knowledge there, so don’t miss out on them.