How we organize our remote team using Slack, Trello and Google Drive
It’s a fact that every company needs to organize itself to work remotely. Companies will hire freelances or 3rd parties eventually, their employees will travel or they will be a bit sick so it’s better if they stay home. On every case you need to have all the company information on the cloud, your employees will need to keep working smoothly and especially, they will need to feel part of the team as everyone else in the office.
On my previous company, we were a remote team and we iterated on how we worked together. On this article I’m going to share:
- Tools we used.
- Product development process (boards, processes and meetings).
- 3 important lessons
Our team
- Main office (CEO, CMO, interns): Madrid, Spain
- Back-end developer: Netherlands
- Front-end developer: Salamanca, Spain
- iOS developer: Zamora, Spain
- Android developer: Valencia, Spain
- Web designer: Argentina
- Graphic designer: Uruguay
- Mobile designer: Madrid, Spain
- Accountant: Valencia, Spain
Tools
We used well known services to have all the information on the cloud and talk to each other when needed.
- Main communication channel: Slack. It has become the town hall of almost every startup.
We had different channels to talk. We had one for each platform so devs could talk. Another for design, marketing or support to coordinate answers.
We also had one channel to talk to a freelancer which was helping us fix bugs on our Android app. There was no need of email. He wrote there and our devs or myself answered inmediately.
Slack removed the use of email inside the company. We only used it to write outside the team.
- Documents: Google Drive for docs and excels; and Dropbox for files (specially design and legal files). You can use only Google Drive or Microsoft Office 365. There wasn’t any outdated excel on emails. All of them were in Google Spreadsheets.
- Task management: Trello. It’s a tool so flexible that we had boards for development, QA, customer ideas, marketing projects, raising investment, etc.
These 3 tools are all your team needs.
Product development process
These were our boards in Trello for development.
Current Development
This board was used by developers every day. On this board we had all the tasks that needed be done in the current sprint (we used Kanban methodology). We had these columns:
- Sprint Backlog: Tasks that needed to be done.
- Blocked: If a developer was working on a task but he realized he needed a design asset or a modification of an API call, for example; he moved the task to this column. This column must be empty if we specified well the tasks. On the Retrospective meeting (at the end of the sprint) we talked about all the cards that went through this column.
- In Progress (8): Tasks developers were currently doing. We couldn’t have more than 8 tasks (2 for developer). If we had, someone wasn’t working correctly.
- Finished: Tasks that were completed by developers but weren’t ready to test (they hadn’t been deployed to the development server or a new test app version hadn’t been released). If we had many, it was a sign that we needed to deploy them to the development server/app.
- QA (8): Tasks that needed to be tested. Each task should have a checklist with all the tests that needed to be checked. QA is probably the most boring part; so we had to commit ourselves to test every day. If a task failed, we added the description of what happened, and we moved it to the first position of the Sprint Backlog column.
- Ready for Deploy: Tasks that had been tested and could be deployed to production.
- Live (15 dic — 21 dic): Tasks that had been deployed each week. At the end of the sprint we moved this column to the Deployed board, and we created a new column with the new dates.
Tasks from all platforms were in the same board. Each task had one or several tags associated with each platform.
That way the Android developer could filter for Android; and the product manager could see all of them at the same time.
Planning
This board was used by developers the day before we had the sprint meeting, and by the product manager everyday. On this board we had all the tasks that we were planning to do on next sprints. We had these columns:
- Inbox: User stories which were going to be implemented on the next 2 or 3 sprints. When the product manager decided which ones were going to be implemented on the next 2 sprints, he moved them to the Design (if needed) or Specs column.
- Design: User stories which needed to be designed (new screen, iteration of a feature). Once the designer finished one of them, he pasted the link to the design file and moved the card to the Specs column.
- Specs: Developers transformed the user stories into tasks, making sure they had all the info + design they needed, adding dependencies on other areas (database, API). They could divide one user story into 4 tasks for example. Those tasks were moved to the Ready column.
- Ready: Tasks that were ready to be added into the next sprint.
Bugs
This board was used by everyone on the team to report bugs. We had these columns:
- Inbox: When a bug was discovered, it was added to this column. If it was a priority, we added the “Priority” tag (red color) and we assigned it to the person that could be responsible. That person had to look into it as soon as possible. Once a week, developers looked into all of them to see if they needed more info.
- Needs input: If the developer needed more information from the person who submitted it, or he needed to review it more deeply; he would moved the bug here.
- Confirmed: Confirmed bugs that needed to be fixed over the next sprints.
Engineering
This board was used by developers to add parts of the code they wanted to refactor; or internal systems they wanted to change. We had a column for each platform.
Ideas
This board was used by everyone on the team to add ideas. We had these columns:
- Our ideas
- Customer ideas
- Crazy ideas
This board ended up having too many ideas, so it needed to be reviewed each month to merge and discard ideas. I wasn’t happy with this board, a possible change could have been having a column for each area of the product (acquisition, activation, engagement, chat…).
Deployed
This board didn’t need to be used. It was just an archive of all the tasks that we had deployed.
Retrospective
This board was used by developers, designers and the product manager to add internal processes that should be improved. We had these columns:
- I like: When someone is happy about something, he/she would add it here.
- I dislike: When anyone was uncomfortable with a process, he/she would add it here explaining his/her reasons.
- Solved problems: Once we had talked about the problem on the Retrospective meeting, we wrote the solution we planned and we moved the card to this column. After several sprints we reviewed if the solution had succeeded.
Feature QA
When we were going to release a big feature, we created a special QA board with tests. Developers who had worked on that feature were responsible for creating this board and all the tests. We had these columns:
- To test: Tests that still needed to pass.
- In Progress
- Failed: The developer must fix them and move the card back to To test column.
- Succeeded
Mobile QA
It’s a good idea to have a board with all the actions that need to be tested before releasing a new version of the mobile app. Those should be just the priority actions. Some companies have three levels of QA, this would be the first one.
–
Product development process
Let’s see now our development process, the meetings we had and how we moved cards between boards. We had sprints of one week, from Tuesday to Monday.
Why one week only? Because we wanted to respect the planning (not adding tasks in the middle of the sprint) and at the same time we wanted to iterate quickly. It felt slow to plan tasks for two weeks. Of course, it’s more work, specially for the product manager; but there are always tradeoffs. It depends on the team and the stage of the company.
Why from Tuesday to Monday? Each company does it differently and there is no right way. We wanted to release to production after each sprint; that way we were sure we finished testing on Tuesday morning and we could deploy on the afternoon or on Wednesday. Also, the Retrospective and the Sprint meetings are almost together so they can be shorter if there is no need to summarize what happened the previous week. It’s also true than doing the Sprint meeting on a Tuesday we avoid many festivities which usually are on Mondays or Fridays.
- Retrospective meeting: Monday at 5pm. On this 30-minutes to 1-hour meeting, we discussed what went good and wrong on the sprint. We reviewed which tasks were left to take them into account for the Sprint meeting. Every several sprints, we reviewed the cards in the Retrospective board, we talked about the problems and agreed on possible solutions.
- Sprint meeting: Tuesday at 10am. On this 30-minutes to 1-hour meeting we chose the tasks, bugs and refactors which we were going to do on that sprint. This is where prioritization took place, which is always the hardest part. There are always bugs to fix, parts that should be refactored and new features to be added or modified. The product manager chose after listening to everyone.
- Daily meeting: Everyday, except Tuesdays, at 9am. On this 15-minutes meeting we discussed the tasks on which we were blocked, and slightly what we did the day before or were going to do that day.
- Product Planning: As we were just a few and I was the product manager, we didn’t need a meeting for this. We talked over it during the week. From Friday to Monday morning, I moved the user stories to be done on the next sprint to the Specs columns on the Planning board, assigning them to the developer who has going to be responsible of converting them to tasks and moving them to the Ready column. Of course, if a user story needed design it should have been moved at the beginning of the week so designer had enough time to do it.
3 important lessons
There are great resources and articles about working remotely and building a remote team. For example, I highly recommend The Ultimate guide to remote working. So I am going to share only 3 lessons.
Over Communicate
Most problems in a team come from misunderstandings. These problems get worse with a remote team. The solution is to over communicate, be sure everyone is on the same page and really understand what it’s expected. Of course, having it written is almost a must. With the process we had, we reduced a lot of the problems and we almost didn’t notice that we weren’t on the same room.
Informal talks
A team works better if its members know and respect each other. If remote workers only talk to each other on meetings, they won’t know each other and they will feel less part of the team. Members should video chat and talk to each other about hobbies, their weekends, families, etc.
A way of doing this daily is to join the video chat of the Daily meeting earlier, and chat while everyone enters. On our company, every Monday we tried to dedicate a bit of time to chat about the weekends; and we sometimes we also talked about geek stuff before the Sprint meetings.
Bring the team together
You should bring your team together as much as possible. Once you have personally known someone, you will start reading differently his/her jokes, sentences, questions, etc. Depends on your budget it could be more or less frequent; but it definitely helps.
If you want to read more about this, these are 3 articles from other startups that helped me organize our remote team:
- How We Use Trello & Google Docs to Make UserVoice Better Every Day
- The Cabify Product Development Process
- Optimizing Trello for the 10-person Opbeat team
The other day I also wrote:
