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
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.
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.