Being late for stand-ups
Does anyone has any good ideas on how to encourage people to be on time for stand ups?
We have a couple of people, or even one person, who is generally late for stand ups.
I've talked to the team about changing the time of the stand up to later to allow everyone this buffer to be on time, they said it is unnecessary. I've also explained why being there is extremely important and they seem (and I say "seem) to understand it.
I've also introduced the "Latte Jar" where you have to pay a dollar for being late. However, it is still not good enough.
In the meantime on my whiteboard that is visible to everyone I started a table "Who's late for stand ups?" and I put a mark next to names of people who are late when they are late. I wrote: "Once you get to 10 marks, something happens". However, I cannot come up with a good idea of what would happen. What punishment that is fun, not mean, but still not desirable can I introduce to this?
In my previous team the thing that worked wonders was "Sprint Driver" - if someone is late for stand ups the most during the sprint, in next sprint they will become a Sprint Driver - they will have to write on the whiteboard during the stand ups, take notes in all meetings, check on Jira board and generally be the team's little helper for the whole sprint. While this role was still spread across the whole team anyway and someone would take on this role without reminders when sprint driver is not there, team members started to show up on time for stand ups as soon as we introduced this.
However, I don't know if this is the correct approach for my new team and would like to check on other opportunities.
What is the real-world impact of this on the team? Are they leaving the Daily Scrum with a rushed or inadequate plan for the day, due to the lateness of that team member, and which everyone understands is rushed or inadequate for that reason?
You do highlight the facts. Then, why don't you ask them how they would like to deal with it ?
It sounds like a good discussion candidate with the team, perhaps at the next Sprint Retrospective.
Experienced Scrum Masters are very keen in identifying potential areas of improvement (such as team members being on time for meetings), but we should encourage the discussion as much as possible, instead of trying to come up with potential solutions ourselves.
What does the team think about stragglers to their Daily Scrum? Is it a behavior that they want remedied, or do they not think it is a big deal? What are their reasons for either way of thinking? Facilitate an open discussion on it, and allow the team to determine what is the best way for them to work.
Awesome question Daria and my team does sometimes suffer from similar problems.
The whiteboard sounds like a great idea for Transparency and as Oliver suggest the Inspection and Adaptation part could be pushed back to the team. An ideal time to discuss this for this would of course be during a Retrospective.
The action of you putting a mark against someone's name when they are late might detract away from the “Servant Leader” perspective and make you come across more like a Boss\Enforcer.
Alternatively you could potentially ask the team if they think it’s a good idea that the person turning up late puts a mark against their own name. Although this is only a small change to what you do currently do this might change mentality and make the problem seem like one for the whole team instead of just a problem for you.
I have heard of various “punishments” to team members turning up late such as:
-
Press-ups
-
Make/buy a tea/coffee round for the team
-
Present a 10 mins presentation on a relevant topic (possibly a scrum or punctuality one)
-
Take on an admin task that the team needs doing
-
etc..
However some of them can border on being cruel and others just add impediments to the team.
Also if you do assign them the “admin task” (or “Sprint Driver” as you call it) then this task will probably away be seen as either a punishment or chore and no one will ever likely want to do it in future regardless of being on time or not.
On the flip side there could be an incentive for people who always turn on on time.
You could potentially discuss with the team and identify something everyone would want to do such as a team lunch, or team outing etc. Then see if the team thinks it’s a good idea if only people turning up on time are able to join in on this.
This approach might give a more positive feeling to the team and also might yield more favourable results.
My team has not yet identified a full solution to this issue so please keep posting back on regarding the different things you are trying and the different results you are seeing...
I would like to thank everyone for the insights.
To anwer Ian's and Olivier's questions: I have an impression they do not see an issue with it.
The stand ups improved a lot since I joined as we started to have more sharing between team members - previously they felt a lot like status updates to the team lead.
But it seems like they don't see how not being able to give and receive each other updates hinders them during the sprint. As an observer I can see it right away - some stories not getting done, code reviews taking several days, etc. Since it's a subtle change, it's almost invisible to them from where they stand. I brought the topic around stand ups in a couple of Retros, but it was not picked up by them.
Timothy, I agree that giving that decision to them is definitely a way to go. But wouldn't bringing this topic up again in a Retro be seen as too pushy? Like, "Daria talked to us about that 3 times now, so I guess we have to do something, otherwise, we will be talking about this unimportant thing forever. "
Mark, thank you for great ideas. I really like the switch from me putting marks against people's names to them - more power to the team.
I have one single person who have not been late a single time and I really want to encourage this behavior, have some kind of trophy for this. Not sure what it can be though. I wouldn't want to tie it all up to money (e.g. buying coffee for everyone, team lunch paid by the company, etc.).
One thing I thought would be interesting to consider with the team is to give the contents of the Latte Jar to the person who has not been late once someone get's to 10 marks.
Something that I've learned is that adults respond better to positive reinforcement than negative reinforcement. Take the Latte Jar, while there is nothing wrong with this idea; the impact isn't that big of a problem. It becomes more of an inconvenience and irritating thing, "eh whatever, it's only a dollar" is how I would take that. Now if you had the ability and resources to do this, here is what I would do in this scenario using the Latte Jar. Every Friday, the team gets coffee provided by you (whether you buy it or the company buys it). If a member is late to a Stand Up or other event, their name is put in the Latte Jar. On Friday, whoever's name is in the Jar, doesn't get the free coffee. This means there is an incentive for the members by getting Free coffee on Friday and all they have to do it show up on time.
If you don't have the ability to get the team coffee or something like that, you could make it a fun thing. In my High School Choir, my choir director had the rule that if you are late; you get to sing a solo in front of the class for 15 seconds or longer and he chose the song. Typically, we did "I'm a little teapot" and you had to do the motions. This made for a good laugh for everyone but it also was an incentive to not be late.
I'm big on positive reinforcement because it garners more teamwork and a more enjoyable environment for the most part. One of the reasons I chose the Scrum Master path is because I get to be a leader, but have a better opportunity to encourage and lift others up. Leave the negative reinforcement to the managers, that's their job. Try to find ways that would garner teamwork without punishment. It's hard because for some teams, positive reinforcement won't work; but it's still worth a try.
Thanks, Curtis. The positive reinforcement makes a lot of sense. I generally like the idea with Friday coffee - it's a more frequent reminder then waiting for someone to get to 10 marks.
I was thinking of using the Latter Jar money to do something like that, maybe only have it every sprint, so that we have enough money in the jar to cover the costs. But our team lead takes everyone for coffee every week in 1:1 anyway, so I'm wondering if this is enough of an incentive. Maybe I can distribute little candy packages to those people who have not been late for stand ups, during Retrospective or Sprint Review.
I wouldn't agree with the High School Choir idea though. Since we work with developers they often are quite shy and don't want to be in the spotlight, especially in a negative way (like signing a silly song).
it seems like they don't see how not being able to give and receive each other updates hinders them during the sprint. As an observer I can see it right away - some stories not getting done, code reviews taking several days, etc. Since it's a subtle change, it's almost invisible to them from where they stand. I brought the topic around stand ups in a couple of Retros, but it was not picked up by them.
My advice is to concentrate on putting transparency over these matters first of all. Once the team see the problems which are being created, ask them what they intend to do about it, and to think carefully about which behaviors they may need to change.
This transparency should extend to stakeholders including the Product Owner, and any higher-ups who are expecting agile professionalism to be demonstrated.
I agree that positive reinforcement is a much better approach than negative reinforcement.
I would add also that you want to be extra-careful singling out any individual behavior for ridicule or punishment. Making team members check their name indicating they were late, or putting their name in a jar, or excluding them from a reward based on their preferred behavior, will only breed deep resentment in my opinion.
One thought might be to stick with team-based rewards, but to specify that the entire team must adhere to desired behavior in order to reap such rewards. In your Friday Coffee example, state clearly at the beginning of the week that everyone on the team will get a free coffee on Friday, provided each Daily Scrum for that week starts on time, and is fully-attended. If one team member is late that week, the deal is off. Allow the team to self-manage around that issue. It may be painful, but the team as a whole can be much more effective in managing behavior than you may be through suggestions and observations.
One tactic that worked for me with one of my teams is to facilitate the Daily Scrum on time, regardless of who is there or not. After late team members walked into a meeting in progress a couple times, they got the hint, and began coming on time.
It really needs to be clear that addressing this is for the benefit of the development team. If they don't see the need to resolve this, perhaps the Daily Scrum isn't working well for them anyway.
Are they using it to set a plan for the day, or are they just using it as a status update?
What happens when people are late? Does the stand-up get delayed? Do members of the team wait for everyone to arrive before they begin? Do some members miss part or all of the discussion?
Perhaps you can observe this... E.g. count how many minutes are wasted for those who attend on time (include yourself if you attend), count the number of minutes of missed conversation, etc.
Then you could present that to the team; perhaps in the retrospective.
Perhaps making that number visible to the team is enough for them to solve it themselves. Either as soon as you mention it, or after a few sprints.
If they don't solve it or at least improve, ask them what they feel about the situation once they've seen your data for a few Sprints.
Hopefully they will want to sort it. Then you can see what steps they would like to take.
A lot of very good points.
Ian, I might have misunderstood your last statement. Could you please elaborate?
"This transparency should extend to stakeholders including the Product Owner, and any higher-ups who are expecting agile professionalism to be demonstrated."
I don't suppose you mean raise this to management and pinpoint people who are not on time. I would like to solve the issue without management intervention if possible.
Timothy, I really like your idea about getting free coffee for everyone if everyone was on time that week. That is a great idea. I was hesitant of having one person left out of an activity because they were late, I agree it might create a very negative atmosphere in the team. So far I only have one person who was always on time for 2 sprints now and I really want to reward this behavior somehow at least for a start.
Simon, that definitely makes sense and those are good questions to ask.
Since I joined the team would always start the stand up even if not everyone is there. It felt like it was for me. I started to walk away from the middle of the circle to allow more team interaction and it seems to work much better now.
Counting wasted minutes when someone's late sounds like a great transparency tool. But in our case since we don't wait for anyone and we never run over 15 minutes, it's not applicable, unless I suddenly ask them to wait for everyone to arrive.
I don't suppose you mean raise this to management and pinpoint people who are not on time. I would like to solve the issue without management intervention if possible.
No. Remember that at the moment you don’t have anything to raise, even if for some reason you wanted to. Any problems are not yet apparent to anyone other than yourself. Nothing can be “pointed to” and no remedy can be proposed.
My advice is to concentrate on putting transparency in place so that the team can acknowledge the issues. Highlight the occurences of waste and inefficiencies. Then they, the team, ought to be encouraged to provide a solution.
This transparency should extend to stakeholders who are not on the Development Team, including but not necessarily limited to the Product Owner. They have an interest in the team’s agile competencies even though they are not in a position to resolve the team’s problems for them.