Who Does What: Roles Across Scrum, Kanban, and Lean
Ask three companies what a Product Owner does and you get three job descriptions wearing one title. Agile role names travel badly, and the confusion is not cosmetic: half the dysfunctions I get called into trace back to a role that exists in name but not in authority, or two people quietly holding the same responsibility with different opinions about it. So this is a field guide: the three generic roles underneath every agile framework, how each framework dresses them, and the question none of the frameworks answers cleanly, where the project manager fits.
The three roles under the costumes
Strip any agile method to its skeleton and three responsibilities remain. Someone owns what to build and in what order, the value decision. Someone owns how the team works and improves, the process health. And cross-functional team members own building the thing, with the authority to decide how within the agreed standards. Every framework is a costume on these three; once you see that, switching frameworks stops being a retraining event and becomes a renaming event.
Scrum: the sharpest role definitions, the most common miscastings
Scrum names all three explicitly: Product Owner, Scrum Master, Developers. The sharpness is a feature, and the miscastings are legion. The proxy PO, responsible for the backlog but required to escalate every real prioritization call, breaks the model quietly, because Scrum's whole bet assumes value decisions take a conversation, not a committee. The secretary Scrum Master, demoted to meeting scheduler, leaves process health unowned. And the anti-pattern I flag most in assessments: the Scrum Master who is also the team's line manager, which converts every retrospective into a performance review with the safety turned off.
Kanban: roles emerge from the board
Kanban prescribes no roles at all, only flow, WIP limits, and continuous improvement. In mature practice two functions crystallize anyway: someone curates and orders what enters the flow (service request manager, in the literature's language) and someone watches the flow itself for aging items and bottlenecks (service delivery manager). Same skeleton, thinner costume. The trap in role-free frameworks is assuming no-role means everyone-does-it; unowned process health degrades exactly like unenforced ground rules, gradually, then suddenly.
Lean: roles serve the value stream
Lean thinking reframes all roles around the value stream: whoever owns waste elimination, flow efficiency, and respect-for-people is doing the Lean job regardless of title. Its distinctive contribution to the role conversation is the chief-engineer archetype, deep technical ownership of the whole product, and its insistence that improvement is everyone's role rather than a specialist's. In practice I treat Lean less as a role system and more as the value-lens the other frameworks' roles should look through.
So where does the PM go?
The question agile literature dodges. Scrum's official answer is that the PM role dissolves into the three others, and inside a single team, that is roughly true. But real organizations run hybrid programs with contracts, compliance gates, cross-team dependencies, budgets, and partner dates, and none of the three team-level roles owns that layer. That layer is where the PM lives in agile organizations: not managing the team's daily work, which the framework handles, but managing the boundary between the team's world and the organization's, translating, shielding, integrating.
The practical takeaway for any framework transition: map the three responsibilities to named humans before arguing about titles. Every value decision needs one owner with real authority; process health needs a name on it; the team needs genuine how-authority; and the boundary layer needs someone who considers it their job rather than their interruption. Get those four assignments right and the framework vocabulary is almost a formality. Get them wrong and no amount of correct terminology will save the standup.
Nguyễn Hải Nam
Project Management Lead. 16+ years from code to delivery. PMP®. Writing here about project management and engineering.