Agile is a way of building products in short, repeated cycles called sprints, with frequent releases and feedback, instead of one big plan locked in upfront. It favors working software, close collaboration, and responding to change.
For UX, the catch is fitting research and design into that fast rhythm rather than a long, separate phase.
Use cases
Bolt UX onto Agile badly and you get rushed design with no validation, plus engineers rewriting work every sprint.
UX a sprint behind: Design is treated as a phase that doesn't fit the cadence, so designers scramble to feed engineering and end up shipping comps with no research behind them.
Shipping the wrong thing fast: The team releases quickly but skips discovery, so it builds a feature nobody needed, efficiently.
How it's used in practice
Work a track ahead: Run discovery (research and design) one step in front of delivery, so engineering always builds something already validated. This is dual-track agile.
Right-size research: Trade month-long studies for quick, continuous testing each sprint, so learning keeps pace with shipping.
Carry a shared vision: Keep a north star for the product so individual increments add up instead of fragmenting.
Embed the designer: Put UX in standups, planning, and retros instead of throwing finished mockups over the wall.
🪄
Pro-tip: "Agile" gets used as an excuse to skip research ("we'll just iterate"). Iteration only pays off if you're learning from real users each cycle, not just shipping faster. Protect research time the way the team protects code review. If your sprints have zero user contact, you're not agile, you're just fast.
Challenges & limitations
It was built for engineering: Agile came from software development, and UX research doesn't always fit neatly into two-week boxes.
Speed crowds out discovery: Pressure to ship can squeeze research, accessibility, and synthesis until they quietly disappear.
Cargo-cult Agile: Many teams adopt the ceremonies (standups, story points) without the actual responsiveness, so they get the overhead and none of the benefit.
Commonly used frameworks
Scrum — fixed-length sprints with set roles and meetings. Best for small teams that want predictable cadence.
Kanban — continuous flow with work-in-progress limits and no fixed sprints. Best for steady streams of work like support or ops.
SAFe (Scaled Agile Framework) — coordinates many Agile teams on one product. Best for large enterprises, though it can crowd out discovery.
