> 3. Daily, standup-like. Keep it short if there isn't a topic that affects everyone. Be fucking ruthless about this. If someone starts digging down into detai

> 3. Daily, standup-like. Keep it short if there isn't a topic that affects everyone. Be fucking ruthless about this. If someone starts digging down into details that only affects them or one other person, postpone that discussion - otherwise, your standups will balloon into hour-long semi-pairing sessions while the rest of your team's attention wanders. And ensure that the rest of your team is empowered to call that out, too - "Can we do a sync about <Topic X> after standup?" > (Some people also suggested pair programming. If it works for you, great, but I am terrible at it. Hard to explain, but coding and speaking are two very different things for my brain. I can't write good code while talking about it, and the whole thing is very stressful for me. I prefer to discuss code asynchronously or on Slack). I find myself having trouble here, too, but one thing that helps is not feeling the pressure to be talking and/or typing and/or reading all at once, for a long time. Allow yourself and your pairing partner to just sit quietly and think during pairing. I also "cheat" - before pairing with someone to support them on a problem they're having, I look at the code myself, first, and start diagnosing things. This prevents the issue of sitting there and staring blankly at code, hemming and hawing while you're trying to explain your thought process at the same time you're having the thoughts.