Who Actually Does What on an Agile Team - and Why so Many Teams get it Wrong
Katrina Ryl
Walk into any product organisation today and you'll find Agile rituals running on autopilot. Stand-ups at 9:15. Sprint planning every other Tuesday. A retro at the end. Burn-down charts pinned to a wall someone walks past on the way to the coffee machine. The mechanics are there. The roles are filled. The Jira board moves. And somehow, the team still ships things that don't quite work, blames each other when they don't, and quietly resents the process that was supposed to fix exactly that.
Date
The problem isn't usually Agile. It's that most teams have inherited a vocabulary of roles from one specific framework, almost always Scrum, without ever stepping back to ask what Agile actually is, what other frameworks exist, and which one fits the work they do. Product Owners write tickets. Scrum Masters book meetings. Designers get pulled in at sprint planning to skin something. Engineers receive specs and build them. QA tests at the end. Everyone is technically doing their job. The product still suffers.
This post is about who does what really across an Agile delivery cycle, the difference between Agile and the frameworks that implement it, where the gaps usually open up, and what the published evidence says about where this works and where it falls apart.
Agile is not Scrum. Start There.
The single biggest source of confusion in this whole conversation is that Agile and Scrum get used interchangeably. They're not the same thing, and conflating them is what produces most of the cargo-cult adoption you see in the wild.
Agile is a set of values and principles for software development, while Scrum, Kanban, and Extreme Programming (XP) are specific frameworks that implement Agile principles. The values came first. The frameworks came second.
In February 2001, 17 software practitioners (including the people who would later be credited as the inventors of Scrum (Ken Schwaber and Jeff Sutherland), Extreme Programming (Kent Beck), and several other approaches) met in Snowbird, Utah, and produced a one-page document called the Agile Manifesto. It contains four values:
|
|
|
|
That's it. No roles. No ceremonies. No sprints. No stand-ups. 12 supporting principles flesh out the values, but the manifesto deliberately stops short of prescribing how to do any of it.
The frameworks (Scrum, Kanban, XP, Lean, Feature-Driven Development, Crystal, DSDM, SAFe) are different attempts to operationalise those values. Each makes different bets about how teams should be structured, how work should flow, and what roles should exist. None of them is Agile itself.
The reason this matters for your team is straightforward. If your only mental model is Scrum, you'll force every kind of work into a sprint container whether it fits or not. Some work doesn't. The same Atlassian guide that explains Scrum is direct about the alternatives. Scrum uses time-boxed sprints and defined roles. Kanban focuses on visualising work and limiting work in progress. XP emphasises technical excellence and frequent releases.
Different bets. Different fits. Different role structures.
The Major Frameworks and Who's on the Team
Scrum: the Structured Workout Plan
Scrum is the most widely adopted Agile framework, and it's the one most people mean when they say Agile. It defines exactly three roles. Not five. Not seven. Three.
The Product Owner works on maximising the product value and also manages the Product Backlog. The Scrum Master leads and guides the entire Scrum Team, as well as teaches and facilitates the implementation of Scrum. Developers are those who develop and create usable Product Increments each Sprint.
The framework prescribes ceremonies (sprint planning, daily stand-up, sprint review, retrospective), artifacts (product backlog, sprint backlog, increment), and a fixed cadence (sprints of one to four weeks). It works well when the work can be reasonably planned in two-week chunks and when the team benefits from rhythm.
What Scrum quietly leaves out is everyone else who actually has to be in the room for a product to ship: designers, researchers, business analysts, QA, content, ops. Scrum absorbs them into the developers as a cross-functional collective. This is technically inclusive and practically problematic, and we'll come back to it.
Kanban: Continuous Flow
Kanban is the second-most-adopted Agile framework and the closest thing to a deliberate counterweight to Scrum. Originating in Lean manufacturing, the Kanban system was developed by Taiichi Ohno at Toyota to improve manufacturing efficiency, and was later adapted for software.
Where Scrum prescribes roles, Kanban does not. Kanban is more fluid in roles. It doesn't define specific roles apart from team members. The focus is on collaboration and ensuring tasks flow smoothly through stages, allowing team members to pick up work based on expertise and availability.
Where Scrum operates on time-boxed sprints, Kanban operates on continuous flow. Work is continuously pulled from the backlog as capacity allows. There are no set time frames, allowing for real-time adjustments based on workflow and demand.
The core mechanic of the Kanban board is the visualisation of work moving through stages (to-do, in-progress, done, or whatever stages fit the team's actual workflow) with work-in-progress (WIP) limits on each column. The team can't pull a new task into in-progress if the WIP limit is already hit. This forces the team to finish what it started before starting new work, which is the opposite of how most teams naturally behave.
Kanban shines where work arrives unpredictably or in continuous streams, such as support teams, ops teams, design teams responding to varied incoming requests, and content teams. It is far less prescriptive than Scrum about who does what; the team has to define its own roles and policies. That flexibility is Kanban's strength and weakness. There's no framework telling you who owns prioritisation, so the team has to decide explicitly.
Extreme Programming (XP): Engineering Discipline First
XP is the framework most people have heard of and least understand. It came out of the same late-1990s context as Scrum but made a fundamentally different bet. Rather than optimising the management layer around developers, optimise the development practices themselves.
XP differs from traditional development through its iterative software development process and emphasis on simplicity. XP focuses on delivering working software frequently, often in one to two-week iterations. Teams write code, test it immediately, and release it to customers for feedback before moving to the next feature.
The roles in XP, drawing from the Agile Alliance's definition, are slightly different from Scrum:
Customer: the most distinctive XP role. The Customer role is responsible for making all of the business decisions regarding the project, including what the system should do, how we know when the system is done, how much we have to spend, and what to do next. The XP Customer is expected to be actively engaged in the project and ideally become part of the team. This is a much more demanding role than the Scrum Product Owner; XP assumes the customer is sitting with the team.
Developers/Programmers: write the code in pairs. Pair programming, where two developers work together at one workstation, is core to XP, not optional. One developer creates the code while the other reviews it in real time, providing immediate feedback and suggestions.
Coach: closer to a senior technical mentor than a Scrum Master; responsible for the team's adherence to XP practices.
Tracker: monitors progress and surfaces problems with the schedule.
XP also embeds engineering practices directly into the framework: test-driven development, continuous integration, refactoring, collective code ownership, and simple design. A 2024 study in the International Journal of Information Systems and Engineering found that XP excels in areas like defect rate reduction (25%) and cycle time performance (30%) compared to other agile methods.
XP is generally considered more effective for small to medium-sized teams. Its highly collaborative practices, such as pair programming and collective code ownership, may become more challenging to manage in larger teams.
Lean Software Development: Eliminate Waste
Lean is less a framework and more a philosophy, lifted directly from Toyota Production System thinking. Lean principles focus on eliminating waste and delivering value with the least amount of resources. It overlaps heavily with Kanban (same origin) but emphasises a broader set of principles: amplify learning, decide as late as possible, deliver as fast as possible, empower the team, and build integrity in.
Lean doesn't prescribe roles either. It's most often used as a layer of thinking on top of another framework lean Scrum, lean Kanban, and is a strong intellectual companion to dual-track agile.
Scrumban and Hybrids
In practice, most mature teams don't use any single framework purely. A common hybrid approach maintains Scrum's roles and key ceremonies while adopting Kanban's visual board and WIP limits. Teams might hold Sprint Planning, Reviews, and Retrospectives from Scrum while using Kanban's continuous flow and pull-based work management.
This is sensible. The frameworks were never meant to be religious commitments.
Where Designers Actually Fit
Regardless of which framework a team chooses, the single biggest unspoken tension in most Agile teams is between design and engineering cadence. The two disciplines operate on fundamentally different time signatures, and forcing them into the same delivery container creates predictable damage.
Classic Agile, born for software engineering, runs on short development cycles (1–2 week sprints) where you build, test, and ship. Classic UX, born from research and design, runs on long discovery phases (interviews, synthesis, wireframes, testing) before deciding what to build.
If you try to compress design into the development sprint, one of two things happens. If design has to chase the sprint, it becomes execution delivery with no research. The designer draws whatever the product manager asks for, fast, without validation. If the sprint has to wait for design, engineers sit idle.
The fix the industry has converged on is dual-track agile, coined by Desirée Sy in 2007 and popularised by Marty Cagan and Jeff Patton. The idea is straightforward. Run two parallel synced tracks, Design and Delivery, rather than one.
The design lane identifies the problem, works on solutions, creates prototypes, tests them and then when the prototype is validated, goes to the delivery lane where product development begins.
In practice, the Design track is usually a small group consisting of a product manager, designer, researcher, and engineering lead. They run one to three sprints (or weeks, in a Kanban context) ahead of the Delivery team. They explore the problem, run research, build prototypes, and validate. By the time something hits the Delivery backlog, the riskiest design decisions have already de-risked.
This maps cleanly onto the Double Diamond structure of any design delivery framework. Discover and Define live in the Design track; Develop and Deliver live in the Delivery track. The two tracks are not sequential phases of a waterfall; they run concurrently, on different cadences, with continuous handoff between them.
Dual-track works equally well over Scrum or Kanban. Over Scrum, Design runs in parallel sprints; over Kanban, Design runs as its own flow with its own WIP limits and inputs into the Delivery flow. The cadence changes; the principle doesn't.
A dual-track is not a separate design team that throws designs over the wall to engineering. The Design group deliberately includes engineering representation. Without it, you get beautiful prototypes that can't be built within the technical constraints.
A Walk Through a Single Delivery Cycle
It helps to follow one piece of work, a feature, a flow, or a capability from problem to production. This is the cycle as it should run, with each role's actual job at each stage. The framework names change, but the underlying work is broadly the same.
Stage 1: Problem Framing (Design Track)
The Product Owner (Scrum), Customer (XP), or whoever owns the what brings a problem to the table, not a solution. Something like: Operators are missing critical alarms on the night shift. The Discovery group: a product person, designer, researcher, and engineering lead pulls it apart. Designers and researchers go to the actual users. Engineers flag technical realities.
The output of this stage is not a wireframe. It's a clear problem statement and a hypothesis worth testing.
Stage 2: Solution Exploration (Design Track)
Designers produce low-fidelity artefacts such as sketches, wireframes, or flow diagrams. They put them in front of users. The engineering lead pressure-tests the feasibility. The product owner confirms it aligns with the broader product strategy. Prototypes get validated, killed, or rebuilt. Most of the design work happens here, and most of it gets thrown away. That's the point.
Stage 3: Refinement and Handoff (Delivery Track)
Once a solution is validated, it moves into the Delivery backlog. The product owner writes the user stories. The designer hands off high-fidelity mockups and interaction specs. The engineering team estimates effort. QA starts thinking about test cases. BAs (where present) document acceptance criteria.
This is the stage where most teams break. The handoff is often treated as a single event. Design is done, throw it to the devs. It should be a conversation that continues through the build.
Stage 4: Sprint Planning and Build (Delivery Track)
In Scrum, the team pulls the now-refined work into a sprint. In Kanban, it gets pulled when a slot opens. In XP, it enters the weekly cycle and the pair-programming queue. Developers build. The designer remains available to answer interaction questions, review build progress, and catch the small details that drift in implementation. QA tests in-flow, not at the end.
Stage 5: Review, Retrospective, Release
At the end of the iteration, the team demonstrates the increment to stakeholders. Honest feedback gets captured. The retro is for the team, not for stakeholders. It's where the team interrogates its own process. Release happens on whatever cadence the product allows; in Scrum, the sprint is a planning cycle, not a release cycle. The sprint is not a release cycle, but instead a planning cycle. That means that scrum teams can deliver at any time. Ideally, they would deliver frequently throughout the sprint, allowing the sprint review to review real customer usage and feedback. In Kanban, this is even more explicit. Release whenever a card crosses the finish line.
Where this Works - ING
The most rigorously documented Agile transformation success is ING's 2015 restructure of its Dutch headquarters. In the year 2015, the Dutch banking group ING embarked on a transformative journey, shifting its traditional organisation to a completely agile model in a big bang fashion. Comprising about 350 nine-person 'squads' in 13 so-called tribes, the new approach at ING tremendously improved its time to market, boosted employee engagement, and increased productivity.
The detail worth noting is the depth of the commitment. The remaining employees had to formally reapply for positions within the remodelled organisation in order to assess and match the right competencies and skillsets to the new roles. In evaluating employees' fit with new roles, alignment with company values, the agile mindset and the Orange Code were favoured over criteria relating to technical capabilities and experience.
That's the line most organisations don't cross. ING made people reapply for their own jobs. They restructured around mission rather than function. But it is the level of commitment to agile resourcing that is truly impressive, avoiding the common trap of adopting some agile attributes but not letting go of legacy structures, processes or governance.
The reason ING worked and most copy-paste Agile transformations don't comes down to this: ING changed the organisation to suit the working model. Most companies try to slot the working model into an unchanged organisation, and the working model loses.
Where this Fails - Spotify
The most-imitated Agile model in the world is the Spotify model, squads, tribes, chapters, guilds, described in a 2012 whitepaper by Henrik Kniberg and Anders Ivarsson. It became the template for organisations attempting to scale Agile. There is just one problem.
Spotify doesn't use it. Spotify didn't really use it then either.
"Even at the time we wrote it, we weren't doing it. It was part ambition, part approximation. People have really struggled to copy something that didn't really exist." — Joakim Sundén, agile coach at Spotify 2011–2017
Source: https://www.jeremiahlee.com/posts/failed-squad-goals/
The failures were specific and instructive. Coordination between squads proved harder than expected. When multiple squads needed to work together, there was no clear mechanism for coordination. The model optimised for squad independence at the expense of cross-squad collaboration. Tribes became silos. The boundaries that enabled tribe autonomy also created walls. Information didn't flow. Duplication emerged. Different tribes reinvented the same solutions.
The role design itself was structurally flawed. The framework saw product owners manage design and engineering teams without engineering managers or at least in short supply. When disagreements within the engineering team arose, the product manager needed to negotiate with all of the engineers on the team.
In other words, Spotify removed an entire layer of accountability under the banner of autonomy, then discovered that someone still had to do the work that layer had been doing. The PO got that work by default, which is exactly what you don't want: a PO who is meant to maximise product value, spending their time mediating engineering disputes.
The deeper lesson is one Spotify's own coaches have been repeating for a decade: companies love introducing one or many of those ideas without understanding where they come from or how they work. And if it doesn't work in their conditions, they blame Spotify. Why did they dare to publish something that isn't working?
Where this Fails More Broadly - Cargo-cult Agile
Atlassian's own writing on the Agile Manifesto names the failure mode directly: there's cargo cult agile, where you're doing and saying the right things, but you don't understand the fundamental principles. You're not getting the results.
The pattern of failure is consistent across industries and frameworks:
Mechanical adoption. In their first attempt at attaining agility, Intralinks took a well-intentioned "mechanical" implementation of Scrum, but failed to deliver against their goal of greater agility. Teams adopt the ceremonies without changing how decisions get made. Stand-ups happen. Nothing changes.
Executive delegation. Leadership commissions an Agile transformation and then disappears from it. The responsibility for implementing a transformation is then delegated ever further downward. It must happen elsewhere. Eventually, it may land at the feet of an agile coach... someone whom few can spare time for, but from whom great results are expected. Again, this is a top-level executive failure.
Wrong framework for the work. Forcing a continuous-flow support team into Scrum sprints, or forcing a complex multi-stream product team into pure Kanban with no planning rhythm. The frameworks have different fits; picking the wrong one and then blaming Agile for the result is common.
Local optima without alignment. Spotify's exact failure mode. Teams gain autonomy without a strategy that ties their work to anything bigger. Twelve squads independently solve the same problem twelve different ways.
Design and research are treated as drag. The dual-track problem unaddressed. Designers get briefed inside the sprint or after it. Research is nice to have. The team ships fast and ships wrong.
What Good Actually Looks Like
The teams that make Agile work share characteristics that have nothing to do with framework choice or stand-up time slots.
A deliberate framework choice, not a default. The team has actually looked at what Scrum, Kanban, XP, or some hybrid is best suited to the work they do, and chosen accordingly. The choice gets revisited. It's not assumed.
Clear role ownership without role rigidity. Everyone knows what they're accountable for. Nobody hides behind their job title to avoid contributing to something adjacent. The designer talks to users. The engineer reviews the prototype. The product person sits in on usability testing.
Two tracks, one team. Design and Delivery are different cadences, but the people on those tracks know each other and talk constantly. Handoff is not a moment; it's a continuous overlap.
Honesty in the retro. Most retros surface process complaints. The useful retros surface uncomfortable truths. Teams that won't have the uncomfortable conversation will ship the wrong thing repeatedly.
Leadership that lets go of legacy governance. This is the one most organisations refuse. They want Agile teams operating under quarterly stage-gate funding, annual headcount planning, and waterfall-style status reporting. The teams underneath that contradiction burn out, ship slow, or both.
The Honest Take
Agile is not a methodology. It's a set of values and a small library of frameworks that try, in different ways, to honour those values. Scrum is the most popular implementation, but it is not the only one, and it may not always be the right one. Kanban suits flow-based work. XP suits engineering-heavy product teams that care about technical excellence above all. Lean and hybrid approaches suit teams mature enough to design their own process.
Most teams skip the work of choosing. They install Scrum ceremonies because that's what their last company did, fill the roles by job title, and assume the framework will do the rest. It won't. Any framework, on its own, is scaffolding. The architecture is the agreement your team has about what you value, who owns what, when handoffs happen, and how disciplines that aren't named in the framework actually fit in, and that agreement has to be written, revisited, and defended.
If your team isn't shipping the right things, the answer is rarely another stand-up. It's usually a longer, harder conversation about which framework actually fits the work, what each role is actually for, and whether the values underneath any of it have ever been agreed.
Sources
Agile Alliance — Manifesto for Agile Software Development. https://agilemanifesto.org/
Atlassian — Agile Manifesto for Software Development. https://www.atlassian.com/agile/manifesto
Atlassian — Agile Scrum Roles. https://www.atlassian.com/agile/scrum/roles
Atlassian — Kanban vs. scrum: Which agile are you? https://www.atlassian.com/agile/kanban/kanban-vs-scrum
Scrum Alliance — The Scrum Team Roles and Accountabilities. https://resources.scrumalliance.org/Article/scrum-team
Wrike — Kanban vs. Scrum: Key Differences Explained. https://www.wrike.com/kanban-guide/kanban-vs-scrum/
Mendix — Kanban vs. Scrum: How to Choose a Project Management Approach. https://www.mendix.com/blog/kanban-vs-scrum/
Monday.com — Kanban vs Scrum: Choosing The Right Agile Method In 2026. https://monday.com/blog/rnd/kanban-vs-scrum/
Monday.com — Extreme programming: a full guide to XP practices in 2026. https://monday.com/blog/rnd/extreme-programming/
Agile Alliance — What is Extreme Programming (XP)? https://agilealliance.org/glossary/xp/
freeCodeCamp — Agile Software Development Handbook – Scrum, Kanban, and Other Methodologies Explained. https://www.freecodecamp.org/news/agile-software-development-handbook/
CorsoUX — UX Design and Agile: Dual-Track Done Right in 2026. https://courseux.com/ux-design-and-agile/
GoodRebels — UX in Agile, better with Dual-Track Scrum. https://www.goodrebels.com/rebelthinking/ux-in-agile-better-with-dual-track-scrum/
Scrum.org — How to Integrate Scrum and UX with Dual-Track Scrum. https://www.scrum.org/resources/blog/how-integrate-scrum-and-ux-dual-track-scrum
DesignMap — Dual Track Agile for Designers. https://designmap.com/ideas/dual-track-agile-for-designers
Scrum.org — Case Studies (Intralinks et al.). https://www.scrum.org/resources/case-studies
Scrum.org — Twenty Top Fails in Executive Agile Leadership. https://www.scrum.org/resources/blog/twenty-top-fails-executive-agile-leadership
McKinsey — ING's agile transformation. https://www.mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation
Medium / Building the Agile Business — Agile Transformation at ING — A Case Study. https://medium.com/building-the-agile-business/agile-transformation-at-ing-a-case-study-907e0324c8c6
Jeremiah Lee — Spotify's Failed #SquadGoals. https://www.jeremiahlee.com/posts/failed-squad-goals/
Chameleon — Why Spotify Squads Are a Popular Failure for Product Teams. https://www.chameleon.io/blog/spotify-squads
The Post-Project World — Why Most Companies Fail When They Copy Spotify's Squad Model. https://medium.com/the-post-project-world/why-most-companies-fail-when-they-copy-spotifys-squad-model-bed4585c3896
Scrum.org — "Spotify Model" – 10 lessons in transplantology. https://www.scrum.org/resources/blog/spotify-model-10-lessons-transplantology
More Ideas
Thoughts, concepts, and ongoing explorations
