When it comes to project management, there are two questions that continue to occupy the greatest PM minds around: "Is it possible to build a fully remote Scrum team?", and if so "can it be as effective as its co-located counterparts?"
In this article, we attempt to answer these questions and (spoiler alert) provide actionable tips that'll help you and your team rock remote Scrum with class. 🕺
☝️ A wee note before we start. For the purpose of this article, we'll be referring to the 2017 version of the official Scrum Guide. You can access and download the full document here.
And now for the fun part...
Scrum is a powerful project management (PM) framework that debuted at the 1995 OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) conference.
According to Ken Schwaber and Jeff Sutherland, the inventors and co-creators of Scrum:
"Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques."
What makes the framework unique is its flexibility and focus on continuous improvement. Teams that use Scrum (called Scrum teams), approach tasks and projects in small, incremental steps called Sprints. Thanks to its granular nature, Scrum lets teams adapt to changing circumstances and project requirements on the go.
👩🏻🏫 Scrum History Lesson: The OOPSLA presentation wasn't the first attempt to crystalize Scrum principles. The term had been used much earlier by Hirotaka Takeuchi and Ikujiro Nonaka who described it in a 1986 Harvard Business Review article, "The New New Product Development Game."
The short answer?
Nearly every type of project you can imagine.
Although the framework was originally tied to software development, Scrum's flexibility makes it suitable for all kinds of ventures. It's especially effective for tackling complex, multi-layered projects that need small, incremental steps and continuous improvement based on feedback loops.
As part of a much larger group of Agile methodologies, Scrum is subject to a set of guidelines and principles included in the Agile Manifesto. One of the 12 principles of the manifesto states that:
"The most efficient and effective method of conveying\
information to and within a development team is\
Given its local-first nature, one of the often-quoted limitations of Scrum is that it can't be effectively used by distributed teams. The reasoning behind this is that nothing beats face-to-face communication.
But is that really the case?
Scrum was originally created for co-located development teams, but back in the 90s the concept of remote collaboration tools (aka "groupware") was still in its infancy. Apart from the good ol' async email and a few innovators like IBM's Lotus Notes, coordinating team efforts online wasn't easy.
Nowadays, we live in a remote-collab wonderland. 🌈 Want to oversee, manage or chat with your team? It's no longer the question of "can I do it?" but rather "which of the thousands of collaboration and communication platforms should I choose?"
Does that mean distributed teams have it too easy now?
No. They still have to deal with time-zone differences, "flexible" working hours, at-home distractions, and the elusive work-life balance (check our article on remote productivity to learn more). But these things are trifles compared to what modern remote workplace has to offer.
With that in mind, let's take a closer look at Scrum essentials and see how we can implement them in a remote environment. 👇
Scrum's effectiveness is set on two pillars:
Flexibility 🤸🏻 and continuous improvement 🏋️.
You already know that Scrum teams can easily adapt to changing circumstances and revise their course of action accordingly. Flexibility also means that Scrum units can quickly regroup and shift focus every time project requirements change.
🏉 Scrum Fun Fact: Did you know that the word "Scrum" (scrummage) comes from the world of competitive sports? In Rugby terminology, it's used to describe a team formation in which players face each other with their heads down and try to snatch the ball from the opposing team.
The second pillar of Scrum, its ongoing, progressional nature, means that each Sprint (Scrum cycle) is set to improve on the previous one and add to the experience of the team. The feedback gathered during a Scrum iteration is fed back into the loop and used in the next cycle.
Both qualities require efficient and effective communication that, according to the Agile Manifesto, is reserved for face-to-face conversations.
The thing is, face-to-face communication can only happen when all team members are present in a fixed time and location. When one link of the chain is missing, direct collaboration loses much of its glamour.
🌎 Face-to-face communication can only happen when all team members are present in a fixed time and location.
For that reason, remote collaboration can actually make up for some of the limitations of co-located teams. It also opens a range of benefits available only to hybrid and fully distributed Scrum teams:
- 👩💻 Meetings happen independently of time and location
- ⏰ Feedback loops are live and accessible 24/7
- 🌍 Talent is not limited to local pools of candidates
- 🙋🏻♂️ Absenteeism rates are lower compared to on-site teams
When we combine the adaptability of Scrum with the flexibility of remote work, remote Scrum teams, wait for it... turn out to be more robust than their co-located counterparts!
Ok, so how does (remote) Scrum actually work? Let's break the framework down into smaller bits and see how each element fits in a remote setup. 🧩
You can think of Scrum artifacts as a single source of truth (SSOT) about everything that happens during a Scrum. Scrum artifacts are sometimes referred to as "information radiators" (as if archeological nomenclature wasn't enough). They hold all the key information recorded in the course and for the purpose of delivering a product or service.
- 📑 Product Backlog is a compilation of everything that needs to be done and serves as a master to-do list for the Development Team. The Product Backlog is continually changing to accommodate shifting project requirements. All items in the Product Backlog are assigned a priority which determines the order in which they're executed
- 🏃🏻♂️ Sprint Backlog is a portion of the Product Backlog slated for the next Sprint (iteration). It includes items the Development Team will focus on as well as a plan for executing them. The Development Team has full control over the Sprint Backlog
- Product Increments 🧩 are the result of the latest and all previous Sprints. Simply put, increments are the cumulative work progress and experience of a Scrum team
As a SSOT, Scrum Artifacts present a great value to the Scrum team. For that reason, distributed teams that want to implement Scrum need a reliable solution to organize and maintain their artifacts.
The key is to keep all Scrum artifacts in a single, easily accessible location and make sure the team always uses the most up-to-date information.
In Taskade, teams can organize their artifacts into Workspaces, Subspaces and Projects. Each method of organization provides multiple customization options such as tagging, color-coding or custom cover images that make navigating Scrum artifacts more intuitive
Scrum teams are self-contained groups of 3-9 people that can coordinate work activities on their own, i.e. without external guidance or supervision. They have all the knowledge and expertise needed to deliver Scrum increments and rarely require outside help except for stakeholders liaison.
- 🧙♂️ Scrum Master (SM) is an expert in the arcane ways of Scrum. SM makes sure that the Development Team understands and follows the principles of the Scrum framework. It's important to note that the role of a Scrum Master is NOT that of a project manager (although the same person can hold both)
- 🕺 Product Owner (PO) is responsible for the contents and maintenance of the Product Backlog. PO prioritizes tasks and keeps the Product Backlog tidy and easy to understand. Product Owner is also the only member of the Scrum team that can cancel a Sprint once its goals are no longer relevant
- 👷♀️👨🔧 Development Team (DT) is the core of the Scrum team responsible for tackling the actual workload set out in the Product and Sprint Backlog. Every member of the Development Team is equal in terms of their role and contribution
To keep a remote Scrum team on track, team managers should attempt to create a similar mesh of responsibilities and permissions to that used by co-located teams. This can be done through a transparent chain of command and clearly defined user roles.
Since certain Scrum elements can be modified only by specific users, it's important to set clear boundaries and communicate "who does what" from day one. For instance, while a PO can update and amend the Product Backlog, the Sprint Backlog is off-limits to anybody but the Development Team.
In Taskade, you can expand or limit access at the Workspace, Subspace or Project level. Users can be assigned one of three roles:
- 👩💻 Admin. Can fully configure and edit projects and templates. Admins have exclusive access to project and workspace settings
- ✍️ Editor. Can create and edit projects and templates within a Workspace. Editors can't modify project or workspace settings
- 🤓 Viewer. Can comment and participate in chats within a project. Viewers can't create or edit projects and templates
You can read more about Taskade roles and permissions in our Help Center (click).
Finally, let's talk about Scrum events (aka "ceremonies). In short, Scrum events are time-boxed instances where the real Scrum
magic work happens. Apart from a Sprint, Scrum defines four major events: Sprint Planning, Daily Scrums, Sprint Reviews and Sprint Retrospective.
As described by the Scrum Guide:
"The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created."
A Sprint is where all the intel and planning accumulated in Scrum artifacts is put into practice. During Sprints, the Development Team tackles a set portion of items from the Sprint Backlog.
Every Sprint consists of four events:
- 📝 Sprint Planning. At this stage, the team decides how they'll execute the next Sprint. The planning stage is time-boxed and limited to 8 hours for every 1-month Sprint. Scrum Master moderates the discussion and makes sure the team follows Scrum tenets
- ⏱ Daily Scrum. Daily Scrums are 15-minute team meetups that happen in the same place and time throughout a Sprint cycle
- 👍🏻 Sprint Review. During Sprint Reviews, the team sums up the work completed during a Sprint. Reviews are time-boxed and shouldn't be longer than 4 hours
- 🧠 Sprint Retrospective. During retrospectives, the team reflects on the latest Sprint cycle. The discussion revolves around the quality of the Sprint and possible improvements in oncoming iterations
Sprint events are all about effective and efficient communication. For that reason, every remote Scrum team should be able to exchange information in a way that replicates the tangible experience of on-site collaboration.
Thre are two ingredients that make this possible: 🗣 A frictionless, unified channel of communication and 📝 a digital, collaborative whiteboard. The goal here is to bring remote work and conversations to the same plane.
Communication efficiency by channel via ZTE.
For instance, whenever your distributed team wants to discuss a Scrum Backlog, they should be able to do so within one environment rather than splitting workflow between two siloed apps.
In Taskade, projects are essentially digital whiteboards that combine collaborative editing with chat, video and voice communication. To further simplify the process, Taskade comes packed with customizable templates of Scrum boards, meeting agendas and much more.
Considering how frictionless online collaboration has become, building a hybrid or 100% remote Scrum team is no longer a challenge it used to be. All that's required is a paradigm shift in the way leaders assemble, organize and supervise their teams.
At the end of the day, it all boils down to cultivating the right work habits and replicating some of the best "local" practices in a remote environment. When we combine these ingredients with a healthy dose of remote camaraderie, remote Scrum becomes a truly agile alternative to on-site collaboration.
👉 Hungry for remote work insights? Jump over here for more insights and studies from Taskade.