There’s stuff we outsource (easy to describe tasks), but the stuff that needs tight iteration loops is so much easier when you can just get up, walk a few meters, and talk about it.
That, by itself, isn't an argument that remote work for a given company will work.
[1] https://thenewstack.io/contributes-linux-kernel/
[2] https://www.cio.com/article/2909736/who-s-behind-linux-now-a...
I'm not saying it's not a good idea to have competing delivery teams. But it's quite expensive.
* Individual parts of the Linux kernel are often developed by people who do work together in an office (e.g. I used to sit with a bunch at Red Hat).
* Top-level Linux folks do meet in person fairly regularly, especially at LF events.
* Collaboration via email etc. is the primary workflow for the kernel, so there's no in-office cabal that has to learn new habits (and likely will resist doing so).
I'm also tired of hearing how silly startups can't do remote, but I don't think I'd hold up the kernel as an example that they could/should emulate.
It’s just poor quality planning and execution.
Your team is just improvising, figuring out as you go, what is exactly that you need to build.
It’s not even Agile. Agile is about tight loop upfront planning, and avoiding last-minute distruttive changes and meetings...
Potato potato. If you can get away with "poor quality planning" in person but not in remote, it doesn't matter what you call it.
If that's the case, you shouldn't be in the business unless you're in a junior/apprentice position (which is fine, one has to start somewhere.)
That's an abomination definition of agile, probably influenced by scrum. In the agile manifesto it says nothing about "tight loop upfront planing", however it does explicitly say[1]:
> Individuals and interactions over processes and tools
> [...]
> Responding to change over following a plan
While that doesn't mean all planning is bad (it isn't and the manifesto acknowledges that), the planning is not the agile part, it's the leftover of the original traditional management, because it is necessary to a certain degree (e.g. for alignment but also for a lot of other business related tasks).
If you're running a pure kanban approach, you don't even plan in tight loops and I had much better experience with that (and a single team lead with a good strategic vision) than I had with Scrum. Scrum is just easier to handle for big (old) organizations and gives developers some protection from bad management.
Sure it might be an abomination, but if we set the rhetoric aside for a minute we should consider the option that the context where Agile is applied isn't just RoR rockin' startups in the Bay. Lets call it dilution perhaps?
Besides, there's context. The Manifesto was drafted in a world still reeling in RUP and floor-wide teams marching towards quarterly releases.
That wasn't sustainable, but neither is "responding to change over following a plan" if that means moving targets every other day. That's a recipe for burn-out, and sprint commitments are sacred.
So yeah, context: respond to change means reassess every some sprint, not pivot 3 times a week.
/s (tongue in cheek people, life's too short for zealotry)