Remote Agile
Introduction
- 2 timezones
- 3 cities
Company-Wide Activity
Backlog Triage
First, all requests for the engineering team must be created in the Backlog Triage board. Because we want to KISS to create a ticket instead of having five boards and confuse the reporter about which board and project a request should go to.
Also because this way, we ensure all new tickets are seen.
Each ticket placed here will be tagged Blocker, Easy, Time Saving, Valuable, or many of them. Blocker means a ticket is a blocker for other tickets; Easy means it can be delegated to an intern; Time Saving means doing this saves us a lot of time, e.g. automation; Valuable means the ticket brings value to the company, e.g. more customer, makes more money, etc.
At the end of each month, the CEO and the team lead do a backlog triage to define the goal for the next month.
Goal of the Month
The Goal of the Month board has lists for Cut-In, Incidence, Maintenance, 60%, 80%, and 100%.
Cut-in is for tickets added after the backlog triage meeting.
Incidence is for serious system problems that happened during a month, e.g. server crash.
Maintenance is for maintenance tickets engineers do in the month.
60%, 80%, and 100% are from OKR.
Agenda
We have a board called Agenda, it has Draft, Backlog, Small Talk, Monday, Tuesday, Wednesday, Thursday, and Friday.
We place tickets on the Monday list if we want to talk about it on the following Monday stand-up and so on. However, each weekday list only has a ticket. Because we intentionally avoid long meetings. If there is a ticket on the week-day list, it's put in the Backlog list. The Draft list is for something we want to talk about, but it hasn't been thought through yet.
We put interesting topics on the Small Talk list, so we have interesting topics during small talks.
We came up with this list because we constantly forget to bring up a topic when we leave "let's talk about it during our stand-up" in a ticket.
We also create a section for irregular meetings and delete it after the meeting is finished
Daily Stand-Up
We have a daily stand-up bot to talk log things we want to talk about. So we can focus on the blockers.
We do daily stand-up at 09:30 a.m. UTC+8 on Zoom. What is worth mentioning here is that we have a daily small talk 10 minutes before daily stand up for small talks, e.g. the life cycle of clothes, various things.
Our trick to making a meeting efficient is to use the annotate feature of zoom to annotate the presenter's screen and a pen and paper to show our ideas fast.
Besides blockers, we also do demos and talk about agenda items.
We usually start a meeting with SYN, SYN-ACK, and ACK instead of can you hear me, yes I can hear you, can you hear me.
Mock-Up
When we design mock-ups, we especially care about:
- Is this mobile-first
- Is it reusing our existing component from the design system. If not, should we change the design or add the new design to the design system.
Hiring
When we consider a candidate, we have to ask questions specifically about remote working, because it's not for everyone at least not without training.
Resolver
In our protocol, we only allow a ticket reporter to close a ticket, because s/he is the only single source of truth about whether a ticket is complete or not.
The same applies to a GitHub pull request conversation, we leave the resolve conversation button to the conversation starter, so they have a chance to verify the result of the conversation.
Team-Wide Activity
Sprint
We run one week sprint because it's easy to protect the team from external interruptions if the external interruption only has to wait for a week.
When there is a bank holiday or if some team member takes a longer PTO, we'll extend a sprint to two weeks so we have less overhead.
Our story points are 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?. Except for 8 story points mean 16 hours, no other story point is associated with a time.
If a ticket is greater than 8 story points, we'll split it. After some tries, we found that we can demo a backend ticket by showing JSON strings in the UI with a staging flag. This technique allows us to split tickets based on the front-end and back-end.
During the retrospective meeting, we look at our burn-down chart and see what we can do to improve it, it's also a good time to encourage the team which is especially important for a remote team. For retrospective, we follow 4Ls Retrospective;
A trick here is that we use date +%U and then modulus the number of team members to decide who the host is for today and the scrum master for the next week.
Another trick is that we create an empty retrospective document at the beginning of each sprint, so the team members write things down immediately when they encounter something during the sprint.
Kanban
The Kanban Board has lists for Backlog, Design, WIP, Blocker, QA, Incident, Staging, and Deployed from left to right.
Give two lists, a list to the left always has less priority than the list to the right. A team member always works on items from a higher priority list.
This ensures our kanban board won't a traffic jam. Given two tickets in a list, the higher ticket has higher priority than the lower ticket, so team members always know which ticket to work on.
At the beginning of a sprint, tickets are placed in the Backlog list with assignees. A team member then moves the topmost ticket from Backlog to Design, once there is a plan, we'll have a 30 minutes meeting between the assignee and the team lead to talk about the plan. We have this list to ensure the assignee and the team lead are on the same page about the final result of a ticket.
Once a ticket graduates from Design, it's moved to WIP. Each team member can only have one ticket on the WIP list. This makes it clear to the team lead which ticket each member is working on.
When a ticket gets blocked, the ticket is moved to the Blocker, this makes it easy to see tickets get blocked and we'll address these problems during daily stand-ups. Usually, this is because we are missing information from the other timezone. Since the team member doesn't have a ticket in WIP, the team member can start a ticket in Backlog.
Once a ticket is unblocked, the team member just works on it in the Blocker column. We don't move it back because it causes more than one ticket to be on the WIP list.
Once a ticket is done either from Blocker or WIP, it's moved to QA, where we do all kinds of QA including code review.
Once a ticket pass QA, it goes to Staging, we don't have a staging environment, and instead, we have a feature flag for staging, when the feature flag is turned on, the feature is available on production. In the next standup, the assignee will demo this ticket. This allows us to catch production problems and also enables us to let outsiders review the result.
Once a ticket pass Staging, we'll remove the feature flag for it, and make it available on production.
If it's too much effort to create a feature flag, we move the ticket to Deployed and do a demo on production.
Once the product owner approves is satisfied, we mark the ticket as complete; if the owner is unsatisfied, we'll move the ticket back to QA or create a new ticket based on the effort and value.
If a server goes down, a ticket is placed in the Incident list, which means the assignee has to put down everything he is currently working on and switch to the incident.
When there is an interrupt, the team lead will ask the CEO: this sprint? next sprint? or next month? If the answer is this sprint, we'll place the ticket in the Blocker list; if next sprint, we place the ticket in the Cut-in in the Goal of the Month board; otherwise, we put it at the top of Backlog triage. Because we run a one-week sprint, so most answers are next sprint or next month.
The reason we do demos during standup is that we have a 12-hour timezone difference which makes it torture for people to stay late.
Release
We only release before work days. i.e. we don't release on Fridays or before bank holidays. This is a way to protect the team from working overtime.
We also release only if the assignee will be available in the next four hours.
Maintenance
Every Friday afternoon (4 hours) and make-up days for bank holidays are our time for maintenance, we fix all kinds of technical issues that don't get prioritised in the sprint.
Mini Study Group
We recently started a mini-study group 5 mins before our small talk. It's mini because we share what we get from a single section of https://www.gabe.pizza/notes-on-component-libraries/
A trick here is that we use date +%j and then modulus the number of team members to decide who the host is for today.
Movie Night
When we plan a movie night, we make it optional, because it's challenging for everyone to have two hours together across all our time zones.
Although we are still planning our first remote movie night, the way we are going to do it is 1. decide on a movie 2. a time
Then everyone opens the movie and zoom in on the same night and enjoy the film while being able to talk to the team member.
Team Building Party
Team building parties are when we have a chance to gather together in a place and have fun. This is especially important for a remote team.
Documentation
Knowledge management goes without saying is especially important for a remote team. We use MediaWiki for our internal documentation platform because it's really fast, people wouldn't want to create a document if it takes longer than 30 seconds to create a new document.
MediaWiki is not only fast, but it also supports back-link and supports showing orphaned pages by default. It's an ideal tool for Zettelkasten-like knowledge management.
Our trick to avoid orphaned pages is to create a link to the empty page first, then click the link, then create a new page.
Password Management
Unfortunately, we have shared login credentials, we put those in a KeePass file on dropbox. So people don't have to wait for others for the credentials.
Please be aware that this is a big NO-NO doing this. There should be no shared login credentials at all.
Communiation
Our communication preference is:
Wiki > Asana > Slack > Zoom
This is based on how easy it is to search for something.
We only ask our team members to be responsive from 08:00 to 12:00 a.m. UTC+8. You are free to arrange the rest of the hours as long as you are responsive during the four hours. E.g. I usually wake up and then start working at 05:00, 06:00, or 07:00.
Onboarding/Offboarding
We use Asana tickets to track onboarding and offboarding tickets.
Afterword
We won't be able to get here if the following doesn't exist: