Decouple your planning cycles and development cycles. You develop at a constant pace, release whenever it is time/convenient to release. You plan regularly.

Planning is hard. Not doing it is not a great plan. Conflating development cycles and planning cycles, which is what a lot of teams end up doing with sprints, either sets the pace too aggressively or not aggressive enough. If it's too aggressive you end up shipping stuff that isn't ready. If it's not aggressive enough, you end up sitting on ready to ship code for too long.

In a company with multiple teams, planning gets harder. Especially if they span multiple timezones. Company sprints are a thing in some companies. But it's not necessarily very effective or scalable.

Calendar driven planning cycles where you ship whatever is in a shippable state is much more scalable and predictable. A lot of large OSS projects practice this (most of them) and it works in large companies too. It allows teams to self organize around known deadlines and work towards them.

That doesn't mean there is no planning but it is acknowledged that plans sometimes don't work out and that that's generally not a reason to stop a release train. If some planned thing isn't ready, park it on a branch and try to get it in the next time. Many OSS projects are very strict on this actually and ship regular as clockwork at a scale and quality level that puts most enterprise teams to shame. A lot of large companies that are typically involved with such OSS work as well do this internally as well. They are too large to orchestrate company wide sprints. So they rally around the calendar instead.

It doesn't actually exclude some teams in such contexts using e.g. Scrum or other agile methodologies. It just doesn't require it. And if you know your agile history, a lot of the Agile manifesto signees were very much into teams electing to use an Agile methodology rather than that being imposed, like is the practice in a lot of companies. It's just that a lot of OSS teams don't seem to bother with that.

One of the biggest mind-shifts for me moving from senior dev to lead was realising that technology is much less of an issue than people. The impact of good communication leading to people understanding and agreeing on what they are working on is overwhelmingly greater than the technology choices we devs typically spend our time arguing about.

Without contradicting "in general", my anecdotal experience is that even well-oiled teams with good internal communication and team spirit can have bad technologies that end a business.

You may well be correct about the general case: I've not witnessed cat-herding, the closest was managment constantly chasing new shinies and one time forgetting to tell the devs about the latest change.

I was absolutely only speaking “in general”. Even with 20 years in the industry my experience can only be anecdotal given that I only had time to work with fewer than 10 companies. :)

That said, I suspect a bad technical decision may have people and communication causes and not fixing the problem once it is apparent is definitely rooted in these.

Technical debt and leadership vacuum are both interesting and intertwined hard problems.

> With all the conservative movements that are going on in the world right now, I really hope we don’t go back to micromanaging as a counter movement to agile. That would be exhausting.

Conservatives are more likely to prefer decentralised decision-making, I would say. At least nominally.