Hacker News Reader

Comment by panqueca | Hacker News Reader

I wonder how I could apply those tips on a daily software engineer scrum meeting.

Cancel your daily meeting and have a single weekly update meeting. Have each project’s lead write down what progress they made last week, risks, problems, wins, and what they’ll expect to do next week.

Spend the first 10m of the meeting silently reading these updates. Then have each lead verbally give a condensed summary of their update (DONT ALLOW them to read verbatim) with a focus on the information that everyone on the team really needs to know, especially problems and blockers. Make sure they do verbally say what their next incremental unit of progress will accomplish and when they expect to have it done.

You can do “people” instead of “projects” for smaller team.

Oh, and keep all the notes and updates in a single shared doc that you add to the top of each week.

I've found you can say just about whatever you want during a scrum meeting. Most people are tuned out and barely listening. Try repeating what you said yesterday. Odds are nobody will notice. If they do, they won't call you out on it anyway.

I often worry about repeating something when I'm working on the same exact thing for days but at some point realized that while I am actually listening to what other people are saying, I'm not internalizing it or taking notes or anything, and it'd probably take 3-4 days in a row of exactly the same update from someone for me to actually notice. And even then it'd probably be more just nonspecific deja vu rather than "oh they repeated that point about that one project."

If you find yourself in a Scrum project the best move is usually to quit and/or burn the place down

Maybe I'm the minority but I like the daily check-in, everyone talking about what they actually accomplished yesterday compared to what they want to accomplish today, having just 2-3 weeks of narrowly scoped work to think about, etc.

I think it can be a very good environment in which to train juniors and mid-level folks provided they are shielded from all the PM/lead/manager type meetings that tend to go along with it.

I mean, there is the whole scrum shebang (along with “scrum masters”, charts, etc.), which I had an “opportunity” to try multiple times before and hate with passion.

And then there is just a daily eng standup with no bs involved, which I like and found it useful if done properly (aka no going on off-tangent stories that have little relevancy for everyone else). We just join the meeting, all give status updates, ask any questions or talk about whatever is needed to be discussed to move forward, and that’s it.

Super useful, fairly informal, no time wasted. For a team of 4, those daily meetings would take us 15-20 minutes at the very most, and that’s accounting for questions/discussions. Often enough, they would be under 10 mins.

I have found the usefulness of the "standup" goes down hill as more non-engineering members are included. Some companies keep it engineers only. Other companies add every PM and tangentially involved manager, director, VP. More than half of my standup is full people not directly working on the project who are just there for visibility. It's insane.

And because of company culture, these mostly-observers are asked for and provide updates. Most of them are not relevant.

Agreed with your take, which is why i specified eng-only daily standups.

If we need non-eng people in a meeting on our team, it would not happen in a daily meeting (barring very rare one-offs). If there are as many non-eng people in a standup as you say, I dont see it being as anything but an excruciating exercise in patience.

Luckily for my team, we dont have a companywide rule on how daily standups should be held (or whether they should be held at all; on my previous team within the same company we did them every other day). So as long as the team manager is fine with the engineers on the team in terms of how they want to run daily standups, there is no problem.

Reply on news.ycombinator.com