It would seem reasonable to me if it were "no meetings with more than 5 people" or something, depending on how their product and development teams are structured. But... three is verboten?
This generalization is clearly not strictly true, but people stick to it anyway without thinking.
Who should get together, exactly? When should they? Why? What is the goal, and are they meeting that goal?
Almost every single recurring meeting I've been in has not considered these things seriously. It's just generic people making a generic meeting to talk about generic things to make it feel like work is getting done, when usually, at the end of the meeting, you realize the entire meeting could have been an e-mail.
The only useful purpose of a generic, purposeless, recurring intra-team meeting is to reinforce social working relationships. They aren't going to solve a bug or ship a new feature or solve a design decision in one of these meetings. They exist solely to talk about work without doing work, because the interaction between humans smoothes the social dynamics of doing work. But nothing actually gets done.
* Engineers rushing to wrap up for the sprint (stress and decreased quality is bad for morale)
* Engineers getting monitored and measured on a task level since all tasks need to be estimated (micromanagement, lack of trust)
* Agility is decreased since everything needs to be planned (lack of autonomy)
Sprints tend to become “phony deadlines”, a key component in “Teamicide” (from “Peopleware”).
I’ve been trying to come up with benefits but I’m coming up short. Wish someone could tell me!
I get the sense most managers stick to scrum and all the unnecessary overhead mainly because they are creatures of habit. Pushing a non-scrum system in an organization that fully embraces it is hard (especially when senior leaders enjoy the micromanaging aspects of it).
That's in the unicorn-rare case that you're in an org that can do "agile" right, but still has the problem of clueless stakeholders shitting everywhere and no discipline or expectation that PMs are empowered to tell them (politely) to fuck off without the support of this kind of framework. Otherwise, yeah, they're not that useful. You can track velocity and such without them, so that's not a good reason to have them.
The dysfunction can certainly go the other way (the stakeholders are competent and reasonable, but the teams are broken) in which case I'd not expect sprints to be helpful, and possibly abusable in the ways you suggest.
> if a team can only plan a couple of weeks ahead, how should stakeholders be able to plan?
When it's done right (ha, ha, ha) there absolutely is long-term planning, but adjustment of priorities sprint-to-sprint (which should be happening due to stakeholders and product managers and such making decisions, since they set those priorities) can affect that—the flux in long-term planning should be a reflection of the reality of choices made sprint to sprint that differ from the original plan, not due to a lack of planning, so that no-one's surprised when the mark that's hit in six months differs—for the good reason that the direction of the project was modified in-flight—from the one that was originally targeted. The entire point of sprints is to allow flexibility without day-to-day thrashing, while also capturing the effects of each sprint's work on that longer-term planning to avoid big surprises farther into the project.
Again, that's all if it's done correctly, and if the situation even warrants using sprints in the first place. Which, every now and then all that's true, but I'd not say it's the norm. I don't think most orgs even think very hard about what the point of having sprints is, before imposing them.
I'm beginning to think most HN posters do not talk to their co workers outside scheduled meetings.
Like seriously, I don't even have stock or stock options, if the company makes more money, it's someone elses choice whether I get anything more out of it, or whether I get fired because my role doesn't fit within their new structure.
I have no idea how they make policies like these work with business partnerships though. I could live with a rule like this internally, but it's hard to get time on a client or partner's calendar and, when you do, recurring meetings let you reserve it.
Of course, if it's just a 5 minute status update you should just send a memo.
> Teams that work together on the same project should regularly get together in a synchronous conversation.
This doesn't prevent that. It seems that it only prevents you from automating the decision on when to do that. If you need to synchronize, you can. However, if you don't, there is no need to hold a meeting. But people tend to make meetings opt-out rather than opt-in. This seems to enforce an opt-in approach first.
- any team member can propose an ad-hoc whole-team meeting at any time.
- any two team members can propose an ad-hoc whole-team meeting at any time.
- any team manager can mandate an ad-hoc whole-team meeting up to four times yearly
The Shopify rule is "no team member and no manager can mandate a recurring meeting with more than one other person."
Also, I would expect the management to be the ones to care the most about hoe team functions overall. They should be the ones to notice communication is dying or that we are splitting into subgroups or that someone is isolated work wise (unable to get answers to questions or whatever).
Team dynamic is literally work of leadership, so they should be able to decide on meetings.