I find a slack channel called #status-updates works wonders. It persists, it's much faster to consume, it's searchable, and you don't have to read it if you don't need to.
- 45 minutes: it should be 5-10 minutes, 15 on a bad day, and literally never 45.
- 15 people: this is probably just too many people in a single standup. Based on my experience, it's quite likely this can be split up into 2-3 teams that can have more autonomy, and meetings like standups will become far easier to run and far more efficient.
14 doesn't seem crazy to me. And splitting this team up runs into some issues as well.
Do you now have 3 tech leads who acting as pm reporting to the head pm? Do you try to split up the code base? How do you split up QA/Production Champion/Devops? All these decisions seems to have drawbacks.
But it always devolves into "what I did..blahblahblah" because both PM/Managers want an accounting and people feel like they need to justify themselves (as you mention).
"what am I doing today" -- not sure yet
I do those every day, they rarely last more than 20 minutes.
seems like your standup team is too big.
Another criticism of a controversial tech that is actually a pitch for a product. It's a Hacker News staple.
Maybe I'm just getting too cynical.
Edit: source, https://www.buzzfeednews.com/article/pranavdixit/google-bans...
Other workflows work asynchronously. E-mail, IM and the like are great for these.
Post-War America erred on the side of meetings, forcing asynchronous flows into artificial bottlenecks. Silicon Valley seems to have over-corrected, replacing ten-minute meetings with full-day Slack threads.
Trying to force asynchronous flows into synchronous constructs introduces unnecessary delays, as the slowest process sets the pace. It also increases overhead, since resource C is occupied while A and B sync. Trying to force synchronous flows into asynchronous constructs introduces mistakes through mis-communications. It also increases overhead, since an additional layer of verifying everyone got critical information is introduced.
Seems like a master decision record in confluence, discussing finer points in a private slack channel, and demo and tie-breaking plus sync with busy or non text thinkers with ad hoc video meetings works well together. Another thing is quick prototypes of ux or architecture designs in codesandbox.
These all work well, but it would be great to have less overhead. Even on a small team though there are so many gaps it feels impossible to reconcile without all these.
Anyone have a team decision making workflow for spinning up new projects that is more efficient?
Written/async communication sounds great in theory, but it takes the discipline most people don't have. Especially when working remotely.
At least during a call you can confront people directly.
Typically, though, goals are unclear and constantly shifting. From that flows multiple tasks that are all high priority up to the point they suddenly become irrelevant. In such an environment communication needs to be continuous. Continuous communication is by necessity synchronous.
Zoom's technical details are a problem too.
