Scrum is terrible for remote teams

Hey,

I'm Sergio Pereira, and this is the Remote Work newsletter 👋

Last week I told you how I handled the question "How can I hire you?", as my life changing job offer was on the table, but my future employer was clueless about remote work contracts.

Today I'll tell you about this popular process that thousands of teams use, but I do NOT. Scrum!

I don't use Scrum in my Remote Teams because it used to add at least 8 hours of meetings per Sprint. That's 2 full days of lost productivity, per team member, per month!

I actually used Scrum a lot, earlier in my career. At times because I was pushed to do it. Other times because I didn't know better. In fact, everyone was doing it, so it felt like the natural way to manage tech projects to me.

But then I started doing some math. These were the normal "Scrum meetings" in my teams:

• 2h 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. Just for process boiler plate.

And those 8 hours of meetings would get eventually 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 Remote+Async, in my opinion!

Since then, I've stopped using Scrum. It was my first step to reduce 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. If you read my content for long enough, you'll know I try to reduce meetings in my remote teams.

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 rigid framework. This is especially damaging for remote teams, where people expect more flexibility.

For me, it makes more sense to develop software in a goal-oriented way. "Goal" meaning: A clear business case that supports *Why* such 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 business case

• Collect requirements

• Assess feasibility and tradeoffs

• Plan/architect the solution

• Implement

• Test

• Launch

• Retrospect on results

So I break new feature requests into these 5 important questions:

1 Why -> The clear business case.

2 What -> The feature that will address the business case.

3 How -> The technical approach to implement that solution.

4 Who -> The team and resources needed for that effort.

5 When -> The delivery timeline, for expectation alignment.

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:

1 We can only define the "What" after we understand the "Why".

2 We can only plan the "How" after the "What" is clear.

3 Defining the "How" implies discussing tradeoffs that affect "Who" and "When".

Usually the document is started by a business stakeholder, or a Product Manager. They define the "Why". Example of "Why": We need 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. Exampel 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 Engineer. 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, the "Who".

Trade offs regarding timeline should have been clarified, and shared expectations about "When" should have been aligned. It ends with ownership + accountability to deliver!

In my teams, we can do this without meetings for most tasks. 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 comms can create very long lead times, so I opt for meeting on those.

Ditching Scrum was a fundamental part of my transition from meeting heavy processes to async workflows. I cover this transition at greater length in my course Mastering Remote Work, where I detail these processes and why I decided to do them this way.

Thanks for reading this newsletter until the end. You can read all past editions here. Make sure to share the link with your friends and colleagues so they can read it too.

See you next Friday,

Sergio Pereira,
Startup CTO & Remote Work Lover