4 ms·

For the last 5-6 years, sending this automated message, once a day, in hipchat/slack/Microsoft teams is what worked well wherever I worked - both semi remote an

For the last 5-6 years, sending this automated message, once a day, in hipchat/slack/Microsoft teams is what worked well wherever I worked - both semi remote and fully remote places: Good morning! Don’t forget to post your update in thread. Be sure to include: 1. What you worked on yesterday. 2. What you plan on working on today. 3. Any blockers or risks you have identified. People usually reply there whenever they start working, and everyone knows what everyone else is working on. In case of blockers, people who can help get a nice reminder of an upcoming meeting, so they can plan their day accordingly. Honestly, the blockers bit was the only useful thing for most of us there, but it is nice to know what others are working on. Then we have a 30-45 minute video call stand up/review/meeting once every week/sprint, to summarise things and to accommodate for the much needed rambling.

torvald 4y ago
I've also have good experiences with this approach. Async by nature, writing it down often helps you actually articulate your problems precisely, and bonus; other teams or stakeholders can skim through the messages getting a situational awareness of what's happening.
randomdata 4y ago
> People usually reply there whenever they start working ... Honestly, the blockers bit was the only useful thing for most of us there What kind of blockers were did you find appearing at the start of work for there to be usefulness derived? I have only ever experienced blocking situations once I am well into the work. And, as tempting as it may be to take the rest of the day off so you have something to tell at the start of the next day, that's not exactly a realistic business practice. Any blockers that do occur are dealt with at the time, leaving nothing unaddressed by the time the next day rolls around. Certainly blockers need to be communicated, but timing them with the start of work seems completely untenable. If they could be foreseen they wouldn't be blockers.
- monster_group 4y ago
  >> Any blockers that do occur are dealt with at the time, leaving nothing unaddressed by the time the next day rolls around. You must not be working with micro-services then. It can take a week just to get permission to call another team's API or a month to get an external vendor to respond to some critical question. Now obviously I am not sitting idle while blocked, but assuming that blocker will be removed by next morning seems quite unrealistic and rarely happens in my world.
  - nfhshy68 4y ago
    I couldn't handle that. At $WORK we encourage teams to unblock themselves. If that means you need to work on someone else's codebase off you go. Territorial people don't last long here. I can't remember the last time I was really blocked by an other team. It's incredibly rare. They either help or get out of the way.
    - monster_group 4y ago
      It's not about being territorial, it's about ownership. I assume you work for a small company. At Big Co. there are thousands of services and APIs. You can't give default permissions to everybody to call every API. That would be a giant security lapse. Other teams let you modify their code but only after they thoroughly understand what you need to modify and what is it that that you are tying to do. They own the code and run in production. So it makes sense for them to critically evaluate whether you should be allowed to do what you are trying to do. All of that takes time and hence multi-day blocker.
      - nfhshy68 4y ago
        Not that small, 2k devs. Generally we don't go walking through other teams code bases unless we have to and we usually consult with the team before doing stuff. They just don't let their roadmap block our roadmap. We don't use microservices. That helps a lot. We also have teams that manage infra. We do own the code we deploy but anyone can jump in and help if a fix is needed.
  - 4y ago
- saidinesh5 4y ago
  Oh day to day blockers, especially when working on multiple things in parallel and you wait on someone else for some tasks. From our logs, some of our last few blockers were: 1) Waiting for someone review and merge a pull request so something else that depends on that can be sent for a release. 2) Some architectural code changes that needed to be discussed with the person responsible for the module before i go ahead with the implementation. 3) Someone waiting on me to finish the CI setup so they can deploy their project 4) Us waiting on external client for more input, so our CEO can go nag them for more requirement updates. 5) Me hoping the someone can fix the frontend code because i was frustrated with my (lack of) CSS knowledge the previous day...
  - randomdata 4y ago
    None of those will come up at the beginning of the day. They are impediments that will only be revealed during the course of the work. Are people refraining from sharing important knowledge as it comes available so that they can grasp at something to share the next day, perhaps because reciting "no blockers" each day grows incredibly tiring? If so, how is that beneficial to the team being left in the dark for longer than necessary?
