There's a reason startups run circles around not-so-agile but yet self-styled agile corporate teams: mental agility. Mental agility is mostly found in young pe

There's a reason startups run circles around not-so-agile but yet self-styled agile corporate teams: mental agility. Mental agility is mostly found in young people and sometimes in older people that choose to stay humble and keep an open mind about their own abilities and skills. I like to think about myself as such; though if I'm honest, I'm more conservative than I used to be. It's disgusting how much value I get out of young people on my team willing to learn whatever and unburdened by experience vs. grizzled veterans with a lot of certificates and a rigid/dogmatic mindset that regard anything new as a threat rather than an opportunity to learn. I find it very energizing to be around such people. I've worked with veteran teams as well (like more than half > 40) and there were some spectacularly cynical types on those teams sucking all energy out of any room they entered. Given the demographics of developers (doubling numbers of programmers every five years), finding yourself on such teams is relatively rare. I've worked with numerous people that had certificates for this and that and rarely came away impressed by their skill sets. Also, I shook Ken Schwaber's hand (one of the people behind Scrum) at the end of a 2 day workshop many years ago that made me a "certified scrum master" and him probably a little bit wealthier. So, I know how hollow that phrase is. Licensed to wield multi colored post-its and sharpies, basically. That was one of the least agile companies I've worked with trying to be agile. No mental agility whatsoever at the senior level. But they compensated by sending all their senior engineers to trainings like this so they could virtue signal their supposed agility. These days, I keep my teams agile mainly by keeping them small. Small, remote teams don't need a lot of process and can resolve issues by simply communicating with each other. Partitioning teams and keeping the team boundaries informal removes a lot of need for process. In person meetings are rare with remote teams anyway. So post-its and sharpy wielding scrum masters have no place in such teams. We do have online meetings but I limit them to once a week for engineers and keep them informal: I want people to talk, ask questions, debate, and bond in the rare meetings we do have. Standups in front of a web cam are even more pointless than the zoned out de-caffienated cluster of extremely bored engineers droning on about what they did or did not do yesterday. So, not a thing that I do. I've always hated those type of standups and lots of developers I respect a lot seem to feel the same. I never got much value out of those. People waiting for such meetings to raise important issues are actually wasting time instead of being agile. Reach out asynchronously as early as convenient. Lots of issue resolution and problem solving does not require having any meetings whatsoever. And when there is a conflict that requires a meeting, have it 1 on 1 as early as convenient and don't burden the rest of the team with unresolved conflict. The best resolution is often just asking "do you have time for a quick call about this?". Waiting for some arbitrary meeting to happen turns those meetings into synchronization bottlenecks. The longer they are or the more you have of those, the worse the problem is. You solve synchronization bottlenecks with asynchronous processes and not with a "stop the world" point in time where people "meet" and are collectively not productive. Some OSS projects function entirely without meetings or meet very rarely. And some of those projects have orders of magnitudes more commits, developers, and change happening than most corporate "agile" projects. So, it can be done and IMHO is actually optimal and more agile.