The daily standup is broken. No wonder. It was invented almost 30 years ago, and we’re still running it the exact same way.
When daily standup 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 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 five 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?
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 firsthand.
How Developers Think About the Daily Standup
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 standup 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 Team Leads and Scrum Masters Think About the Daily Standup
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.
How CTOs, VPs, and Directors of Engineering Think About the Daily Standup
When I was VP of Engineering, I liked to pop into a standup 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 Standup
I’ve worked with a lot of product owners. Some okay; 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.
Okay product owners show up to the standup occasionally when they need an update, and they dominate the conversation with their questions.
Great product owners show up to the standup 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 development team can connect the dots between their work and real-life use cases.
When it’s just a status meeting, 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.
Introducing the Daily Standup 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 standup worthy of the 21st century 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.
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 and 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 Change Daily Standups Now?
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 standup 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 newborn 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.
When I interviewed Shweta Saraf, Sr. Director of Engineering at Equinix, she also made great points about how remote teams have issues with daily standups, and should be remote-first, not remote-friendly when it comes to meetings.
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 standup 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 are 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 time-boxed to 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 standup 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 with LinearB it can be.
Updated Framework
- What did I do yesterday?
- What will I do today?
- 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 into 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 task board 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 mockup. 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 standup: getting pulled into 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.
New Technology
Standard issue tracking and Git tools are just not good enough to be able to answer these questions easily. It’s difficult to get insight. There’s a lot of manual work for everyone on the team, and the issues are rarely well organized.
We correlate project management, Git, and release data to to help you visualize, surface, and address the things that can affect delivering on your promises. With our Pulse dashboard, you get a quick overview of WIP, to do, and Git activity not linked to Jira tickets. Project Delivery Tracker and our planning accuracy metric shows you bottlenecks caused by unplanned work, such as scope creep or technical debt.
With LinearB, you’ll be able to proactively communicate blockers and risks in daily standups to ensure you’re hitting your goals. Let us show you how!
