Working Remotely with Developers and Testers

From the Agile Manifesto: 

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

There are times when you can't be in the same room as some or all of the rest of your team to have that face-to-face conversation, so how can a writer work as part of a team remotely?

Let's get one thing clear: Agile can and does work with remote team members. This applies to writers as much as developers, testers, designers, etc. In theory even a scrum master could be remote (although that might be one of those times when theory and practise diverge).  I'll explain how this can work, but nothing beats practical experience and as a manager of writers I've managed all 4 of the possible scenarios:   

• Local writers working with local teams; 
• Local writers working with remote teams;
• Remote writers working with local teams; 
• Remote writers working with remote teams (i.e. a worker who is not working in the same geographical location as me and nor are they working in the same location as their scrum team, who were based in a different geographical location to mine).

I know that all of these scenarios can work for writers, because I've managed writers who have been successful and productive members of scrum teams in all of these scenarios.  There's no doubt in my mind that the simplest and most effective situation is for all team members to be in the same location, and preferably the same office space***.  But there are often good reasons why one or more members of a team will be working remotely, and, if you are the remote worker, it is your responsibility to find ways to be an effective member of the team.  It is the responsibility of the rest of the team to help you be effective. 

The following lays out the most important things for being an effective remote worker in a scrum team over a period of time:

1 - Communication
2 - Trust
3 - Availability
4 - Clarity of goals

Before we look at these in more detail, it's worth emphasising that if you haven't worked with all of the remote team members before, then face-to-face meeting at the start of the process can be very helpful.  Putting a face to an email signature and having an idea of them as a living, breathing person can make faceless communication much less fraught. It’s very easy to read the wrong intentions into written communication, especially if you don’t share a common native language and/or culture. Meeting people can prevent a lot of that kind of problem by giving you a sense of who they are as people - remember that most communication is non-verbal, so you'll get far more out of a 30 minute meet-and-greet than you will out of a month's worth of dialling in to conference calls. 

If meeting the team in person isn't possible for whatever reason, try doing virtual face-to-face meetings using video conferencing.  Introduce yourself, ask questions about what each team member does, what they need from you and what you need from them.  This will at least give you some kind of baseline to work from, because you don't want your first person-to-person contact with a team member to be at a moment of stress or pressure.

Assuming you've met your team either in person or by video, lets look at the 4 key areas in more detail.


Communication
 
Clear, agreed lines of communication are key when working in an scrum team. By working remotely you're giving up one of the biggest assets that a scrum team has - regular face-to-face communication within the team - and as such you must agree on methods and systems for replicating this as much as possible.  The obvious tool is video conferencing, and it should be a matter of course that you attend all ceremonies using this tool. But over and above these set-piece meetings, use instant messenger, email, Slack, Hangouts, or whatever combination of tools that works for you and your fellow team members, and use them a lot.  Part of being a remote worker is making sure that your team remembers and includes you, and if you've never worked remotely before you might be surprised by how easy it can be to feel, or be, forgotten.  Regular (at least daily) contact with your team outside of the set-piece ceremonies will help you keep in the loop, and help your team mates keep you in the loop, and nothing is more important for an agile team than everyone knowing what is going on.


Trust

My experience of managing writers is that a good member of staff is good regardless of whether they are working remotely. I appreciate staff who are pro-active, good at gathering information, independent and who know when they need to involve me and when they don't, and that is the same for both local and remote workers.  Unsurprisingly, these skills are also key to being an effective member of a scrum team, especially if you work remotely and you don't have a long history with your team.  You can't assume that your new team will have an immediate level of trust in you and your work, because until you've proven it - and they've proven the same to you - you're all still finding your way. 

It's only once the team's velocity has stabilised that the team as a whole will have a good feeling for which team members have what strengths and weaknesses. The developer who's not the quickest at getting their task done, but who is the social glue that holds the team together, provides a value over and above just their output; as a remote worker, you don't have this kind of opportunity to provide additional value because you're not in the office with the rest of the team.  Therefore your team mates need to trust the quality and quantity of your output, and your contributions to meetings - those are your core competencies and you will be judged on them.  That can feel a bit harsh sometimes, but one of the downsides of remote working is that your lack of physical presence gives the rest of the team less day-to-day evidence on which to evaluate your contribution, so make your contributions regular and high-quality!


Availability

If there is a particularly annoying problem when dealing with remote workers, it's that they aren't working when you are, so you can't get hold of them. This is really, really irritating because they have become an impediment to your work, and as they are part of the same scrum team that should not be happening, even if they are part-time or working in a different time zone.

To be clear, I'm not saying that people who work part-time or in a different time zone are a impediment to the team.  What I am saying is that the team should know when someone will be available so they can plan accordingly.  If I need something from a part-timer who works 10am - 2pm 5 days a week, then I can just ask them on any given day during that time slot. That's not an impediment because I know when they will be available.  Similarly, if I work 9am - 5pm and a remote worker in a  different time zone works the equivalent of 11am - 7pm, that's also not an impediment because I know I can contact them between 11am and 5pm.  The impediment is the uncertainty of when I can and can't get hold of a team member.

To remove this impediment, try instigating a block of core hours – e.g. 11am – 2pm  - when people will always be available for ceremonies, conference calls, IM/email exchanges, etc. This gives everyone the flexibility at the beginning and end of the day when you aren’t expected to answer immediately, whilst still providing a standard block of time each day to ask questions, get answers, have meetings, etc. This will help with planning and time management, and remove the impediment of uncertainty.

An additional remedy is making sure all calendars are shared, either by sharing individual calendars or, preferably, having a team calendar where everyone adds in their holidays, booked meetings, and so on.  This provides a central location for remote and local workers to easily find out when a person they need will next be available.


Clarity of goals

There are short term and long term goals that the whole team should be working towards.  The short term goals will normally be sprint and release based, so it is important to clarify up front what deliverables are included in the Definition of Done for both the sprints and the release. This is even more important if you're working remotely because the assumption for a remote worker is that they tend to be slightly more autonomous, especially if they are a contractor and/or non-developer.

For the long term, try to build a common goal and sense of direction between both teams. Meeting face-to-face helps build the required trust to work as a team; having a shared, agreed goal helps that team have a focus. In general terms, it’s about developing strong relationships quickly and making sure you’re all pointing in the same direction. Again, as a remote worker this is particularly important.



What else do you think is important when you're providing documentation remotely for a scrum team? Sound off in the comments!


Update: Content curator, blogger, entrepreneur and all-round high-achiever Belle Beth Cooper has put together a stupidly good guide to remote working which I can't recommend highly enough.  If you want more articles, Belle has kindly added a section at the end of the guide with her recommendations.


*** - The caveat is that some people prefer to be on their own for periods of time, and suitable allowances such as private offices (where available) should be made for that, but they should still be easily reachable.