How to Use Scrum with a Decentralized Team
I manage a decentralized team of about 15 people. At first, it was a struggle figuring out how to work with talented people from around the world until I realized that I needed a different style of project management, so I went with Scrum.
The Pros of Scrum
First off, anyone can learn Scrum. It's not hard to learn and there are hundreds of companies that can provide training and certification. I think the question most people ask me is, "Does it work?" and and I usually respond with "yes". It's especially helpful on projects that are expected to last forever, such as a growing website or SaaS service. This is because Scrum allows product owners to create a wishlist of every feature they want. The only thing stopping them is time and money.
Said differently, project management is about balancing time, scope and resources. Scrum is a unique style of project management that helps you reduce the risk of failure by hyper-focusing on SCOPE. Yes, the scope aspect of software projects is often more complicated than people think. Therefore, scope needs to be broken down into bite-sized tasks. Those tasks are often called Features, Bugs, or Chores and Scrum does an excellent organizing and prioritizing those tasks
Scrum and a Decentralized Team
Although Scrum is a fantastic process for building apps, one of its key recommendations is for teams to meet up in person to conduct a daily "Scrum," or check-in. This is difficult if your team is not all in the same place.
In my situation, I cannot always find the talent I need in Los Angeles. So for the past few years, I've begun working with people from all over the world. I've worked with art directors in Portland and Johannesburg, a full-stack engineer in Boston, Scrum managers in New York and even Android developers in Buenos Aires. At first I thought it would be impossible to manage across multiple timezones but 6 years later, I can't imagine working any other way.
I've learned many lessons but below are a few key concepts I think are foundational. This isn't a comprehensive list so if anyone has more ideas to share, please do.
Communication can be organized into a series of sub-topics but at face value, these are my preferred tools for getting teams to communicate online.
- Uber Conference is excellent for team meetings. The service allows you to either call in via phone or a browser. The service can also record meeting if you need it.
- Skype is useful if someone on the team has really poor Internet.
- Slack is better than e-mail. The key features I love about Slack are that you can send large files and create private channels. Slack also integrates with Scrum tools such as JIRA or PivotalTracker.
- I prefer Slack over e-mail but hey, if you can do your work via Gmail, that works too.
- Once you have an assignment and you've built your team, the next step is to set a schedule (daily or weekly) and stick to it. It's important to build routines early on while the team is flexible.
- Google Calendar is your best friend. Everyone in the world has some form of a Gmail account, and Google Calendar in particular will auto-adjust dates and times based on a user's local settings. If I send a calendar invite for 10 a.m. PST, someone in Istanbul can receive the invite with the date and time adjusted for their local time. This eliminates any confusion.
Before a Meeting
- It's a good idea to send a meeting reminder to all invitees before the meeting. I suggest Slacking, e-mailing or text messaging people as a friendly reminder.
- It is not sufficient to just Slack someone a reminder and not get a confirmation. You should always know if someone will be able / not able to attend a meeting.
- This is very important because there will be moments when someone from a different time zone might be calling in and it's midnight their time. The last thing you want to do is waste their time by not having everyone present at the meeting.
Running a Meeting
- Try not to ask people, "What did you do?" It sets the wrong tone.
- Usually within a meeting, people will bring up more issues, tasks or wishlist requests. It's your responsibility to hear those tasks and itemize them into something like PivotalTracker.
- PivotalTracker is excellent for creating Features, Bugs, and Chores. JIRA works too, so the key is just picking one.
- People will communicate via e-mail, phone, text message, etc., and that's totally fine, but at the end of the day, everything (and I mean everything) must be logged down to a bug, feature, or chore. If a task is in an e-mail but not in PivotalTracker, then you're not doing your job.
- If a Product Owner is making requests via e-mail, never let it sit there. Convert the bugs, requests, and chores into PivotalTracker.
- Try your best to assign a task to someone. If you don't know who to assign it to, ask around.
- Always create user stories and use this pattern:
I am a... who wants to... so that I can...
This is very important. Very very important. If you can't create a user story that follows this pattern or task, then it probably means that you lack clarity on the problem. In which case, you must find out: What is the task? Who will the task serve? Who will the task help?
Rule of Thumb
â€¢ Everything starts out in the Icebox (aka wishlist). The Icebox will never be completed (unless the project ends) so it is imperative to constantly add, organize and prioritize items.
More to Learn
Although I've managing multiple teams for many years now, I still find myself learning new things. Lately, I've been spending a lot of time studying cultures of the world. Yes, as I continue building teams from around the world, I'm realizing that people from different cultures communicate differently because they hold different values and beliefs. It's actually incredible how people from around the world treat concepts like punctuality, authority and context differently. In this area, I've again learned a lot but I still have a long ways to go before I can master the art of team building.