Time to change how we do Stand-Ups

Justin Lam on January 10, 2019

We are all familiar with the Stand-Up meeting, where everyone meets on a pre-determined cadence (every day, 3 times a week, etc...) to answer the... [Read Full]
markdown guide
 

In my team we sometimes do the classic stand up meeting and sometimes we do the meeting using Slack. What I observed is that, when we do it face to face, there is a significant increase in tangent discussions but also it's easier for us to spot problems and give tips into each other's tasks. So, I'm not really sure if doing this kind of meeting thru text is better or not

 

Maybe a hybrid approach. Face to face once a week, while the rest of the time through text?

 
 

As a Scrum Master, I’ve been in a few daily scrums (which, by the way, don’t need to be standups). I tend to bring the time down even further, to maybe 5 minutes, so that it doesn’t feel like waste. An independent facilitator surely helps.

 

100% agree on writing down all the things we shared during Daily Stand-ups.

I've been in so many meetings just trying to remember what we said yesterday or last week and sometimes there are topics that are not directly impacting the work of most of the team; as you said, it might be just human nature.

But wasting other people's time is a sin.

Good and to the point post!

Regards,

 

The 3 question format seems less than optimal to me. We should know what was done and what is going to be done based on whatever tool/board/etc is being used to manage the work.

For me the real question for the standup is - what is our plan of action for the team for today. This is a team discussion based on the work to be done and involves the "what are the roadblocks" type of questions.

We have tried Slack. Didn't work well for us.

 

Can you share more about what didn't work?

 

We have tried both, I'm not sure which I prefer. I certainly feel more productive with async standup.

 

We generally don't type out our dailies in Slack, unless teammates arrive at the office later than face-to-face daily meeting time. When someone misses the daily for whatever reason, we do not schedule for later time to avoid messing with everyone's personal schedules. In this case, the person that missed the daily shares it in Slack for everyone. We adopted this model as we are working for an external client with which we share a Slack for written communication and conference calls. The only downside of this approach is that whoever misses the daily does not get to hear other people's daily. However, it turns out quite alright because all developers are in the same office.

The above was a comment towards point 2. Other comments pretty much summed up what you should do to solve your issues.

 

I don't understand how you solve this statement: "The only downside of this approach is that whoever misses the daily does not get to hear other people's daily. However, it turns out quite alright because all developers are in the same office." Does the individual just go around asking everyone their daily updates? If that's the case, why do they have to share it on Slack since they are going around talking to each person individually. Also, do you realize how much time is wasted trying to find each teammate?

 

We're a small team of 6 developers sharing the same office space and we're sitting right next to each other, so finding teammates is not a problem at all. Those who miss the daily meeting share their updates by writing in Slack, most importantly, for our client to be up-to-date on our progress.

Does the individual just go around asking everyone their daily updates? If that's the case, why do they have to share it on Slack since they are going around talking to each person individually.

Not really. Besides daily absences not being that frequent, we, the devs, generally don't do have to do that because, except for task-specific details, are aware and contextualized with what everyone is doing. Devs missing a daily once in a while never proved to be problematic. However, our client has to be up to speed at all times.

Being physically close to each other enables us to reach out for one another without hassle whenever we have to sync or sort out any issue. As an example, ocasionally, I am tasked with work that has a relationship or dependency on someone's else work. Even if one of us misses the daily, we speak one-on-one throughout the day to check up on each other's work.

Of course, whatever works for us may not work for you or someone else's team.

 

Our team has had similar thoughts about the typical stand-up recently as well. For us, the problems were related to people but also the format.

  • Company dictated that agile process was "owned" by a single manager. Their attitude tended to be that everything needs to be done in the sprint, regardless of any problems. Others quickly fell into a pattern of not bringing up issues due to negative reactions or being called out, instead of a helpful environment. It became a report to your manager meeting or a PSA meeting about deadlines.
  • The three typical stand-up questions were not giving us much information (partly due to the reason above this one). Sometimes work overlapped, sometimes it didn't. I usually did not care much what others worked on or were working on, I could look at our board for that information. What I cared about was what I might need from the team or what I could do to help the sprint move forward. If others were not willing to share and answered the bare minimum for the three questions, it would have required someone (scrum master) to draw information out of each person without seeming overbearing, which can be draining and is not an easy task.
  • Nothing documented from the meeting, nothing comes out of it. For those that were looking to get something out of it, it felt like a mandatory waste of time.
  • As you mentioned, people were late, missed the meeting regularly, or just wanted to chit-chat.

We did the Slack-bot stand-up 2 days a week, but those seemed even more ineffective because not everyone filled it out or read the other statuses.

We ended up moving to a format with a documented agenda that roughly stays the same from sprint to sprint. Each "stand-up" (it became more of a sit-down) we review the purpose of the meeting, pull up the sprint board, and document any actions that come out of it. It became a bit more structured and I think we get a lot more out of it. This does require someone putting together the agenda and starting the meeting by reviewing it. Those that like to chat or stroll in late to the meeting may not like this format. We are working on ways to make this a little less rigid.

I'm not sure why this is the go-to format in most information out there on agile, it relies on all people being onboard and working to get the most out of the stand-up. I think that type of scenario is hard to come by. I would say adjusting to meet your team's needs is the way to go.

 

Thank you for the insight into your team. This just shows that there is no one solution. The traditional Stand-Up is just one form of tool which perhaps was abused or used a little too religiously. I am happy to hear that you found a format that worked for you team, and perhaps everyone should start evaluating how best to make information flow efficiently in their own team.

 

