Search

Home > Scrum Master Toolbox Podcast > From Component Teams to Cross-Functional Teams — How to Navigate the Hardest Agile Transformation | Viktor Glinka
Podcast: Scrum Master Toolbox Podcast
Episode:

From Component Teams to Cross-Functional Teams — How to Navigate the Hardest Agile Transformation | Viktor Glinka
Category: News & Politics
Duration: 00:17:18
Publish Date: 2026-04-22 10:05:00
Description: Viktor Glinka: From Component Teams to Cross-Functional Teams — How to Navigate the Hardest Agile Transformation

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

"Our customers do not buy our components. They use the product as a whole. And when it comes to integration, the real problem pops up." - Viktor Glinka

Viktor brings a challenge many Scrum Masters face: transitioning from component teams to cross-component, cross-functional teams in a large-scale Scrum setup. Picture 8 to 10 teams, each owning their own part of the system, never touching anything else — and the company stuck in delivery for months. The premise behind component teams sounds logical: specialization leads to speed. But as Viktor explains, that speed is local — optimized for the component, not the product. When integration time arrives, responsibility gaps appear, rework multiplies, and teams start identifying with their components rather than the product. "We're the billing team — we don't deal with anything else." When they reorganized into cross-functional teams, the complaints were immediate: "I was really productive before, and now I can't finish anything." Viktor and his fellow Scrum Masters took a two-pronged approach. First, they secured time credit from leadership — a couple of months where learning was prioritized over deadlines. They ran mob programming sessions, coached teams, and removed impediments. Second, they shifted focus from outputs to outcomes, organizing customer interviews that helped developers understand what users actually needed. The development director reinforced this by joining refinement sessions, telling teams: "You might not develop anything if it still satisfies the customer need." The result was a shift from transactional stakeholder relationships to genuine cooperation, and teams that began to see beyond their component boundaries.

Self-reflection Question: If your teams are organized around components, what would it take to run one experiment — just one sprint — where a team picks up work outside their usual component? What would you need to make that safe?

[The Scrum Master Toolbox Podcast Recommends]
Total Play: 0