Marriage of Agile and UX – Why is it so challenging?

Agile methodologies originally did not encompass user experience design or acknowledge the role of UX designers. Instead, agile teams focused on improving products based on customer and stakeholder feedback through iterations. One reason UX design is absent in Agile approaches is that Agile was developed by developers for developers, aiming to enhance the traditional waterfall model prevalent at the time, where development teams worked on large projects in a sequential manner. The omission of the designer's role in agile teams may stem from the assumption that agile methodologies solely concern the coding phase. However, deciding what to build and how it should function for users is equally crucial, as is doing it well. There's no point in creating something incorrect or unnecessary quickly and efficiently.

The Agile Manifesto was published in 2001 and has since accumulated many myths and misunderstandings. Most of these stem from anti-patterns and challenges that UX designers encounter when implementing User-Centered Design in agile teams. Let's examine these misconceptions related to the Agile approach.

While it's true that agile methodologies often help teams build digital products faster than they could in a traditional waterfall process, the problem lies in the misconception that "faster" is the primary goal of agile. Sometimes, striving to build faster can actually be harmful. If we're running in the wrong direction, running faster only takes us further away from where we intended to go. Agile emphasizes quickly delivering software or its components into the hands of users. This can easily lead to misinterpretation: "Let's deliver it to users as quickly as possible and move on to the next thing." However, the true aim of agile is to swiftly present the work's outcomes to users so that we can gather feedback and continuously improve.

In such teams, UX researchers and designers often work faster to constantly feed new elements into development. Programmers and management focus almost exclusively on speed and burndown charts, with the primary success criterion being the number of features delivered. Such teams often transform into "feature factories" that simply churn out functionalities one after another, without iteration or even measuring effectiveness.

This approach can result in significant technical and UX debt because all effort goes into creating new things as quickly as possible, without considering how they fit together. It's not uncommon for designers to complain about not having time to think through designs or conduct user tests. In such situations, it's valuable to ask the team: How will we know if the functionality we're building will be successful? What are the indicators? How will we measure it? It's also important to pay attention to previously built features. If the team rushed to deliver new functionalities in recent sprints, it's crucial to find out how they're performing with users. If such information is lacking, it might be worth conducting research or analysis to determine if those functionalities were worth building at all.

Understanding the desired outcome of a feature will help refocus the team on not just getting things done but ensuring they are useful to end-users. This way, if a feature doesn't achieve the desired result, there's a good reason to continue working on it until it truly meets its goal, rather than just being deployed hastily.

This belief is particularly challenging to understand because the idea of receiving continuous feedback from users is central to the Agile Manifesto. However, in practice, while some agile teams excel at gathering feedback on already released products, they often neglect exploratory research focused on uncovering user needs and innovating within the product.

A common manifestation of this issue in teams is the phrase, "We don't have time for research," coupled with assigning UX designers tasks like "creating mockups" within a few days, with absolutely no time allocated for user testing. This occurs when research is perceived as the job of a separate team or position. Even in interdisciplinary teams comprising designers, developers, and product specialists, research is often sidelined or utilized only for specific purposes, leading the team to view research as someone else's responsibility.

Another reason for this gap may be the belief that research needs to be time-consuming, treating it as a major event in the project's lifecycle. Some teams try to compensate for this by starting with a "sprint zero," which is essentially a single sprint dedicated to research and design before technical development begins. However, not all research and projects fit neatly into a single sprint.

To address this, we need to embrace the interdisciplinary and multifunctional nature of agile teams, which means involving everyone more deeply in research. Instead of viewing research as something done by an outsider or a designated individual, the entire team should take ownership and collaborate on experiments and studies to gather insights and data. This can be done in various ways and doesn't necessarily mean halting technical work while every developer conducts user interviews. It involves finding ways to automate user feedback collection to the extent possible and establishing a rhythm for user interaction, such as usability tests or in-depth interviews.

