Scrum + Team Topologies: Why Your DevOps Team Structure Might Be Slowing You Down

I spent three years at a company that spent $4 million on “DevOps transformation.” New tools, new cloud infrastructure, training budgets, the works. The velocity of the platform stayed flat.

The problem wasn’t the tools. The problem was the org chart.

Everyone knew it, too. The “DevOps team” was one of those orgs where people got paged at 2 AM because someone else’s pipeline broke. They spent their days being interrupted by teams who couldn’t own their own infrastructure. Every request went into a ticket. Every ticket meant waiting. Every wait meant a stream-aligned team sitting idle.

I see the same pattern everywhere. Companies treat DevOps like it’s a function, not a structure. They hire DevOps engineers, stick them in a team, give them a mandate to “enable engineering,” and then wonder why the org chart creates bottlenecks.

The fix isn’t more DevOps engineers. It’s a different way of thinking about how teams should be organized.

Why Transformation Without Structure Change Fails

Most DevOps transformations are tool-focused. Move to cloud. Replace Jenkins with GitLab. Adopt Kubernetes. Add observability. All real work. All important. And all completely insufficient.

Tools don’t fail. Structure fails.

A team designed to be a centralized gate for every deployment will move faster with better tooling, but it will still be a gate. Add GitOps, add better monitoring, add container orchestration. The fundamental problem remains: one team owns infrastructure. Everyone else depends on that team. When that team is full, everything backs up.

I watched a team spend six months implementing ArgoCD, expecting it to be the breakthrough. Deployment time went from 45 minutes to 12. But stream-aligned teams still couldn’t deploy on their own. They still needed the DevOps team to create the pipeline definition. Still had to wait for a code review from people drowning in reviews. The bottleneck moved, but it didn’t disappear.

The real transformation is about who owns what. Which teams are responsible for deployments? Which can make decisions without asking permission? These questions aren’t answered by installing software.

The Shared DevOps Team: A Design Anti-Pattern

The classic structure: hire DevOps engineers, create a team, hand them the infrastructure. Everyone else uses that team as a service.

This works fine until it doesn’t. Usually stops working around the time you have three or four stream-aligned teams all competing for DevOps’ attention.

What happens next is predictable. The DevOps team starts triaging. They get formal about intake. They create a ticketing system. They do sprint planning. They create a backlog. They explain that they’re “not a build-on-demand shop.”

The irony is brutal. The more formal the DevOps team becomes — the more it acts like a software team — the less like infrastructure it becomes. It becomes a shared service team, structurally similar to a support desk. You can make a support desk more efficient, but you can’t make it stop being a bottleneck when too many people need it.

I’ve been on the DevOps team side, and I’ve been the engineer waiting in the backlog. Both perspectives are miserable. DevOps feels like they can never say no, never finish anything, always behind. Stream-aligned teams feel helpless and dependent. Both are true. Both are symptoms of the same structure.

The shared DevOps team isn’t a failure of execution. It’s a failure of design.

Team Topologies: A Different Model

Team Topologies proposes four types of teams, each with different responsibilities and interaction patterns. The idea: once you know what type of team you are, you can design the right structure around it.

The four types are stream-aligned teams, platform teams, enabling teams, and complicated subsystem teams. Almost every org needs all four. Almost every org is missing at least two of them.

A stream-aligned team is the core. This team owns a feature, a product, or a user-facing capability — end to end. They write the code, own the tests, own the deployment. They’re organized around a continuous stream of work that customers care about. Conway’s Law says your architecture mirrors your organization; stream-aligned teams make that work for you instead of against you.

Most orgs claim to have stream-aligned teams. But there’s often a hidden dependency: someone else owns infrastructure. Someone else owns the CI/CD pipeline. Someone else owns deployments. Strip those away, and you don’t have a stream-aligned team. You have a team that’s aligned to code, not to outcomes.

A platform team doesn’t own customer work. They build internal capabilities for the stream-aligned teams — the infrastructure, the CI/CD platform, the observability stack, the deployment tooling. They’re a service organization, but they’re fundamentally different from a shared DevOps team.

The difference is mindset. A shared DevOps team thinks of requests as tickets. A platform team thinks of the stream-aligned teams as paying customers and designs accordingly.

An enabling team is temporary. They form to help a stream-aligned team develop a capability they don’t have yet. Maybe the platform is new and nobody knows how to use it. Maybe the org is adopting Kubernetes. The enabling team teaches, then disbands. If an enabling team is permanent, it’s a failure mode — it means the stream-aligned teams will never own that capability.

