Agile anti-patterns that can harm UX — Part 1

7 min readJan 1, 2024

Across the globe thousands of teams use Agile practices and principles to develop software. I don’t think that it’s contentious to say that Agile has become the de-facto method by which ideas are turned into computer code, but whilst Agile is hugely popular and hugely influential, it has a dirty little secret. One which can seriously harm the success of products and services developed using Agile. You see, Agile was created by developers, for developers. Certainly, none of the founding fathers of Agile (for they were predictably all male) were designers and like an unwanted guest who never received a golden ticket to the magical Agile factory, design has never really got a look in.

From day one design, and designers have always had to fit around Agile, which has led to many teams following Agile anti-patterns. Anti-patterns which can lead to poor design, a poor UX for users and therefore less successful products and services.

In this 2-part series I will run through the 10 most common Agile anti-patterns that can really harm UX. For each I’ll outline what the anti-pattern is and more importantly how you can avoid it. Let’s start with Agile’s aversion to upfront design.

Zero upfront design

To some devout followers of the Agile faith, any upfront design work is considered heresy. I’ve even heard rumour of product designers being burnt at the stake for suggesting such a thing. Afterall, the Agile manifesto calls for:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Manifesto for Agile software development

The thinking goes that rather than wasting time on upfront design work, teams can rapidly cobble something together, release it, get customer feedback and then change it accordingly. The problem is that it’s surprisingly hard, surprisingly costly and sometimes surprisingly damaging to change something once it’s been released. A constantly changing product can be confusing for users. A constantly changing product can lead to lots and lots of design debt building up. A constantly changing product can be expensive to develop as poorly thought through ideas are quickly abandoned.

It shouldn’t be a case of zero upfront design, or months of upfront design, it should be a case of just enough upfront design. For example, 1-week design sprints can be a great way to rapidly design, prototype and validate a concept. See Making 5-day designs sprints more user-centred and 15 tips for running remote design sprints for more about running design sprints.

*Just enough upfront design can help set-up Agile teams for success*

The unicorn designer / researcher

Agile loves a generalist, a jack of all trades. The thinking goes that if you have specialists in an Agile team they can become blockers and bottlenecks. If your Agile team is full of generalists anyone can pick up any job that needs to be done.

This is why Agile teams will value full-stack developers over front-end specialists and will look for generalist designers / researchers over specialist designers and specialist researchers.

The problem is that not only is it nigh on impossible to find someone who is brilliant at design, whilst being equally brilliant at research, even if you can find a mythical unicorn designer / researcher, they are not going to be able to do the workload of two people anyway.

*Don’t waste your time trying to find a unicorn designer / researcher*

Rather than one unicorn designer / researcher it’s better for Agile teams to aim for a UX pair within the team. For example, a specialist designer and a specialist researcher, or a more generalist designer, paired with another designer (such as Oda’s design duo model). This better supports the parallel demands of design and research, plus it’s certainly easier to find two people with complementing design and research skillsets, than one person who can do it all. See Why there’s still a need for UX designers in product teams for more about why it’s important to have UX specialists in Agile teams.

Planning only a sprint ahead

The Agile manifesto advocates, “Responding to change over following a plan”. Unfortunately, many Agile teams interpret this as not needing a plan at all, or at least only needing to plan a sprint ahead.

Believe me, Agile teams do need a plan, and they need to think ahead of just their next sprint. When no long-term plan exists teams tend to make decisions that can make sense in the short term, but which they will later come to regret. For example, choosing a navigation pattern that doesn’t scale as the product grows, or inadvertently building lots of siloed features. An absence of long-term planning can also lead to lots of design debt being introduced due to the lack of alignment and co-ordination across sprints.

Agile teams don’t need to plan everything out, but they should certainly have a good idea of what the next 3–4 sprints will be focused on, and how this work fits into the longer-term product vision. A great way to do just enough planning is through user story mapping, a team exercise to break up user journeys and tasks into work for the team to undertake. See the excellent user story mapping resources from Jeff Patton for more about user story mapping.

*User story mapping can be a great way for Agile teams to do just enough planning*

Researching, designing & delivering work within the same sprint

If an Agile team doesn’t want to do lots of upfront design and research work, it can be tempting to try to research, design and deliver a piece of work, all within the same sprint. The Agile equivalent of laying the railway track, whilst the train is still running.

The problem is that in reality, this simply isn’t feasible for the vast majority of work. By trying to squeeze the design, research and delivery into a 1-week, or 2-week sprint, Agile teams inevitably end up trying to do too much. They have to make a million and one assumptions because there isn’t time to test those assumptions. They end up choosing the easiest to deliver design ideas, rather than the best because the sprint clock is ticking so furiously. They often end up releasing something that isn’t finished, because they are so desperate to get something out of the door.

Rather than trying to research, design and deliver work within the same sprint it’s better to have distinct, but interconnected discovery and delivery tracks. This dual-track approach (shown below) allows for ideas and potential opportunities to be explored and tested prior to being delivered. See Stop using Agile as a design process for more about how to use a dual-track process to ensure that design and discovery work can be carried out ahead of delivery.

*A dual-track approach is a great way to design and research work ahead of delivery*

Not iterating after releasing

Many Agile teams follow the mantra of, “ we’ll release it, get feedback and then iterate”. Good in theory, but not so good in practice. You see many teams that attempt this inadvertently fall into the feature factory trap. They release an early version of a feature, promise themselves that they will iterate it once they’ve got some feedback, but never do. They simply move on to the next shiny feature, then the next, then the next, until the early version of the initial feature is a long forgotten memory.

Agile teams certainly shouldn’t be iterating for the sake of it, but 9 times of 10 a feature will require iterating after its initial release. It’s therefore important for teams to plan for iterations, to allow enough time between iterations to gather some feedback and to consider what their criteria should be for further iteration. See this MVP madness must stop! for more about the importance of iterating after releasing.

Coming next

In the second article in this series find out about 5 more Agile anti-patterns that can harm UX, and how to avoid them.