Team Roles
Roles in a lean-agile team are defined by contribution, not title. A team needs a set of capabilities present — the way those capabilities are distributed across people, and how titles are assigned, is secondary.
How Roles Work in a Lean-Agile Team
Collective ownership over individual accountability. The team owns quality, security, and operations collectively. Done means the team is satisfied — not that an individual has signed off. This mirrors what organizational research on self-managing teams has consistently found: shared responsibility for outcomes produces better results than fragmented accountability for activities.
T-shaped skills over specialists in silos. Each team member has depth in an area of expertise and the ability to contribute across the team’s full scope. This enables the team to absorb variation in demand without creating bottlenecks at individual specialists.
Minimized handoffs. Work is organized so that it moves forward within the team, not between separate specialist functions. Testing, security, and operational concerns are addressed continuously — embedded in how the team works, not added as stages after development. Each handoff is a potential queue, and queues extend lead time.
Requirements as a shared activity. There is no separate requirements role or function. The work of understanding and refining what to build is done collaboratively between the Product Owner, the team, and relevant stakeholders. A Business Analyst is a competence — someone who supports requirements analysis and domain understanding — not a role that owns requirements on behalf of others. Separating requirements from development creates queues, interpretation loss, and slower feedback.
Core Roles
| Role | Focus | Key responsibilities |
|---|---|---|
| Agile Team Member (Dev Engineer) | Design, build, test, operate | End-to-end delivery within the team. Cross-functional by expectation. Shared ownership of quality, security, and operations. |
| Product Owner (PO) | What and why — at team level | Maintains and prioritizes the team backlog. Ensures the team works toward business and customer goals. Works closely with the Product Manager at DVS level. |
| Agile Coach | Flow and improvement | Removes impediments. Coaches the team in continuous improvement. Facilitates team events. Not a project manager. |
| Business Analyst | Requirements and domain understanding | Supports the PO and team in translating business needs into backlog items. A competence embedded in the team or shared with product management — not a central requirements function. |
| QA / Test Specialist | Built-in quality | Drives test automation, integration testing, and quality practices within the team. Builds quality in rather than checking it at the end. |
| Architecture (team-embedded) | Technical design | Applies reference architecture and supports design decisions within the team. Works in close coordination with any DVS-level architecture function. |
| UX Designer | User experience | Generates user insights, prototypes, and improvements. Often shared across two or three teams rather than dedicated to one. |
| CI/CD / Cloud Engineer | Pipelines and operations | Ensures build, test, and deployment pipelines are fast, reliable, and provide observability. May be a team member or a shared support resource. |
| Security Champion | Secure-by-design | Guides secure coding practices within the team. Connects the team to any shared security enablement function. |
On the Product Owner Role
The PO is not only a team role. POs are part of the product management function at DVS level — they form a network with the Product Manager and other product management roles to maintain coherence across the value stream. Their team backlog work is the operational expression of a broader product strategy they actively participate in shaping.