Why Scrum is Ideal for Managing Remote Teams

Categories : What We Do

Why Scrum is Ideal for Managing Remote Teams

By Samuel Khew on 16 October 2020

As the entire world has come to a grinding halt due to the spread of the novel coronavirus, we are fortunate to be in an industry that has not been as badly affected as others. Every company in every industry has been forced to overhaul their operations, and almost overnight, employees all around the globe are working remotely from home in an effort to maintain social distancing and minimise the spread of the virus. While remote work is nothing new, never before has it been as ubiquitous as it is now.

As a remote software development agency we know a thing or two about working remotely as we have been managing and delivering projects to our partners all over the world long before coronavirus reared its ugly head. A major factor in our success as a remote agency is the Agile framework we use – Scrum.

Scrum makes it easy for teams to be flexible, to respond to changes quickly, and to improve constantly. Here is how Scrum has enabled us to be successful in delivering products remotely both before and after coronavirus.

Inspect & Adapt

Scrum teams are supposed to frequently inspect the way they work and adapt to improve efficiency and effectiveness. After every inspection, teams agree on what works well and what does not, then improve the former and fix the latter.

This concept that knowledge is derived from experience is known as empiricism.

As teams work together day by day, Sprint by Sprint, they learn how best to be successful under the given circumstances.

While empiricism is typically used to improve development practices and processes, it conveniently caters to a new unknown that has been thrown into the mix for many organisations around the world – remote work.

Here are a few examples of adaptations that my teams have decided to implement:

  • Setting core hours where teammates are expected to be online
  • Expectations when we are away from our keyboards dealing with food deliveries or babies crying
  • Communication of design concepts to always be on a video call, rather than chat
  • Video always on for calls
  • GIFs are welcome and encouraged
  • Definition and proper use of the “Do not disturb” status
  • Team lunch on Zoom every Friday

Obviously, what your team decides to implement is up to you and your team, but the empirical process of inspect and adapt is key to bringing issues to light and helping your team be the best remote organisation you can be.

Regular Check-ins

It can be a challenge to find the perfect balance between too many meetings and too few. We have all experienced the occasional miscommunication, since apparently 93% of communication is nonverbal (or is it?). And there are days with back-to-back meetings where nothing of value gets done.

Agile values time and dictates that working software is the primary measure of success and value. Inspect your organisation, determine what is of value, and adapt accordingly – and you have just been empiricised (not a word? It is now!).

The godfathers of modern day software development, Ken Schwaber and Jeff Sutherland, designed the Scrum framework to maximise value and minimise time waste. There are 4 formal meetings in Scrum that occur at intervals throughout the Sprint.

  1. Daily Scrum
  2. Sprint Planning
  3. Sprint Review
  4. Sprint Retrospective

Each of these meetings in Scrum is also time-boxed. Meetings should not exceed the allotted time, because that takes away from time our engineers can spend on coding – working software is the primary measure of success, remember?

Another benefit of this design is regularity. Every team knows when their Daily Scrum is and because it is the same time every day, it is hard to forget. It becomes part of the team’s DNA. For me currently, I know that 3pm – 4pm every Monday – Thursday is booked for Sprint Meetings for four different projects. No need to think about it. No need to double check. It is there and it will consistently be there until the end of the project.

Clearly Defined Roles

There are three roles in Scrum.

  1. Product Owner
    In charge of making all product decisions from requirements to priority.
  2. Development Team
    In charge of building the product. Everyone involved falls under this role (Designers, Developers, Dev Ops, Architects, Business Analysts, Project Managers, etc).
  3. Scrum Master
    In charge of applying, coaching and promoting all things Scrum within the team and organisation.

Three simple and clearly defined roles make for very little management overhead because everyone knows what to do and where to find the support they need.

This is especially useful in a remote situation because if you have messaged someone with a query, it could take some time for them to reply, and having waited that time, you surely do not want the answer to be, “Oh you need to ask Sarah about this.”

Scrum development teams are also expected to be self-organising, meaning it is their prerogative to decide how best they can work together to accomplish their goals – further minimising the need for management oversight.

A team well-rehearsed in Scrum, with everyone playing their respective roles well will result in a highly productive team, even if they are scattered across the globe.

A Remote Concept

If you are new to working remotely or managing a remote team, take heart, because it is new to a lot of other people too. Be flexible and open to change. Keep doing whatever works, and dump whatever does not. Find that sweet spot between micromanaging and being hands-off. Lead your teams by defining, modelling, motivating, and coaching them on what their roles are and how to play them effectively.


RELATED POSTS

Increasing Productivity Graph
When the Team Became TOO Productive

Post By Samuel Khew | 17 February 2020

At Suria Labs we are all about results. Discover how to create a culture and environment that maximises your team’s productivity.

How to build a Minimum Viable Product

Post By Alastair Johnson | 12 February 2020

How to build a minimum viable product – your guide to a successful project.

Minimum Viable Product
What is a Minimum Viable Product?

Post By Alastair Johnson | 11 November 2019

What is an MVP and why does your custom software project need one?

Tablet with custom software
6 reasons to build a custom software solution for your business, and one reason to avoid it.

Post By Alastair Johnson | 14 October 2019

There are excellent reasons to build custom software solutions. A custom-built, or bespoke, software solution can revolutionize your business.

Custom Software Development
Custom Software Development Partners - 8 Attributes for finding the Best.

Post By Alastair Johnson | 30 September 2019

Choosing the right partner to build your custom developed software solution is critical to the success of the project.

Agile custom software contract
An Agile software contract sets up your project for success.

Post By Alastair Johnson | 22 August 2019

A great Agile software development project needs a contract that supports all parties to deliver the best outcome.

Share On :