I’m happy to be part of a team which supports remote working. This post collects a few notes on how agile practices fare when people may not be colocated. I don’t claim what’s written to be generally true; rather, it’s specific to me, my team, and how we work.
We’re by no means entirely distributed. There are seven of us in the engineering team, all UK based. We have a dedicated office space and of the seven, four are office-based and three are remote workers. Office-based staff are free to work from home when it suits. I’m office-based but work from home around 40% of the time, for example. Remote workers typically visit the office every couple of weeks to attend the sprint ceremonies — review, retrospective, planning. The rest of the company is more distributed and mobile, comprising product and marketing, medical experts, operations engineers, sales and admin.
Stand up meetings work well. We’re all in the one timezone and our stand up starts promptly at 9:15 and typically lasts 20 minutes. Those in the office gather in a conference room. Remote workers call in. We use GoToMeeting for audio, video and screen share. There’s a large monitor on the wall and the laptop driving it also functions as a second display. The monitor displays the electronic kanban board showing the current state of the sprint. The laptop screen is for webcam output. A speaker-phone handles audio in the conference room. Those calling in use headsets.
The meetings work because they’re short and to the point. Audio in the conference room is adequate at best, but we work around the limitations with a clear protocol, taking it in turns to speak. Not all home workers use webcams, though most do; and the conference webcam doesn’t fit everyone who’s in the meeting room. It is better if everyone uses a webcam, but the meeting remains effective even if they don’t.
The meetings work equally well — better even — if we don’t use the conference room and everyone joins the meeting from their desk, whether that’s at home or in the office. As a result the meeting is mpre punctual and less of an overhead, since there’s no fiddling with conference room setup: we all connect in advance and the meeting starts when an organiser opens it. Since we all have good headsets audio is clear, meaning interjections and group discussions are possible: it’s easier to share a joke.
We call it a “Daily Share” rather than “Stand Up”, but I still think of it as a stand up meeting and always stand up, whether at home or in the office. It’s a physical cue I’m engaged with the meeting and makes a change from sitting down. Other remote workers sit down but are equally engaged.
As mentioned we have a digital Kanban board which provides the primary focus for stand up meetings. We use Taiga. It’s OK. You can see stories. Tasks appear, get assigned, move to the right towards completion. Metrics update.
I miss having an actual, physical Kanban board. There’s something agreeably tangible about having real cards with stories written on them by hand. Screens are too flat and print is too bland. Having a board you can walk up to and inspect is good. It’s satisfying to move cards by hand, or cross them off with a marker pen. These physical actions reinforce the sense of progress in a way the online system fails to match. I also like the fact that a physical board very obviously gets cleared down and rebuilt at the end of every sprint. The work that’s done is done, and the finished cards can be discarded.
I don’t do a huge amount of pair programming but, oddly, I find this also works well with a remote partner. Indeed, there are some advantages to pairing remotely.
First, setting up a pairing session isn’t intrusive. To pair with someone in the office I’ll approach them in person, which makes it harder for them to say no, or not yet. To pair with a remote colleague, I’ll send a message; it’s easier for them to control the right time.
When I say remote pairing what I mean is screen-sharing using Skype. There’s no dual use of the keyboard and mouse. I’m aware of software which does allow the computer controls to be fully shared: we aren’t using it … yet.
A second advantage to this distributed arrangement is that there’s no special set up needed to make the desk pair-friendly. You don’t need a second mouse and keyboard, or any extra space to fit two people round one screen. You don’t need to shift chairs or mugs. What’s more, you can include another colleague at any point without fuss.
Thirdly, for me, it’s a less intense experience. I’m in my space, my partner’s in theirs. We’re focusing on the screen in front of us and the sound coming through the headset. It’s concentrated but relaxed. I almost never use the webcam for these sessions — I find it a distraction. Maybe I’m saying remote pairing is easier on introverts.
I haven’t found a good way of running design sessions remotely. I miss the interaction and activity of having a group of people working together, and the flexibility of a whiteboard which starts clean and ends up packed with boxes, bubbles and arrows.
I usually run retrospectives for my team. We try and get everyone in for them, as well as for the other sprint changeover activities.
It’s a challenge running this particular activity with remote participants. The foundation of a good retrospective is engagement and interaction (though of course all meetings would benefit from such focus). Retrospectives are also energetic and mobile. Stand up, sit down, switch tables: these are all things I get my team doing. We draw pictures, scribble notes on index cards and post-its, pass things round — activities which remote attendees find hard to follow, let alone participate in.
Despite these challenges it has been feasible to include remote attendees in retrospectives. My attitude, though, is that everyone’s invited in person to the retrospective — along with the other sprint changeover activities — and my priority is to make the meeting work for those who are physically present.
That said, some activities work well with remote attendees. It’s quite fun to hold pictures up for display to the webcam and see a remote colleague do the same. A goldfish bowl discussion works very well with remote attendees. I’ve also been pleased with the way everyone adapts to the challenge of the distributed meeting.
One final point: it’s even more important not to let this meeting overrun when you have remote participants.
On the other hand, product demonstrations work well for local and remote workers. Again, we use GoToMeeting, and again there’s a clear protocol — who’s talking when. A nice benefit of using GoToMeeting is that the demonstration can be recorded for those who can’t make the meeting, or would like to replay it.
It’s hardly surprising that a distributed version control system works well for a distributed team. We use GitLab as a front-end and it’s excellent.
We use slack for team communications. I’m surprised how much I like it. I can remember how long it took me to use the most basic emoticons in emails etc, and now I’m actively searching for the perfect emoji to react with. I’ve even installed the slack app on my phone.
I’m less keen on Skype. It seems both bossy and needy. However, I do use it for phone calls and screen sharing, and it does a fine job of both.
We don’t use of cloud technology, docker etc as much as I’d like, but we are moving in that direction. I have a hefty laptop which weighs me down on my cycle+train commute.
Level or ramped access to a building isn’t just for wheelchair users: parents with baby buggies appreciate it, as do couriers wih trolleys, and people who simply find steps hard going.
Similarly, a working environment which is designed to be remote-friendly works better for everyone. For example, when your stand-up meeting is a hosted session that participants dial in to, it’s possible to attend even when you’re neither working from home nor in the office — as was the case last week when I had to drop my daughter off somewhere just when the meeting was due to start. It’s also trivial to open the meeting to observers, who can quietly attend from any location without any change to the setup. As already mentioned, meetings can be recorded, so even if you can’t attend you can play back, and if you did attend you can replay later.
Of course you need to regulate access to company confidential material: source code, design documents, slack channels etc., but use a modern, hosted solution, with well-defined roles and permissions. Does everything need to be behind a VPN? Make sure the servers are maximally available with minimal red-tape, whatever the time, wherever the client and and whatever operating system it’s running. Making remote-friendly decisions with modern infrastructure benefits all.
You have to trust your employees to actually work when they’re working from home, but something’s wrong if that trust is missing. I worked in one office-based job where the boss — if he wasn’t in the office — would make an excuse to phone in late in the day, ostensibly with a query, but actually just checking we were still there. Years later, it still rankles! If, however, you allow and encourage staff to work from home when it suits, without having to make a formal request, you’ll find that trust repaid and with interest. I’m happy to handle a support issue in the evening if I’m set up to do so at home, especially if my (home) working day has flexed so I can take my son to the dentist.
I’m happy to be part of a team which supports remote working. Agile practices adapt well to an environment where not everyone is in the office all of the time, though it certainly helps to get together in person sometimes, especially for design sessions, retrospectives and planning. The tools to support a distributed team are improving all the time. Being remote friendly benefits everyone.