For example, a method like "Four on Friday" could involve scheduling user interviews on one day (e.g., Friday) during a sprint, inviting team members in different roles to observe these sessions and thereby consistently increase the team's understanding of users. It's important to remember that research is essential for creating products that solve real problems, and understanding users isn't something a team can delegate to someone else.

The iterative and incremental nature of work in agile teams can lead to another misunderstanding: that Agile prevents a comprehensive vision and product design. In agile teams, user stories are often broken down into small pieces or tasks. This can mean a designer receives one of these tasks and is asked to create a mockup. Attempting to design a single screen for a specific feature without user research or understanding the overall context can result in a subpar outcome. To create a truly useful interface, designers need a good understanding and insight into how everything will work in the rest of the product. Designing a single screen in isolation from the whole can lead to the need for later rework.

There are several ways to approach this. Many agile teams start by building the simplest possible thing that will work. Then, as we need something more complex, we want to rework the functionality (interface and/or code) with new items. The advantage of this approach is that we never do more work than is absolutely necessary. For users, a simple version may be completely sufficient or they may switch to a completely different way of using the functionality, which is fairly common these days. Rapid technological development is changing many of our habits.

When designers, due to the fast pace of ongoing tasks within the team, feel they don't have time for real research or broader design work, they may find themselves in a situation where they feel they don't have time to create typical artifacts for UX Designers. Sometimes, this isn't necessarily a bad solution - not every project or every stage requires pixel-perfect mockups, a set of personas, or a Customer Journey Map. What's important is creativity and flexibility in how we define and select the artifacts we deliver.

Again, the myth of lacking deliverables or artifacts arises from a belief in insufficient time or actual lack thereof. As designers, during studies or agency work, we spend a lot of time creating artifacts independently, which are visually polished and conceptually refined because we are evaluated on both aspects. In agile teams, artifacts delivered by UX designers are primarily a means of communication rather than an end in themselves. Because good agile teams are interdisciplinary by nature and people work closely together, this can naturally reduce the demand for highly detailed and refined artifacts.

Other factors, such as having a solid design system and ensuring everyone on the team understands the user goals and business objectives for a specific functionality, mean that design can be conveyed even in written form or through a conversation between a designer and developer.

We also need to rethink how we communicate UX research findings. Instead of a full 100-slide extensive research report that takes a month to create, findings can come directly from analysis and synthesis sessions involving the whole team. It could be a two or three-page summary of key insights and recommendations that are easier to implement and can be reviewed by the entire team.

None of these things mean a lack of artifacts. The role of a UX designer or researcher remains to communicate information to other team members and ensure continuous learning about users, often requiring a means of communication. The most important thing to remember is the flexibility of approach. Not every feature change requires a fully interactive prototype or a perfect mockup. Not every study needs to be described in a large report. Instead of defaulting to maximum documentation, it's valuable to ask: What's the minimum I need to do to convey everything I need to? Perhaps it's a conversation with a developer and an Excel spreadsheet with error message texts. It could be a well-written user story and a few wireframes. It might involve direct collaboration with a programmer to solve a problem while writing code. But it could also be a meticulously crafted pixel-perfect mockup and a fully interactive prototype – these have their place too.

We should treat the artifacts we deliver – as designers – like any product. Therefore, understanding what our users (in this case, our team colleagues) need and finding the most effective way to provide it is crucial.

And one last important point: Sometimes, the decisions we make need to be documented. This helps us remember why we made them and what exactly they were. All to ensure we can communicate effectively with future versions of ourselves or in situations where the team composition changes.

Although no two agile teams are alike, certain common patterns can be identified. Good agile teams are interdisciplinary and autonomous, working iteratively and incrementally, which enables smooth communication and continuous improvement of both the product and team work. Learning to work in an agile team is challenging for designers because each team is different, even within the same organization. There is no perfect design style; instead, it's about continuous experimentation, learning, and adapting to the team's needs and circumstances.

It's crucial to understand that there's no one-size-fits-all technique or methodology that works perfectly in every team and situation. Depending on the specific patterns.