The simple fact behind the game Telephone — and the reason it’s still played even while phones themselves have changed so drastically over the years — is that messages often warp when passed from one person to another. When a remote software team is about to kick off a mission on behalf of a company, both parties are preparing for a significant undertaking of their time and energy. The last thing either wants, nor can afford, is to waste valuable resources trying to parse out murky messages.
To reduce the amount of hair-tearing mistakes in the otherwise lovely collaboration between remote squads and companies, we present seven key best practices for both parties to bear in mind, all gathered from experienced squad leads in the Mission network, some with over 20+ years of experience.
1. Make your requirements and needs crystal clear
Tech writer Kostya Stepanov says good communication, “soothes the nerves, creates friendly working relationships, and gives more freedom to a developer.” It starts with clarity on the mission requirements and expectations. Easier said than done. On the company side, it’s best to get aligned internally on what your needs, expectations, budget, and timeline are before reaching out to a company like Mission to provide you with your squad. That way, in your early meetings, you can give the team all the information they need to plan their strategy for hitting your objectives as efficiently as possible.
Paramount for a strong line of communication is establishing regularity and processes that your teams can rely on. When there’s a more predictable method in place for feedback and check-ins, both companies and squads can begin to build well-earned trust in one another.
2. Inform the squad on the chain of command
As obstacles come up — and they inevitably will — who can the squad leads speak to to most expediently resolve them? Is there any way to “skip the line” to speed up resolution? In the early stages before kicking off your mission, communicating clearly who can be reached, as well as how and when, will ensure that problems are solved as quickly as possible.
3. Have an agile setup to match the agile method of your squad, whenever possible
The agile methodology for software development is a highly collaborative approach in which software is produced in stages called “sprints”. It’s essentially a way to facilitate a fast and flexible workflow, and it speaks to how effective it is that so many software teams tend to be arranged this way. But what happens when an agile team works with a more rigid and hierarchically arranged “waterfall” type company?
As one experienced Tech Lead put it, “If we operate quite independently, then it’s not a big deal if the company is not agile, but it’s not often the case. Most of the time, we work as an extension of the company’s team, so we need to be integrated and we need to ensure that we work well alongside the company’s team. That’s when it’s important that the company is following the same agile methodology as us, otherwise it’s not efficient.”
If you’re not set up to match an agile method team, be sure to discuss how to coordinate or “translate” between your different approaches during the kickoff period. This will ensure less friction coming up once things get going.
4. Get it right from onboarding
While most of these pointers apply for both clients and squads, this one is just for the squads. Make sure every squad member knows what’s expected of them and how it contributes to the big picture. Leads should have regular touch points with his team members to ensure a strong feedback loop. The leads need to find a balance between meeting the needs of the company and also to those of the squad’s resources. After all, an unhappy collaborator will not stick around.
5. Be flexible and prepared enough to endure budget shifts
The company may undergo budget changes on their end, so team needs to be flexible enough to accommodate major changes to scope, scale, priority list, and/or timeline. This is where having clear lines of communication, and having the chain of command for getting in touch, will be particularly helpful.
The company can rest assured that a flexible squad can accommodate the new reality on their end. There should be encouragement and support to have even these potentially difficult conversations with the leads. If things change, there can be new conversations to relaunch the kickoff on the new course, with all of the best practices applying to this new transformative stage.
6. Know that you can bring in resources as needed, and invite them in early
If you need specialists, experts, or other resources, bring them in early rather than scramble to find them after the mission gets going. This is better than letting things get kicked too far down the road, having to scramble to patch holes last minute. Companies like Mission have experts and specialists on-call for this very reason. And hey, if you can figure out which might be needed at kickoff and integrate them into your squad, then they’ll be there as soon as their skills are required. But if an unforeseen obstacle pops up after the mission is underway, working with a company that has them waiting on the sidelines is the best way to go.
7. Keep a simple, accessible backlog
On the squad side, refining the backlog is a small — some say the process shouldn’t exceed 10% of your working time — but important practice to keep. A backlog can too easily swell up with tweaks of all sizes, and different features targeted for implementation. If the company’s needs are kept in mind, as well as the crucial factor their time and budget play in any project, then it shouldn’t be too difficult to keep the backlog efficient.
On the company side, a squad is going to find your backlog — if one exists — as it is. But if you’re reading this and still have time to refine your own, this will ensure the squad can more effectively move through their mission. So if you haven’t given yours a spring cleaning in a while, now’s the time!
