Building software is an endeavour that relies heavily on people. And where you have people, you have communications problems. Even when everyone involved is working in the same place, getting communication right is hard. When projects are outsourced to offshore teams, the challenge is even greater.
“But I gave you the requirements.” Yep, we’ve all heard that one before.
Communication is vital for the shared understanding that’s at the heart of building software – and it’s a fundamental part of what makes Agile approaches so good at reducing risk, getting projects moving faster, and making software relevant.
To get communication flowing effectively, I focus on six key principles:
1. Bedtime is at 8, every night
My children understand that 8 o’clock is bed time. It’s simple, and there are no arguments. Granted it took a while to get there, but it works. They understand it, they can plan for it and it takes away any uncertainty. We also have a big clock on the wall to make it visible.
In the same way, Agile Scrum daily stand-ups give people a structure to work to. They know they will be talking at a certain time every day, and they know what the conversation will be about. Whether those involved are all in the same office or split between home and offshore locations, stand-ups ensure the right communications happen.
Stand-ups are also an important part of risk reduction. In his book ‘Principles of Product Development Flow’, Don Reinertsen states that ‘cadence and synchronisation limit the accumulation of variance.’
Providing a daily synchronisation point, Scrum stand-ups nurture shared understanding and so make a strong contribution to this limiting of variance: if a member of the team has misunderstood something, the misunderstanding will soon be corrected. Risk is limited to work done in the last 24 hours.
In addition, having these regular synchronisations creates awareness amongst multiple teams and reduces planning and resource management overheads.
I also advocate additional sync points such as Sprint Planning, Retrospectives, Demos and Integration. The more you make things regular and predictable, the more you reduce risk.
2. Fast cars need good roads
Without the right infrastructure and tools, even the smartest workers can’t do their jobs well. If you are using outsourcing to reduce cost, spending money on extras might seem counter-intuitive. However, I suggest the focus has to be on value. Yes, outsourcing can reduce headline costs, but it’s still down to you to ensure you get best value from each individual – whether on your own payroll or outsourced – and from the team as a whole.
Invest a little extra at your end to equip your own team, and make it a condition of the contract that the outsourced provider includes specified communications enablers. You’ll be rewarded by higher performance all round.
What enablers should you focus on?
My top four are good internet connections, proper laptops, headsets, and video conferencing.
Good internet connections
This one needs no explanation. Good internet connections are fundamental – but all too often I find remote workers don’t have them. Especially when working from home, connections tend to be poor. Which in turn means communications will be poor and people less efficient.
It’s easy to assume everyone has a laptop; they don’t. Yet having your own laptop makes a big difference in meetings (whether face-to-face or virtual) when people are using screen sharing and other direct communications techniques such as drawing or sharing notes. For the cost of a laptop (which should last at least two years), the gains in productivity, quality and overall value are exponential.
The tendency when communicating with offshore teams is for both groups to huddle around a speaker phone. You can’t hear people over the background noise, and when they do speak, voices are distant. The often-overlooked headset provides a simple solution. Sound and voice quality is a huge improvement over the speaker phone scenario, and people feel better connected.
After laptops, headsets should therefore be your next investment. They’re not expensive and they last. I’ve have used the same one for about four years now; it’s battered but still does the job. Check what you buy is compatible with the technology you have available. I tend to find Skype and Skype for Business to be pretty standard.
Seeing the team face to face makes a big difference. So much human communication is non-verbal – body language, posture, and facial expressions all contribute to the real meaning behind what we say. When you see people, you understand faster, and you interpret their spoken words more accurately. You also build stronger relationships, which makes for more open, direct and effective communication.
Logistics can present a challenge, but a little planning goes a long way. I normally have one person in each team dedicated to meeting logistics. They take responsibility for scheduling, coordinating and ensuring everything is in place – and soon become expert in finding rooms that work.
3. Always have something to point at
When you’re talking about something with someone at a distance, don’t assume the other person knows what you are referring to. Find a way to make sure. If there’s a number, use it. If you can put what you’re looking at onto a screen share, do it. If neither of these are possible, draw what you’re talking about, take a picture, and share it. See [Agile tools that work], for some insights into low-fidelity approaches such as sketches and whiteboards. There’s no better way to avoid ambiguity – and this approach also helps to cross the language barrier.
4. Always point at the same thing
I find this a problem a lot. We’ve got something to point at, and we think we’re pointing at the same thing as the people we’re talking to, but it turns out it’s a different version. The simplest thing to do – if the hardest to implement – is to ensure there is a single version of the truth. No matter what tool you use for managing your delivery, Team Foundation Server (TFS), Jira or any other flavour, make sure there is only version of the truth for everything.
This leads nicely onto one of my pet hates, email.
5. Email will cost you money, and lots of it
The problem with email is that it’s a bit like a members’ only club. Three people send emails about something specific, reach an agreement and move on. Three weeks later a similar issue is encountered by two other members of the team. Because they weren’t members of the original club, they have no knowledge about what was discussed, and start from scratch to resolve the issue.
The knowledge of the original resolution is locked away, and the effort to resolve the same issue is duplicated. This is wasted time, which translates into real money.
Further drawbacks of email are that it tends to share information in big batches and promotes elongated asynchronous communications cycles.
There are much better options.
When working on projects with teams, I rely heavily on tools derived from the web and social media. These include:
Team rooms – like chat rooms, team rooms give teams a space to discuss work in progress, ask questions, share status, and clarify issues that arise. Communications are captured and can be seen by all.
Wikis – collaborative web sites where users create, collect, organise and revise information.
Yammer – an internal social network for your own business. You can post messages, ask questions, have conversations, create groups, and collaborate on documents. Information is tagged and organised so it’s easy to find.
Slack – a real-time messaging platform that streams conversations into channels for different teams and topics, organising information and making it easily findable.
6. Speak the same language, be on the same page
Sharing, understanding and using a common vocabulary makes a big difference. We typically encourage Agile teams to adopt Scrum. We then ensure that people within the teams are trained up according to their roles: Scrum Master, Product Owner and Developer. This means that wherever team members are located, roles and responsibilities are clear and there’s a shared understanding of the project.
The specifics matter less, but look for opportunities to standardise. Read the same books, use the same training sites – I use Pluralsight as a means to communicate complex technical ideas.
Review how your in-house and offshore teams communicate. Focus on creating and maintaining shared understanding, and think value not cost. Put regular synchronisation points in place, provide the right tools, standardise as much as you can, and find ways to avoid ambiguity.