- commandlinefan 4y ago
  > What kind of blockers I've worked under that "today/tomorrow/blockers" regime before and never once, in the years we labored under it, did anybody report a single blocker besides "my computer crashed, waiting for IT to fix it".
nivertech 4y ago
> 1. What you worked on yesterday. everyone can see it on issue tracker > 2. What you plan on working on today. everyone can see it on issue tracker / Kanban board / etc. > 3. Any blockers or risks you have identified. for any blocker/risks I'll encounter, I'll send an email (and file bug/issue/ticket) immediately - no need to wait until the next morning. Why do we need to use tools that less (or no longer) technical people can understand, if we still required to duplicate this data in email (or god forbid in actual meeting)? This only makes sense under SDLCs which don't require detailed task breakdowns, like RUP, mini-waterfall, or Shape Up. But Shape Up provides some good solutions for risk management/status updates (e.g. Hill Charts [1]) without going down to daily standups. -- [1] Hill Charts https://basecamp.com/shapeup/3.4-chapter-13 https://basecamp.com/shapeup/3.4-chapter-13 https://basecamp.com/features/hill-charts https://basecamp.com/features/hill-charts https://3.basecamp-help.com/article/412-hill-charts https://3.basecamp-help.com/article/412-hill-charts
- pjmlp 4y ago
  Not the OP, but I can easily answer. No matter how often it gets repeated, not everyone bothers to update the board, while for some psycological reason most answer on messaging apps.
- whent 4y ago
  > everyone can see it on issue tracker I don't think this is necessarily true. If an engineer is blocked on a difficult problem for a day they don't have time update issue tracker to say they are blocked.
  - nivertech 4y ago
    I personally mostly worked under SDLCs were the developers have autonomy and do task breakdown by themselves, rather than by being assigned by PM/SM (except bugs/support tickets). If that's a psychological issue, not sure daily standup can help here, unless the PM/SM will try to interrogate that person, or try to guess if somebody is blocked.
- usrusr 4y ago
  Everyone can, but why would anyone do? Our default state is "I don't care what you do, that knowledge is a distraction detrimental to my own work. Ideally I'd want you all to work, if you have to, when I don't". The rituals exist to break down those walls, even if just a little. It's best illustrated by the author's failure indicator "If the manager or “scrum master” can’t show up, the stand-up doesn’t happen". That's so very telling. The alternative approach of the chat reminder tries to minimize friction (short writeup is so much easier to consume than trawling The Board) instead of forcing everybody to be present (and presumably listen, which does not necessarily happen)

torvald 4y ago

I've also have good experiences with this approach. Async by nature, writing it down often helps you actually articulate your problems precisely, and bonus; other teams or stakeholders can skim through the messages getting a situational awareness of what's happening.

randomdata 4y ago

> People usually reply there whenever they start working ... Honestly, the blockers bit was the only useful thing for most of us there What kind of blockers were did you find appearing at the start of work for there to be usefulness derived? I have only ever experienced blocking situations once I am well into the work. And, as tempting as it may be to take the rest of the day off so you have something to tell at the start of the next day, that's not exactly a realistic business practice. Any blockers that do occur are dealt with at the time, leaving nothing unaddressed by the time the next day rolls around. Certainly blockers need to be communicated, but timing them with the start of work seems completely untenable. If they could be foreseen they wouldn't be blockers.

monster_group 4y ago
>> Any blockers that do occur are dealt with at the time, leaving nothing unaddressed by the time the next day rolls around. You must not be working with micro-services then. It can take a week just to get permission to call another team's API or a month to get an external vendor to respond to some critical question. Now obviously I am not sitting idle while blocked, but assuming that blocker will be removed by next morning seems quite unrealistic and rarely happens in my world.
- nfhshy68 4y ago
  I couldn't handle that. At $WORK we encourage teams to unblock themselves. If that means you need to work on someone else's codebase off you go. Territorial people don't last long here. I can't remember the last time I was really blocked by an other team. It's incredibly rare. They either help or get out of the way.
  - monster_group 4y ago
    It's not about being territorial, it's about ownership. I assume you work for a small company. At Big Co. there are thousands of services and APIs. You can't give default permissions to everybody to call every API. That would be a giant security lapse. Other teams let you modify their code but only after they thoroughly understand what you need to modify and what is it that that you are tying to do. They own the code and run in production. So it makes sense for them to critically evaluate whether you should be allowed to do what you are trying to do. All of that takes time and hence multi-day blocker.
    - nfhshy68 4y ago
      Not that small, 2k devs. Generally we don't go walking through other teams code bases unless we have to and we usually consult with the team before doing stuff. They just don't let their roadmap block our roadmap. We don't use microservices. That helps a lot. We also have teams that manage infra. We do own the code we deploy but anyone can jump in and help if a fix is needed.
