At a previous company we successfully implemented most of the ideas in the article (and stayed remote) while encouraging as much synchronous work as we could. I personally find that there are a lot of benefits to synchronous work for junior engineers.
Some examples of the balance we found:
> (async) We required agendas and public documentation of meetings so folks would be comfortable skipping them if they weren't relevant.
> (sync) We pushed for live pair programming when reasonable to encourage learning skills from each other.
> (async) We allowed folks to skip standups if they sent their daily updates out before the meeting.
> (sync) We had virtual office hours so junior engineers had an easy place to get help.
This sounds pretty great tbh. I'm essentially a junior, and I can see this format helping juniors get used to having good habits in regards to thinking forward about what needs to be done with the stand-ups, while giving them enough options for support in the office hours.
> We allowed folks to skip standups if they sent their daily updates out before the meeting.
Once again assuming the purpose of a standup is to "give updates." It's not. It's for the team to collectively look at what they got done in the last 24 hours, and make a better plan as to what they're going to get done in the next 24 hours as a group.
It's not a status update; it's a mini inspect-and-adapt cycle.
We have dashboards for that. We know exactly what our colleagues have been working on in the last 24h (column In Progress), what has been done (column Done). What needs to be done in the future is discussed in planning meetings.
With modern tooling (even Jira helps here), daily standups have zero value.
If you don't have standup how does the PM waste an hour of your workday talking about their pet? That seems to be what standups are for at every job I've had with standups.
In order for this to work, the status updating needs to become part of everyone’s regular workflow. Otherwise the dashboards are never accurate. I worked in a place where people would set aside time weekly to “do JIRA” meaning all other times, JIRA was not an accurate reflection of where the project was. Totally useless.
This is a really good point. This should be a reminder at the top of every stand-up notes document. :)
To clarify why this worked for us: our daily inspect-adapt cycle focused on things that would affect our sprint plan, so if everything was going smoothly we wouldn't mess with the plan. Hence offline updates were ok if there were no changes necessary. Our more general inspect-adapt cycle occured on a weekly basis with sprint planning - which was required attendance. Not quite as agile, but worked in our environment.
Some examples of the balance we found:
> (async) We required agendas and public documentation of meetings so folks would be comfortable skipping them if they weren't relevant.
> (sync) We pushed for live pair programming when reasonable to encourage learning skills from each other.
> (async) We allowed folks to skip standups if they sent their daily updates out before the meeting.
> (sync) We had virtual office hours so junior engineers had an easy place to get help.