Nearshore Agile Development: Why Project Decision-Makers Should Care About Agile

 

For a business undertaking a serious software development project, following an agile-based approach will make a difference to the quality of the outcome – especially with regard to nearshore software development. 

Project decision-makers who are not directly involved with software development often don’t appreciate the role that agile plays in delivering a quality product. However, by ignoring agile best practices when working with nearshore development teams, businesses risk delaying the product development cycle and impacting the overall quality and time-to-market. This is why you should care about nearshore agile development. 

What is agile, exactly?

To a certain extent, agile is a victim of its popularity as it’s often reduced to a buzzword or misinterpreted among the general population. Agile was developed in 2001 by a group of 17 software developers who agreed that there needed to be a less document-heavy approach to development than the prevailing approaches at that time. 

The group came up with the concept of “agile,” and created a manifesto with these four main pillars:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

To complement the value set, the group also developed a slightly more comprehensive series of principles. While the software engineers were aware they had created a valuable document, it’s unlikely they understood how much they had changed the development process, especially when working with displaced teams. 

Why care about nearshore agile development?

Nearshore development is a type of outsourcing where companies leverage the resources of a separate country that is physically close to. For example, at Asymm – as a company based in San Diego, California – our natural nearshore partners are based in Mexico. 

Once a company overcomes initial barriers to entry, nearshore development represents a more cost-effective solution to large software projects or for ongoing needs. With Mexico in particular, US companies gain access to a strong pool of talent that is available in the same time zone, or with only a few hours’ difference. 

The problem with traditional development approaches

The overall characteristics of a nearshore development team are that it’s remote and often displaced, meaning that each developer is operating from a different location. If we take the Waterfall approach – a traditional, linear, document-driven approach to development – and apply it to a nearshore context, progress is likely to be slow. 

This is because the Waterfall approach follows a set number of rigid steps, usually: Requirements, Design, Implementation, Verification, and Maintenance. For this approach to work, all project requirements must be found in the Requirements phase, meaning that there is a solid understanding of the end user’s needs or the client’s vision. With all the information gathered, the design begins, followed by the implementation (writing the code), and so on. 

It’s a logical approach, but when dealing with multiple stakeholders and developers, it’s rarely this simple. Unless a team has an extremely exacting vision of what they want the end product to achieve – and never waiver from that vision –  it’s almost impossible to gather accurate requirements at the beginning of the project. 

This rigidity is the heart of the issue and is why nearshore agile development is the preferred approach. 

What is an agile development methodology?

While agile isn’t a methodology in itself, the principles behind it have influenced other approaches. When beginning a project, key decision-makers will need to choose a specific methodology to ensure the unity of the team, whether Scrum, Adaptive Project Framework (APF), Extreme Programming (XP), Learn, or Kanban.

That said, all agile-influenced development methodologies follow the same general lifecycle:

Concept

In the Concept phase, the project owner will determine the project scope or prioritize the most important project if there are multiple. As with the Waterfall approach, the owner will discuss key requirements and prepare documentation that includes the features and the proposed end result. 

The difference is that these requirements are kept to a minimum with the understanding that they can be added to at a later stage. In the Concept phase, the product owner will also look at the time and cost involved with potential projects, allowing them to decide whether it’s feasible in the first place. 

Inception

With the concept outlined, the product owner will begin building the software development team and provide them with the necessary tools and resources. Once this is done, the design process will begin to create a user interface mock-up and to build the project architecture. 

Unlike the Waterfall approach, there will now be further input from key stakeholders to diagram the requirements and determine the functionality of the project. This will be followed up with regular meetings to ensure all requirements are included. 

Iteration

Next, the team begins building the product, with developers working alongside UX designers to turn the design into code. The goal by the end of the first iteration (also known as a sprint) is to build out the bare functions of the product. 

Later on, in following iterations, the features will be enhanced or tweaked. In many ways, this is the stage that makes agile development so different from its traditional counterpart. By working in quick iterations, it’s easier to apply feedback from the client and improve the software as you go. It’s also the longest stage of the process. 

Release

Before the release can take place, the quality assurance team will perform tests to check if the code is clean, remove any bugs, and ensure the software is fully functional. There will also be a certain amount of user training at this stage. Once this is done, it’s ready to be released. 

Maintenance

The software is now available to customers or deployed internally in a company, depending on the nature of the product. To ensure the system always runs smoothly, the software development team will be available to provide ongoing support or fix any bugs that are found. They may also train the users if needed and will perform general maintenance tasks, such as upgrades or adding features.

Retirement

Finally, once a product becomes obsolete or incompatible with an organization’s needs, it is moved into retirement. After the users are notified, they will be migrated to a new system and the developers will carry out the end-of-life activities and remove support.  

Forming a nearshore agile development team with Asymm

With its flexible approach and strong built-in communication practices, agile is the natural choice for companies working with remote development teams. However, regardless of the specific approach, the extent of a project’s success will depend on the strength of the team that’s put together in the Inception phase. 

Nearshore developers based in Mexico represent a strong talent pool of professionals who are highly trained, affordable, and familiar with industry-standard agile approaches. While the initial barriers to access can be substantial for businesses who have never operated in Mexico before, the benefits far outweigh the risks. 

At Asymm, we specialize in facilitating operations between US technology companies and Mexico’s talent pool. When working with us, we orchestrate the administrative, legal, operational, and compliance responsibilities that are required for the nearshore software development market. We work directly with you to identify your needs and source the talent that’s familiar with agile methodologies to bring your project to life. If you’re undertaking a large software development project and need help getting it off the ground, reach out to us today for more information.