Are Daily Scrum meetings worth it?
blog.valuemotive.com
blog.valuemotive.com
That mindset is precisely the reason why these meetings are important, because these grievances might not necessarily reflect or deserve a ticket. They might be nothing or they might be something. What's important is that these meetings create a space where they can safely be addressed without creating any burden on the team and on the individual reporting them.
I've read somewhere that these meetings work as therapy for the team. Perhaps by putting it this way you might better understand the issues these meetings solve.
That doesn't cut it. Being expected to talk about stuff doesn't put you on the spot, and purposely requesting the team to address a concern makes you stand out as the one creating problems where none existed.
"Worked on adding discounts to the shopping cart page. Went over to talk to Chris in billing about that, and he mentioned in passing that they are planning to move on to SAP next year."
That could be incredibly important information for the team! It doesn't come up as naturally when working through stories as in a round robin.
Walking the board is much more helpful for the team and retrospectives and one to ones can be used to talk about productivity differences, individualities and other issues.
We came up with a variant to fix this. You have to say what the next person in the circle said they'd do yesterday before your talk.
This forced everyone to pay more attention as you don't know who would be standing next to you tomorrow. It wasn't easy to do but I think it did make people more aware of what was going on.
Here's the reason: managers are so spread thin that they don't want to be in 5-10 standups all morning, so they combine around organizational structures rather than product(s)/deliverable(s). Another case of the software delivery matching org structure...
> because government project? although I imagine this happens in non-gov settings too, this is just my experience.
Why not split into smaller work groups? What's the advantage of 20 person teams?
So instead of wasting some people time, you are now wasting 2x that time.
Make the meeting relevant to everyone, make it tight (time-wise). Hiding the problem under a tarp ensures it doesn't get any improvements.
Focussing on the work to be done puts the emphasis on teamwork and skips the pressure on people to justify themselves or play politics by showing off.
That's assuming everyone is doing the work and they're being trusted to do the work. If that's not the case, then you have bigger problems than the format of your daily standup, and standup is not the best time to address them.
The goal is not to explain what you did. Happy with the approach because knowledge is actually spreading across the team currently. Meeting do get much longer though (1 hour usually), but time is recovered mostly on code reviews which become shorter. Usually lot of discussions sprouts out of this, leading to better code overall.
Personally, I always try to take quick notes ahead of time in order to be able to listen to others during the meeting. I'd highly recommend this to everyone to help focus on what others are saying.
Our 'walk the board' process was saved for tuesdays and thursdays and involved product and project managers. We set a 45-minute max so noone would rabbit hole on any one ticket.
This has been my favourite process so far because this was the highest level of team accountability I've experienced and you would only spend 1.5 hours a week in meetings.
Maybe it's better when you take away the power relations. And reduce the frequency during non-critical periods.
I don't have a good argument for the second part, except that I'd attend it to be up to date whenever I could.
But if I wasn't productive yesterday, I'm not delivering today...
Also, the fact that someone _says_ the focus is on delivery doesn't mean the dramatic focus of the situation is not on whether or not you've "been good" yesterday.
What do you mean by this? Are there significant issues with the management or other devs? This really should be a time where you bring up the issues you're having, and options for others to help you.
Sometimes, tickets just get way underpointed, and I've definitely felt the "on trial" frame of mind, but that's more me putting more pressure on myself. It definitely helps when the rest of the team is asking "ok, you're in a rough spot. What can we do to make it easier?"
Any issues with the management an engineer brings up are issues readily solved with a pink slip for the engineer. "Reading the room" is essential -- understanding the company culture -- before you speak. And even then, you might be wrong.
I mean, if there isn't a manager who can give you orders and personally decide whether you get fired or not. Of course that's not very realistic in a privately-owned, hierarchically-managed commercial company.
If you don't have pervasive psychological safety, there's a lot of stuff from XP that isn't going to work.
https://youtu.be/OMDQzITWJyU?t=204
From "The Dictator", where Nuclear Nadal is reporting on his progress.
Other teams do async standup via Slack, via Standup Alice. It seems to work for them.
I also really like the addition of an "open forum" in my team. Is there anything you've heard from other teams that will probably have an impact on this sprint's tickets or ones in the queue for the next one? Its also a good time for the PMs to relate any relevant conversations had with other PMs that we should know about.
The real key to this is there's no power play involved, and to have a good sense of scope about what's appropriate to bring up and what isn't. We're also a hybrid core/product team, so regular checkins are beneficial overall.
Normal offices accomplish that with water cooler talk and informal chatter, but you miss on that with remote teams. There might be a better way to solve the “loosing of esprit de corps” thing but dailies are the easiest thing I’ve seen do that.
The idea is to be able to share the squishy emotional human bit of working with a team of people.
Without it I've seen people just slowly drift apart. You'd see a comment from a coworker on your PR and be like "argh who is this guys think he is! He's totally wrong" but if you can talk with him about it in video it becomes a lot less confrontational. You can apologise and be apologised to.
A jira board is just a means to have some shared concern to talk about. And done properly can leave you with a feeling of being part of something bigger, rather than a lonely coder talking to a computer.
Unless that doesn't happen. Perhaps he digs in his heels that he's "right" when he's demonstrably wrong? Or 'he' is the team lead, and it doesn't matter whether he's right or wrong, we all now move in that direction "because". Having to have video/f2f in situations like that adds more stress.
Dealing with this situation now, and it's bad.
A better strategy I think is to try to get emotionally in sync with the other person first. Win them as a friend so to speak. And visual queues in that case become paramount. Co-location is even better, but we're talking about remote now don't we.
People sadly don't usually listen to the facts, especially if there's an argument, and double that if the argument is public (more than two people involved). It requires enormous emotional courage to admit someone's right before a lot of people, so we hardly every do it. That's what most of the advice from those books is to get to know people first, gain their trust and talk to their emotions rather than the facts.
Dailies are not meant to fix that I think, more like keep the team working in the long run if it had a good start, and help leaders find out about problems quickly and address them elsewhere.
Going off topic a bit though but in your example - a team lead that's going off to a demonstrably wrong direction - well they have more things on their mind than that particular thing probably, "does my team listen to me" might be one of them or "other business consideration that we're not privy to" is another.
One way to approach this is to support them publicly but have a one-on-one with them and express your concerns, without personal judgement and the like. After which you can ask them to help you with a particular task, preferably one that you know will hit the problem where you've thought the direction would be bad. And never say "I told you so!" Help them through the arising situation and bam! You will have them on your side plus the project would be moving in a good direction.
Also a lot of times it might turn out that this direction was actually preferable. You'll get to say "yeah you were totally right" and win them to your side as well, and learn a new thing in the process!
I've got a couple of current situations where... the other person is not wrong (charitably "right"), but the timing and prioritization is poor. Or, they may be 'right' but for wrong or bad reasoning. (yes, doing "foo" in the code is good because is helps with code readability, but no, it doesn't bestow another layer of security to the project, and no, it's not a 'performance boost').
These are even harder situations to deal with, because, again, technically, the idea being presented isn't "wrong" or "bad" in an absolute sense, just... strategically, it a step in a demonstrably bad direction wrt to project progression and hitting deadlines.
> or "other business consideration that we're not privy to" is another.
I've been on teams of up to 50 people - divided in to multiple smaller teams - company in the hundreds of employees. Yes, there may be reasonings that I'm not privy to - completely understandable (expected). I've been on teams of 3-4, talking to an end client multiple times per week about goals/deadlines/etc. There should not be any reason for info siloing with respect to anything at that level (save, perhaps, financial considerations like salaries, contract amounts, etc).
Programmers: no.
Project managers: Why can't we do this twice a day?
That quote sums it up pretty nicely. To bad of a naming for this type of meeting. Hard to negotiate to do a "daily" less then daily.
When it's work best anecdotally, is when we hold regular retrospectives ON our agile ways of working. EG: Is the standup working for us? What should we stop/start/continue in our standups?
When this 'retro of agile' (rather than just project/product retros) take place regularly you quickly come across a format and cadence that works for the team.
Tools are just tools, they should work for us, not the other way around.
Later during our 1-1, I asked her what the issue was, and she bluntly told me that she thought standups were useless.
I never brought it up again, as she was an amazing developer, and her documentation was absolutely pristine. After that, I myself stopped seeing the value in universal standups. If a person is good, they make it known in other ways.
It's a sad culture when a developer thinks they don't need the team or when, for some reason, they don't have to come to standups.
Of course, that doesn't help you if you're stuck in an organization doing it badly.
It's childish and immature and if you for some reason need to do it to be able to communicate, learn how to communicate properly, don't foist your miserable way of working on others.
"What did you do yesterday".
How is that not a loaded question?
JUSTIFY YOUR EXISTENCE. Every day.
Anyone encouraging standups is just contributing to the poor mental health of programmers.
It sounds like either your work culture is somewhat toxic, or else you are rather defensive.
Also, how can standups be designed to make the team work more effectively? They essentially steal some of the best development time in the day by insisting on being the first thing done in the morning, when most people are fresh and ready to go. There's no way in hell this was designed to be anything but a manager's control tool designed to slow down the team in bureaucracy and bullshit. And it does a great job at that.
Tips:
* NO MANAGERS. The standup is for the scrum team to organise and help itself. It is not there give a status update for the manager. The manager isn't in the team, and people have trouble talking freely when the manager is around.
* Do an issue based standup. Discuss the status of each issue on the board from the right to left. The primary question is "What can we do to keep these issues moving along through the process?".
* At the end you can ask "Does anyone have anything else important to add?". Maybe people have to leave early today etc etc.
That's it.
She was quite communicative in other ways -- just didn't see the need for standups. Due her effectiveness, I had no reason to try to change that behavior. She got shit done, and everyone knew it -- with our without a standup.
Edit: And please note that I said "universal" standups. I feel we often want to apply a one size fits all to developer mindsets. Maybe she was shy. Maybe she felt pressure from the ceremony. Maybe she did just feel it was a complete waste of time. Either way, my job as PM was to get products built, and a big part of that was understanding the individual mindsets and capabilities of the engineers on my team.
This for me is the biggest drawback. When you are in the zone and interrupted it takes long to get back in the flow again.
Another point is I don't solve problems in a linear fashion. When I am stuck I sometimes jump to another part of the application that I know I will have to tackle later on. That's just me. This is hard to explain in Agile with a PM/scrum master present.
Edit: PM/scrum master because we have mixed environment.
Jumping between different stories before finishing them is fine in solo projects, but if you're working with others, it means more code conflicts. That said, it is absolutely possible to work on multiple stories in Scrum.
This is why you do the standup first thing, before people have started working. There is no flow to interrupt.
> Another point is I don't solve problems in a linear fashion. When I am stuck I sometimes jump to another part of the application that I know I will have to tackle later on. That's just me.
If you're doing XP, or any kanban-flavoured variety of agile, you pick up one story/feature/etc and work on it until it's done. You might jump around in the codebase to build that feature, but you work on one feature. That's easy and natural to describe in a standup.
If you're not doing that, then indeed, it's going to be hard to talk about what you've done.
But to be honest, what you're doing is almost certainly not very effective, so maybe stop doing that?
That requires all the people to come to work at the same time.
You most certainly don't have enough information to make such a recommendation.
So, basically, what you're really saying is they're not needed and you don't need scrum masters or POs.
PS: in our case SMs and POs are actually doing useful work and we aren't holding any worthless meetings which are solely to entertain people not doing anything. If that was what you implied.
That is exactly what I do. Every morning answer 3 things in Slack. It is also good way to say "Good morning, now I start to work on X, yesterday I did Z and I need some help on Y.
Doing it as you suggest is simply doing daily update reports and negates the point of a daily scrum.
I feel often Agile principles are taken as buzzwords without really trying to understand the point. Now, whether the point works for you and your team is another question.
Granted you can always snooze a bit and pretend, but that kind of bad faith is usually indicative of other deeper problems with the team.
Also this can become a drag if you’re “held accountable” rather than “helped in need” but smart leaders would recognize that and attempt to fix the problem in the team, and a daily like that can be a tool for them to diagnose problems like this.
This seems to be an overlooked aspect here in the comments too. Yes, nobody likes to be forced to do something but in this case it's worth it. We have enough distractions as it is so taking 15 minutes to focus on what's important to our colleagues can bring forth valuable connections of ideas and people.
This does really vary hugely from team to team and even project to project though. I fear "agile" methods have forgotten the meaning of the word they are based on at times. Regular re-factoring also applies to development and operational models I find.
Then you move forward to move say the dailies in Slack, at which point they just get posted whenever people see fit, which sort of works unless the problems themselves need to be solved synchronously, as it is with many cases and they easily just end up being status reports instead of actual planning.
I think it's good to start the day together, with some idea of what everybody is working on. It helps to detect some issues that otherwise might be ignored or detected too late. Generally, communication is good, and short communication is better.
Short is definitely good as is the chance to chip in a bit of unsolicited advice from one dev to another ;-)
Kanban board gets reviewed weekly for assignment and direction (and I keep an eye on it thoughout the week). Blockers get addressed asynchronously in dedicated discussion spaces as soon as they arise. If a solution isn't found in chat then it becomes a topic on the sync meeting. But generally, there's no "spinning wheels" as everyone is mature and doesn't need a short leash.
Which leads me to trust. Everyone in our team has a decent amount of experience. They all know when they are stuck and they all know where to ask for help. I've always felt that trust is empowering and that's what I wish for everyone on my team.
But in this context, 1:1 are very important and I try my best to make them safe spaces for people to bring up issues which would be more uncomfortable to bring up in a group setting, especially for introvert personalities.
Ideally, pick what works best for YOUR team. Experiment and try new things. What works today may not be the right thing in a year. These are tools, not dogmas. The worst process is the one everyone follows but nobody knows why nor how/if it helps.
- Project Manager (Proxy Product Owner) is communicating with the client on a daily basis and is getting some important updates about the progress of the Sprint;
- if there are some unexpected developments (for example, some User Stories appeared to be more complex) the Team and the PO can make a decision about it together, discuss various options, etc;
- the distributed team has a chance to see each other (we were encouraging video calls via Google Meet).
However, there are some certain rules which should be followed in order to make Daily Scrums effective:
- video (or at least audio) conferences for distributed teams – it can actually be slower to have this meeting via Slack;
- they must be timeboxed (15 minutes max);
- stay pragmatic about what you are discussing and ask the feedback of your team about it.
If a team isn't well-functioning, then daily scrums could have some value -- but I think a better approach would be to fix the team.
It worked great. We ended up doing a quick meetings 1-2 times a week to sync-up and get the idea of where we are. Any blockers would be brought up informally (through Slack or in-person). We all knew each other well, so trust was high to begin with. Also, it was a relatively small team of 5 people.
I guess the point is that "having daily standups" is not agile. Regularly asking yourselves if they are or would be useful (whatever the answer may be) is.
Title: Is [x] better than [y]?
Article: Depends on context
You also foucs on assigned tasks rather than a team working together to get stuff done. Sounds like Software engineers, not product engineers. If you are pre assigning tasks and working separately then yes a daily scrum has no value.
But that isn't the point of a daily scrum, or scrum/agile at all. The focus needs to be on getting value to a customer together as fast as possible - not individuals doing a task each to build to a pre-defined whole. Iteration not increments.