Hacker News Reader

Comment by 40acres | Hacker News Reader

I've found the best way to avoid interrupting engineers is to have a daily sync (a.k.a stand up meeting). My team meets for 30 minutes each morning to give an update, have Q&A, and discuss priorities and issues. We're a small team (3 developers) but it works perfectly because folks either had their inquiry answered earlier in the day or can execute good judgement to try to figure it out and if not ask about it tomorrow. We all receive tickets and if it's critical enough we'll meet to devise a plan. Under this scheme we are rarely interrupted and have been grinding through features all summer.

View on HN

A daily sync is way too often on teams that know what they're doing. It feels like busy work and is a waste in throughput and stress. Once a week, with committed items with a true definition of done is all that is needed. Anything in-between should be facilitated by the team members to unblock each other. Anything else is just stakeholder over management and or inexperienced teams.

edit: at the most, I think async are passable via slack or something similar. Otherwise all data on this can be easily done via a Kanban board.

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

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.

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

> Anything else is just stakeholder over management and or inexperienced teams.

At Pivotal we see the PM as part of the balanced team. The PM, just like designers and engineers, will have the daily standup, weekly retros and planning meeting together. The goal of the standup is to share what of interest happened yesterday, if help or opinions are needed and discuss pairs for the day. Sometimes discussions start about topics mentioned in the article where it's crucial to have the PM there.

Standup should usually be around five minutes. That's the reason it's not a sit-down meeting.

My reaction to this would be the work committed to was unclear. A task should have all the items clarified before being committed to. If there are questions throughout the iteration then the work was poorly planned. It should be a rarity that a task was ill defined.

My view is that a PM is available as a resource to clarify as needed. Meetings between the "doers" of a team and the PM should not be forced, especially daily. This leads to micromanagement and changing requirements too often.

But alas, everyone has a different philosophy. :)

Changing requirements is fine, though, so long as there's a discussion. Engineering explains what it might involve and the PM gets to decide if they think the change is worth it. Generally once a week is fine. Changes at sub-weekly cadence suggest deeper problems that need to be sorted out.

My personal preference is for very fine-grained stories rather than giant chunks of acceptance criteria. The latter tend to turn into week-long wanderings and get edited over and over. Whenever I've been able to I've coached PMs towards smallest possible units of value.

To clarify my definition:

Changing requirements should only happen outside the scope of committed work; otherwise you're building churn, poor features, and poor code.

This lever of "committed work" can be adjusted per team (1 week, 2 weeks, 4 weeks, and so on).

It seems you agree with my view of a minimum of 1 week before it can change.

I agree also with fine grained tasks/stories. As small as possible and as consistent as possible. They should all have clear DOD's though.

Definitely agree with smallest possible units of value (that also varies per a person).

Yes, I think we basically agree. Normal practice at Pivotal is to hold weekly Iteration Planning Meetings (IPM). Most product managers aim to keep around 2 weeks of ready work in the backlog, based on what Tracker is predicting. Anything more than that will be usually be cards in the icebox.

Perfect! Music to my ears.

>Once a week, with committed items with a true definition of done is all that is needed. Anything in-between should be facilitated by the team members to unblock each other. Anything else is just stakeholder over management and or inexperienced teams.

Finally! A sane voice appears!

> daily sync (a.k.a stand up meeting)

*status report

> My team meets for 30 minutes each morning

That is far too long IMO and IME

> We're a small team (3 developers)

30 mins for 3 devs...

It's not just a status report, it's a casual discussion about the work. We collaborate on strategy, talk about any issues, and coordinate with each other. We front load information sharing so that it's rare to have to share information (ie. interrupt) at other times in the day.

Reply on news.ycombinator.com