Daily stand-ups have two formats, one is Round Robin that has origins in Scrum, other is Walk the Board that is more Kanban. I highly recommend you switching from "did yesterday/do today" to "walking the board" as it is less about checking what each employee delivered in a day but rather what the team can do to move tickets through the board. It is also more inclusive allowing quiet/introverted/non-native English speaking members of the team to participate in the meeting rather than rehearse their updates in their heads ignoring others.
I agree with this, I found that if you go for the Round Robin format, often, people are just thinking about what are they going to say next, and how to make it sound like actual valuable work rather than listen to the colleagues. It gets akward when some people get a lot done (apparently) and others not, also not everyone knows how to "sell" their work, and IMO it can create weird dynamics.
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.
I agree with this. By far the least useful of the standard standup questions is "what did you do yesterday".
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.
It should be noted that the "round robin" format has an important aspect which is to enable each team member to air his/her personal grievances regarding anything related to the project.
> rather than rehearse their updates in their heads ignoring others.
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.
Walking the board is effective to have all team members in the same page of what's going on. But if the amount of tickets on kanban boards is huge, it could be time consuming. I'd rather have weekly "walking the board" meeting than a daily.
The last few teams I've worked on moved the daily Round Robin into slack. You would have to fill it out an hour after signing in and before you left for the day. Accountability was key and having it in the dev-chat saved a lot of time.
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.
Making classic standups useful and comfortable definitely requires psychological safety. You need to feel like you can occasionally say "worked on X, didn't make any progress", and a manager or a rival isn't going to pounce on you for it.
If you don't have pervasive psychological safety, there's a lot of stuff from XP that isn't going to work.
My 2c - the key is that the focus should be on delivery and not some justification for the work you did yesterday. The idea being that you are standing up looking at the work in front of you and the TEAM itself should be focused on how to move things across the board (ie delivering it to whatever definition of done makes sense for you)
>Maybe it's better when you take away the power relations
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?"
I skipped some meetings randomly (I was busy on the phone), so that's the escape hatch. But alternatively one might argue that if it's mandatory nobody will come.
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.
For me, they are. More so in my current role with a fully remote company. All calls are video calls, with RingCentral, Slack or Google Meet. We get to see each other face to face, get some social time and chit-chat a few minutes before diving into the standup.
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.
I think they are worth it for remote teams. Most of the work comms can be easily done in slack, but there’s definitely a benefit of making people talk to each other and express emotions at least once a day.
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.
Personally I don't like the daily scrum meetings need a coordinated time. For the company I currently remotely work for, it's fine for my colleagues if I just write down in Slack what I worked on during the day at whatever time is convenient for me.
Why not weekly? Or twice a week? Advantage of remote is that you can prioritize incoming information and everybody is onboard with asynchronous communication by default.
Agreed - whether it should be done daily or not is a decision based on a wide number of inputs.
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.
I'm sorry, stand ups are literally a psychological trick played by middle managers to put pressure on devs. They undoubtably lead to higher turnover from devs fleeing chickenshit and I've never seen one actually lead to better code.
In a past life as a Product Manager, one of my top devs rarely attended standups. One day, she rolled into the office mid standup, went over to the coffee machine, and prepared a cup. Never looked in our direction, and proceeded to begin her work.
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.
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.
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?
There's no PM present in the Scrum daily. In fact, there's no PM in Scrum.
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.
The one true benefit that i remember from my time working in scrum was when we moved the scrum meeting from morning to 12 o`clock.
And the benefit?
After the meeting, everyone was already standing, so we went straight to lunch as a group without any further delay. Saved a lot of time and effort to organize everyone.
Personally, I like the slack message standup over the meeting, but that's mainly because I'm a terrible listener, at least with text I can go back and see what a certain person has decided to mention. I also feel like it's easier to mention someone that I might need help from during the day
The problem I have with the Slack model is that it becomes opt-in. Lots of Devs simply won't read the channels because they won't care what other people were doing even if that knowledge helps people to skill-share, coach, encourage or take part of the work off of someone else.
I don't like or dislike daily meetings much personally, but I think they are needed - mainly for scrum master and PO. Daily can't be replaced realistically with bug tracker dashboard because 80% of daily time is not bug status discussion but let's say mostly human problems. Also I believe there is zero correlation between success of the project as a whole and a need for daily, none at all. People suggest async text in chat but eventually harder and more detailed issues will raise a need to actually talk and while it will save 20 minutes time of each participant who now don't have to listen to other people's issues it will also isolate people from potentially useful information and prevent them to suggest their ideas or ask for clarification , basically limiting in-team collaboration.
I think they are needed - mainly for scrum master and PO...[but] there is zero correlation between success of the project as a whole and a need for daily
So, basically, what you're really saying is they're not needed and you don't need scrum masters or POs.
> Another variation would be to do the daily on Slack which can even be asynchronous.
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.
The thing with dailies is not that you share your updates, its more that you’re forced to listen to everyone else’s.
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.
Regular updates on the bug/task tracking systems together with notification and Q&A on a more stream based async system like Slack work well for us. Lack of activity is usually a sign of an issue, usually someone being stuck, a bit down or on a roll. All need a check-in, even the on-a-roll person as sometimes they get carried away without letting people know about changes. We tend to have weekly in-person synchronisations meetings.
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.
The point of a stand up is to get everyone face to face to enable quick interactions and collaboration, and to do so in a very lightweight way.
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.
As so many things with scrum, a lot depends on the attitude of the scum master. If the scrum master is an ambitions person and focusing on results, stand-up meetings can be become a drag. If however, the scrum master has a focus on the team and it members, it can become a source of cooperation and encouragement. Many companies that want to implement scrum, do not want to pay the cost of hiring people who are good at being scrum masters (and are not necessary software engineers), but decide to assign the role to some existing people in the company, which, often results in people who see it is a stepping stone to a management position to opt for the role of scrum master.
I see the value in daily communication and the general topics (yesterday, today, blockers) of the dailies, but at the same time the daily standups show how the in general much of the modern work and communication has moved to asynchronous methods but the text book example still requires the events to happen in a synchronous way (eg. standup at 9 am) which obviously causes issues.
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 they're absolutely worth it. The interruption of flow is minor, because they're predictable. You can plan around them. If you're working on something really complex and urgent, I don't mind if you skip it occasionally (but don't make that a habit).
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.
Yeah, nothing worse than finding out that someone has implemented something that you've already done somewhere else because you didn't know it was being worked on.
Short is definitely good as is the chance to chip in a bit of unsolicited advice from one dev to another ;-)
I haven't found a way to make daily standups work in my team which is fully remote and spread out on 3 continents and 4 time zones (so there is no "start of day"). Instead I have a weekly sync with everyone and 1:1 with each person on a weekly basis.
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.
Yes, they do but it depends on the context. In my previous company (web agency) they were solving several issues at the same time:
- 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.
In my experience, daily scrums are without value. A well-functioning team already knows what everyone else is working on, what problems they're having, and etc.
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.
When I was put in charge of a new team for a new project at my previous company, we did the most agile thing there is.
We got together and asked ourselves (all of us having previously been on teams that had daily standups): "So, what do you all think, is the daily standup worth it? No? Alright, let's try without it."
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.
[+] [-] kozhevnikov|6 years ago|reply
[+] [-] alfonsodev|6 years ago|reply
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.
[+] [-] chimprich|6 years ago|reply
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.
[+] [-] rumanator|6 years ago|reply
[+] [-] jeresuikkila|6 years ago|reply
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.
[+] [-] mcv|6 years ago|reply
[+] [-] a012|6 years ago|reply
[+] [-] Antoninus|6 years ago|reply
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.
[+] [-] klemola|6 years ago|reply
[+] [-] einpoklum|6 years ago|reply
Maybe it's better when you take away the power relations. And reduce the frequency during non-critical periods.
[+] [-] twic|6 years ago|reply
If you don't have pervasive psychological safety, there's a lot of stuff from XP that isn't going to work.
[+] [-] philjr|6 years ago|reply
[+] [-] dd82|6 years ago|reply
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?"
[+] [-] loa_in_|6 years ago|reply
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.
[+] [-] dd82|6 years ago|reply
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.
[+] [-] seer|6 years ago|reply
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.
[+] [-] wsc981|6 years ago|reply
[+] [-] bitL|6 years ago|reply
[+] [-] mikece|6 years ago|reply
Programmers: no.
Project managers: Why can't we do this twice a day?
[+] [-] sod|6 years ago|reply
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.
[+] [-] Plyphon_|6 years ago|reply
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.
[+] [-] a_ranom_dev|6 years ago|reply
[+] [-] kierenj|6 years ago|reply
[+] [-] distantaidenn|6 years ago|reply
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.
[+] [-] mmsimanga|6 years ago|reply
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.
[+] [-] twic|6 years ago|reply
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?
[+] [-] mcv|6 years ago|reply
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.
[+] [-] ferreus|6 years ago|reply
[+] [-] hugg|6 years ago|reply
[+] [-] lbriner|6 years ago|reply
[+] [-] Yizahi|6 years ago|reply
[+] [-] mattmanser|6 years ago|reply
So, basically, what you're really saying is they're not needed and you don't need scrum masters or POs.
[+] [-] jpkeisala|6 years ago|reply
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.
[+] [-] seer|6 years ago|reply
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.
[+] [-] carwyn|6 years ago|reply
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.
[+] [-] mytailorisrich|6 years ago|reply
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.
[+] [-] fjfaase|6 years ago|reply
[+] [-] petetnt|6 years ago|reply
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.
[+] [-] celticmusic|6 years ago|reply
[deleted]
[+] [-] mcv|6 years ago|reply
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.
[+] [-] lbriner|6 years ago|reply
Short is definitely good as is the chance to chip in a bit of unsolicited advice from one dev to another ;-)
[+] [-] athenot|6 years ago|reply
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.
[+] [-] valcker|6 years ago|reply
- 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.
[+] [-] JohnFen|6 years ago|reply
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.
[+] [-] balfirevic|6 years ago|reply
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.
[+] [-] pszndr|6 years ago|reply
Title: Is [x] better than [y]?
Article: Depends on context
[+] [-] THrau|6 years ago|reply