DEV Community


Posted on

Stand-Up 2.0: It’s Time To Ditch The Daily From 1993


The daily stand-up is broken.

No wonder. It was invented almost 30 years ago and we’re still running it the exact same way.

When daily stand-up meetings started in the early 90s, the software development process looked very different. Git didn’t exist. We wrote code locally on our desktop computers. Jira didn’t exist. We planned with spreadsheets. Collaboration tools didn’t really exist. We sent emails. DevOps didn’t exist. Automation tools didn’t exist. Analytics tools didn’t exist.

Don’t get me wrong, I loved the early 90s 🙂

The Early 90s“When I wake up in the morning the alarm gives out a warning… Yadda, yadda, yadda.”

The typical technology stack for a developer has changed dramatically.

We manage code in Git which is connected to our teammates through communities like Github, Gitlab, and Bitbucket.

We have countless DevOps tools that automate our work throughout every area of the development pipeline.

We communicate with our teammates through Slack and Teams constantly.

We have analytics dashboards with data to measure everything.

This technology has changed the way we work. Software development is an activity that is much more connected, collaborative, automated, and data-driven than it was even just 5 years ago.

So why does our most important team activity of the day still run off of a 30-year-old framework leveraging outdated data from Jira, no automation, and none of these other tools we use to run our business?

Personal Problems

I’ve personally felt pain with daily stand-up meetings in almost every possible role – as a developer, as a dev team leader, as a scrum master, as a VP of Engineering, and as a product leader.

The following are problems I’ve experienced, seen, and heard about first hand.

How developers think about the daily stand-up

Another meeting . . .
First coffee. Then all the things.

The unicorn is almost 100% right. Except, instead of email, most devs I know just want to drop their status update into Slack and get back to work. If they aren’t blocked that day, what’s the point?

And therein lies the problem. Most developers don’t think of the stand-up as a meeting that was designed for them to get value. It’s for my team lead and our scrum master and maybe our product owner. Not for me. When the majority of the people in our meeting don’t see the value and would rather skip most days, we have a problem.

And there’s another elephant in the room. A lot of devs don’t like to ask for help in front of their peers. Speaking up to admit you’re blocked is really hard for some people. So we’re putting a barrier between them and the main value of the meeting – removing impediments.

One more thing. So let me get this straight… I show up to this meeting. I listen to everyone share an update that could have been in Slack. I share my update. We run long. And then I still get pinged 10 more times throughout the day for updates? What was the point?

How dev team leads and scrum masters think about the daily stand-up

When I was the lead for a single team, I found our daily very useful. It was one of my best tools for diagnosing risk to our iteration and keeping us on track. But I still had my issues with it.

For starters, I had to wade through all of the updates to get to the part I cared about: blockers and risk. We probably spent 80% of most meetings sharing status updates. Leaving very little time for valuable, actionable conversations. Even though the goal is to take problem-solving offline, I hardly had enough time to gather the information that would help me act after the meeting.

We spent a lot of time discussing whether Jira was up to date. It almost never was.

I also struggled to get everyone to share their status in a consistent format. Some would say about 10 words and be done in 20 seconds. Others would share a lengthy verbal history of the last 24 hours 🙂

The worst part was knowing that I didn’t get the whole truth a lot of the time. For some devs, getting them to speak up about a problem was like pulling teeth.

Despite having a timekeeper (2 minutes per person – yeah right :-)) and doing our best, we ran long almost every day. I could feel the tension in the room most days – everyone just wanting to get back to work.

LinearB Dev Team
The LinearB dev team sitting in the daily stand-up??? Shame.

How CTOs, VPs, and Directors of Engineering think about the daily stand-up

When I was VP of Engineering, I liked to pop in to a stand-up occasionally to “take the pulse” of a team or get an update on a specific feature the business cared about.

I knew they acted differently and were even less likely to speak up when I was there but I showed up anyway because there weren’t many other opportunities for me to see an entire team together in action.

Unfortunately, looking back on it, I’m pretty sure my presence derailed the meetings. Why? Because my reason for being there didn’t align with the purpose of the meeting. I wanted facetime with the crew or I wanted a specific status update. I was almost never really concerned with their specific iteration.

How product owners think about the daily stand-up

