The Inverted Daily Standup

What can we revisit and recycle from what Agile development has taught us, instead of discarding it in the post-agile era

© 2017 Tom Gately, Pixar Animation Studios

It is not news that the whole Agile approach is somehow outdated if taken too strictly, with people like Nate Walkingshaw stating that Agile Died While You Were Doing Your Standup or Marty Cagan revisiting the usefulness of a typical Roadmap. This interesting change is happening: we focus on outcome rather than output, and that necessarily demands revising the way products are developed at core.

I suggest we don’t discard completely what Agile development has taught us, but rather to take its insights and be open to test several models until finding something that works for a given team (until it breaks, the moment we change again!). In this article I’ll focus on the Daily Standup Meeting:

Why not reversing one of Agile’s core institutions and see if it boosts your product team’s performance?

The classic Daily Standup

Daily Standups are a core part of Scrum/Agile development, serving multiple purposes depending on the team’s structure, maturity and size. Broadly speaking, these are its main goals:

1. Identify pieces of finished work that can follow through the current team’s work flow (typically from In Development to Peer review, to Test, to Deploy, etc). The ‘What did I do yesterday’ question.
2. Create awareness for what is being tackled, manage team capacity and avoid overlapping effort. The ‘What will I do today’ question.
3. Bring a shared commitment environment where team members push each other to move forward. The ‘What will I do today’ question and its impact on others perception of one’s work.
4. Identify team’s problems or blockers that need to be addressed or will reflect a change in the current plan, kicking-off topic-specific discussions within the team so that it can move faster while enabling alignment. The ‘Do you have any roadblocks’ question.
5. Create a plan for the next 24h hours for what is currently in development or blocked — typically until the next standup.
6. Bring developers, QA, PMs and designers to the same page on what’s the pulse of the team and how things are progressing.

The default timing for a Daily Standup is in the morning, and most of the product teams run it as a first thing to kick off the day. Here’s an outlook of the typical Daily Standup Model:

• Run first thing in the morning
• Face to Face, for 15 min maximum
• Answer the 3 following questions in turn: 1) What did I accomplish yesterday? 2) What will I do today? 3) What obstacles are impeding my progress?
• Discuss any needed topics in depth just afterwards as a follow up
• Work
• Repeat the next morning

While a lot has been discussed about the best time of the day to run them (here, here or everywhere), the universal answer keeps on being “It depends!”. Given this, I wanted to test this concept further and, along the way, make some changes to its format so that it could fit our current team setting and development culture.

Introducing the Inverted Daily Standup

Here’s the model we are testing at our team at Monzo:

• Run last thing in the day
• Slack, asynchronously if needed
• Answer the 2 following questions in turn: 1) What did I accomplish today? 2) What will I do tomorrow?

(The “What obstacles are impeding my progress?” is not used in this model)

• Discuss any needed topics in depth when relevant as a follow up
• Collaborate
• Repeat the next evening

Assumptions and Impact of Potential Solution

Let’s go through the structure of the Inverted Daily Standup Model and reflect on its assumptions and why it might have a positive impact:

Run last thing in the day

Most people are most productive in the morning, starting fresh to tackle the biggest challenges they have when their brain is at highest capacity. If we can allocate our cognitive effort to tasks other than planning the day and doing an effort to recall what was done yesterday we should take the opportunity.

People also tend to be more effective with a specific plan and a clear prioritised direction, and starting the day with this ready in advance is a plus for a productive kickoff.

Slack, asynchronously if needed

Without a doubt, face-to-face communication is still the most effective way of coordinating a group of people working towards a common goal, but the main purposes of the standup outlined above can be met by asynchronous communication via Slack, given that the team communicates extensively throughout the day if there needs be (more on this below).

The fact that we do it via Slack accommodates the following team specific needs:

1. It avoids the need to coordinate schedules and the logistics around getting a room and waiting for everyone to be present
2. It does not differentiate remote and non-remote team members (our team has both)
3. It’s in written form, making everything more palpable and concrete, and stays present for future reference if needed
4. It can be read by everyone in the team (and outside) at different times, giving the ability kickoff separate follow-up discussions and be transparent by default

Answer the 2 following questions in turn:

1. What did I accomplish today?
2. What will I do tomorrow?

By flipping the model to evaluate what was done today and reflecting on what will be planned for tomorrow we emphasize the evaluation of outcome by and individual and make clear this can (and should) serve as a sort of examinations of conscience.

Doing it this way, each team member will be able to have fresh in their mind what was really achieved during the course of the day and the impact it might have in future work. Planning will tend to be more adjusted to realistic expectations, thus we might be more successful attempting to remove any optimistic bias or planning fallacy when planning ahead, a common error of these types of check ins.

3. What obstacles are impeding my progress?

We don’t cover blocks during the daily check in as we believe no significant blocker should wait to be raised, no matter what time the Daily Standup is held.

We have core hours of productivity where non-interruptive work is held, but also have an interesting implicit model of interruptive work where if there is a significant blocker for a given team member, it is discussed in team (or 1:1) when timing is appropriate. Engineers are incentivized to raise an obstacle with the relevant peer to move faster, and the rational is valid for interactions between engineers<>engineers, PM<>engineers and engineers<>PM.

An important note and an assumption for this model to work is that the PM is acting as a first line go-to for many kinds of issues coming from the team’s stakeholders, allowing the Engineering team to increase their non-interruptive work time.

If there is a relevant topic to be discussed between the PM and and engineer, the PM will either:

1) Send a Slack message alerting for the topic so that it can be addressed when the Eng. looks at Slack or is on a small break, thus being as soon as possible but without interrupting the Eng. flow

2) Wait for the Eng. to go on a break (bathroom, food, etc). For this PM<>Engineer relationship to be effective and for blockers to be addressed fast and shortly, we have also adjusted the sitting plan accordingly to increase informal meeting time (more on that here) and facilitate these short, effective encounters as follows:

Sitting plan that encourages short informal interactions between Engineers and PMs

As seen above, PMs are easily reachable as they are in the natural path for an Engineering taking a break, incentivizing this way many more short talks where not only work gets unblocked but also innovative ideas are triggered. We have noticed that the value of these talks is increasing daily and not only the PMs can reach out to the Eng. when appropriate but also the Eng. reach out and swing by the PMs desk as a way to move faster and bounce some ideas throughout the day.

The remaining practical implementation is quite simple: we have a simple Slack reminder at 17h00 every weekday:

Each team member answers the questions 1 and 2 above directly on the thread to maintain team visibility and adds anything that might be relevant for the day. The next day, the team starts to tackle the prioritized plan from the day before!

Known Issues

There is no one size fits all, so this is not likely to work effectively given the current constraints:

• It is not ideal for remote-only teams, as sometimes the standup is an important moment where everyone speaks to each other through video call
• It does not work for teams in different time zones (but then, does any model?)
• It is not ideal when the team leaves the office at considerable different times
• If the assumptions of being more productive in the morning + planning the next day afterwards being better don’t hold, this doesn’t hold
• A Slack thread only works for teams that are disciplined and used to have Slack as a main working tool
• The Slackbot might make it less personal at the beginning before it’s a habit, so it might take time to be effective
• The Engineers need to be comfortable with small periods of informal discussion throughout the day, to address any questions/blocks or adjust daily plan accordingly — communication is key!

This is a small but hopefully interesting detail of a bigger approach I am aligned with on how we should take product development through radical collaboration, user centricity and a focus on problems (vs solutions) and outcomes (vs outputs). I hope to be able to write about it soon!

Let’s see how does this play out, would love to hear your thoughts. You can reach out directly at franciscocarvalhoaraujo@gmail.com.