Why I Don’t Use Scrum To Manage My Remote Teams

It adds at least 8 hours of meetings per Sprint. That's 2 full days of lost productivity, per team member, per month!

So this is what I do instead.

Earlier in my career, I did use Scrum. A lot, actually.

At times because I was pushed to do it. Other times because I didn't know better.

Everyone was doing it, so it felt like the natural way to manage tech projects to me.

These were the normal "Scrum meetings" in my teams:

2 hours for grooming.
1h30m for sprint planning.
2h30m for stand-ups (15m x 10 days).
2h for retrospective.

Every team member started a 2-week Sprint with 8 hours in meetings already scheduled.

And those 8 hours of meetings got extended every Sprint.

Because either:

Those scheduled meetings overran.
The proverbial "Let's take this one offline" (= another meeting).
The even more proverbial "Let's book a follow-up to close this off" (= another meeting).

I started seeing red flags in Scrum when I started implementing asynchronous processes in my teams.

I hired people in different time zones, and forcing them all to sit in so many meetings started feeling like a big bottleneck.

Scrum isn't compatible with Async, IMO!

Since then, I've stopped using Scrum to manage remote teams. It was my first step to reducing meetings in my teams.

Beyond the time actually spent in meetings, they are also a big distraction for people who need to do deep work.

The 2-Week Framework Isn’t Practical

Another thing I don't like in Scrum is how it forces all projects/features into a 2-week framework.

Some features are small and take just a few days. Others are enormous and take longer than 2 weeks.

Not all types of effort fit well into such a fixed framework.

The Better, Goal-oriented Management

For me, it makes more sense to develop software in a goal-oriented way.

"Goal" means a clear business case that supports Why such a feature needs to be built.

Eg: "We need HIPAA compliance to sell to clients in the Healthcare sector"

Between idea and shipping, there are many activities, such as:

Create a business case.
Collect requirements.
Assess feasibility and tradeoffs.
Plan/architect the solution.
Implement.
Test.
Launch.
Retrospect on results.

So I break them into these 5 important questions:

Why -> The clear business case.
What -> The feature that will address the business case.
How -> The technical approach to implement that solution.
Who -> The team and resources needed for that effort.
When -> The delivery timeline, for expectation alignment.

Documentation Is Key

Now, I don't bring my whole team into a "brainstorm" meeting to address these questions.

Each depends on different stakeholders, and they can be tackled sequentially for the most part.

In my teams, all these 5 questions live in the same collaborative document.

I have these 5 questions as sections of a Notion template.

Some rules are:

We can only define the What after we understand the Why.
We can only plan the How after the What is clear.
Defining the How implies discussing tradeoffs that affect Who and When.

How We Do It

Usually, the document is started by a business stakeholder or a Product Manager. They define the Why.

An example of Why: "We need to comply with regulations in the Healthcare sector, so we can expand our sales in that vertical."

From this Why, a Product Manager usually crafts the What. It needs to be clear enough so that Engineers understand it, but flexible enough to take input around feasibility and implementation tradeoffs.

An example of What: "Our data needs to be stored in HIPAA-compliant servers."

The How, Who, and When are usually collaborative, and led by technical stakeholders, eg: an EM.

Resources or time constraints force to cut scope. Trade-offs are to be discussed collaboratively.

Example of How: "Move database and file system to HIPAA-compliant AWS services."

The How discussion should clarify the tasks to be done and the assignee for each of them, which is the Who.

Trade-offs regarding the timeline should have been clarified, and shared expectations about When should have been aligned.

It ends with ownership + accountability to deliver!

When Meetings Are Necessary

In my teams, we can do this without meetings for most tasks. So I make sure to reduce meetings as much as possible.

For tasks with denser trade-off considerations, we jump on a meeting to discuss those live and commit to an approach.

Long iterations over async communication can create very long lead times, so I opt for a meeting on those.

This is how I shifted from a heavy meeting culture (led by Scrum) to an Async-first workflow.

I can tell it was one of the key contributions to this acute before & after effect in my career.

I'm now more productive, my teams are more efficient, and none of us is burned out.

I'm launching the course "Mastering Remote Work" soon. It includes a deep dive into the processes I use to manage my remote teams around the globe.

Join the waitlist for early access and a 30% discount.

Follow me for more knowledge about remote work

I’ll be publishing new articles every week, and new social media content every day. If you enjoyed this article, follow me on Twitter or Linkedin, and stay in the loop. Share my content and drop a comment there. Let’s help more people learn about remote work.