I’ve worked with a lot of product owners – some OK, some great. Helping to manage product is part of my job at LinearB right now so I’ve been cataloging the behaviors I have observed from the great ones so I can replicate it.

OK product owners show up to the stand-up occasionally when they need an update and they dominate the conversation with their questions.

Great product owners show up to the stand-up every morning because they would never miss an opportunity to unblock a teammate. They listen and they pick their spots with only the most relevant questions. If they do take time to talk, it’s to describe the customer experience so the dev team can connect the dots between their work and real-life use cases.

When the meeting is all status updates, a great product owner doesn’t get a chance to add value.

And what are they looking to get out of it? Our deadline – are we going to hit or miss it? That’s my biggest complaint today with our internal daily meeting. I rarely leave knowing if we’re really on track.

Daily Stand-Up 2.0

We have to fix this. The daily meeting is an incredible opportunity to set up our teams for a great day. But we’re wasting it.

What does a daily stand-up worthy of the year 2020 look like?

Have you ever seen the movie Minority Report? I imagine it like that. But instead of Tom Cruise, there’s software developers. And instead of predicting crime, we would predict when we’re going to miss our delivery date or when we’re going to have quality issues.

Minority Report Standup
Pictured left: Tom Cruise. Pictured right: Software engineers from the future. In case that wasn’t obvious 🙂

In case you haven’t seen the movie… Tom Cruise is a police officer from the future who uses a three-dimensional dashboard to predict and prevent crime.

Every morning he walks in and his dashboard has already compiled all of the activity for him from the last day, filtered the most important facts, and presented them visually so he and his team can see exactly what needs their attention. Then they discuss their plan of action and go save the day. Their meeting is fast, efficient and it helps them catch the bad guys (almost) every time.

The movie came out in 2003 while I was in college at Villanova getting my computer science degree. I loved it and definitely imagined myself graduating and getting a cool job where I could move virtual TV screens around in the air 🙂

Why Now?

My windowless "office"

I’ve been spending a lot of hours lately in a tiny windowless closet under my stairs – my work-from-home “office”. Things get weird in there sometimes. Obviously. I’m comparing our daily stand-up to a Spielberg sci-fi movie.

I have a lot of time to think. One thing I keep coming back to is that time is so precious. I love building products that people use. I love hanging out with other engineers. I also love spending time with my family and my new-born daughter. Not one of those things is served by spending 45 minutes, 5 days a week in a boring meeting that most people don’t want to be in that I’m not getting anything out of.


I don’t have all of the answers. But I have put a ton of thought into this and I’m going to share my ideas and a path forward. And, more importantly, I’m putting skin in the game. The entire dev team at LinearB is putting skin in the game actually. More on that below.


Developers generally hate meetings. But is it really so unrealistic to think we could create one meeting that devs actually want to attend?

Hypothesis: The daily stand-up can be a meeting that not only provides value to everyone in the room – including developers – but it can be a meeting that everyone is excited to attend. As a result, collaboration will increase, contributors will think more strategically about team goals and teams will deliver a high-quality iteration on time more often.

As a community, I think there’s a few things we need to create to bring this idea to life:

-Updated framework. “What I did yesterday” and “what I’m doing today” are a core part of the problem. Those are status updates that could be covered by a Slack message. I think we can run the meeting with better questions that will lead to more actionable discussions during and after.

-New contract. Everyone who attends should know what they need to put in and what they can expect to get in return. And the value should be on par with the investment.

-Updated guidelines. Should this meeting really be 15 minutes? Should we really go around to everyone even if they have nothing important to say? I’m not so sure.

-New technology. Like everything else we do, the stand-up should be data-driven and automated. Why can’t all of the status updates be on the screen on a dashboard when we walk into the meeting? All of the data is there in Git and Jira so I think it can be.

LinearB is building the stand-up dashboard from Minority Report. Want to join our mission and help us define Daily Stand-Up 2.0? Sign up for our early access program.

Updated framework

What did I do yesterday?
What I am I working on today?

Focus on:
How am I blocked?
What’s distracting me from my #1 priority?
Will we ship on time?

Guiding the daily with questions still makes a lot of sense to me. But before we get into that…

Should all attendees prepare for the daily before they arrive? Everything I’ve ever read about meeting best practices suggests we should.

