Episode
From Component Teams to Cross-Functional Teams — How to Navigate the Hardest Agile Transformation | Viktor Glinka
- Published
- Apr 22, 2026
- Duration seconds
- 1038
- Processing state
not_requested
Actions
POST https://stenobird.com/v1/public/podcasts/scrum-master-toolbox-podcast-agile-storytelling-from-the-trenches-445588/episodes/from-component-teams-to-cross-functional-teams-how-to-navigate-the-hardest-agile-transformation-viktor-glinka/transcription-requests
Idempotently request low-priority transcript generation for this episode.GET https://stenobird.com/podcast/scrum-master-toolbox-podcast-agile-storytelling-from-the-trenches-445588/from-component-teams-to-cross-functional-teams-how-to-navigate-the-hardest-agile-transformation-viktor-glinka.md
Read the agent-friendly Markdown representation of this episode resource.
Summary
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 a…