Very common problem

Scrum is Agile, and Agile is "Individuals and interactions over processes and tools". And "we don't need software to solve human problems".

I agree with Martin, Scrum master should work to avoid one-to-one discuss, overtime, useless subjects...

The Yesterday and Today work can be find with Kanban or ticket system, the most important part of Standup is "I need this ressource today", "I need to restart this server" or "I need some help"(dual programming) because exceptions and error should be asked on chat. Face-to-face, eyes away from screen, stand-up position is good for empathy (and health).

 

I actually proposed something similar to my team. We now post our statuses on a slack channel, we’ve been trying a bot which automatically asks people for the status and blockers and forwards answers to the channel. We still do the daily meetings but now it’s mostly focused on discussion that actually needs to happen. We’re a distributed team though so the meeting is via conference call and is time capped. I think that fusion ultimately solves all/most issues mentioned. It is ultimately I think a team norms problem though, regardless of how you do it

 

I've done that before. It's the only option on snow days. Definitely better for keeping things focused, and easier to spin out side discussion (especially when it requires a URL), but I still prefer the face-to-face because there's things you don't pick up otherwise. The way someone says "I'm almost finished" that makes you think there's a month of work left, for example.

Stand up once a day, but feel free to ask those 3 questions in chat whenever there's a natural cadence - first thing after login, just before lunch, and at the end of the day. It helps hold you accountable for your own plans.

 

Don't underestimate the positive effects on team cohesion and individual morale gained from random incidental chatter. It doesn't have to happen anywhere in particular, but if you accidentally kill it entirely then you've lost an incredibly valuable resource.

 

i have to disagree completely. based on my personal experience, these anti-patterns are not based on the format but rather on the people involved....

1) easily solvable. just communicate when the person is back. it's not forbidden to talk during the day to each other. if that happens, search for the why.

2) if that is the case: talk to your scrum master. punctuality is a sign of respect of the other peoples time which directly affects team-dynamics.

3) "that's a lot of detail - can we discuss this afterwards?" solved. or if it affects everybody on the team, the daily is the right time and place.

4) again: someone cough the scrum master cough could act as a moderator.

5) see 4

6) ¯_(ツ)_/¯ if the information is needed for a long time, why isn't it documented somewhere?

Group chat won't fix any of these. for example if someone like to go into deeply technical rambling won't stop that because he has to type them out. it'll probably encourage them...

 

We solved the same issues exactly the way Martin is mentioning.

Meetings do need a good moderation, which leads to a dictator like moderator.

I could imagine really long posts written in an hour by some of the people and others just having not even a sentence, which would make moderation of a written stand-up even harder.

Just my 2 cents.

 

Thanks and I appreciate the perspective. I think sometimes a different format can help direct and remove some of these unnecessary workarounds. We place processes in place because people don't behave the way we want them to behave. In an ideal world where people would just do what we ask, we wouldn't really need checklists and processes and doing things in a certain format.

I'm just proposing an alternative because it's been clear from talking to many closer colleagues that face to face Stand-Ups can be a total waste of time and needs to change. Unfortunately, when I propose change, many are resistant and go back to old bad habits.

 

I totally understand your proposal, and I'm not trying to talk you out of it - if it works for your team, i would be really happy for you :)

The question i always ask myself when i read proposals like these is "would i want to work with a team that works like that?"

 

I like your optimism. I do think these problems are solvable in the way you described, but there is one caveat to all of this: none of this works without team buy-in.

If the team doesn't think punctuality is important and is consistently five to ten mins late what can you do?

Furthermore, even if you have a moderator like a scrum master, I've found most scrum masters to be pretty passive in their approach to moderation, favoring conversations after stand up rather than correcting in the moment. Even the few that do attempt to correct in the moment are often not taken seriously.

I feel like a lot of this kind of reduces to, does your team give a shit enough to respect the rules of standup? In my experience most don't, and I can't imagine most corporate environments getting rid of developers / team-members for being late to stand ups.

 

I agree with Martin, you have more fundamental issues that are the root cause of this issue and a virtual standup isn't going to fix them. All that can do is reduce the 'cost' of your bad standups.

Fundamentally it seems you have 3 problems:

  1. people who do not respect scrum
  2. people who do not understand scrum (which could be the cause of #1)
  3. people who do not respect each other

3 is the most important and if it persist is a sign of a toxic work environment. You said that you brought this issue up but nothing happened. How and who you raised it to is important. Complaining that people should be on time for standup to the team is less likely to get results than getting the team to agree in a retrospective that being late and wasting other people's time is bad and putting it in the 'things to be improve' column or raising it to management that a few peoples conduct is wasting the rest of the teams time. In my experience management hates wasting their precious technical resources time (unless they're the one doing it :P) and will do something. It could be that the answer is to just cancel all standups, if they're not providing value.

 

I know scrum masters, particularly those new to it, can be wary of confrontation, but that's when team rules can really help. Then it's not about that person Vs the SM.

People keep going off topic? Anyone can cough and ask for the conversation too be taken offline. The SM needs to support them however. Or set a timer. Everyone gets 1m or less.

Everyone is late, hold it 5 minutes after the coffee run. Everyone stops for coffee.

There's techniques for everything, but they're all more effective if people know what they are in advance, to help the team police themselves.

 
code of conduct - report abuse