You may have hit on a carrot.
Team building is people skills, and it's about finding well springs of motivation, soft skills, getting people talking to each other, making sure people aren't forgetting things.
Unfortunately people coming from an engineering/programming mindset can go the other way: management is about making lists, and getting people's names on those lists. Management is about making processes, and making people conform to those processes.
I'm not saying those aren't useful tools, but they need to be seen as that. Tools. Means to an end, not ends in themselves.
Most software developers want to do good work. They want to write code to make things happen, because that's what they were trained to do. Original agile was about trying to liberate that instinct from the crushing weight of corporate processes so that teams of developers could self-organize to do the things they generally naturally want to do.
I don't recognize that in SCRUM based teams today.
And as for your point, I do think that remote work makes things harder, and I've yet to see a remote team that fires on all cylinders. But for years I worked on hobby projects with people who I never met face to face and it was fine. So I dunno.
The way I see it is businesses can have it one of two ways:
They can acknowledge that remote work is fine and allow their teams to work from wherever and figure out timezone differences and async collaboration workflows
Or
They can decide that remote work doesn't work. Then they must stop hiring expensive remote consulting firms and cheap offshore remote teams. They also must stop spreading teams out across multiple regional offices across North America
It is absurd to make people commute to an office building only to have people dialing in to meetings from other office buildings in other countries anyways, and then say remote work doesn't work
But yes, mixing remote and on-premise and expecting it to produce improvements is broken. Or being done for the wrong reasons.
I seem to have landed myself at a job like that just recently, in hopes of sparking joy with in-person collaboration again. I am not happy about it.
A lightweight process works well when you have engineers that are all of the following: - experienced - competent - understand their problem domain - actually care
In other words, a team of strong engineers (and a great, accessible product owner).
What I’ve found is that lightweight agile fails without a lot of oversight and frequent checkins, for anything else.
So SCRUM is SE training wheels because it forces a cadence, gets engineers to start breaking down work, and estimate; but the cost is that it holds-back great engineers with all of the (stifling) ceremonies.
I’ve gently nudged my risk adverse tech-lead to consider moving to Kanban now that his team is pretty strong now.