If we all showed up to the meeting already familiar with the progress that was made yesterday by everyone and the open WIP for today, we could jump right in to the good stuff.

That’s my first proposal to the community:

Let’s make “yesterday” and “today” table stakes for attending the meeting.

I realize that “yesterday” and “today” are part of making a commitment to the team and being accountable. This is very true and useful. In fact, that’s why I would argue that a Slack message or an automated dashboard is a better way to share it. Because it’s in writing.

Now back to the issue of value. Which questions will help provide the most value to everyone in attendance including developers?

How am I blocked?

Giving and getting help is really valuable. And everyone I interviewed feels like this element of the daily works well. So let’s keep it.

What’s distracting me from my #1 priority?

When we think about blockers, we tend to focus on two types:

Technical. I’m having a problem in the code. I’m having a problem connecting to a new API. I couldn’t’ find what I need on StackOverflow 🙂

Dependencies. I’m waiting for a UX mock-up. I’m waiting for someone to pick up my pull request. I’m waiting for someone else to finish their service so I can finish mine.

But there’s another kind of blocker that can be even more disruptive that we don’t often talk about in the stand-up: getting pulled in to projects that are not my #1 priority.

What should my #1 focus be and what is pulling me away from it? It could be an unexpected bug or request from the CEO. It could be too many meetings. It could even be something at home limiting working hours.

Talking about it every morning will help our devs to think strategically and take more ownership over how they contribute to the most important business priorities. It will also empower them to push back when it makes sense – which is a muscle most devs need to build more.

Team leads and scrum owners will benefit as well because they’ll get more “truth” about things affecting the current iteration and have the ability to clear a path for the team to focus on what matters. When I was a team lead, the worst thing for me was to find out that a dev was working on one thing when they really thought they should be working on something else.

In addition to the benefits you’ll get in the current iteration, the team will benefit because over time. As you observe that certain patterns are distracting focus over and over again, you can invest in mechanisms to fix it.

This question pairs well with a metric I used to track called iteration churn – how many tickets are coming in and out of our iteration after it begins?

Iteration churn and focus disruption both speak to predictability which everyone on the team cares about.

Will we ship on time?

Delivering everything in the iteration on time is the ultimate team effort. So shouldn’t everyone on the team participates in the discussion about if we’re going to hit our deadline?

Most devs have a sense of whether or not they are on time. Most devs have a sense of whether or not they have too much or too little work. Most devs know if they are working on a branch that feels complicated or risky. If I’m working on something that another dev is dependent on, I have the ability to foresee a cascading effect of delays that could eventually affect the whole team.

Someone might have information that affects the whole team and iteration like a company offsite being planned or a new big enterprise customer that requires XYZ feature.

By the way, they’ll appreciate being asked their opinion so they don’t have to do what they do now which is to walk out of the room and whisper “What a cluster. We’re never going to finish”.

Their opinion about whether the iteration is on time is relevant input for the team lead or scrum master because it goes to the heart of what they’re trying to get from the meeting. And if a developer does not have a good sense of timing, WIP balancing, and risk, they’ll only get better at it by getting repetitions. Which is great for leadership because they’ll be leveling up everyone on the team.

Product will love this conversation too because they’re the masters of scoping down and figuring out how to deliver 80% of the value to customers with only 50% of the work.

Next steps

I’m committed to figuring this out. It’s going to be a process and I’m going to need your help.

Here’s what I’m going to do (skin in the game):

I’m going to continue writing about this. In my next blog, I’ll share ideas for a New Contract and Updated Guidelines.
Our dev team is designing an experiment to test the hypothesis. We are running this new stand-up internally so we can work out the kinks and share our results with you.
We’re building the stand-up dashboard from Minority Report and we would love your feedback. Click here to sign up for our early access program.

Daily stand-up
The LinearB dev team in our daily stand-up working on a dashboard to help make the daily stand-up better. Very meta!
Here’s how you can help:

Tell me everything that’s bad about this idea. I need critical feedback. Send me your questions and ideas. What else do we need to really fix this? I would love to chat over Slack, Zoom, or email. Please get in touch:

Dan Lines
COO & Co-founder

Top comments (14)

linearb_inc profile image

Sascha - this is great!

