I’m in awe (thank you)
Two weeks ago I posted a blog about reinventing our daily stand-up meeting:
Stand-up 2.0: It’s time to ditch the daily from 1993
We don’t need a meeting to discuss individual status updates that could be a Slack message.
Let’s create a meeting focused on working together as a team to deliver our iteration on time.
I proposed a new framework that can be summarized into 3 key points:
- The stand-up should give everyone in the room value every day. Especially developers. Not just team leaders.
- Team members show up to their daily already familiar with what their teammates did yesterday and what they have open today – aided by a simple Slack message or a data-driven dashboard.
- Instead of status, the meeting focuses on three topics:
– How am I blocked?
– What’s distracting me from my #1 priority?
– Will we ship on time?
At the end of the post, I asked for feedback. And I got it. An incredible amount of it.
So let me first say thank you. I’m humbled that 100+ of you took the time to respond, give honest feedback, and share your own ideas.
I’m working on two more posts right now. One about the guidelines and technology we need to make the Stand-up 2.0 framework work. Another documenting the experiments our own dev team has been running at LinearB to see what they like and don’t like.
But all of your ideas have helped us evolve our thinking. So I figured I better share the feedback I received so we can continue the discussion together as a community.
Our community is ready for change
One of the main goals of Stand-up 2.0 is to make the daily more dev-centric.
“The standups I’ve been a part of were either a total joke or just management getting a status update.”
-Jason, Software Engineer
Jason is not the first engineer I’ve heard this from over the years. I do think this is a widely held belief across our community. But you’ll see below it’s not quite that simple.
More than 100 people responded through chat, Linkedin, text, and email. I attempted to filter the most thoughtful and interesting comments representing the spectrum from excited and supportive to critical and apathetic.
The feedback below is organized into 10 themes that emerged as I was processing everything:
1) Not everyone agrees
One CTO I’m friends with straight up said it was a bad idea.
“Not so sure on this one, Dan. Getting everyone to prep ahead of time is tough.”
-Jill, CTO
A few people told me the stand-up is fine the way it is.
“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.”
-Arash, London
2) But, it feels like we’re on to something big
I was overwhelmed by the amount of positive, passionate feedback. Thanks for the encouragement, Everyone! It feels like the desire to change has been bubbling in our community for a while and now the dam is close to bursting.
“I found your article and 🤯💡🤯💡🤯💡 I’m intrigued as heck and would love to learn more.”
-Danielle, Front End Developer
“I found the article really interesting – the problems are well described from the perspective of each persona and some of them should be resolved by your updated framework. We are facing similar concerns in my current company and we are progressively addressing them.”
-Julien, Software Engineering Manager
“Dan, I love the blog about standups – you’re totally right. Why are we still asking about status updates? This makes no sense.”
-Robert, VP Software Development
“Great idea, Dan! It’s not the stand-up itself, the way it is done needs to change.”
-Sandeep, Enterprise Transformation Leader
“I read your article and really enjoyed it. Please continue your efforts to bring this to life.”
-Nadav, Full Stack Developer
“I’m inclined to agree with you. Especially the larger the standup, the more people sleepwalk through it.”
-James, Lead Consultant
“When I read your stand-up piece… Dude, you almost made me cry.”
-Harry, Scrum Master
Wow, Harry. I assume the crying is good? 😭
It says a lot about our community that so many are open to such a high degree of change for a ceremony so embedded in our process. Continuous improvement is part of our agile mindset but that doesn’t mean change isn’t hard. When something works for a long time, it’s easy to get comfortable.
As one developer points out:
“The theory behind agile/scrum is good but not perfect for everyone. It needs some updating. Frankly, the agile community looks like a bunch of asshats with how they argue so much.”
-Danielle, Front End Developer
You’ll get no argument from me, Danielle 🙂
Pain is the catalyst for change. And clearly here, we’ve struck a nerve.
Join the movement.
3) Some teams are already post stand-up 1.0
“In a truly high performing team I’d replace standup altogether with a nice coffee and a croissant.”
-Pm_me_your_amphibian
“We do weekly stand-ups and ad-hoc meetings when needed. And then we just share a Slack update at a designated time each morning.”
– Felix, VP Engineering
“COVID forced us to type up our stand up into a chat group each morning. It was the best thing that could have happened. Now we have a written commitment from everyone and as the boss, I have an instant snapshot of what everyone is doing. The team is loving the extra time in their day.”
-Ganzibai, Dev Team Lead
“I have a completely remote team (pre-covid). We use Jira, Slack, and Github. We’ve been doing weekly stand-ups and just use Slack to request an ad-hoc meeting if there is an impediment that arises before the standup.”
-Samwheat90
I’m fascinated by this! I had honestly never heard of scrum teams not holding a daily stand-up meeting.
I have a few takeaways from the comments above:
- The maturity of your team matters. If you’re forming, storming or norming, you probably need more mechanisms to talk to each other – like meetings. If your team is performing, I can see how eliminating the daily meeting (replaced by a detailed Slack message or some kind of dashboard) could work.
- Whether you hold a meeting or not, writing down your commitment makes a lot of sense. It can organize everyone and increase accountability. Again, especially if your team is still learning to work with each other.
- Should the daily stand-up meeting actually be weekly?
4) Some people had a lot to say
I received several long emails. I couldn’t include all of them but thanks to everyone who took the time to share their thoughts in great detail.
“I wrote a response to your article online, then I realized it got a little long and the character limit is 600. I figured since I’d written it I’d email it to you directly.”
-Ben, Program Manager
I’ll summarize Ben’s email for you:
The stand-up is all about communication. “It sprang from a recognition that developers are typically awful at communication and much prefer to silo themselves and deep dive into code or spin their wheels on a problem in silence instead of announcing when they’ve completed a feature someone else was waiting on or are looking to pick up their next piece of work.”
The stand-up is not a status update. “The objective is to solve the inherent lack of communication between the team by providing a forum that allows whole one-off team broadcast instead of multiple singular point to point messages between team members that isolate everyone else.”
It takes a lot of discipline to make stand-up 1.0 work. “The examples you listed as problems are real issues, but they’re not process-based. You’re spending longer in your stand up because your ticketing system isn’t up to date, you feel you don’t know if you’re going to make the sprint goal, your product owners need to ask for updates – all of these can be generalized as a lack of communication coming from your developers.”
In summary… Ben is saying that if everyone did their job by updating Jira tickets, attending the meeting on time every day, staying within their allotted two minutes and openly communicating when they need help, we wouldn’t need to change the stand-up framework.
I don’t know Ben but I like to think of him as an optimist 🙂 He’s arguing for how it should be. He believes that people are capable of better communication and a higher level of accountability.
I believe this too. But I also accept that different people have different strengths. Not everyone is comfortable speaking up and asking for help. And the entire industry struggles with updating Jira. So, call me a realist, but I think we need to accept how it is and try to make it better.
More importantly, even in elite teams where there is a high level of communication and accountability, I still think we can still elevate the stand-up and use it as a forum to talk about things that are more central to delivering a high-quality iteration on time.
5) There were a lot of ideas for Stand-up 2.1
“We started doing mini demo sessions in our stand up if anyone has anything to show. It’s been helpful. Keeps everyone engaged.”
-JPenrose13
“I’d get rid of the round-robin “3 questions” that many people seem so attached to. I have never worked in a team where that is a valuable format for a standup. Walking the board keeps people focussed on the sprint goal and the tasks in hand.”
-Pm_me_your_amphibian
“My latest project team focused on answering the questions with regard to the current Sprint goal: ‘What did I achieve yesterday in order to reach the Sprint goal?’, ‘What do I plan to do today to bring us closer to the Sprint goal?’, ‘Do I anticipate something that could get in my way?’. Answers excluded any unrelated activities.”
-Sascha, Germany
“One additional value of the daily now that we’re working remotely is the “social” aspect. It’s a way to know if everyone on the team is doing ok. I think it’s quite valuable seeing/hearing the voice of your teammates every day.”
-Nicolas, Product Owner
I love these! Thanks for sharing. I guess it’s time to write Stand-up 2.1 🙂
Our team definitely makes a point to socialize in the daily. We also have been experimenting with doing “mini demos” in our stand-up too.
Both things make the meeting longer but everyone leaves feeling connected to their teammates and energized to work on cool stuff of their own.
My favorite suggestions were ones that emphasized team-oriented discussion. You can see this represented above in Pm_me and Sascha’s comments.
The current stand-up framework encourages devs to think and talk about their own work. Then managers take that info and compile it and process it. Part of making the stand-up more dev-centric is making it more team-centric.
I want to help developers see the bigger picture so they can connect their work to business priorities and customer use cases. Framing the stand-up around how the team is working together to serve customer and business priorities by delivering the current iteration is a step in that direction.
6) There is disagreement around “blockers”
“I find the whole concept of getting asked “are there any blockers?” daily during standup somewhat condescending. What kind of developers end up blocked and wait until the daily standup to mention it? If there’s a risk of running over a deadline, then they should mention it to the manager ASAP.”
-Mihai, Senior Software Engineer
“I wish my stand up would just be… do you have any blockers? Do you need anyone else’s time? Those two things are the only things I actually care about. I only barely listen to what people did yesterday/doing today to see if they need anything from me or if I could help them.”
-Giannisisthebeast
Stand-up is not about status. It’s about uniting the team in common purpose and direction plus a forum in which volunteers step up with their time or resources to help team members experiencing blockers.
-Russell, Software Engineer
“I think many standups have repeat offenders who ramble on for too long, and don’t think about what their audience needs or wants to hear. So re-framing that, to ensure there’s a conversation between blocked people, is really important.”
-James, Lead Consultant
I totally agree that, as a developer, it’s our responsibility to raise our hand when we need help or we’re behind schedule. In super high performing teams that are constantly talking to each other, I think this does happen. But I’ve seen first hand that it’s tough for many devs to speak up. Junior devs sometimes don’t know they’re in trouble until it’s too late. Even some senior devs sometimes spend too much time troubleshooting.
One of the main reasons the stand-up was created to begin with was to give everyone a dedicated time to ask for help. And yet, sometimes blockers still don’t get surfaced.
I personally think the solution to this is automation. If the team got alerted in Slack every time a teammate was blocked, behind schedule, or working on something high-risk, this problem would mostly go away. Everyone could get help in real-time whether they are comfortable speaking up or not.
I also love the part about “considering the audience.” Another way to think about this is communicating the “why” in addition to the “what.” If the entire discussion is framed around the team instead of the individual, everyone in the room will have more context and will care more.
Blockers, delays, and high-risk branches. . .
Help your teammates in real-time with automated Slack alerts.
7) Many people feel strongly about who attends the daily
“Agree with you 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.”
-Andrew, Full Stack Engineer
“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.”
-Rich, Full Stack Developer
“Although the executive managers (CTO, VP, or Directors of Engineering) might occasionally attend the scrum team’s daily standup, they would probably benefit more from the higher-level detail shared during the Scrum of Scrum across multiple teams.”
-Julien, Software Engineering Manager
I personally think anyone who is responsible for directly delivering value to the customer during the iteration should be in the stand-up. If it happens that a senior leader thinks they should attend, they just need to be highly aware that their presence alone can disrupt the team. And they should NEVER ask for a status update on a specific thing.
By the way, if executives and business stakeholders had a detailed, accurate, up-to-date view of what’s happening with the features they care about, most wouldn’t need to attend the stand-up or scrum of scrums and risk ruining it.
Unify analytics from Jira and Git.
Get LinearB. Free for dev teams.
8) Many people feel their Jira board isn’t helping
“Jira is regularly used as a crutch that people use to avoid having actual collaboration conversations. I have yet to see a single IT shop that is using Jira that hasn’t over-engineered the setup with dumb workflows designed to “make things smoother” but are no substitution for actual conversation.”
-KraterMcNicey
“This is another anti-pattern, and I’m constantly reminding my teams to update the board to reflect reality. The purpose of the board is transparency, visibility, and communication—not just within the team, but across the org, meaning anybody should be able to look at the board at any time and know what’s up. I’ve seen teams where the ingrained habits were so bad, they neither updated the board nor talked to each other.”
-Whatsthesothat
If your board is fully updated and you can use it to spark useful conversation… great! You’re in the top 5%. I still think we can use the visibility to focus on a better, more team-oriented conversation.
For most of us, no matter how hard we try (or threaten :-)) , Jira is not up to date. This is a huge problem we’re working on at LinearB.
9) There were some metaphors
“The best analogy that relates to this is a guy is in the forest hitting a tree with a spoon to try to cut it down. A lumberjack walks by and sees him. The lumberjack gives the guy a saw and walks away, pleased with himself that he helped the guy. The guy looks at the saw and starts to hit the tree with it and curses it because the saw isn’t working any better than his spoon. “
-Whatsthesothat
Whoa… you just blew my mind 🙂
Bonus section: My two favorite quotes
“A status meeting implies an asymmetric, likely authority-based meeting with a report card. Employees kneeling to their overlords, if you will. This is not Agile because it’s not what a self-organizing team is to be doing.”
-Russell, Software Engineer
Russell, you had me at overlords!
“You are a revolutionary. You’re actually starting a movement.”
-Chinonso, Lead Software Engineer
Chinonso, I’m humbled by that. Thank you. But I mostly think of myself as a nerd in a windowless closet who really, really cares about software developers 🙂
10) My biggest takeaway: Developer empowerment
There was one theme that came up over and over again… the stand-up might be useful for team leads and product owners but it has little value for developers.
“In my experience and the various agile scrum trainings I’ve done, no one has ever once said… let’s ask the devs what they think.”
-Danielle, Front End Developer
I think Danielle is right. And I wonder how many developers feel like Giannis.
“I have tried to change things by speaking up in retros but the product owner and scrum master seem set on generic scrum and most the other team members don’t care that much to change it either.”
-GiannisIsTheBeast
So how do we empower developers to adapt the development process from the bottom-up? For starters, I think Kevin is on the right track.
“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? This is a sanity check for avoiding unnecessary meetings that can be done in seconds via an email or Slack, versus having everyone held hostage in a room for an hour.”
-Kevin, Software Architect
I’m going to share more ideas about this in my next blog.
Join the revolution
We still need all of the help we can get!
Please share your feedback directly in the comments section or send me a note through Linkedin. I would love to hear from you.
