You want to expand your software development business, but have second thoughts about hiring locally due to recruiting and staffing costs? You wish to increase your development capabilities, but your stakeholders press for more cost-efficiency, and your onsite staff already have a lot on their plate? You need to implement cutting-edge technology, but your local talent pool is scarce? You are not alone here. More and more businesses feel the need for going global. In fact, in 2016, the number of remote workers is expected to reach 83% compared to last year’s 77%. This has been a growing trend, as hiring remotely has proven a smart and low-cost solution.
Today, global talent search has acquired a more sophisticated character: ‘rightsourcing’ is a new strategy, and a long-term dependable bond is an objective. Guided by the reasons of security, automation, political and cultural background, companies favor offshore teams that meet specific criteria of process organization and management. This is where a result-oriented methodology, like Agile, comes to the fore. It makes the process more transparent, thus washing out the differences in time and distance.
Companies that practice Agile have already found their golden mean on how to smoothly build a remote team; how to ensure flawless cohesiveness, communication, and productivity in the distant environment; and how to save your time and pains finding a ‘well-begun-half-done’ option.
In this article we will present our ideas on getting a remote development team up and running in Agile.
Establish proper communication
In fact, successful communication with a distant team does not boil down to the use of smart tools, but rather the way you anticipate all the needs and work out a strategy.
The inability to apply to the remote environment a cornerstone principle of agile methodology – face-to-face communication – often deters remote teams from going agile. However, with a bit of tweaking the tech aid to meet our daily needs, we can ensure meaningful and efficient interaction. Let’s herewith adhere to a new philosophy of distant communication – to be open and accessible.
From Day One, efficiency is translated into communication being:
- multi-channel. In remote environment it’s vital for communication means to be durable and meet different needs. Make sure that a suite of tools and software is ready, user-friendly, and accessible to everyone. You will frequently make use of videoconferencing, desktop sharing, instant messaging, and more.
- pertinent. Using appropriate modes and channels in different situations and purposes. Do not use email or call as a primary method of discussions and decision making. Use person-to-person communication to make decisions and store all the information in your data sharing repository.
- sufficient. Make sure that you have enough time to be able to communicate in real time. Besides, your calls and meetings must be regular, so that everyone is kept apprised of accomplishments, setbacks, and any work-related issues. Keeping the minutes is also a time-conserving asset, to be used as a ‘cheat sheet’ to follow and account for in the next meeting.
- influential. Send follow-up emails after each significant call. (Project manager can write them). Use an instant messaging platform such as Google Hangouts for video calls to achieve a desired level of engagement.
Collaboration and data sharing
Collaboration of teams needs adjustment, primarily due to distance and time.
To begin with, different time zones make real-time communication harder. Normally, this is resolved by scheduling some time-overlap. The two teams can collaborate during these few hours and organize common stand-ups, planning meetings, sprint reviews, and retrospectives. On the upside of a faraway location, there is a ‘follow-the-sun’ development technique where one team does some work during their workday, hands off the work to another team in a significantly different time zone, who picks up the work and continues with it.
Another task at hand is to bridge the distance gap by providing convenient collaboration environment. On the face of it, the internet abounds with various tools for virtual team collaboration. So it’s not finding one that is a problem, but picking the right one. Here is some reasoning behind our choice of tools.
As with other aspects of process organization, the ‘trial-and-error’ method doesn’t work for us. Our company, for one, is in the habit of following best practices. What mattered to us was:
- the popularity of tool among other remote dev teams;
- the ability to minimize the hassle and optimize the process by integrating other tools.
Upon these criteria, we ended up choosing this suite:
- Confluence – for basic enterprise communication and knowledge exchange;
- Google Hangouts – for chats, videocalls, and other modes;
- Jira, Trello, PivotalTracker – for bug and issue tracking;
- GitHub, BitBucket – as a source code repository;
- Slack – to integrate them all and ensure advanced team communication.
When collaboration is hindered by distance and time, all you need is eliminate these two obstacles, or at least reduce their impact. Luckily, this is feasible today by creating an efficient virtual environment and adopting it to your business needs.
Team structure and processes
Before the start, there are a number of organizational issues to decide on:
- the degree of formality;
- how much reporting and supervision is to be done;
- what methods and practices have to be implemented;
- how the team will be structured and scaled;
- how the domains of authority and the responsibilities will be distributed between the in-house and remote teams;
- how the level of performance is measured.
Degree of formality
The solution largely depends on the ultimate goals and mutual preferences. When the client-vendor relationship is still in the making, the level of formality may be higher, so formally mandated checkpoints and documentation of accomplishment of specific objectives are essential to meet safety, reliability, and legal requirements. At the very least, having user story and bug report templates, elaborating and signing off the Definition of Done are necessary steps.
Amount of reporting
As a rule, we prefer more progressive and result-oriented Agile methods, with minimum documentation and regular contact between the teams, as the detailed description of the process and the artifacts are stored in the collaborative virtual environment, such as Slack.
Choice of methodology
There is an adaptive approach to the choice of methods and practices. We often adopt some elements from Scrum, and others from XP, or Kanban, or whatever to tailor the process to particular needs.
Jobs breakdown
A team’s size and structure depends on a project’s needs. Some teams are created for short-time services, but more often it’s a long-term relationship.
Let’s have a look at the jobs breakdown via Scrum development framework. Inside the Scrum team, the key participants – the Product Owner, the Development Team, and the Scrum Master (aka Feature Team Lead) – interact on a daily basis to facilitate work efficiency. There is a pivotal player who serves as a nexus between business and technology as well as in-house and remote teams – the Product Owner. He/she translates business objectives into technical vocabulary. Demanding as it is, this role should be carefully granted to a visionary, well-versed both in business and tech aspects. Thus don’t fall into the trap of appointing someone within a Dev team – it’s an outsider’s role. The Product Owner, who is solely accountable for the process realization, ensures that knowledge asymmetry is eliminated both ways between the in-house and remote teams and that a balance is maintained between the client’s requirements (including possible alterations) and the Scrum Team’s potential of their implementation.
The customer’s recommendations are verbalized to the team and are formulated into items of the Product Backlog, which makes the whole process transparent and easy to track. It also reduces the time spent by individuals on documenting their own progress.
Sometimes in larger projects, a technical Product Owner serves as an ambassador to the Development Team providing local expertise and communicating the vision of a Senior Product Owner.
Domains of in-house and remote authority
In this ‘process tailoring’, some questions deserve careful consideration. Primary concerns are related to the areas of control and accountability of the in-house and remote teams, as well as the scope of responsibilities, and the mode of interaction between various nodes. Particularly, this concerns the questions of training, resource management, performance audit, process sustainability, data security, etc.
Initial-stage tasks. Every stage of product development is driven by its own objectives, contributing to the final goal of the enterprise. In case of a remote team creation, the initial stage requires careful preparation and high-level discussion of administrative issues. It’s important to agree on the terms and accountability for job advertising, screening, interviewing, selecting, hiring, and onboarding talents, as well as on the number and credentials of desirable candidates.
Creating diagrams of processes. An effective way of presenting information is visualization. Though the areas of control and the responsibilities’ distribution are thoroughly documented, it always helps to actually SEE the whole picture. Thus a detailed diagram showing all the nodes and their interrelation will give quick and easy answers on who the movers of the process are, who they are accountable to, and how the teams interact at each stage. A diagram like this gives a more informative view of the events and roles’ interplay, compared to a simple tree of titles.
Agile workflow assessment
Definition of done is a checklist of properties that the final product must have. Meeting these criteria serves as the primary indicator of quality performance. It’s the Product Owner’s duty to create a clear, unambiguous, and comprehensive definition of “Done” in accordance with the project’s final objectives. The Scrum Master also assists in product planning by providing technical solutions and practical organizational ideas to help achieve artifact transparency. The entire team participates in deciding on the workload for every sprint, to ensure delivering potentially releasable functionality. The Scrum Master closely oversees and evaluates this process, provides support and recommendation so that all the requirements are met and the final product corresponds to the definition. Thus it’s critical for the Scrum Team to reach a common agreement of what “Done” properties are.
Quantitative work measurement. Choosing and setting up the proper metrics will help to elicit quantitative indicators of performance. The measurements may include: the average task to time ratio, the downtime rate, the client/vendor bug-tracking ratio, etc. The measurement process is fully automated – all you need is to set up task-, time-, and bug-trackers. However, the final assessment has to be made by a specially trained specialist.
Strong and clear goals. The success of collaboration depends directly on clear common understanding of mid-term and ultimate goals. With no hidden agenda or double-crossing. This is only possible if all participants are treated as partners. Regardless of the organizational structure, it must be built on the principle of cooperation and openness, with a ‘no-silos’ policy as the work process often requires collaboration across multiple functions and responsibilities.
Invest in training
As our experience with newly-created remote teams shows, knowledge transfer happens at the same time as the main operation. There is always a need for faster knowledge acquisition. And training demands investment. This issue is really controversial: to train or not to train. The ideas here might shed some light.
The ultimate objective is to make sure everyone is on the same page and optimize the learning curve.
And yet again, we decided to follow best practices in training:
Boot camp. The idea is to bring all or at least key participants together at the start and get them to work through a number of sprints as a united team. This will give a good kick-start to collaboration by:
- sharing knowledge, vision, and corporate culture;
- marking key milestones of the project;
- developing common awareness of customer context, aligned use of tools, initial architecture design, definition of done, programming standards.
Rotating guru. As the effect of initial interaction wears off, it becomes important to refresh the feeling of belonging and break down silos. The idea is to delegate an in-house team rep to travel and work closely with the vendor’s team for a period of 3 weeks or so. That produces a ‘cross-pollinating effect’.
Remote pairing. Remote pairing is really practical and easy to arrange. That’s another great opportunity of building up knowledge on a regular basis.
Take advice of your outsourcing service provider
A remote team is not the same as freelancers working from home. It’s a finely-tuned and, therefore, highly productive body of professionals who share the same office, have common goals, and are fully accountable for their work.
We’ve tried to share our vision on some aspects of remote team building. There is still more to this process. How to find the best talent, how to handle legal matters, how to work with Ukrainian outsourcing service providers, and how we can help. There is a lot more valuable information that the management and HR of the contractor company can share regarding their employees. Our highly skilled specialists will walk you through the process of building and managing your very own remote team. We take personal pride in ensuring our partners’ success.