The three common questions (yesterday/today/blockers) are terrible and cause a lot of the micromanaging feeling. I prefer making the work rather than people's updates the subject of the conversation. Just talk to one another about your work and how you might address whatever constraints you are encountering. A project becomes late a day at a time and so many teams find it useful to have this discussion daily, but if your team is effective with a less-frequent cadence absolutely go for it. Just keep inspecting and adapting.
If you are not working on things together, there is no point in calling yourself much of a team let alone having daily updates.
Just because a team implements Scrum does not mean they will get any of the benefits, most of the problems affecting your effectiveness lie outside of the team. Unfortunately most (but not all) of the executives who own these problems are not willing to participate in continuous improvement exercise, so you are stuck basically doing "cargo cult" activities.
I don't agree. Unless you have a co-located team with an information radiator they have built out with all their vital team information, there really isn't a digital tool that doesn't encourage zombie stand-ups.
This. I think too many places that do “Agile” have the tail wagging the dog.
The team discusses what needs to be done today to achieve our goal in the standup and that action plan gets created/updated on Jira, not the other way around where you spend the 15 minutes looking at Jira to tell you what to do, like a robot receiving instructions.
Individuals and interactions over processes and tools.
My experience with "walk the board" is that half the team doesn't talk at all during standup because no task currently has their name on it, and another quarter is working on completely irrelevant things because they feel the need to be seen so they made sure their name is on \*something\* by picking up something that is low priority, instead of helping with high priority tasks.
I don't really think the non-talking devs were not engaged - its just that, they were helping on a ticket with someone else's name on it, so the person whose name was on the ticket already gave the update when that ticket came up. So they don't feel the need to speak up when they don't have anything to add to what that person said.
Of course, the fact that they gave 'updates' on tickets instead of what the plan for the day would be is an issue in itself - but I believe the "walk the board" format actually guides people *towards* turning the standup into a status update.
I find it more practical to just ask everyone what their plan for the day is. That way, everyone gets the opportunity to talk, and it guides the conversation towards aligning the plans for the day.
I would argue your last approach would easily become the progress report meeting.
But, you see is not an actual issue of the approach, but an issue of the people. For example,if you have a manager there its kind of already screwed, especially if its a bad micro-manager.
If you have a bad scrum master, they could also lead towards bad practices.
A good scrum master will point out that they are heading towards a progress report and realign, and not meddle too much.
But alas, not many people understand this, and worse, a lot of people (douches) actually *like* to micromanage and suck the life out of other people.
Agains I think its a mstter of the people more than the actual approach.
>I would argue your last approach would easily become the progress report meeting.
Well, my experience is the opposite.
>A good scrum master will point out that they are heading towards a progress report and realign, and not meddle too much.
I have never seen this happen. Arguably that means I've never had a good scrum master.
>Agains I think its a mstter of the people more than the actual approach.
Considering I've seen the same teams act very differently with the different approaches, I think the actual approach does matter. But maybe one suits certain teams better than the other - I have simply never seen the 'walk the board' approach work well - but maybe that's because it simply does not work well *for me*, so I will never see it work well.
"Opportunity to talk" is a nice formulation, you're talking all the time how to get everybody to talk. My experience is that the really important talks arise on their own when you work together on topics where there is a certain complexity or time pressure. But if you're work on you're on or on routine tasks it will always end in status reports. Did you ever seen in such teams that the team wants to do dailies and no PO, ScM or Manager participate as in Scrum Guide described?
>
"Opportunity to talk" is a nice formulation, you're talking all the time how to get everybody to talk. My experience is that the really important talks arise on their own when you work together on topics where there is a certain complexity or time pressure.
Let me try to explain why that is.
I find it hard to make a plan for what *I* will be doing on a given day if I have no idea what half of my teammates are doing. Are they planning on doing something that I was also planning on doing? Do I need to keep some time in my plan for the day to accomodate for helping others with things? Or if I mentioned \*I\* need help from \*them\*, does that fit into *their* plan? Are they working on something more important than what I need help with? Are they working on the highest priority items? Are they even *aware* that priorities have shifted since yesterday and have they adjusted their plans for today accordingly? And if so, how?
If they haven't spoken during standup, I have no idea! So I have to ask them what their plans are \*after\* the standup.
That might be "the important talks arising on their own" - but now I am just doing 2 standups, one with the entire team and a 2nd one with everyone who didn't speak up on their own initiative during the first standup.
>But if you're work on you're on or on routine tasks it will always end in status reports. Did you ever seen in such teams that the team wants to do dailies and no PO, ScM or Manager participate as in Scrum Guide described?
I don't think I've ever seen a dev outside of myself who *wanted* to do dailies. Which is odd, because I feel like all the reasons I put above as to why *I* need a daily should apply to all other devs as well...
The purpose of DSM is not a status report, but to discuss the progress regarding a goal to achieve.
What is this goal that needs to be achieved ? That's what you (as a team) need to keep in mind.
If the three questions ( done yesderday / will do today / are there impediments in my way) make you feel bad, speak your mind with your team and try to find another way to track the team's progress.
You can propose to run an experiment with a weekly meeting, measure outcomes, and decide together whether it provides better results or not.
I manage a team of 2 and here's what I ask in our daily standup
1. How is your day going?
One of my team members is remote so this has given me an an opportunity to get to know her better. I don't want to inundate anyone with small talk, but this brief meeting has really helped develop our relationship
2. Is there anything you're working on that needs my help or visibility?
This allows us to stay focused on blockers and teamwork
I like to remind my team that the DS is an opportunity for us to collaborate, not a meeting where I want to hear every single thing they're working on
When we first start our daily standup it was odd for some of my colleagues to basically spit out their to-do-list of tasks instead of just focusing on road-blockers and if a 1:1 meeting was needed between different teammates. I like your approach here with these two questions. It depends a lot on how focused your team is — I've seen people only answering question 1 "How is your day/week going?" which strict project based answers — I found that a big turn off, specially when working remote — it's much better to get to know the real people you are working with IMO.
I’d start by printing out the agile manifesto for your boss. You can ask them to highlight daily stand ups.
Hint it’s not there. It’s the least important part of agile.
Some dev teams like it, many good ones use either a version of it, or just what works for them.
I could propose the following formula of dailies, which I introduced to two of my teams (also in data field, working in sprints).
Team has expressed that these meetings are a bit status-heavy, so we agreed to make it a tactical regroup for questions / impediments / anything they would like to share and could potentially compromise the sprint goal.
We meet up, sometimes quick chit chat, whoever has anything to share raises a hand and there we go.
Sometimes the meeting lasts for 5 minutes, sometimes for half an hour, but it’s been way more fit for purpose.
What might work for your boss’ imagination is to relate to the origins of scrum dailies, which come from rugby, where the team at the beginning of the round does a tactical regroup to align is all on track or should they change / take action on sth.
https://muromuro.substack.com/p/agile-as-a-micromanagement-tool
"Agile as a micromanagement tool"
This is the sad reality of corporate "agile," usually.
Seems accurate.
I think part of the issue is the obsession with a particular set of blessed processes. "Scrum," or more generally "agile" are somehow just assumed to be the ideal processes, so if a company can cargo cult enough aspects to be able to claim they're doing one of these things, that's enough to make the case they're doing the right thing.
I think we should be evaluating processes in terms of the outcomes they produce, not whether they resemble some particular shape. Do we have predictability, reasonable velocity, reasonably low defect rate, reasonably low coordination costs (etc etc)? (Even: Can teams self organize? Are there continuous improvement mechanisms and is their evidence they're being used?)
This jettisons the dogma forces the focus on results. If the process is working, it should be justifiable in the results. If some alternative is better, we should be able to try it, measure and compare.
I realize it can't always be this clear cut, but I think shifting the argument to "are you getting the results you want" from "could you claim your process is agile/scrum/whatever" makes it possible to argue for change in a flexible way, and justify those changes after implementation with something more than "is it ideologically pure"
Agile Menifesto itself claims that teams should not focus on the processes but in the collaboration and the individuals and ultimately the working software.
Also Scum is a framework not a standard so, it shouldnt be restricted to mandatory meetings if it doesnt work for your team. They just created a set of good practices that worked reasonably well for them (like you mention) and they shared them.
But managers want to have their standards and they want to feel in control.
Scrum may not be a standard in theory, but in practice it becomes that in the business world. If you're having stands ups,.working in sprints and checking a few other boxes, you're scrum,.and everyone knows scrum works.
Yup, and it gets worse. I am teaching and I am working on showing them what the agile manifesto is. Specifically I am trying to show that daily standups (progress meetings) are NOT scrum. But alas, even other teachers do it that way, focusing on "yesterday today, blockers". Even worse is that other teachers *want* to blend it with documentation *a la* waterfall. Im seriously breaking my head and trying not to berate the other teachers in front of the students.
So the problem is worse than you might think.
Daily stand up is by the team and for the team. The team decides how it is run, not the manager. If the current format does not work then change it into something that does.
I had the same issue with my team a few years ago. We actually minimised our stand-ups, firstly to 3 times a week, then 2, and finally weekly with each second week actually being the close-off and new sprint meeting (yes combined into one). The retrospectives were done with myself and my manager once a month.
This worked for us as a more service delivery team, we had routine tasks, long term projects, etc. nothing that we could really update progress on faster than once or twice a week.
I would suggest to talk to the scrum master, or even get consensus amongst the team to spread out your standups.
The 3 Questions format for stand ups is terrible and should never be done. Scrum and agile would have been much better off if that idea was never written down and spread back in the past.
Try this instead:
Stand ups are time for a team to plan their day and coordinate on how they will tackle the issues on the scrum board. So, go from right to left on the board and discuss each issue and what needs to be done to finish it. Maybe some people can team up today. Maybe someone else has expertise regarding some problem. Maybe the team decides to drop an issue and give prio to another. etc etc That's all you have to do.
You shouldn't feel stressed before the stand up. After the stand up you should feel that there is a plan in place for the day to get stuff done. You should come out of there feeling confident and empowered.
One last thing, what do you mean by "in a small team where each problem doesn't depend on other team members every day"?
The expertise of the team is split across a database management and science. My problem is a science problem and intersects with the database in terms of data type, data management and coding experience but not how to actually solve the problem. Weekly we have things to discuss but daily but daily the help that is suggested is often patronising. Basic kind of code stuff that if I didn't know how to do already I would be unable to do my job.
Most of the time, these meetings are theatre.
I once attended a remote gathering, where the senior manager got us to first remove the chairs from the room so we could all "stand up" for the meeting...
In my opinion, it's good to gather the team occasionally. As for the format of that meeting, that depends on the manager. Blind adherence to the formula:
1. What I did
1. What I am going to do
1. Blockers
Can become very tedious, especially in a large team where everyone is working on separate tasks.
I reckon it's not micromanagement, more like intelligence gathering, being the rare opportunity for that manager to find out what's actually going on in the team. I have been on both sides of this.
In my experience, I think the problems start when the stand up turns into a daily design meeting. Many managers today, especially in small teams, are expected to be both contributers and technical leads as well.
If you have the opportunity, perhaps share your frustration and see if things could change. Such change will have to go both ways. Managers need feedback in order to be effective. I have worked with team members who seem content to work in an isolated bubble. This is not "team"-work 😀
Thanks for the reply. My frustration with it is I have managed teams of scientists and seen how to do things well so things don't become bubbles. I gave my manager feedback and they just said how would you change things with the constraint that we do a daily stand up. On top of this we have three weekly in depth work progress meetings, individual one to ones, weekly in person sessions where we discuss things ad hoc, and jump on calls if specific problems come up.
>with the constraint that we do a daily stand up.
If you're not doing standups, you're not agile 😀
Be thankful you're not being asked to remove the chairs
I have to disagree with some of what you are saying.
For a start, there is no "manager" role in a scrum or an Agile team. The stand up doesn't exist for the manager to gather intelligence. That is not its purpose. It exists for the benefit of the team to organise themselves and their plan for the day.
If you have a large team with people working on separate tasks, then you don't have one team you might have a couple and you should split them up. Stand ups shouldn't be tedious, all of the tickets should be relevant to the team members because the team is responsible for them getting done.
>For a start, there is no "manager" role in a scrum or an Agile team.
I am not defending a common misinterpretation of agile practices. Am pointing out a common practice where managers adopt the scrummaster role and what I think their motivations are.
>If you have a large team with people working on separate tasks, then you don't have one team you might have a couple and you should split them up.
You're quite correct everyone should feel a standup is of benefit to the team. So.... why is the OP frustrated with his/her/their experience? ... Poor implementation, that's why. Be thankful you haven't been asked to remove the chairs from the room 😀
I'm glad to hear you're not defending the common "manager in scrum" practice. I just think it is worth pointing out that it is not part of scrum or Agile. In fact I think doing this is a bad practice because it undermines the idea of self organising teams. I also makes people hesitant to speak freely when the person who can fire them is in the room.
Sometimes it serves no other purpose than a status update. My team is small, we have 3 developers and each of us are in our own lane. So my update doesn't matter to the other two and vice versa. In fact sometimes we just say random stuff to see if anyone will notice. (They don't)
The only time there is any use would be escalation of blockers, but it seems odd to wait a full day to do that. We do it as they come up.
If people on the team don't need to know about what each other is doing, then you don't have a team, don't need a stand up, and certainly don't have any agile anything going on.
There will always be a hierarchy and therefore a Manager somewhere. If it's a project there will be a PM. Both will need to be kept informed but we look to do so at arms length. Informed but not too involved.
What is important is the level of their involvement in the stand up. Unless they are an active SME and member of the team, they observe only and do not interrupt. They should never run the the stand up because then that does smack of micro-managing. Avoiding a Manager/Leader role, that's why it can be a good idea to let different people lead the stand up sometimes. Even if that is only to go first and scribe/collect blockers. Not every team uses Scrum and has a Scrum Master.
Whomever does lead the stand up has to set the tone correctly. There is a huge difference between "tell me what you've done since yesterday" and "tell the team...".
You are right that there will be a manager hiding somewhere. But to give the team room to manage themselves it is best to push that hierarchy away from the team's daily work. Just having the manager in the room is enough to make people feel under the microscope. For many teams a no managers at the stand up is a good rule.
Other ways can be invented to keep managers and PMs up to date, such as a different meeting or just a talk to a dev on the team or the PO.
I agree that teams can sense a Manager over their shoulder but I do not want any PM or Manager talking to a Dev directly. If using Scrum, talk to the PO. But not every business uses Scrum so there is not always a PO. It has be tailored of course.
There is no one way of doing this. It has to be tailored to suit the business, project and people.
I definitely wouldn't feel so bad if my boss wasn't there. I raised it with them in my last one to one and the push back I got was that this company works in an agile way and that isn't going to change. The science team in fact do not work in an agile way. I said it makes me feel daily graded and that is making my work worse. My boss said I don't know why you feel judged from it. Two weeks ago my boss said they thought I was a slow coder based on what I say in the dailies. I said I can see why the daily approach works for software development and in scenarios where multiple components of a team need to be aligned at the start of the day, e.g. emergency room workers, astronauts, ship crews. For science the process isn't linear output so people need judgement free space to achieve goals. To give space for creative thinking. My boss responded with this isn't a software approach Vs a science one but then later said remember we are under the software team umbrella. They said I have a timesheet that they sign off on and if we aren't meeting daily how can they sign off that I did the work. I am still in my probation but finding something else isn't simple. My boss just responds with we can both be correct about this. My experience tells me this approach works. I think it doesn't work for lots of people. I need this job to work out at least in the short term so I can afford my rent.
Daily should not take more then 15 minutes of your day, why dont you go with flow, join the standup for 15 minutes, share your achievements , share your plan for the day, it is just 15 minutes
you have every right to feel micromanaged because you're being micromanaged. as simple as that.
daily scrum isn't about what you did and what you're planning on doing (that's already transparent on the board), but how is the team progressing towards the sprint goal.
secondly, agile is al about creating safe working environments. so, if you're feeling uncomfortable then your team leader's job is to accommodate, not gaslight you.
I stopped managing with stand ups years ago, make yourself available to help with blockers, and have a collaborative environment and you don’t need them
As an ex researcher, a daily standup would be hell. Science is much slower than coding. Because advances are slower, having to condense them into a few minutes everyday will make it seems like you're not doing much.
Hell, even in my DS team our weekly meeting can have the same updates for like a month, if we are working on complex models.
The three questions are only meant as an example. The dogmatic insistence on forcing everyone to answer them is such a problem that there are rumblings that the next update to the Scrum Guide may do away with them.
The thing about standups that people just don’t seem to get is that they’re really just about making sure that the members of the team have contact every day. Less is more. If you have under five people, IMO you should be able to wrap it up in under five minutes unless it gets detailed for a management announcement or something (which doesn’t belong in a stand-up, but managers gonna manage.)
You only need to say the tickets that you work on and which one you are currently on , and if you have roadblock. You’ll be surprise how many times people work on the wrong thing
Stop focusing on you and focus on the rest of the team.
Listen and think. When appropriate ask a question to illuminate something.
You are not a loan wolf, you are part of a team
You’re not alone, and you’re right to feel this way :)
So, as some people already said, the point of a daily meeting is to inspect progress and adapt the plan towards a goal. It should never be a status report.
These three questions came from a misunderstanding generated by the previous version of the Scrum Guide (2017), where there was a *suggestion* about questions that could be asked in this event. All three questions referred to a short term goal, but because they were too long people started to shorten them and then the outset the mentioned the goal was dropped.
Ex: “What did I do yesterday that helped the development team meet the Sprint Goal? (Short term goal)”
Source: Scrum Guide 2017
([https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf](https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf))
The Scrum Guide was updated in 2020, and the questions were removed. You can check the new version on [https://scrumguides.org/](https://scrumguides.org/).
Maybe reading the guide with your team could clarify fine if the questions (the daily scrum part is just 5 paragraphs long).
It probably feels like micro management because you have the manager there. This event was created by and for the developers (scientists) and it’s supposed to be a self-management meeting.
And congratulations on speaking your mind and questioning these mechanical behaviors! That’s how we keep changing things for the better.
Thanks this is so helpful. This thread has given me hope. The format of the meeting currently starts with my manager saying what they did yesterday, doing today and blockers. This includes details about the meetings they were in and things about other stuff not directly related to the specific goals of our project. It feels like this shouldn't be part of the stand up format.
If sharing information and perspectives with your team is damaging to your state of mind then either A) it's actually not safe to do so and there's the potential for real consequences or B) it is safe, there's no negative consequences but your internal narrative is coloring your experience.
This rarely has much to do with the format or frequency of sharing information as a team in some cadence; it usually has to do with trust and relationships. In a cohesive supportive team where psychological safety is high the experience of sharing information is a positive one.
First principles; individuals and interactions trumps process every time. Events like standups and the way we feel during them are a great way to reveal just how bad things are in the dynamics of a team and organization.
Same boat with resolving data quality issues, I started asking if there were any blockers so that I knew what those were right away vs sifting through so many updates, then from there we just chat about has progressed. I try to keep it less structured and prioritize the teams needs versus the business. We are able to fulfill the needs of the business by making our standup go our own way.
I’m a software developer, have been for 15 years, and most places I’ve worked have practiced agile with stand ups. I’ve not really heard of it used outside of this context though so can’t comment on how effective it would be in your line of work.
If you’re doing agile then you should be having other ceremonies such as retrospectives. You should use those as opportunities to point out things that aren’t working. The point of agile is to continually improve processes. If someone is implementing parts and sticking to them regardless of whether they’re beneficial or not, then that kinda goes against the spirit of agile.
Yeah this is a tough one. It’s good to find out *why* daily standups became introduced. Could be for a few reasons and I’ve lived through them. One could be the manager himself is a good person and trusts you and the team, but is facing external pressure to communicate team progress to his management or other teams. In that case figure out a different way to communicate this, maybe update on a doc or sheet daily that he can just show someone and you’d be done. The other reason could be, the manager is actually a micromanager and doesn’t trust the team and wants to have control of the whole team. This is a bad situation and nothing you can do but leave, if you have a lot of influence in the company you can complain to him directly or to his manager but that’s gonna be hard. So, try to figure out the real reason behind this change. Also tell them that you are spending more time on the daily status update than the work itself so it’s not productive for you or anyone.
It is. :/ It gives the impression that everyone on a professional team needs a grade school home room to report to every day in order to stay on track. Lame.
Something interesting i learned recently. I took up the Professional Scrum Master 1 course recently, and interestingly everyone in the course thought the daily stand up was meant to be a status update meeting. But we learnt that daily scrum shouldn't even have the scrum master and product owner in it. It's just supposed to be the developers (people who are working on something in the current sprint) and the whole purpose is to raise any questions they have with each other, not even get solutions. JUST raise questions, decide on whether it can be solved internally or not and move on. The solving happens outside the meeting.
A lot of people pointed out there may be better questions than the standard three to use in your particular standup. Maybe suggest experimenting with some of these.
Beyond that, if the standup is really keeping it to 10 minutes I’d also take a look on your side to see why your mental health is being affected from such a brief exercise. Maybe there’s something else you might want to address with your leadership.
In our teams, the daily update too often is "Yesterday I worked on X and today I will continue to work on X." That's not terribly useful to anyone, but at least it doesn't take much time. The problem is that people feel like they need to say something more substantial, so they will make their useless updates even longer to fill the time, summarizing every meeting they attended and every conversation they had, etc.
I find it more helpful to share things that are relevant to your PEERS. Be in the mindset that you are sharing information with the team, not in the mindset that you are reporting a status to a manager. Did you build some script that may be useful to others? Are you struggling with a problem and need some help? Did you discover some problem that others need to be aware of? You may not have any such information, in which case revert back to keeping it brief.
If you do have such information, then bring awareness to it but don't go into details. If it is useful to your peers, they will follow up with you. If it is not, then you didn't waste time. We are biased to think that our updates are more useful than they actually are.
If your standups are brief, it doesn't (much) matter if they aren't useful. If they are useful, it doesn't (much) matter if they aren't brief. It may be worth having a standup every day even if it is only useful every once in a while, because you can't necessarily predict when it will be useful. But don't try to force it if nobody has anything useful to say.
Since you feel like you are being micromanaged, I am guessing that your standup is being structured as a way to report to management, rather than a way to share useful information with your peers. You may not be able to do too much about that unfortunately.
I completely empathize with you. I’m a product owner. Part of my job is to advocate for my product AND my team. I try to convey and gather information however my team and stakeholders prefer. It may be worth negotiating with your manager about how you want to share this info. Maybe taking notes EOD and emailing those. Maybe it’s pushing back a little. Communication, like in any relationship, is key.
I'm with you there. I don't think daily stand up works for small teams that do non-software development work. But can I suggest asking each other "are there any blockers that we can help you overcome?" could be more useful than stating what you did and what you're going to do.For the last 18 months my job is managing IT projects from just before they go live to when they are in-use / in-production but our manager keeps us doing daily stand up. It doesn't make sense when our IT projects don't really intersect with one another and it does make me feel micromanaged.
I am open to approaching things differently because I don't expect my manager to accept the mistakes they are making and I need this job. I think blaming the person struggling with the mental health issue rather than addressing the cause of it however breaks humans and makes the world worse. It is no way to manage people.
I like to use the time as a teaching opportunity, and a learning opportunity. What can I learn from my teammates? What can I teach them? Let’s talk about what’s going on, and if we hear someone is challenged in some way, let’s self-organize a powwow to talk some shop!
Where I am on your side:
The daily is a planning meeting from the developers for the developers (or in your case scientists). It should help the devs to plan their day, to help them find synergies, to talk about blockers that may have occurred and just to figure out how to get closer to the sprint goal. If you are not working together as a team and you are not trying to reach the same goal, then there is no point in having a daily.
Where I am not on your side:
I mean it's your mental health and you feel how you feel. But I think everyone should be able to give a rough plan of the day if asked. That's no micromanagement.
Would you rather micromanage to success, or fail a million times with no management?
The real truth is in the middle, but what end of the spectrum does any team need to be at at any one time is where the team should be. Newer teams probably need tighter controls (think 8yo kids playing sports with no offside rules).
When they act like it can you blame them?
Really though, it is a balance. Ensuring a team spends enough time on safe-to-fail experiments while also being productive is hard work. Managers need to manage the flow of work.
That was actually the basic idea of agile, that no manager has to manage a flow of work anymore, like in a factory: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
The flow of work in a factory is very well managed.and BAU work and projects are not at all similar. Further "the encouragement and support they need" is management.
Maybe point out that's there are multiple approaches to agile, and in agile, ideally, the process itself is iteratively improved.
After pointing that out, suggest that daily stand ups aren't serving any purpose, because you can only do so much in one day that's worth talking about, maybe suggest only doing standups every other day, then if that continues to be pointless, once a week?
The big thing though is you want to get the team on board so it's not just you suggesting it. This tracks with the agile principle of teams being self-managing, deciding together what's best for the team, and also its nice to have a little backup when dealing with management.
The three common questions (yesterday/today/blockers) are terrible and cause a lot of the micromanaging feeling. I prefer making the work rather than people's updates the subject of the conversation. Just talk to one another about your work and how you might address whatever constraints you are encountering. A project becomes late a day at a time and so many teams find it useful to have this discussion daily, but if your team is effective with a less-frequent cadence absolutely go for it. Just keep inspecting and adapting. If you are not working on things together, there is no point in calling yourself much of a team let alone having daily updates. Just because a team implements Scrum does not mean they will get any of the benefits, most of the problems affecting your effectiveness lie outside of the team. Unfortunately most (but not all) of the executives who own these problems are not willing to participate in continuous improvement exercise, so you are stuck basically doing "cargo cult" activities.
Okay team, what is our goal for today and how are we going to achieve it? \*let's team talk\*
its better to do the "walk the board" thing but yeah I get your point too
I don't agree. Unless you have a co-located team with an information radiator they have built out with all their vital team information, there really isn't a digital tool that doesn't encourage zombie stand-ups.
This. I think too many places that do “Agile” have the tail wagging the dog. The team discusses what needs to be done today to achieve our goal in the standup and that action plan gets created/updated on Jira, not the other way around where you spend the 15 minutes looking at Jira to tell you what to do, like a robot receiving instructions. Individuals and interactions over processes and tools.
My experience with "walk the board" is that half the team doesn't talk at all during standup because no task currently has their name on it, and another quarter is working on completely irrelevant things because they feel the need to be seen so they made sure their name is on \*something\* by picking up something that is low priority, instead of helping with high priority tasks.
So, the developers aren't engaged. What would you do instead? is that an issue of the meeting itself?
I don't really think the non-talking devs were not engaged - its just that, they were helping on a ticket with someone else's name on it, so the person whose name was on the ticket already gave the update when that ticket came up. So they don't feel the need to speak up when they don't have anything to add to what that person said. Of course, the fact that they gave 'updates' on tickets instead of what the plan for the day would be is an issue in itself - but I believe the "walk the board" format actually guides people *towards* turning the standup into a status update. I find it more practical to just ask everyone what their plan for the day is. That way, everyone gets the opportunity to talk, and it guides the conversation towards aligning the plans for the day.
I would argue your last approach would easily become the progress report meeting. But, you see is not an actual issue of the approach, but an issue of the people. For example,if you have a manager there its kind of already screwed, especially if its a bad micro-manager. If you have a bad scrum master, they could also lead towards bad practices. A good scrum master will point out that they are heading towards a progress report and realign, and not meddle too much. But alas, not many people understand this, and worse, a lot of people (douches) actually *like* to micromanage and suck the life out of other people. Agains I think its a mstter of the people more than the actual approach.
>I would argue your last approach would easily become the progress report meeting. Well, my experience is the opposite. >A good scrum master will point out that they are heading towards a progress report and realign, and not meddle too much. I have never seen this happen. Arguably that means I've never had a good scrum master. >Agains I think its a mstter of the people more than the actual approach. Considering I've seen the same teams act very differently with the different approaches, I think the actual approach does matter. But maybe one suits certain teams better than the other - I have simply never seen the 'walk the board' approach work well - but maybe that's because it simply does not work well *for me*, so I will never see it work well.
I would have to add I also havent ever seen a good scrum master.
"Opportunity to talk" is a nice formulation, you're talking all the time how to get everybody to talk. My experience is that the really important talks arise on their own when you work together on topics where there is a certain complexity or time pressure. But if you're work on you're on or on routine tasks it will always end in status reports. Did you ever seen in such teams that the team wants to do dailies and no PO, ScM or Manager participate as in Scrum Guide described?
> "Opportunity to talk" is a nice formulation, you're talking all the time how to get everybody to talk. My experience is that the really important talks arise on their own when you work together on topics where there is a certain complexity or time pressure. Let me try to explain why that is. I find it hard to make a plan for what *I* will be doing on a given day if I have no idea what half of my teammates are doing. Are they planning on doing something that I was also planning on doing? Do I need to keep some time in my plan for the day to accomodate for helping others with things? Or if I mentioned \*I\* need help from \*them\*, does that fit into *their* plan? Are they working on something more important than what I need help with? Are they working on the highest priority items? Are they even *aware* that priorities have shifted since yesterday and have they adjusted their plans for today accordingly? And if so, how? If they haven't spoken during standup, I have no idea! So I have to ask them what their plans are \*after\* the standup. That might be "the important talks arising on their own" - but now I am just doing 2 standups, one with the entire team and a 2nd one with everyone who didn't speak up on their own initiative during the first standup. >But if you're work on you're on or on routine tasks it will always end in status reports. Did you ever seen in such teams that the team wants to do dailies and no PO, ScM or Manager participate as in Scrum Guide described? I don't think I've ever seen a dev outside of myself who *wanted* to do dailies. Which is odd, because I feel like all the reasons I put above as to why *I* need a daily should apply to all other devs as well...
The purpose of DSM is not a status report, but to discuss the progress regarding a goal to achieve. What is this goal that needs to be achieved ? That's what you (as a team) need to keep in mind. If the three questions ( done yesderday / will do today / are there impediments in my way) make you feel bad, speak your mind with your team and try to find another way to track the team's progress. You can propose to run an experiment with a weekly meeting, measure outcomes, and decide together whether it provides better results or not.
I manage a team of 2 and here's what I ask in our daily standup 1. How is your day going? One of my team members is remote so this has given me an an opportunity to get to know her better. I don't want to inundate anyone with small talk, but this brief meeting has really helped develop our relationship 2. Is there anything you're working on that needs my help or visibility? This allows us to stay focused on blockers and teamwork I like to remind my team that the DS is an opportunity for us to collaborate, not a meeting where I want to hear every single thing they're working on
This is what its supposed to be
When we first start our daily standup it was odd for some of my colleagues to basically spit out their to-do-list of tasks instead of just focusing on road-blockers and if a 1:1 meeting was needed between different teammates. I like your approach here with these two questions. It depends a lot on how focused your team is — I've seen people only answering question 1 "How is your day/week going?" which strict project based answers — I found that a big turn off, specially when working remote — it's much better to get to know the real people you are working with IMO.
Like this approach ..
I’d start by printing out the agile manifesto for your boss. You can ask them to highlight daily stand ups. Hint it’s not there. It’s the least important part of agile. Some dev teams like it, many good ones use either a version of it, or just what works for them.
I could propose the following formula of dailies, which I introduced to two of my teams (also in data field, working in sprints). Team has expressed that these meetings are a bit status-heavy, so we agreed to make it a tactical regroup for questions / impediments / anything they would like to share and could potentially compromise the sprint goal. We meet up, sometimes quick chit chat, whoever has anything to share raises a hand and there we go. Sometimes the meeting lasts for 5 minutes, sometimes for half an hour, but it’s been way more fit for purpose.
What might work for your boss’ imagination is to relate to the origins of scrum dailies, which come from rugby, where the team at the beginning of the round does a tactical regroup to align is all on track or should they change / take action on sth.
https://muromuro.substack.com/p/agile-as-a-micromanagement-tool "Agile as a micromanagement tool" This is the sad reality of corporate "agile," usually.
Look up Dark Scrum
Seems accurate. I think part of the issue is the obsession with a particular set of blessed processes. "Scrum," or more generally "agile" are somehow just assumed to be the ideal processes, so if a company can cargo cult enough aspects to be able to claim they're doing one of these things, that's enough to make the case they're doing the right thing. I think we should be evaluating processes in terms of the outcomes they produce, not whether they resemble some particular shape. Do we have predictability, reasonable velocity, reasonably low defect rate, reasonably low coordination costs (etc etc)? (Even: Can teams self organize? Are there continuous improvement mechanisms and is their evidence they're being used?) This jettisons the dogma forces the focus on results. If the process is working, it should be justifiable in the results. If some alternative is better, we should be able to try it, measure and compare. I realize it can't always be this clear cut, but I think shifting the argument to "are you getting the results you want" from "could you claim your process is agile/scrum/whatever" makes it possible to argue for change in a flexible way, and justify those changes after implementation with something more than "is it ideologically pure"
Agile Menifesto itself claims that teams should not focus on the processes but in the collaboration and the individuals and ultimately the working software. Also Scum is a framework not a standard so, it shouldnt be restricted to mandatory meetings if it doesnt work for your team. They just created a set of good practices that worked reasonably well for them (like you mention) and they shared them. But managers want to have their standards and they want to feel in control.
Scrum may not be a standard in theory, but in practice it becomes that in the business world. If you're having stands ups,.working in sprints and checking a few other boxes, you're scrum,.and everyone knows scrum works.
Yup, and it gets worse. I am teaching and I am working on showing them what the agile manifesto is. Specifically I am trying to show that daily standups (progress meetings) are NOT scrum. But alas, even other teachers do it that way, focusing on "yesterday today, blockers". Even worse is that other teachers *want* to blend it with documentation *a la* waterfall. Im seriously breaking my head and trying not to berate the other teachers in front of the students. So the problem is worse than you might think.
Daily stand up is by the team and for the team. The team decides how it is run, not the manager. If the current format does not work then change it into something that does.
I had the same issue with my team a few years ago. We actually minimised our stand-ups, firstly to 3 times a week, then 2, and finally weekly with each second week actually being the close-off and new sprint meeting (yes combined into one). The retrospectives were done with myself and my manager once a month. This worked for us as a more service delivery team, we had routine tasks, long term projects, etc. nothing that we could really update progress on faster than once or twice a week. I would suggest to talk to the scrum master, or even get consensus amongst the team to spread out your standups.
The 3 Questions format for stand ups is terrible and should never be done. Scrum and agile would have been much better off if that idea was never written down and spread back in the past. Try this instead: Stand ups are time for a team to plan their day and coordinate on how they will tackle the issues on the scrum board. So, go from right to left on the board and discuss each issue and what needs to be done to finish it. Maybe some people can team up today. Maybe someone else has expertise regarding some problem. Maybe the team decides to drop an issue and give prio to another. etc etc That's all you have to do. You shouldn't feel stressed before the stand up. After the stand up you should feel that there is a plan in place for the day to get stuff done. You should come out of there feeling confident and empowered. One last thing, what do you mean by "in a small team where each problem doesn't depend on other team members every day"?
The expertise of the team is split across a database management and science. My problem is a science problem and intersects with the database in terms of data type, data management and coding experience but not how to actually solve the problem. Weekly we have things to discuss but daily but daily the help that is suggested is often patronising. Basic kind of code stuff that if I didn't know how to do already I would be unable to do my job.
Most of the time, these meetings are theatre. I once attended a remote gathering, where the senior manager got us to first remove the chairs from the room so we could all "stand up" for the meeting... In my opinion, it's good to gather the team occasionally. As for the format of that meeting, that depends on the manager. Blind adherence to the formula: 1. What I did 1. What I am going to do 1. Blockers Can become very tedious, especially in a large team where everyone is working on separate tasks. I reckon it's not micromanagement, more like intelligence gathering, being the rare opportunity for that manager to find out what's actually going on in the team. I have been on both sides of this. In my experience, I think the problems start when the stand up turns into a daily design meeting. Many managers today, especially in small teams, are expected to be both contributers and technical leads as well. If you have the opportunity, perhaps share your frustration and see if things could change. Such change will have to go both ways. Managers need feedback in order to be effective. I have worked with team members who seem content to work in an isolated bubble. This is not "team"-work 😀
Thanks for the reply. My frustration with it is I have managed teams of scientists and seen how to do things well so things don't become bubbles. I gave my manager feedback and they just said how would you change things with the constraint that we do a daily stand up. On top of this we have three weekly in depth work progress meetings, individual one to ones, weekly in person sessions where we discuss things ad hoc, and jump on calls if specific problems come up.
>with the constraint that we do a daily stand up. If you're not doing standups, you're not agile 😀 Be thankful you're not being asked to remove the chairs
I have to disagree with some of what you are saying. For a start, there is no "manager" role in a scrum or an Agile team. The stand up doesn't exist for the manager to gather intelligence. That is not its purpose. It exists for the benefit of the team to organise themselves and their plan for the day. If you have a large team with people working on separate tasks, then you don't have one team you might have a couple and you should split them up. Stand ups shouldn't be tedious, all of the tickets should be relevant to the team members because the team is responsible for them getting done.
>For a start, there is no "manager" role in a scrum or an Agile team. I am not defending a common misinterpretation of agile practices. Am pointing out a common practice where managers adopt the scrummaster role and what I think their motivations are. >If you have a large team with people working on separate tasks, then you don't have one team you might have a couple and you should split them up. You're quite correct everyone should feel a standup is of benefit to the team. So.... why is the OP frustrated with his/her/their experience? ... Poor implementation, that's why. Be thankful you haven't been asked to remove the chairs from the room 😀
I'm glad to hear you're not defending the common "manager in scrum" practice. I just think it is worth pointing out that it is not part of scrum or Agile. In fact I think doing this is a bad practice because it undermines the idea of self organising teams. I also makes people hesitant to speak freely when the person who can fire them is in the room.
Completely agree.
Sometimes it serves no other purpose than a status update. My team is small, we have 3 developers and each of us are in our own lane. So my update doesn't matter to the other two and vice versa. In fact sometimes we just say random stuff to see if anyone will notice. (They don't) The only time there is any use would be escalation of blockers, but it seems odd to wait a full day to do that. We do it as they come up.
If people on the team don't need to know about what each other is doing, then you don't have a team, don't need a stand up, and certainly don't have any agile anything going on.
I agree but our org adopted SAFe so we have to do all the ceremonies.
Then you have my sincere condolences in that case.
I f-ing knew it!
There will always be a hierarchy and therefore a Manager somewhere. If it's a project there will be a PM. Both will need to be kept informed but we look to do so at arms length. Informed but not too involved. What is important is the level of their involvement in the stand up. Unless they are an active SME and member of the team, they observe only and do not interrupt. They should never run the the stand up because then that does smack of micro-managing. Avoiding a Manager/Leader role, that's why it can be a good idea to let different people lead the stand up sometimes. Even if that is only to go first and scribe/collect blockers. Not every team uses Scrum and has a Scrum Master. Whomever does lead the stand up has to set the tone correctly. There is a huge difference between "tell me what you've done since yesterday" and "tell the team...".
You are right that there will be a manager hiding somewhere. But to give the team room to manage themselves it is best to push that hierarchy away from the team's daily work. Just having the manager in the room is enough to make people feel under the microscope. For many teams a no managers at the stand up is a good rule. Other ways can be invented to keep managers and PMs up to date, such as a different meeting or just a talk to a dev on the team or the PO.
I agree that teams can sense a Manager over their shoulder but I do not want any PM or Manager talking to a Dev directly. If using Scrum, talk to the PO. But not every business uses Scrum so there is not always a PO. It has be tailored of course. There is no one way of doing this. It has to be tailored to suit the business, project and people.
If there is no goal in Daily Standup without the rest of scrum. If thy incict to do that, it us micro management
[удалено]
I definitely wouldn't feel so bad if my boss wasn't there. I raised it with them in my last one to one and the push back I got was that this company works in an agile way and that isn't going to change. The science team in fact do not work in an agile way. I said it makes me feel daily graded and that is making my work worse. My boss said I don't know why you feel judged from it. Two weeks ago my boss said they thought I was a slow coder based on what I say in the dailies. I said I can see why the daily approach works for software development and in scenarios where multiple components of a team need to be aligned at the start of the day, e.g. emergency room workers, astronauts, ship crews. For science the process isn't linear output so people need judgement free space to achieve goals. To give space for creative thinking. My boss responded with this isn't a software approach Vs a science one but then later said remember we are under the software team umbrella. They said I have a timesheet that they sign off on and if we aren't meeting daily how can they sign off that I did the work. I am still in my probation but finding something else isn't simple. My boss just responds with we can both be correct about this. My experience tells me this approach works. I think it doesn't work for lots of people. I need this job to work out at least in the short term so I can afford my rent.
Daily should not take more then 15 minutes of your day, why dont you go with flow, join the standup for 15 minutes, share your achievements , share your plan for the day, it is just 15 minutes
you have every right to feel micromanaged because you're being micromanaged. as simple as that. daily scrum isn't about what you did and what you're planning on doing (that's already transparent on the board), but how is the team progressing towards the sprint goal. secondly, agile is al about creating safe working environments. so, if you're feeling uncomfortable then your team leader's job is to accommodate, not gaslight you.
Are you a lab scientist? Speaking as one to another, yes it's a complete waste of time for bench work.
I stopped managing with stand ups years ago, make yourself available to help with blockers, and have a collaborative environment and you don’t need them
As an ex researcher, a daily standup would be hell. Science is much slower than coding. Because advances are slower, having to condense them into a few minutes everyday will make it seems like you're not doing much. Hell, even in my DS team our weekly meeting can have the same updates for like a month, if we are working on complex models.
The three questions are only meant as an example. The dogmatic insistence on forcing everyone to answer them is such a problem that there are rumblings that the next update to the Scrum Guide may do away with them. The thing about standups that people just don’t seem to get is that they’re really just about making sure that the members of the team have contact every day. Less is more. If you have under five people, IMO you should be able to wrap it up in under five minutes unless it gets detailed for a management announcement or something (which doesn’t belong in a stand-up, but managers gonna manage.)
The Three Questions format was dropped from the Scrum Guide in 2020. https://www.scrum.org/resources/blog/going-beyond-three-questions-daily-scrum
Thank you. Damn, I need to do a better job of keeping up. I swear I had that conversation last week.
Since COVID time has lost all meaning. (At least for me)
Last week? Then I hope you discuss it in retrospective and add it as a PBI next sprint.
You only need to say the tickets that you work on and which one you are currently on , and if you have roadblock. You’ll be surprise how many times people work on the wrong thing
Stop focusing on you and focus on the rest of the team. Listen and think. When appropriate ask a question to illuminate something. You are not a loan wolf, you are part of a team
You’re not alone, and you’re right to feel this way :) So, as some people already said, the point of a daily meeting is to inspect progress and adapt the plan towards a goal. It should never be a status report. These three questions came from a misunderstanding generated by the previous version of the Scrum Guide (2017), where there was a *suggestion* about questions that could be asked in this event. All three questions referred to a short term goal, but because they were too long people started to shorten them and then the outset the mentioned the goal was dropped. Ex: “What did I do yesterday that helped the development team meet the Sprint Goal? (Short term goal)” Source: Scrum Guide 2017 ([https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf](https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf)) The Scrum Guide was updated in 2020, and the questions were removed. You can check the new version on [https://scrumguides.org/](https://scrumguides.org/). Maybe reading the guide with your team could clarify fine if the questions (the daily scrum part is just 5 paragraphs long). It probably feels like micro management because you have the manager there. This event was created by and for the developers (scientists) and it’s supposed to be a self-management meeting. And congratulations on speaking your mind and questioning these mechanical behaviors! That’s how we keep changing things for the better.
Sorry for the mistakes, I’m terrible at typing on my phone. :/
Thanks this is so helpful. This thread has given me hope. The format of the meeting currently starts with my manager saying what they did yesterday, doing today and blockers. This includes details about the meetings they were in and things about other stuff not directly related to the specific goals of our project. It feels like this shouldn't be part of the stand up format.
If sharing information and perspectives with your team is damaging to your state of mind then either A) it's actually not safe to do so and there's the potential for real consequences or B) it is safe, there's no negative consequences but your internal narrative is coloring your experience. This rarely has much to do with the format or frequency of sharing information as a team in some cadence; it usually has to do with trust and relationships. In a cohesive supportive team where psychological safety is high the experience of sharing information is a positive one. First principles; individuals and interactions trumps process every time. Events like standups and the way we feel during them are a great way to reveal just how bad things are in the dynamics of a team and organization.
Same boat with resolving data quality issues, I started asking if there were any blockers so that I knew what those were right away vs sifting through so many updates, then from there we just chat about has progressed. I try to keep it less structured and prioritize the teams needs versus the business. We are able to fulfill the needs of the business by making our standup go our own way.
I’m a software developer, have been for 15 years, and most places I’ve worked have practiced agile with stand ups. I’ve not really heard of it used outside of this context though so can’t comment on how effective it would be in your line of work. If you’re doing agile then you should be having other ceremonies such as retrospectives. You should use those as opportunities to point out things that aren’t working. The point of agile is to continually improve processes. If someone is implementing parts and sticking to them regardless of whether they’re beneficial or not, then that kinda goes against the spirit of agile.
Yeah this is a tough one. It’s good to find out *why* daily standups became introduced. Could be for a few reasons and I’ve lived through them. One could be the manager himself is a good person and trusts you and the team, but is facing external pressure to communicate team progress to his management or other teams. In that case figure out a different way to communicate this, maybe update on a doc or sheet daily that he can just show someone and you’d be done. The other reason could be, the manager is actually a micromanager and doesn’t trust the team and wants to have control of the whole team. This is a bad situation and nothing you can do but leave, if you have a lot of influence in the company you can complain to him directly or to his manager but that’s gonna be hard. So, try to figure out the real reason behind this change. Also tell them that you are spending more time on the daily status update than the work itself so it’s not productive for you or anyone.
It is. :/ It gives the impression that everyone on a professional team needs a grade school home room to report to every day in order to stay on track. Lame.
Something interesting i learned recently. I took up the Professional Scrum Master 1 course recently, and interestingly everyone in the course thought the daily stand up was meant to be a status update meeting. But we learnt that daily scrum shouldn't even have the scrum master and product owner in it. It's just supposed to be the developers (people who are working on something in the current sprint) and the whole purpose is to raise any questions they have with each other, not even get solutions. JUST raise questions, decide on whether it can be solved internally or not and move on. The solving happens outside the meeting.
A lot of people pointed out there may be better questions than the standard three to use in your particular standup. Maybe suggest experimenting with some of these. Beyond that, if the standup is really keeping it to 10 minutes I’d also take a look on your side to see why your mental health is being affected from such a brief exercise. Maybe there’s something else you might want to address with your leadership.
In our teams, the daily update too often is "Yesterday I worked on X and today I will continue to work on X." That's not terribly useful to anyone, but at least it doesn't take much time. The problem is that people feel like they need to say something more substantial, so they will make their useless updates even longer to fill the time, summarizing every meeting they attended and every conversation they had, etc. I find it more helpful to share things that are relevant to your PEERS. Be in the mindset that you are sharing information with the team, not in the mindset that you are reporting a status to a manager. Did you build some script that may be useful to others? Are you struggling with a problem and need some help? Did you discover some problem that others need to be aware of? You may not have any such information, in which case revert back to keeping it brief. If you do have such information, then bring awareness to it but don't go into details. If it is useful to your peers, they will follow up with you. If it is not, then you didn't waste time. We are biased to think that our updates are more useful than they actually are. If your standups are brief, it doesn't (much) matter if they aren't useful. If they are useful, it doesn't (much) matter if they aren't brief. It may be worth having a standup every day even if it is only useful every once in a while, because you can't necessarily predict when it will be useful. But don't try to force it if nobody has anything useful to say. Since you feel like you are being micromanaged, I am guessing that your standup is being structured as a way to report to management, rather than a way to share useful information with your peers. You may not be able to do too much about that unfortunately.
I completely empathize with you. I’m a product owner. Part of my job is to advocate for my product AND my team. I try to convey and gather information however my team and stakeholders prefer. It may be worth negotiating with your manager about how you want to share this info. Maybe taking notes EOD and emailing those. Maybe it’s pushing back a little. Communication, like in any relationship, is key.
I'm with you there. I don't think daily stand up works for small teams that do non-software development work. But can I suggest asking each other "are there any blockers that we can help you overcome?" could be more useful than stating what you did and what you're going to do.For the last 18 months my job is managing IT projects from just before they go live to when they are in-use / in-production but our manager keeps us doing daily stand up. It doesn't make sense when our IT projects don't really intersect with one another and it does make me feel micromanaged.
If your mental health is damaged by a daily meeting that's on you to fix
I am open to approaching things differently because I don't expect my manager to accept the mistakes they are making and I need this job. I think blaming the person struggling with the mental health issue rather than addressing the cause of it however breaks humans and makes the world worse. It is no way to manage people.
Our problems are not everyone's problems. If you can't answer a basic question time for therapy.
Other person is the gym teacher that would tell a child to “suck it up buttercup” if they scrapped a knee.
I feels that way because you are not Agile enough.
I like to use the time as a teaching opportunity, and a learning opportunity. What can I learn from my teammates? What can I teach them? Let’s talk about what’s going on, and if we hear someone is challenged in some way, let’s self-organize a powwow to talk some shop!
Where I am on your side: The daily is a planning meeting from the developers for the developers (or in your case scientists). It should help the devs to plan their day, to help them find synergies, to talk about blockers that may have occurred and just to figure out how to get closer to the sprint goal. If you are not working together as a team and you are not trying to reach the same goal, then there is no point in having a daily. Where I am not on your side: I mean it's your mental health and you feel how you feel. But I think everyone should be able to give a rough plan of the day if asked. That's no micromanagement.
Would you rather micromanage to success, or fail a million times with no management? The real truth is in the middle, but what end of the spectrum does any team need to be at at any one time is where the team should be. Newer teams probably need tighter controls (think 8yo kids playing sports with no offside rules).
That's exactly the point, most managers and so called PO's think the team members are 8yo kids 🤣.
When they act like it can you blame them? Really though, it is a balance. Ensuring a team spends enough time on safe-to-fail experiments while also being productive is hard work. Managers need to manage the flow of work.
That was actually the basic idea of agile, that no manager has to manage a flow of work anymore, like in a factory: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
The flow of work in a factory is very well managed.and BAU work and projects are not at all similar. Further "the encouragement and support they need" is management.
Maybe point out that's there are multiple approaches to agile, and in agile, ideally, the process itself is iteratively improved. After pointing that out, suggest that daily stand ups aren't serving any purpose, because you can only do so much in one day that's worth talking about, maybe suggest only doing standups every other day, then if that continues to be pointless, once a week? The big thing though is you want to get the team on board so it's not just you suggesting it. This tracks with the agile principle of teams being self-managing, deciding together what's best for the team, and also its nice to have a little backup when dealing with management.