Working with remote Teams

For the last 3 years I have been working mostly remote and I was recently asked by 김진하 of luuv.it what my recommendations or learning were, so I took the IM protocol of our conversation and share my insight with you now. The following insights are considering a start-up

englishteaching  Huboard

englishteaching Huboard

 

Code Climate. Hosted static analysis for Ruby source code

Code Climate. Hosted static analysis for Ruby source code

with remote employees and remote employees and part timers in the engineering team.  But many items still apply to any project work.

I want to start our mentioning the tools I have come to adopt, the tools do not matter, but no knowing them can leave you in a disadvantage that you do not need to be. It is mostly not about the tool by a specific vendor but the functionality they provide.

Daily Stand-up, my team started using Google Hangouts about 1 year ago and never have moved back to Skype or other solutions anymore, it is the best choice for doing stand-ups with remote team members. You can always create a secondary email address just for the Google Hangouts. The importance is, on time, with video! You see who is sick or who puts a frowny face at a new task, when you have voice only or are doing just emails you are missing out on visual cues.

Shared Task Board that shows status and process of tasks. Being an engineer my decision is based on the environment I work in. For development with Github, I have started using Huboard, when developing  at work, where we use Jira, we use Kanban-Boards, when no development tool is in the front, using Trello works well for me. Make sure to include management, investigation, setup tasks as well to give the team a common understanding on what is going on. Do not only put engineering tasks on there but group items well and make use of filters or have multiple boards.

Write Stories that are small, split them if they get big and group them in epics. When you have a team of remote workers and you leave them with huge stories to work on, the feedback cycle gets longer and you might not hear back for a week while they work on it. Small stories make sure that you keep flow and visibility. Sometimes tasks cannot be broken down, but make it a principle to break them down as much as you can – divide and conquer. With bigger stories make sure the whole team has reviewed them also your application architect/database architect. Also if you do not know how to split it, ask your engineers how to do it. If your engineer cannot even say how long it will take, let him investigate.

Acceptance Criteria, Definition of Done are important to define for the team and validate for each story you put out. It makes it clear to the team and everyone else what is expected. Google Drive has helped me to keep documentation/base line acceptance criteria/definitions shared and updated for the whole team.
Automated Code Inspection helps you to see how your team is doing. I started using CodeClimate for my Ruby-on-Rails projects.
Code Review done by the team members can assure that technical debt, code rot but also good patterns and good code is discovered by the team. In a small team with engineers all equal, set forth some rules what to watch out for during code review, e.g. automated tests, development on a feature branch, i12n captions … I asked for a recent projects the engineers to switch roles, anyone could do code review but just not on his own code. The code review I am talking about is just one engineer going over the code of another, not a formal meeting.
Monthly 1:1 check-ins I believe are important when working remotely or with remote employees. Give them time to see you face to face at least via video conferencing, take the time to catch up what else has been going on for them. Basically this is trying to make up for the water cooler talk that you cannot have with them.
All this visibility comes at the cost of initial pre-planning / analysis time and that is extra work, but you are rewarded with less work down the stream. Good work starts with good requirements, it is the big job of the Product Manager/Product Owner to specify things granular and split things up as much as reasonable.
Do not get tempted to just throw change requests, thinking the engineer will figure out what you want.
That is more time spent in the end as you will need more iterations down the road, and it is hard to measure the quality and work of the engineer if you give him vague tasks.



One thought on “Working with remote Teams

Leave a Reply

Your email address will not be published. Required fields are marked *


*

2 + 8 =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>