- 4y ago
saidinesh5 4y ago
Oh day to day blockers, especially when working on multiple things in parallel and you wait on someone else for some tasks. From our logs, some of our last few blockers were: 1) Waiting for someone review and merge a pull request so something else that depends on that can be sent for a release. 2) Some architectural code changes that needed to be discussed with the person responsible for the module before i go ahead with the implementation. 3) Someone waiting on me to finish the CI setup so they can deploy their project 4) Us waiting on external client for more input, so our CEO can go nag them for more requirement updates. 5) Me hoping the someone can fix the frontend code because i was frustrated with my (lack of) CSS knowledge the previous day...
- randomdata 4y ago
  None of those will come up at the beginning of the day. They are impediments that will only be revealed during the course of the work. Are people refraining from sharing important knowledge as it comes available so that they can grasp at something to share the next day, perhaps because reciting "no blockers" each day grows incredibly tiring? If so, how is that beneficial to the team being left in the dark for longer than necessary?
commandlinefan 4y ago
> What kind of blockers I've worked under that "today/tomorrow/blockers" regime before and never once, in the years we labored under it, did anybody report a single blocker besides "my computer crashed, waiting for IT to fix it".

nivertech 4y ago

> 1. What you worked on yesterday. everyone can see it on issue tracker > 2. What you plan on working on today. everyone can see it on issue tracker / Kanban board / etc. > 3. Any blockers or risks you have identified. for any blocker/risks I'll encounter, I'll send an email (and file bug/issue/ticket) immediately - no need to wait until the next morning. Why do we need to use tools that less (or no longer) technical people can understand, if we still required to duplicate this data in email (or god forbid in actual meeting)? This only makes sense under SDLCs which don't require detailed task breakdowns, like RUP, mini-waterfall, or Shape Up. But Shape Up provides some good solutions for risk management/status updates (e.g. Hill Charts [1]) without going down to daily standups. -- [1] Hill Charts https://basecamp.com/shapeup/3.4-chapter-13 https://basecamp.com/shapeup/3.4-chapter-13 https://basecamp.com/features/hill-charts https://basecamp.com/features/hill-charts https://3.basecamp-help.com/article/412-hill-charts https://3.basecamp-help.com/article/412-hill-charts

pjmlp 4y ago
Not the OP, but I can easily answer. No matter how often it gets repeated, not everyone bothers to update the board, while for some psycological reason most answer on messaging apps.
whent 4y ago
> everyone can see it on issue tracker I don't think this is necessarily true. If an engineer is blocked on a difficult problem for a day they don't have time update issue tracker to say they are blocked.
- nivertech 4y ago
  I personally mostly worked under SDLCs were the developers have autonomy and do task breakdown by themselves, rather than by being assigned by PM/SM (except bugs/support tickets). If that's a psychological issue, not sure daily standup can help here, unless the PM/SM will try to interrogate that person, or try to guess if somebody is blocked.
usrusr 4y ago
Everyone can, but why would anyone do? Our default state is "I don't care what you do, that knowledge is a distraction detrimental to my own work. Ideally I'd want you all to work, if you have to, when I don't". The rituals exist to break down those walls, even if just a little. It's best illustrated by the author's failure indicator "If the manager or “scrum master” can’t show up, the stand-up doesn’t happen". That's so very telling. The alternative approach of the chat reminder tries to minimize friction (short writeup is so much easier to consume than trawling The Board) instead of forcing everybody to be present (and presumably listen, which does not necessarily happen)