One of the fundamental challenges with Agile is matching its elegantly simple three-role structure—Product Owner, Scrum Master, and Scrum Team—into the complex variety of roles, experience levels, and hierarchies that exist in real corporations. Agile presents a flat, streamlined world where a Product Owner defines what to build, a Scrum Master facilitates how teams work, and a Scrum Team executes the work. But corporations don't operate in three roles. They have Management chains running from team leads through directors to VPs and C-suite executives. They have Architecture functions defining technical standards and platforms. They have Development organizations split by seniority levels from junior engineers through principal engineers. They have Quality Assurance teams separate from development—testers who validate software after developers write code. They have Project Managers who are responsible for fitting projects into timelines for customers, managing budgets, coordinating resources, and ensuring delivery commitments are met. And cutting across all of this, companies organize by functional domains: Product teams defining customer experiences, Engineering teams building systems, Security teams managing risk and compliance, and Infrastructure teams maintaining platforms and operations.
The fundamental challenge is mapping this two-dimensional corporate reality—Management/Architecture/Development/QA/Project Management on one axis, Product/Engineering/Security/Infrastructure on another—into the simplified Agile world of Product Owners, Scrum teams, and Scrum Masters. This role is still critical as corporations do not work in sprints or story points—they work on revenue and when things need to be delivered to customers. Executives and customers don't care about velocity or sprint burndown charts; they care about delivery dates, contract commitments, and business outcomes. Where do architects fit when Agile says teams should be self-organizing? What happens to managers when Agile emphasizes servant leadership and team autonomy? How do you handle Security and Infrastructure specialists when Agile advocates for cross-functional teams? What about QA engineers when Agile encourages developers and testers to work together as a single team, testing continuously rather than in separate phases? And critically, what happens to Project Managers when Agile claims that project management responsibilities are distributed across Product Owner, Scrum Master, and Development Team roles? People tend to split QA and Developers as separate functions with different goals—QA finds bugs, developers write code. But Agile pushes for integrated teams where quality is everyone's responsibility and testing happens simultaneously with development, not afterward. Do senior engineers become Product Owners, Scrum Masters, or remain in development teams? These aren't abstract questions—they represent real career paths, compensation structures, and organizational power dynamics that companies must resolve to make Agile work at scale. The gap between Agile's theoretical simplicity and corporate structural complexity is where most transformations struggle, stumble, or fail entirely.
My approach, which has worked well in practice: Product Owners should be groups of people who know both the business and how teams operate—distinguishing between technical and business-focused product people based on what they're building. Architects aren't just writing specifications; they're helping distill business requirements into technical direction and vice versa, guiding teams to make the right technical decisions while also coaching them—they're technical experts and teachers. The role of Manager is still very important—coaching career development, helping the team, managing salary and HR problems is a critical part of the daily working machine whose ultimate goal is to build products and grow the business as well as provide the necessary support to us workers. Managers remain crucial for resourcing teams correctly, ensuring people are happy and developing professionally, and providing career advancement opportunities. QA is another critical role within Engineering teams that people traditionally split from developers as a separate function. Agile encourages working together as a single team, doing development and testing simultaneously rather than throwing software over the wall. Sometimes there aren't enough QA people in the team and developers must take more responsibility for quality. Transforming QA professionals into quality coaches and advocates—similar to how architects become coaches—can mitigate this problem. For Project Managers, I use the Product Owner and a Project Manager working together to split the yearly cycle into PI (Program Increment) cycles—like Scaled Agile does—quarterly, providing visible deadlines at the PI level. I find PI useful because we review the whole roadmap at regular cadence, however still allowing modifications at the sprint level for flexibility. My Motto is "Embrace" changes do not fight them. We will not stop changes and we will not ever lock content. We might keep the basic rule of not changing things within a sprint. I leverage weekly Planning meetings and Scrum of Scrum meetings where the key stakeholders from Product Owners (technical and business), Scrum Masters, Architects, Managers, and anyone from the development contingent who wants to participate discuss issues, align on plans, and address any modifications to the current PI or future PIs. Again, all in a continuous and iterative approach that maintains alignment without losing agility. This bridges the gap between corporate needs for predictable delivery dates and Agile's sprint-by-sprint approach. The fundamental challenge is mapping the real corporate structure—Management/Architecture/Development/QA/Project Management on one axis, Product/Engineering/Security/Infrastructure on another—into the simplified Agile world of Product Owners, Scrum teams, and Scrum Masters.
This perspective aligns with what leading companies discovered through their transformations: ING's "zero handovers" principle validates both the Product Owner group approach and the integrated QA model—they consolidated seven team-centric POs to one product-centric PO working with multiple teams, and eliminated separate testing phases in favor of continuous quality built into sprints. The architect-as-coach model mirrors what Scott Ambler calls "Architecture Owner" and SAFe's enabler pattern, where architecture work becomes visible in backlogs rather than happening in ivory towers. The QA-as-coach transformation follows the same pattern: Atlassian's engineering teams have QA members pair with developers in exploratory testing, creating knowledge transfer where "when developers become better testers, better code is delivered the first time." A financial services company reorganized their 40-person QA team into embedded quality engineers, reducing defect detection time from days to hours while developers started writing better test cases during development. Henrik Andersson's widely-discussed perspective argues "Agile teams don't need testers—they need Quality Coaches" who help teams make requirements testable, set strategies for test automation, and coach developers on selecting test cases to implement. TestRail's research confirms that having developers participate in testing is critical for faster bug identification, shared quality responsibility, and improved communication—with automation testers specifically coaching developers on unit testing approaches. The manager role transformation matches ING's experience where managers shifted from delivery ownership to people development while teams owned execution—they still handle hiring, performance, and career development but protect team autonomy. For Project Managers and the PI planning approach: SAFe explicitly addresses this through Program Increment Planning—regularly scheduled events (typically quarterly, every 8-12 weeks) where multiple Agile teams align on objectives for the upcoming increment. Organizations using SAFe commonly choose 12-week PI intervals specifically to align with financial quarters, recognizing that corporations operate on quarterly revenue cycles and customer commitments, not just sprint-by-sprint delivery. The PI Planning two-day event brings together Product Managers, business stakeholders, and all ART teams to create a unified roadmap with visible milestones while still maintaining sprint-level flexibility for adjustments. Atlassian, Capital One, and numerous large enterprises use this quarterly PI planning model combined with ongoing sprint execution—the PI level provides the predictability and timeline visibility that executives and customers require, while sprints enable the iterative learning and adaptation that makes teams effective. Scrum.org acknowledges that while there's no formal "Project Manager" role in Scrum, the core project management skills—budgeting, resource coordination, risk management, stakeholder communication, timeline tracking—remain essential and must be addressed, often distributed between Product Owner (prioritization and business value), Scrum Master (impediment removal and process facilitation), and managers (resourcing and coordination). Some organizations have both Project Managers and Scrum teams working together successfully, especially during transformations or on large initiatives where the Project Manager handles vendor contracts, budget management, and executive reporting while Scrum Masters ensure teams maintain agile practices. Companies solve the functional split (Security, Infrastructure, DevOps) by embedding specialists into cross-functional teams while maintaining expertise through Spotify's Chapter and Guild patterns—Chapter Leads manage careers and standards for specialists working across squads, ensuring technical excellence without creating departmental bottlenecks. The same pattern applies to QA: quality engineers embed in teams as members rather than separate departments, with quality communities of practice for knowledge sharing and continuous learning.