One of the biggest mistakes I’ve seen in Agile adoption is the separation of design and development into different teams, each with their own Product Owner and their own Product Backlog.
On paper, it sounds organized - possibly even efficient. In practice, it’s a nightmare.
Let me tell you what happened.
A Tale of Two Teams (and Two Product Owners)
I once worked with a Scrum Team that outsourced their UX design to a third-party vendor. This vendor had their own Product Owner, their own Sprints, and their own development process. They worked one Sprint ahead of the back-end development team, the idea being that they would “hand off” polished designs to the developers just in time.
It didn’t work.
The designs often didn’t match what was technically feasible. Sometimes they looked great but didn’t align with our architecture. Other times, the behavior was buggy or inconsistent with the rest of the product. So we’d get the designs, discover the issues, send them back with feedback, wait one or two more Sprints, then try again.
It felt like a washing machine. Work just kept swirling around—back and forth, Sprint after Sprint—without going anywhere.
We tried everything - shared Refinement, design approvals, and then more approvals. Everything but the one thing that would have worked: working together as a cross-functional team.
Scrum Was Designed to Avoid This
Scrum is designed for cross-functional teams—teams that have all the skills necessary to deliver a valuable product increment together, every Sprint. That includes designers, developers, and anyone else needed to build the thing and make sure it works for users.
When you split the work into “design” and “development” teams, you’re essentially creating two products by defining the product too narrowly.
Why is this a problem?
Because now you have two sources of truth. Two definitions of success. Two backlogs that may—or may not—align. It’s no wonder things fall apart.
What to Do Instead: Integrate Design and Development
The solution is simple, even if it’s not always easy: when defining the product, start with the customer. If you're building a website, for example, then that is your product. If the product is a website, then you may need front-end developers, back-end developers, SQL resources, content writers, and more. Whatever your product is, build one product team.
When I say one product team, I don't necessarily mean just one Scrum team. I mean that there may be several teams working together to support a single product, with a single Product Owner and a single Product backlog. Each team may have a mix of different skills, such as back-end developers, front-end developers, or whatever else the team needs to deliver value. Every Sprint they work together to deliver functioning software. It works end-to-end. Not just design. Not just development, but everything you need to deliver value.
If you're building a website, for example, then bring UX designers into the Scrum Team as full members. Treat their work as part of the same Product Backlog. Let them collaborate daily with back-end developers to ensure that what gets built is both usable and technically feasible.
Here’s what happens when you do that:
Feasibility discussions happen before work starts, not after.
Product Backlog Items aren’t considered “done” until they’re fully tested, usable, and working.
Designers learn more about the technology. Developers learn more about the users. Everyone learns more about the product.
And most importantly? Work stops spinning in circles.
UX Isn’t a Pre-Stage—It’s Part of Delivery
Some people still think design has to happen “ahead” of development. But in Scrum, design can happen with development. UX research can inform the Product Backlog. Design ideas can be prototyped, tested, and iterated on within a Sprint. And as a team, you can slice work so that each Sprint delivers something real—something useful.
Final Thought
Design and development are not separate products. They’re two sides of the same effort to deliver value. Splitting them into different teams with different timelines and different leaders is a recipe for waste, rework, and frustration.
Scrum gives us a better way: cross-functional, self-managing teams working together to build the right thing, the right way.
It’s time to stop the rework machine and start building cross-functional teams that work together.