Matches my experience well. Scrum works OKish in small teams depending on how mature their tech-lead and product owners are. It seems the default in consulting

Matches my experience well. Scrum works OKish in small teams depending on how mature their tech-lead and product owners are. It seems the default in consulting companies where tech consulting companies work with non technical customers. I've seen a few good examples and also some really bad examples of its application. As soon as you scale scrum to organization wide, you get inter team communication challenges for which Scrum has no clear solutions (because its a team methodology and not company methodology). Once you have multiple teams that need to align their plannings to get stuff done, inter team dependencies become a bottleneck. Add a few external teams to the mix and you get a perfect storm of conflicting interests, miscommunication, politics, etc. Having a lot of dependencies between scrum teams also means you get a lot of decision making lag. Scrum teams have two issues: they work in sprints with some fixed length and you can't introduce new work during a sprint. If either is not true, you are not doing Scrum. When you have a graph of interdependent scrum teams, the lag you build up to get anything done is basically proportional to the path length through the graph. The bigger the org chart, the slower things get and it adds up quickly. The longer the path, the more planning and implementation sprints are involved in each team along the path and the more chance there is for things to get lost in translation. Beyond 3 vertices, the whole thing starts looking like a very chaotic waterfall style process where it takes months/years to even agree to do a thing. I speak from experience. The most dysfunctional thing I've seen on this front was Nokia flying in teams from three continents to have a bi-monthly sprint planning about 12 years ago. That worked just about as well as you can imagine (i.e. not at all). You needed to get your requirements scheduled 3-4 months in advance to stand a chance in hell of anything happening under 6 months. I'm talking critical stuff getting de-prioritized because one or more teams involved got other priorities imposed on them and thus had to say no. One of two things happens in such organization (usually both): 1) things get escalated to VP level management, a lot, and there is a lot of politics with lots of egos clashing. 2) teams eliminate dependencies to each other to speed things up (i.e. they reinvent wheels they could have reused just so they don't have to deal with each other). Both are bad for productivity and cost. The way out is to bypass middle management, ignore the process (on both sides) and establish direct lines of communication with engineers in different teams. Once you have that, pragmatic decision making can actually happen. At this scale, middle management should just not get involved with day to day engineering decisions and instead enable the day to day interactions and smooth out any inter-organizational bottlenecks. Most of the big companies mentioned in the article are not great at this either. E.g. the reason Google has so many chat tools is because they have teams working against each other rather than with each other.