What Scrum Actually Looks Like at Enterprise Scale

Most Scrum explanations are written for a team of 5–9 people building one product. That’s fine, but it’s not what Agile looks like inside a company like Bosch, where you might have hundreds of development teams working across dozens of products that all need to ship together.

I worked there long enough to see how you scale the theory into something that actually coordinates at that level — and what the overhead looks like when you do.

The baseline: what Scrum is

Scrum breaks work into short cycles called sprints (typically two weeks). At the end of each sprint, you have working software. Three roles carry the process:

• Product Owner — owns the backlog, decides what gets built and in what order
• Scrum Master — keeps the process running, removes blockers, shields the team from interruptions
• Development Team — self-organizes around the sprint commitment

Four ceremonies structure the sprint: planning (what do we commit to?), daily standup (what’s blocking us?), review (show the work), retrospective (improve the process). The Product Backlog is the ordered list of everything the product needs. The Sprint Backlog is the slice of that the team takes on this cycle.

For a single team this is genuinely lightweight. The overhead is maybe 10% of the sprint.

Why this breaks at scale

Ten teams building ten independent services can each run Scrum in isolation. But when those teams are building parts of the same product — or when a feature requires coordinated delivery across three teams in the same sprint — pure Scrum doesn’t tell you how to synchronize.

Dependencies. Shared architecture decisions. Release trains that need to ship a coherent product, not ten independent feature drops. This is where you need something on top of Scrum.

What we ran: SAFe

The Scaled Agile Framework (SAFe) organizes teams into Agile Release Trains (ARTs) — typically 50–125 people across 5–12 teams. Each ART delivers a coherent product increment on a shared cadence called a Program Increment (PI), usually 8–12 weeks (four to six sprints).

The key event is PI Planning: two days, all teams in the same room, mapping out the next increment together. Teams identify dependencies between them, flag risks, commit to objectives. At Bosch this meant getting people from multiple locations into one place — logistically heavy, but it forced cross-team alignment that wouldn’t happen otherwise.

Level	Who	Cadence
Team	5–9 developers	2-week sprint
Program	Agile Release Train (~100 people)	8–12 week PI
Portfolio	Multiple ARTs	Quarterly/annual

Between PI Planning sessions, a Scrum of Scrums handles the ongoing coordination: representatives from each team meet regularly to surface cross-team blockers before they become actual blockers.

What works and what doesn’t

PI Planning is genuinely useful. Two days is a lot of time, but having every team in the same room eliminates entire categories of “we didn’t know you were building that” surprises. The dependency mapping alone is worth it.

The overhead is real though. SAFe adds roles (Release Train Engineer, Product Management, System Architect), ceremonies (System Demo, Inspect & Adapt), and artifacts on top of what each team already runs. For a startup or a small product team, it’s absurd. For coordinating hundreds of engineers across hardware and software with shared release dates — which is exactly what embedded systems work at a company like Bosch looks like — it’s closer to necessary than optional.

The failure mode is treating the framework as the goal. Teams that are doing SAFe “correctly” but shipping nothing useful have optimized for the process rather than the outcome. The ceremonies are there to enable delivery, not replace it.

The right tool for the scale

Small team building one thing: vanilla Scrum, maybe even simpler. Multiple teams building a shared product: Scrum plus some coordination layer, Scrum of Scrums at minimum. Hundreds of teams with hard dependencies and synchronized release dates: SAFe or something equivalent, because the coordination problem is real and you need a shared language for it.

The Agile manifesto was written by seventeen people in a ski lodge. That doesn’t mean it stops being useful at 10,000 engineers — it means you have to build the scaffolding to make it work at that scale.