Hacker News Reader

Comment by opportune | Hacker News Reader

I like daily syncs if they are done quickly (<15m), and if people are working on different-enough things that they don't really know what their teammates are working on. Because that way you can unblock each other and actually use agile the way it was meant to be done in the face of underestimated tasks or changing requirements

View on HN

With a visual system like Kanban, it's quite easy to see what other people are working on. The problem I have with daily syncs is that it's redundant to information already available, and you're forcing people to "meet" without any value. A lot of conversations in that "sync" are just noise to a majority of participants. It's kind of like a bunch of people talking to a wall unless you happen to be associated directly with the update – which is more rare.

In my experience, the need is to provide a clear method of communication and ability to unblock one another. A Kanban board is perfect for this, as well as committing to a definition of done.

Anything else... is very wasteful in my experience.

For me, what is in a Kanban board is not enough info to be able to determine when I can help unblock other people on my team. I think this probably depends on how you use project-management software and what your team works on; for me, a teammate's item might list "Create pipeline to process dataset Y on hourly basis". If they are running into issues, I don't know if it's something I've seen before with that dataset, or that pipeline tech, or the processing script, or end-to-end latency, or XYZ. A standup helps clarify things somewhat

Also if a teammate is actively working on something that is a downstream dependency of something I am working on, then I can passively learn about requirements and expectations for my own work, become aware of issues ahead of time, etc.

Initial reaction:

1. For transparency any member of the team can identify blockers in Kanban by putting them in the blocked column. 2. If you're blocked, and running into issues, you'd reach out to anyone that can help you. Why would you wait for a standup or "talk to the wall" for that? Just be proactive.

Dependencies should be known before committing to a scope of work (iteration) with the team. Planning stage (minimal time investment for scope of work definition) vs committed work stage (in progress iteration).

In my experience anything more than 10 minutes is a smell. It typically means you've got stories that are too big, have unaired problems, that you dive into implementation instead of just syncing briefly, or the team has too many people.

I personally think brief dives into implementation / explanations of issues is fine. If something takes only 5 minutes to discuss between everyone, I'd rather do it while I'm already in a meeting, and having the whole team there helps opinions get heard. But this is just personal preference

My preferred way to handle this is to explicitly acknowledge that the meeting isn't just sync-up, it's really two meetings:

- sync up / status is 15 mins. Any implementation discussion gets put in the parking lot

- once we've gone around the table, the rest of the meeting is handling the Q&A / parking lot we parked during the status discussion. Anyone not directly concerned by it is encouraged to leave, get out and be productive!

This gets you the double benefits of interrupt coalescing (a single regular interruption instead of 2 smaller ones where one is an irregular surprise), and preserving the quickness and relevance of the stand-up, as it's really just the first 10-15 minutes of the calendar slot, after which you're good to leave.

Reply on news.ycombinator.com