Engineering team composition has historically been organized around the constraint that writing code is slow and skilled developers are scarce. Ratios of developers to product managers, to QA engineers, to designers, to technical writers — all of these reflect an underlying assumption about where the production bottleneck sits. When that bottleneck moves, the ratios that were optimized for the old constraint become wrong. AI-assisted development has moved the bottleneck. For teams working effectively with generation tools, the constraint is no longer coding throughput.

The product owner in scrum is responsible for maximizing the value of the product resulting from the team’s work. The Scrum Guide is admirably concise on this point and deliberately silent on how it is achieved, because how it is achieved depends entirely on the product, the organization, and the market. What the definition does not convey is the difficulty of the role when it is done correctly. The product owner must maintain a clear product vision, own a prioritized backlog that reflects that vision, be available to the team for clarification during the sprint, and make decisions about scope and trade-offs in real time.

The scrum master role is routinely reduced to meeting facilitation and impediment tracking. The scrum master runs the standups, schedules the retrospectives, maintains the board, and removes blockers that the team surfaces. Done well, this produces smooth ceremonies and a team that is not visibly impeded. It does not produce the organizational change that agile practice requires to sustain value over time. The Scrum Guide defines the scrum master as responsible for the team’s effectiveness and for helping everyone understand scrum theory and practice, both within the team and across the organization.