This post will be part 2 of the “Working effectively in remote teams” series I’m writing. Read part 1 here where I talk about the tools that I like to use in remote teams. In this part 2, I’ll go over the process that the remote teams I have worked on generally work with.
Again, before we begin, this post will pertain mostly to software development teams as I generally work in software development teams in my professional life. In this post, we’ll cover the workflow that I like to use when I work remotely.
The workflow will revolve around the tools that I suggested in Part 1 of this series, mainly Waffle, GitHub, CodeShip, CodeClimate, and AppSignal. I’ll just list out what each of the tools are for here for those who don’t want to read over Part 1.
- Waffle – Trello like board that integrates tightly with GitHub Issues
- GitHub – For code repository and ticket tracking
- CodeShip – Continuous Integration
- CodeClimate – For catching obvious red flags in code quality
- AppSignal – Exception monitoring (feel free to replace this whichever service you prefer)
One thing I should mention is that I’ve never worked in an environment where we had continuous integration continuously developing new fresh code to production as long as the tests passed on CI. I’ve heard about these mystical work places where these systems were put in place, but I’ve never worked in one. So the process that I will be describing here will be specific to one week sprint formats.
- All of tickets that needs to be worked on are listed on GitHub Issues page on a daily basis. They are labeled as ready, feature, bugs, maintenance, sprint-name, project-name, and etc. All of these tickets are considered “backlog” and are automatically synced to the Waffle board.
- The tickets that need to be worked on that week’s sprint are marked as “ready” and moved to the “ready” column.
- Developers grab the tickets on the “ready” column of the Waffle board and move them to the “in progress” column of the Waffle board as we work on them. The priority of the tickets that the developers work on vary, but generally speaking, bugs that affect customers are always priority.
- Once the tickets are finished, we make a pull request, link the pull request on the ticket themselves, and move them onto the “code review” column
- In the “code review” column, an automatic script that runs on an hourly basis assigns the pull requests to a specific developer on the team (not the developer who created the pull request), and the assigned developer reviews the code. If the reviewer thinks that the code is satisfactory, he/she gives a “thumbs up” and merges the pull requests to the develop branch of our codebase. The reviewer then moves the ticket on the waffle board to “ready to test” column. Also, when the code is merged into the develop branch, the CI tool automatically deploys the code to our staging server. If the code review didn’t pass, the waffle ticket goes back to in progress until the code review passes.
- In the “ready to test” column, we have a QA person who manually tests the feature on the staging server. If the QA person decides that the code satisfies the requirements of the ticket, he/she gives a thumbs up, and then moves the ticket to the “ready to deploy” column.
- The day before deployment to production, which have always been Fridays for me, we stop all merging of code onto development branch and halt deploying to staging. This means that on Thursday, all active development halts and we focus on fixing bugs that may be on staging and focus on tickets that have not passed QA. Also, if everything looks good, we continue working but we stop merging code to develop branch altogether.
- On Fridays, we merge develop branch into master branch, and then deploy to production. If there are any tickets that have not been finished, we cherry pick those out to prevent it from being merged into master and deployed to production.
So that’s pretty much the process.
As you can see, the process is not too different from a normal weekly sprint that many other on-site software development teams may have. The only difference is that the members of the teams I work on are spread throughout the world and we communicate heavily via slack, email, video conferencing calls, and etc.
I’ll wrap up this post and the series here, but I think anyone who read this can conclude that as long as you hire competent and self-managing people, you definitely do not have to have your entire team in one physical location to run a software development team effectively.
If you have a team who works on-site and would give remote work a shot, I think the tools and the processes that I wrote about should help you start experimenting with remote work.