5 Best Practices When Assembling Your Agile Team Offshore

The efficiency of agile teams could make or break with this one factor: their members. It’s as simple as that.

In Agile software development, you basically want your team to deliver the most potentially deployable software at the completion of every iteration, with as little waste—human resources and rework—as possible. That’s a tall order, especially if you’re working with an offshore team.

Well, this is something we do on a regular basis here at Arcanys. Over the years, and after assembling several hundreds of dev teams, we’ve learned the importance of a well-structured development team, coordinated by a good project manager. We’ve also continuously worked on putting these elements together and achieving that right balance. Allow us to share our findings and proven principles here.

Fancy yourself a fast reader but not such a patient listener? Then read on.

1. Focus on keeping your team small.

It is easy to assume that the larger a team, the more productive it is, and the better results it is able to drive. But this is actually a misconception that has hounded many organizations. In fact, large teams are often much less efficient than smaller ones. One primary reason for this is that they require more communication and management. Plus, many software development tasks are not that easily distributed or divided over a number of individuals.

Based on our experience, a team composed of 4 to 5 devs is a good size to achieve that optimal balance. Past this threshold, the work process would no longer be as efficient. Of course, the team size must be balanced with its capacity—the skills and knowledge necessary to execute the sprint backlog.

Thus, the best solution in projects where more individuals are involved is to create small, independent teams of 4 to 5 people. As opposed to a single team with 20 members, multiple 4 to 5-person teams would have better task management, encounter fewer bottlenecks in communication channels, and therefore would be more productive.

2. Choose the right individuals to satisfy all the skill sets needed.

a. Choose your developers' profiles.

Before getting more people on board, make an in-depth assessment—What types of developers do you need? Keep in mind that with today’s more versatile and complex software development projects, developers have gotten more specialized. So instead of doing it all, many of them focus on specific parts of development: front end (the visible parts of a website), back end (the hidden databases and infrastructure), and full-stack (a hybrid of both).

Each aspect requires different skills sets:

• Frontend development. Handles the part of an application that is exposed to public views, such as the interface or the front office. Frontend developers have programming skills but also handle design, animation, cross-platform, and responsive design. They’re the ones creating the interface that will let users interact with the application, using programming languages like HTML, CSS, and JavaScript.
  
  
• Backend development. Refers to the back office or the hidden part of the application. Backend developers are skilled in data management, security, database, API access, and other processes related to the business logic of the application or system. With their mastery of languages like NET or JavaScript (Node.js), and their knowledge of software frameworks, their skills can expand to operations. In that case, we can label backend developers as “DevOps,” which describes a set of skills more than a job title.
  
  
• Full-stack development. Because they are able to do portions of both frontend and backend development, full-stack developers are quite a rare breed. They’re familiar with HTML, CSS, JavaScript, and one or more backend languages. Nowadays though, the development world is so demanding that even full-stack developers are not actually writing the entire code of an app or software by themselves, and to that end, we often prefer to have specialists.
  

Another critical aspect of dev teams is the seniority level. Tech companies should put careful deliberation into their engineering job levels and make sure their team members have well-defined roles. When the organization determines a clear path for the developer’s career ladder from the outset, they can set more accurate expectations for a particular engineer, and determine both salary level and responsibilities.

Project roles and tasks should be distributed among team members according to the seniority level they hold. Are there difficult tasks that require supervision or assessment? Or do you need someone to bring a better appreciation of the work in its entirety? Then it’s time to call in the senior developers and/or architects.

Regardless of where your team is based, having the right person for the job could spell the difference between success or failure in your project development.

b. Identify other technical skills needed.

While your software development team would form the core of your group, there are other technical skill sets that might be needed for your project. These include:

• System operations. SysOps, as we call them, take care of the monitoring and support on the hosting and network side of the application.
  
  
• Mobile developers. Developing native mobile applications is different in many ways than web applications, and that’s where you would need some dedicated mobile app developers. Those who choose to specialize in this field are competent in languages like Java, Objective-C, Swift or Javascript (Ionic, React Native), and others.
  
  
• Test engineers. Test engineers are responsible not only for implementing tests but also for designing and building effective testing strategies. Having them as part of your team would therefore help you streamline your test systems and drastically improve the output of the team.
  

c. Determine your support functions.

Aside from developers and technical people, there are other support functions to be filled in your team. What additional roles would you need?

