Thread by @SergioRocks

Why I don't use Scrum to manage my Remote Teams?

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

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:

- 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 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. 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.

Here I wrote more about 7 ways I replace meetings with async processes:

https://twitter.com/SergioRocks/status/1523649517354201088

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.

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 them 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".

Eg 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.

Eg 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.

Eg 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.

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 more productive, my teams are more efficient, and none of us is burned out.

https://twitter.com/SergioRocks/status/1576988011576922121

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👇

remote-work.io/course-masteri…

Interestingly, I read recently in @GergelyOrosz's newsletter that most Big Tech companies don't use Scrum either.

Instead, they use some variant of Plan > Build > Ship. I had never seen that coined as a process, but resonates a lot with my approach.

newsletter.pragmaticengineer.com/p/project-mana…

@GergelyOrosz That's a wrap!

If you enjoyed this thread:

1. Follow me @SergioRocks for more of these
2. RT the tweet below to share this thread with your audience

https://twitter.com/SergioRocks/status/1577644315924467712

If you'd like to dig into the collaborative process that my teams do while planning a new feature, check this thread:

https://twitter.com/SergioRocks/status/1588170448285712384