Hacker News Reader

Comment by saidinesh5 | Hacker News Reader

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.

View on HN

> 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/features/hill-charts

https://3.basecamp-help.com/article/412-hill-charts

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.

> 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.

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.

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)

> "Everyone can, but why would anyone do?"

Some of us do care and see the big picture of things, but that mostly limited to tech/product companies/startups, much less so to enterprise employees, or agency-supplied contractors.

I.e. it boils down to incentive alignment, and to a lesser extent professional curiosity.

> "I don't care what you do, that knowledge is a distraction detrimental to my own work."

Agree, so it doesn't matter whether this distraction is done by issue tracker, email, or an actual meeting.

At least in the issue tracker case it's stored in a structured database which I can easily query (even programmatically via API/bots), and much less distractive than in email/meeting.

> everyone can see it on issue tracker

Only if you have a perfect board, no things ever come up out of order, a be everyone has the same idea of granularity. In practice, no, that information is going to be either unclear or wrong.

If your stand up chat updates in slack are on auto pilot the process is working.

If it's not, there should be something to discuss in retro.

Use it as a signal, not the signal.

> 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.

>> 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.

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.

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.

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.

> 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.

Sure, but you are still unlikely to realize that you're blocked by that exactly at the start of your day. Once your blockage has been communicated, likely in the middle of your day, the state will remain until you are unblocked. There is no value in repeating every day that you're still waiting on Outside Vendor. The blocking state has been addressed. It is known that nothing will change until the state has changed.

And it is not like Outside Vendor can update you in an internal stand-up on why it is taking them so long, given that they won't be present, so you're not even getting that value out of bringing it up again.

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...

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?

> 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".

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.

Reply on news.ycombinator.com