• Business analyst. IT business analysts perform many non-technical tasks that are critical to any software development partnership. They work on documentary requirements (user stories, BRD, FRD, etc.), discuss with dev and test teams, and interact directly with the project managers.
  
  
• QA tester. Quality Assurance in software has a lot to do with testing software and reducing bugs. But beyond testing activities, QA ensures that all aspects of the project—processes, procedures, tools, and people—adhere to the standards of creating a quality software product.
  
  
• Project coordinator. Armed with communication and organizational skills, project coordinators help ensure that software projects reach completion. They arrange project phases and schedules, track progress, manage resources, and in general, remove roadblocks that would slow down the team’s work.
  
  
• UI/UX Designer. The UI designer is primarily responsible for the layout of the software or website, while the UX designer is concerned with the overall feel of the product. While both functions can be handled by a single person, what’s important is that you have a designer on your team.

3. Make sure you have at least one senior engineer in your remote team + a technical lead on your side.

Whoever the vendor and whatever your edge, make sure you have at least one senior developer on board. A senior engineer would be expected to have been in the industry long enough to have experienced a variety of issues and what can be done about these. Because they have a better appreciation of the work in its entirety, senior developers are critical assets in Agile teams and can guarantee the quality of the entire code base.

Typically at Arcanys, we try to assemble dedicated teams composed of at least one senior developer, completed with other mid-level and junior developers. At the same time, we also advise partner organizations to have their own local expert (CTO) who can keep pace with the remote team’s progress and guarantee that what is being developed matches the company’s expectations on a technical level.

4. Get the ratio right.

Once you have identified the profiles needed for a particular project, it’s time to assemble your dedicated team. In most projects, we usually have a business analyst involved at the beginning to help you refine the specifications and build your mockups. Now how you put together your team—how many individuals in what roles—would, of course, largely depend on the product you want to develop. However, we've been generally successful with the following headcount ratios:

• 0.5 Business Analyst who can help refine the specs and build the mockups with a UI/UX designer at the beginning of your project;
  
  
• 2 to 4 Developers who will handle backend and frontend development or both;
  
  
• 0.5 to 1 QA Specialist to continually test the working software and ensure product integrity;
  
  
• 0.25 Project Manager/Coordinator to oversee the non-technical aspects of the project: schedules, work hours, budget, costs, and others.
  

One thing that is often overlooked but is very crucial to the team is the importance of preventing the onset of loneliness among members and keeping their motivation high. As much as possible, avoid having a lone developer work without a team. This would not only curb his/her productivity, but it would also hinder that developer from addressing issues as soon as they arise without anyone else to confer with.

You can find more tips to help keep your team members motivated in this article.

5. Communicate well and be open to changes.

Every successful team starts with effective communication. This eliminates misunderstandings, promotes a healthy work environment, and ensures that tasks are carried out seamlessly. In a software development project, good communication also includes strict guidelines on meetings, documentation of the interfaces or entry points, openness to change, and a tad of goodwill.

In 1967, computer scientist and programmer Dr. Melvin Conway coined what is now known as Conway’s Law, which states:

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

In other words, multiple developers must communicate frequently with each other in order for a software module to function.

As mentioned earlier, a common, effective setup is to divide your bigger team into subteams responsible for their own subsystem. This strategy works well in encouraging open communication lines among the members. We usually recommend creating the teams around your system’s architecture because, in this setup, they can function as a small yet efficient agile team, responsible for delivering working software on a timely basis.

Openness to change is another critical factor here. Let’s be honest. Most of the time, blockers are not due to technical constraints but fear of change. Stakeholders and team members need to realize that being open to change is such an important value when it comes to collaboration. One team can easily block the progress of the project as a whole, simply because they want to protect their small, controlled world. For them, accepting change equals giving up control. To alleviate these types of problems, good corporate culture and the right tools can help instill a better perspective.

Make your agile offshore team work.

Many organizations would think twice about forming an agile offshore team, and for good reason. You would need to worry about making agile development work for you, and then consider the perceived difficulties of having geographically distributed teams. But taking heed of the best practices we’ve outlined here should help you leverage the benefits of this setup—cost-effectiveness, access to a wider pool of talent, quality output, and more.

And given today’s improved modes of communication, you can still keep track of your project’s progress and your team members easily. With careful planning, a sound partnership with your outsourcing provider, and the right team, there’s no reason why you can’t find success with an agile offshore team.

Have questions or curious to see how we could help? Get in touch with us.