I think the guiding light of the iteration deadline or sprint goal is a good one. It helps the team take the first step away from a simple "how do I justify my time as an individual contributor" status update and helps focus on "Are we as a team going to deliver".

This shift can also make the standup feel less judgemental/big brother. "We're all in this together, so let's crush it. How can we help each other do that?"

awshanks profile image
Andrew Shanks

Agree with your point on who attends can derail the meeting and make it a status update. The more senior a person there the less people want to be open about issues for fear of looking bad. The Jira board or whatever tool the team use to track should be up and the developer talking just chooses what to talk about that needs action.

yerac profile image

Although worth noting that a stand-up meeting should only be attended by the delivery team, nobody else. It's up to the PM to deliver updates to stakeholders or external interested parties.
A lot of people that dislike the meetings are usually running them wildly incorrect or using them as project update sessions!

awshanks profile image
Andrew Shanks • Edited

Oh I completely agree. In most teams I've been in that's not up to the delivery team. If there are other managers more senior then they just attend or make the meetings what they need them to be, project update sessions.

Thread Thread
linearb_inc profile image

This is an interesting topic to dive into. Who to invite to the standup. Maybe we'll cover it in the next blog? Stay tuned . . .

kevinhooke profile image
Kevin Hooke

Organizations need to encourage their people to question 'why are we doing this?' and ask whether it adds value. If it doesn't add value, why are you doing it? Similarly, the old joke about 'we have x people in this room for an hour, at $y/hour this meeting is costing us (and most likely the client) $x*y - is this meeting worth it?' - this needs to be asked seriously as a sanity check for avoiding unnecessary meetings, or exchanges of info that can be done in seconds via an email or Slack, verses having everyone held hostage in a room for an hour.

15 min standups are more efficient than many other traditional status meetings in the past (if you keep them timeboxed), but if the information being shared is not useful, why do it? If the opportunity for team members to ask for help when they're blocked is the most valuable part of a standup, you don't need the whole team in a room to enable this?

linearb_inc profile image

Kevin - exactly. I've have actually done that calculation in my head when in large unnecessary meetings at previous companies.

I think you're right that blockers that are dependencies are better handled through slack. Mostly because you can get things moving sooner.

For technical blockers, I think it is useful to talk about it as a group sometimes. Everyone on the team has a different background and maybe someone has already tackled this. Still possible on Slack, but I think better solutions can sometimes be landed on through conversation.

arashkiani profile image

Nothing out of ordenery here, as far as I remember the contract has always been; what did I do yesterday, what am I going to do today, and any blockers. The main frustration often come imo from lack of leadership and team not working together in order to solve the problem.

linearb_inc profile image

Arash - thanks for reading and sharing your thoughts.

I think a lot of devs share your thoughts of "that's always the way we've done it". I think what's interesting is the shift to talking about all things through the context of delivery. So the most important thing to talk about is what's preventing that (blockers, dependencies, etc). Framing the conversation this way makes sure that the time is most efficiently spent. Any other conversations about what was done can also be framed this way. For example, here's what I released yesterday and what's progress.

arashkiani profile image

Essentially you are saying the same thing in slightly more complecated way! I mean maybe there is a small opportunity to teach the right way of doing it (what you achieve yesterday what will you achieve today, how can we help you do better ) but what we both are saying is already in place.

As for maximising the delivery I still think it's 80% leadership issue, 20% team not understand the importance of working together.

arashkiani profile image

Personally I actually like standup as it gives me a memory boost to start my day. Yesterday I worked on abc today I am working on xyz. Possibly I will have problem with def. Would make my day if someone comes back to me and say you missing g-w have a think through that and let's work together if you need extra eyes. Honestly that's what I try to do for my team as often as I can.

yerac profile image

Have you seen Azure Devops boards? Kind of the same thing. We use them for our stand-up as we have a dashboard with the kanban lanes, plus another swimlane for items the team moved into "blocked" or "waiting".
Focus of the meeting a quick update if you moved something into blocked, quick check of the capacity chart to see if you should still meet assigned tasks, quick look over anything in the "unassigned" column.

All hooks into our Git and TFVC repos and backlog boards and updates in real-time.

cpjolicoeur profile image
Craig P Jolicoeur

Reminds me a lot of Standuphub -

Good luck with the launch!