Why designers fail to integrate into Agile teams
Prescriptive Agile frameworks make it hard for designers to add valuable contributions to the team. Without discovery practices as part of the sprint, the product is destined to fail.
In 2011 I was a UX Designer in a design studio. Our design process was waterfall. I designed every detail in Photoshop before handing the mockups to the developers. After delivery, we prayed to the gods that the final product would work as designed. Guess what? It never did.
Desperate to find an alternative to our ineffective process, I stumbled upon Agile and it blew my mind. After failing to convince my manager to change our waterfall methodology, I joined a company where Agile was deeply ingrained in the culture. I was excited to be part of a cross-functional team and I could not wait to start working in sprints. But my excitement quickly turned into frustration.
I resented the fact that my creativity was confined to a two-week sprint.
I was used to creating the entire experience of a product, with complex and detailed features. But in my new Agile team, I was designing fragments that felt incomplete. I used to have control over every aspect of the design, but now I had to negotiate with engineers about every design decision. On top of that, I started to resent the fact that my creativity was confined to a two-week sprint.
But it wasn’t all that bad. Gradually, I began to appreciate the benefits of designing in an Agile environment. I realized that collaborating with developers accelerated the design process. Developers, with their technical knowledge, came up with innovative ideas that I could never have thought of. Besides, correcting mistakes within the small cycles of the sprint was incredibly efficient.
I discovered that my problem was not with Agile but with Scrum. Scrum is an Agile framework that puts a lot of emphasis on speed and efficiency. The prioritization of efficiency leaves little room for exploration and experimentation. To make things worse, the Scrum sprint does not include contact with users, so there is no way to validate the quality of the user experience.
The problem has never been Agile but the rigidity of some of its frameworks.
Fortunately, Agile states that we should prioritize interactions between people over processes. That’s how we refined our methodology one retrospective at a time. We created a more inclusive space for designers by incorporating practices from Design Thinking and Lean UX.
I have no particular quarrels with more flexible Agile methods like Kanban or Lean Software Development. Most of my grievances are directed towards Scrum. I believe its prescriptive nature is the primary cause of designers' frustration when joining Agile squads.
Scrum was created by developers
It all started in 2001 when 17 engineers defined a set of principles known as the Agile Manifesto to improve the development of software. If you haven’t read the manifesto, you should, it’s short and insightful.
The core principles of Agile, such as iteration, autonomy, and adaptability, align deeply with the essence of design. The challenges appear when integrating design practices into rigid Agile frameworks. The manifesto doesn’t dictate specific methods. It says nothing about backlogs, daily stand-ups, retrospectives, or user stories. Scrum invented those.
Scrum took shape in the early 90s. Back then everything was simpler. There were no mobile devices or micro-interactions, typography was reduced to web-safe fonts, and the layouts were constrained within HTML tables. At the time product design was engineer-driven, with designers limited to making the final product “prettier”.
With the evolution of digital products designers turned from executors of requirements to active participants in the entire product lifecycle. The conversation shifted from features to journeys. The generic user became a persona. And a good user experience turned from luxury to commodity.
The core principles of Agile, such as iteration, autonomy, and adaptability, align deeply with the essence of design.
To understand users and measure results you need discovery techniques. The problem with Srum is that it was initially tailored for feature delivery, not for uncovering user needs or validating product outcomes. That’s why the absence of research in the sprint presents challenges when integrating designers into Scrum. Modern product design demands discovery, experimentation, and validation.
Methodologies like Lean UX offer an alternative to bridge the gap between design and development practices. I’ve previously written about how Lean UX brings the best from Agile and Design Thinking. However, no methodology will work in an environment that doesn’t appreciate the value that design practices bring to the product and the team.
Velocity metrics limit creativity and innovation
People respond to incentives, often in ways that are not entirely obvious. During British rule in India a bounty program offered rewards for every dead cobra. And what happened? Well, people started breeding cobras for the reward.
Scrum incentivizes speed and efficiency, but success shouldn’t be measured by the speed of completed features. Success should be measured by the progress we make toward outcomes. An obsession with velocity metrics often results in teams becoming a feature factory, shipping deliverables without thinking about their impact in the users and the business.
The time constraints that Scrum sprints impose on designers, limit the space to think deeply about problems. Designers love to explore diverse paths and this clashes with the prioritization of velocity. When designers work under tight time frames, the tendency is to settle for the first safe, conventional solution. This encourages conformity instead of pursuing innovation.
Success shouldn’t be measured by the speed of completed features but by the progress made toward outcomes.
Balancing speed and efficiency with the iterative nature of design is crucial to create an environment where creativity and innovation thrive. Achieving this balance requires a shift from output-driven metrics towards a focus on outcomes.
There is no room for research during the sprint
You cannot state that your solution works if your claim is not backed up by the customer's feedback and the market data. It's that simple, without evidence your statement is just a hunch.
Every idea is an assumption until validated with users. Product discovery is a filter to discard bad ideas. It prevents us from wasting time and effort on building things nobody wants. We need to make sure that our solution is valuable to our users, works as intended, and generates the expected outcome.
The problem is that many Scrum teams resist integrating research practices into the sprint. Some hold the belief that talking with users will slow the team down when the opposite is true. It accelerates the project by preventing wasted efforts on unproductive ideas.
A common mistake is doing a big research project before starting product development. This is problematic. Separating research and development into distinct phases mimics a waterfall process. Integration of research into every Sprint is crucial.
Testing at the end doesn’t work either. That is not true discovery, is just seeking an “approved” seal. When the product is already built, there is little room to iterate. Any problems discovered at this point are usually ignored because of time constraints.
Research isn’t about scrutinizing every backlog feature. Research is about talking to users and learning within each sprint. It’s about validating and refining ideas grounded in data, not opinions.
Research is about validating and refining ideas grounded in data, not opinions.
By expanding our definition of done from “works as designed” to “validated with customers” we can change the teams’ incentives to prioritize research in the sprint. Rather than fixating on shipping features, the emphasis should be on satisfying customers’ needs.
I highly recommend reading Continuous Discovery Habits to understand the value of research in Product Design. It also offers great advice on how to integrate discovery practices into Agile frameworks.
Iteration is an unfulfilled promise
One of the main frustrations I’ve heard from designers working in sprints is the pressure to deliver something that feels incomplete — a half-ass product instead of a kicks ass product.
To be fair, this one is not entirely Scrum’s fault. Scrum prioritizes incremental iteration, but it also encourages revising features once you have user feedback. The problem is that teams often focus on the incremental part and forget about rethinking previous decisions. The hunger to get bigger can be stronger than the desire to get better.
Without iteration, there is no improvement. You’re not going to make the product perfect with one stroke
Digital products are complex and unpredictable. That’s why continuous iteration based on user and market feedback is essential. Without iteration, there is no improvement. Without iteration, we place designers in an impossible position, expecting them to nail the solution on their very first attempt.
Developers and designers should be best buddies
Design as a discipline leans heavily on intuition, differing from the reason-driven traits often associated with engineering. This is a powerful combo, much like the Star Trek duo of the logic-minded Spock and the emotionally driven Captain Kirk.
Diversity of ideas is a net positive. Teams operating in silos end up with bureaucratic requests, excessive documentation, and unproductive meetings. In contrast, by collaborating and sharing different perspectives, we reduce blindspots and get closer to the best possible solution.
True agility appears when teams adapt their methods to suit their needs.
Doing Agile it’s not about following prescribed frameworks. True agility appears when teams adapt their methods to suit their needs. Don’t be afraid to change the rules, Agile is flexible and open to customization. Explore alternatives like Lean UX. There are many ways to do Agile. Just remember to be committed to iteration, have great communication, and work on improving not only the product but also the team.