A complicated subsystem team owns something specialized that doesn’t fit a stream-aligned model. A complex recommendation algorithm. A financial calculation engine. These should be rare.

Stream-Aligned Teams Own More Than You Think

Once you accept that stream-aligned teams own their outcomes end to end, the scope expands considerably.

They own the code, obviously. But also tests. The build pipeline. Deployments. The infrastructure that runs their code. Monitoring and alerting. Runbooks. Incident response. Architectural decisions within their domain.

This is uncomfortable for most orgs. It means every stream-aligned team needs people who understand infrastructure. It means teams can’t throw things over the wall and walk away.

But it also means teams can move fast. They don’t wait for a deployment queue. They don’t book meetings to discuss pipeline design. They can experiment with their deployment strategy without asking permission.

The first time I was on a real stream-aligned team, it was startling how much faster everything moved. We wanted to change our deployment strategy — we did it. We wanted to experiment with a different database configuration — we did it in a lower environment. We wanted to roll out a feature flag — we deployed it. The coordination overhead disappeared.

The platform team makes this possible. They don’t own the deployments. They own the infrastructure that makes it safe for stream-aligned teams to deploy themselves. They provide the Kubernetes cluster. The CI/CD platform. The monitoring system. The templates and abstractions that make it easy to do these things without deep infrastructure expertise.

When it works, teams look autonomous. When it doesn’t, it looks like chaos. The difference is the platform team.

Platform Teams and the “Platform as a Product” Mindset

Platform teams have to think like product teams.

A product team thinks about their users’ experience. They gather feedback. They iterate on the interface. They remove friction. They build things people actually want to use. They measure success by adoption and satisfaction.

A shared DevOps team thinks about their backlog.

I’ve seen platform teams fail spectacularly when they built for themselves instead of for users. A platform team would build elegant infrastructure — perfect APIs, comprehensive features — and then stream-aligned teams would ignore it and build their own shadow infrastructure. The platform team would blame the teams for not understanding the architecture. The reality was that the architecture was optimized for the platform team’s own perspective.

One platform team I know made a simple change: quarterly roadmap reviews with their internal customers. Stream-aligned teams came prepared with what was slowing them down. The platform team listened, pushed back sometimes, explained their tradeoffs, and actually updated their priorities based on feedback.

They stopped building new features. Spent two quarters fixing warts — confusing deployment UI, painful secrets management, too many hoops to add a new service. Adoption went up. Happiness went up. Time to first deployment dropped.

The platform team felt better too. They had clarity. They had a customer. For Backstage to work in this model, the platform team has to own it the same way — not as infrastructure to be deployed once, but as a product to be continuously improved based on what teams actually need.

Enabling Teams: The Bridge

Most orgs don’t execute enabling teams well, because permanent enabling teams are almost never the right answer.

The idea: when your org needs to adopt a capability nobody has yet, you form an enabling team. They have deep expertise. Stream-aligned teams work with them, learn, build the capability into their own practices. Then the enabling team disbands.

After a time — weeks, a few quarters at most — the enabling team goes out of business. Stream-aligned teams own the capability now.

I’ve seen orgs with a permanent “Kubernetes enablement team.” That’s not an enabling team. That’s a failure. Either the platform is too hard (a platform team problem) or the stream-aligned teams should have learned Kubernetes years ago and should own it now.

Enabling teams need a success criterion. A plan to go out of business. Otherwise they become a permanent crutch that prevents teams from ever becoming independent.

Where Scrum Fits (And Where It Doesn’t)

Scrum works well for stream-aligned teams. Backlog of work, product owner who prioritizes, team commits to a sprint, delivers an increment, inspects and adapts. Stream-aligned teams should lean toward continuous delivery, but Scrum sprints and continuous delivery aren’t fundamentally incompatible.

Scrum gets into trouble when you try to apply it across team boundaries.

SAFe proposes PI Planning: Program Increment Planning. All the teams — sometimes dozens — get in a room together, sync up on dependencies, negotiate how their work will interlock, commit to the next 10 weeks together.

In theory: alignment. In practice: theater.

I’ve been in PI Planning sessions with 80 people. Nothing of value happened, and it took two days. Teams had already talked to each other. They already knew the dependencies. PI Planning didn’t add information. It added overhead.

The fundamental problem is that Scrum is designed for a single team. When you try to use it to coordinate multiple teams, you’re outside its domain. Teams that move fast in SAFe environments often skip PI Planning or treat it as a formality. Teams that take it seriously move slower.

