You don’t need standup

Notice: Below represents PERSONAL beliefs of palmerj3 (Engineering lead at Spotify) about agile and team organization. Your results may vary.

I recently became a technical product manager at work and this puts me in charge of a team of engineers for the first time. Up until January I was a developer who was upset at how many meetings I had.

So I ran an experiment for the last six months which consisted of a few new behaviors:

1. No stand-ups
2. No planning at regular intervals
3. No retros
4. All meetings are optional

This may sound extreme. But there is some logic to this madness.

I wanted the team to know I trusted them. To know that it’s ok to tackle tech debt, explore, and work at their own pace. I laid out the goals for the quarter and trusted that the work would get done. Then I got the fuck out of the way.

Would you believe it: work got done. A lot of it.

We were an extremely productive team that responded to change and nailed every goal we set out to.

But before we go into detail about why this experiment worked, let’s see how a typical agile team operates.

A typical agile team

We’re going to create a fictitious team called the SuperAgileRockstars.

SuperAgileRockstars do weekly sprints.

So every Monday they spend an hour planning the work for the week. They meet every morning at 10am for standup where each team member says what they did yesterday, what they are doing today, if tasks are blocked, and give announcements. At the end of the week they spend an hour doing a retrospective where they discuss what went right, what went wrong, and create tasks to address these issues.

It sounds pretty logical, right?

How can this paradise of productivity be broken? Let’s see.

1. Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t. As the team grows this becomes even more complicated.
2. Stand-ups ENCOURAGE plans to change daily. Lack of consistency is a great way to ruin developer flow.
3. Standup forces every team member to be productive at a set place and a set time
4. Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that tech debt is such a common problem. Developers shouldn’t have to PUSH for tech debt to be addressed. Teams should operate at a sustainable pace.
5. Why do we encourage problems to be discussed once a week? We should address them immediately, not just at retros.
6. Sprints encourage iterative development. This sounds really good to people like me who strongly advocate small, concise, pull requests over long-living feature branches. But it’s not the same thing. Sprints encourage features over tech debt. How often have you had to advocate spending an entire sprint tackling tech debt?

What would happen if we didn’t plan every week, didn’t do retros, and didn’t do standup?

Stop doing standup

Standup has always bothered me. It usually serves to interrupt developers, make them feel pressured to prioritize features over tech debt, and has been known to last longer than 1/2 hour.

The natural side effects of not doing standup are:

1. Developers communicate more
2. Your team becomes more remote-friendly
3. Tech debt gets addressed
4. Developers feel more in control and less stressed
5. Developers know you trust them and that you have their back

At Spotify my role is a technical product manager. It’s my role to “steer the ship” (e.g. decide what we work on). If I’m changing my mind about this on a daily basis that’s problematic. If the entire organization changes its mind on a daily basis then it’s my job to fix that.

The reality is: I’ve told my bosses what we’ll deliver by the end of the quarter and I would rather trust that my team know what’s required to get there and be creative along the way.

I want to give them as much freedom as possible to get shit done.

Feel like taking a day off to work on open source? Fuck yeah.

Feel like working on something completely different for a few days? Have fun.

Think our tech debt is out of hand so you want to spend some time fixing it up? We are best friends now.

I know you’re going to get us to our goals and who am I to tell you every single day, “well the highest priority item on the backlog is x,y,z”.

Fuck that noise.

Stop planning every sprint

Planning on a regular basis is another thing that has always bothered me. It’s rare, in my experience, that things change so drastically that the entire team needs to get together and figure things out. But if there is an emergency then by all means call a meeting and communicate that shit. That said, I’m not against planning, I’m against planning on an interval.

So what do things look like if we don’t plan every week or two:

1. Developers are trusted to be working on the correct things
2. Developers aren’t interrupted nearly as much so things get done
3. Backlog is used as a priority queue of work to be done
4. Tasks are added to the backlog as needed, continuously
5. Blockers are communicated right away
6. Planning happens when plans change. Meeting fatigue is reduced and the team knows this was a last resort and is important

Stop doing retros

Say you’re in a relationship and it’s going amazing. You should totally start going to couples therapy once a week, right?

Of course not. So why the fuck are we doing retros every week or every month?

Furthermore, why are we waiting until retros to discuss problems or to give praise?

What do things look like when we stop doing retros:

1. Developers aren’t interrupted and get shit done
2. Problems are addressed sooner
3. Stickies and sharpies are returned and we buy lunch instead

Here’s some questions I know you’re wanting to ask

“How will I know what to work on?”

Good: Pick an item from the backlog.

Better: The backlog is prioritized and you pick the highest priority item from the backlog.

Best: You work on tech debt or open source because you need a mental health day.

“What do I do if I’m blocked?”

Good: Pick a different item from the backlog.

Better: Create a “blocked” column in trello, move the task there, then pick a different item from the backlog.

Best: Put the task in the “blocked” column, pick a different item from the backlog, and drop a message in slack letting the team know it’s blocked.

“How will I track the progress?”

Good: Ask the team. Don’t ask every day.

Better: Keep the backlog up-to-date & relevant. Fucking look at Trello.

Best: Communicate to the team if anything high priority is happening. Otherwise trust that work is getting done until that trust is broken. Casually get updates every so often over lunch and/or beers.

“Hold on. We totally handle tech debt and we do stand-ups!”

Awesome!

You must have vocal developers who are willing to push for tech debt to be addressed and management that deeply cares about engineering quality.

The reality is that most companies don’t operate this way and even your company is likely not a great environment for introverts.

Conclusion

Effective teams question everything. They also trust each other. They also get a lot of shit done.

This article is my attempt to question what’s become the default behavior of agile teams. Daily stand-ups, weekly/bi-weekly planning, and weekly/bi-weekly retros. We didn’t even discuss estimation either.

My advice for all teams is to not start by complicating things.

Stand-ups, planning, and retros are a tool and you should be putting a lot of thought into what tools you use.