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 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?
We’re building the automated stand-up dashboard of the future, connecting and correlating data from Git and Jira. Sign up for our early access program.
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
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.
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.
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?
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.
Disclaimer
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.
Hypothesis
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:
- 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.
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
W̵h̵a̵t̵ ̵d̵i̵d̵ ̵I̵ ̵d̵o̵ ̵y̵e̵s̵t̵e̵r̵d̵a̵y̵?̵
W̵h̵a̵t̵ ̵w̵i̵l̵l̵ ̵I̵ ̵d̵o̵ ̵t̵o̵d̵a̵y̵?̵
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.
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@linearb.io.
LinearB gives dev leaders access to the real-time data they need to run standup 2.0. Want to make tomorrow’s standup better than today’s? Get started now for free.
Dan Lines COO & Co-founder LinearBOriginally published at https://linearb.io on June 12, 2020.