Team Topologies suggests the right answer to inter-team dependencies is to minimize them. If you can’t minimize them, your team boundaries are probably wrong. Scrum within a stream-aligned team: great. Scrum as multi-team coordination: usually a sign the structure needs work.

Cognitive Load: The Metric Nobody Measures

Most orgs measure velocity, deployment frequency, MTTR. They don’t measure: does this team actually understand what they own?

When cognitive load is too high, teams stop testing. They stop thinking about the next thing to build. They go into survival mode. Incidents consume everything. Quick fixes pile up. Technical debt compounds. You can’t hire your way out of it.

I’ve been on teams where the cognitive load was crushing. You’d make a change and have no idea what might break. Deploy and pray. Get paged and spend hours figuring out which system was involved.

The fix sometimes isn’t more people — it’s fewer systems. Sometimes it’s simpler systems. Sometimes it’s a better platform that abstracts the complexity away. I’ve watched teams go from chaotic and reactive to calm and productive just by reducing the number of systems they owned. Not by hiring. By drawing better lines.

The platform team’s job, in this framing, is cognitive load reduction. They build abstractions that let stream-aligned teams own outcomes without understanding every underlying layer. You don’t need to understand Kubernetes internals to deploy. The platform encapsulates that. You don’t need to know how GitLab runners are tagged to use the CI/CD platform. That’s handled.

When the cognitive load is right, teams can think ahead. They can improve. They can experiment. When it’s too high, they’re just reacting.

Interaction Modes

Team Topologies describes three ways teams interact: X-as-a-Service, collaboration, and facilitating.

X-as-a-Service is asynchronous. One team provides something through an API or a product interface. The other team uses it. They don’t need to coordinate in real time. The platform team provides CI/CD infrastructure as a service. Stream-aligned teams consume it. No synchronization required.

Collaboration means two teams working together on a shared problem, with shared ownership. Higher friction, real-time coordination, slower. Sometimes necessary. Rarely the best default.

Facilitating is an enabling team pattern — one team helps another team accomplish something, but doesn’t share ownership of the outcome.

Most orgs have too much collaboration and not enough X-as-a-Service.

Collaboration feels comfortable. You know everyone. You make decisions in real time. But it doesn’t scale. When every decision requires a meeting with multiple teams, bigger orgs thrash. X-as-a-Service scales. The platform team has to document what they’re doing. They have to maintain backward compatibility. They have to design for their users. But once they do, teams can move independently.

The goal is to use collaboration where it’s genuinely necessary and X-as-a-Service everywhere else. In practice, most orgs have this exactly backwards.

How to Identify a Bottleneck Team

If you have a shared DevOps team, you probably have a bottleneck. Look for these signals:

Stream-aligned teams finish their work and then wait days or weeks for infrastructure to create a pipeline. Infrastructure work competes with servicing requests — the team can’t improve the platform because they’re too busy fielding tickets. Stream-aligned teams have started writing their own deployment scripts because the platform takes too long to deliver changes.

Measure cycle time. If stream-aligned teams have long cycles because they’re waiting on infrastructure, the platform is a bottleneck. That’s the number you should be showing to leadership.

How to Fix It

The fix starts with a conversation: do you own end-to-end deployments, or do you hand off to someone else? If they hand off, find where the handoff lands.

Then: form a platform team. Extract the tooling work. Build abstractions. Make deployment simple. Move infrastructure ownership into stream-aligned teams.

Stream-aligned teams will need to hire or grow differently. They need people who understand infrastructure alongside the people who write application code. Some call them platform engineers. Some call them SREs. Whatever the title, they need to exist in the team and own the outcomes alongside everyone else.

The first month of this transition is chaotic. Teams suddenly own things they’ve never owned. They make mistakes. They learn. Then it gets dramatically better.

The GitLab + ArgoCD GitOps pattern is a concrete example of what this looks like in practice: stream-aligned teams own their deployment config, ArgoCD syncs it, the platform team owns the cluster and the tooling. Nobody is waiting for a ticket.

The Takeaway

Shared DevOps teams and SAFe PI Planning both feel like they’re solving the coordination problem. And they are — but they’re solving it by trading independence for coordination. And independence is more valuable.

Teams that can move autonomously move fast. Teams that need coordination with a dozen others will always be slow.

The better answer is to structure teams so you don’t need as much coordination. Give stream-aligned teams autonomy over their outcomes. Support them with a platform team that builds for their needs. Use enabling teams to transfer knowledge, not to hold it permanently. Keep collaboration minimal. Default to X-as-a-Service.

If your DevOps team is a bottleneck, the problem isn’t the DevOps team. The problem is the structure. And structure is something you can change.