FIVE Best Practices To Build Your Nearshore Innovation Team
Are you a football or basketball fan? Did you enjoy the last Superbowl or NBA All-Star game? If you did, you’re familiar with what a great team looks like. The concept of a great team is applicable to every aspect of life.
Based on the experience gained from more than 200 successful projects, this report outlines what the ideal nearshore innovation team looks like in software development.
Effectively creating your software development team will make the difference between success and failure. There are numerous factors to take into consideration. But before we examine each of these in turn however, it is necessary to consider that the project will be influenced by whether or not the project scope is defined upfront. There are two main scenarios which can occur, and this influences the remaining decisions:
- Clear project scope definition. In this situation the service partner can rapidly establish measurable goals and objectives together with the client. This helps the vendor quickly understand the roles needed for the team, and build the team faster. Put simply, having a clear project scope definition helps establish measurable goals and objectives.
- Unclear or missing project scope definition. Sometimes companies are interested in outsourcing the development of their product, but they don’t have a specific project yet. The service provider agrees with the client on the process and can make suggestions based on their experience. In these situations the vendor will likely take a much more active role in identifying the work which they can help the client with – and it is therefore crucial that the client selects a vendor which has the experience and capabilities to take a more proactive, upfront role.
The scope of the project will have a significant impact on how you create your innovation team, and should be kept in mind while considering the following best practices.
Top 5 Best Practices For Creating Your Nearshore Innovation Team
The following section outlines 5 best practices when creating your nearshore innovation team
Team Size Should Be Kept To 7-10 Members
The team size will depend on numerous variables including scope, budget, expectations and time-to-market gap. The typical Scrum team comprises of 7-10 members: 1 Scrum Master, 5-7 development engineers, and 2-3 quality assurance (QA) engineers. A good rule of thumb is to add one QA for every two developers. This is the sweet-spot for productivity.
If the team size increases, so does the potential number of conflicts. In turn this can result in less cohesion within the team, and lower productivity. If this occurs, the best option is to split the team into sub-teams. Each sub-team works as an individual team, reporting to the same Scrum Master and product owner, and their work is coordinated to achieve the client’s goals. Sub-teams are more effective and easier to manage than larger teams. This results in increased productivity and higher client satisfaction.
It is also possible to have one product owner, but multiple teams of 7-10 people, each with a Scrum Master. Everyone is working on the same product backlog.
Find The Best Talent, But Remember The Importance Of Culture
In today’s global world teams are often spread across different locations. Finding and recruiting the best talent available is the main priority for many organizations, regardless of geography. This is particularly the case given the current war for talent. But while distributed teams represent the norm in an increasing number of organizations, they do present a number of challenges in managing individuals and building the best culture to ensure your team achieves success.
Effective communication between distributed team members does not happen by chance, but requires a set of processes and guidelines to ensure all team members are on the same page. For distributed teams, pay attention to efficient management and communication.
When selecting individuals for the team make sure they are well suited to collaborative work, particularly when the team is not physically sitting together – for example personality traits such as flexibility, communication skills, and self-reliance and motivation will all likely be on your list. Look to your human resource teams for guidance in helping to identify the personality characteristics that individuals will need based on your circumstances, and how to identify these traits. For instance, if you have an aggressive timetable for your project, make sure the individual is used to working to fast turnarounds.
Precisely Define The Methodology Together With The Provider
The software development methodology has implications for how teams perform and the coordination between the client and provider. The first step is agreeing on a methodology, or a version of one. Just stating that you will use Agile can mean very different things depending on the organizations´ interpretation of Agile.
If you have limited or no experience working with a third party service provider, then look to the provider for guidance for best practices in managing the relationship. This extends to selecting and applying the most appropriate methodology. For example, while both sides may be in agreement on implementing Scrum, mature service providers will often modify this slightly to meet the exact requirements of the client. Such providers will typically use an assessment framework to identify in detail your development and delivery environment, and use this assessment as a basis on which to make recommendations. Typically the assessment will examine your people, technology, processes, and your overall organizational structure – this is particularly important if you have limited experience with either Agile, or working with a nearshore innovation partner.
Outline Roles And Responsibilities On Both The Vendor And Client Side
Roles and responsibilities which are not clearly expressed and understood by both sides of the relationship, create noise and friction that decreases the productivity of the team. The classic roles that a company needs on a development project are:
- Scrum Master/Team lead
- Subject matter expert (SME)
- Development engineer
- UI/UX developer / Graphic designer
- Quality assurance (QA) engineer
It is important to clearly define each of these roles as well as their responsibilities on both the vendor and client side of the relationship.
The process starts by knowing the skills needed, and identifying the profiles of individuals that match the skills you are looking for and which align to the company’s values.
Put In Place Clear Practices For Communication For Team Members
Communication is a critical but often overlooked factor in project success. Effective communication, particularly in teams which are distributed across different locations and geographies, simply does not happen without appropriate guidelines. It goes without saying that language and cultural differences will in many cases impact team communication.
Team leaders should be responsible for setting the guidelines which will lead to the most effective communication. What is the optimal level of communication? In which instances should you use instant messaging versus email? Team members should also be empowered to communicate freely with each other and this may require investment in specific communication tools.
While email remains the most ubiquitous communication tool, it also often slows down communication. The use of instant messaging for example by Skype, or video conferencing with Google Hangouts makes it easier for real-time, personable communication. So make sure every team member has a webcam on their computer, and can share their computer screen at the click of a button with other team members.
Meanwhile consider traveling to meet the team or invite the team to your office. Personal, face-to-face meetings only help improve the relationship.
Developing a world-class software development team is not easy. Ultimately the key deciding factor will be commitment – what level of commitment will you provide to this project and its ongoing success. Just because you are working with a partner does not mean you can offload responsibility for success. Particularly with a nearshore Agile innovation team, speed is of the essence and any questions which arise need to be dealt with immediately. Therefore it should be seen as a partnership where all parties are responsible for project success. Achieving this will be a key step in building your nearshore innovation team.
To find out more, we recommend reviewing the following reports and webinars:
To find out more, we recommend reviewing the following reports and webinars