Agile & UX: a failed marriage?

Published in

UX Collective

20 min readMay 30, 2023

A spring being pulled in different directions.

This article analyses the integration or attempted integration of User Experience & Design (UX) into the Agile software development model/philosophy. It argues that despite several attempts at striking a balance between the two, a fruitful integration between Agile and UX design remains stubbornly hard with limited examples of true success. It is based my personal experience as a UX/D leader and management scientist, and does not represent my organisation. Lastly, I’ll write a follow up article on ideas to help save this marriage; it will explore ways to overcome these challenges in ultimately building and scaling an effective UX/D org.

One more article on Agile & UX?

This article is based on a decade + of experience with top global corporations across domains, countries and maturity levels. It provides a real world view of the challenges that UX practitioners and Agile delivery teams face in the world of software/product development. It identifies and operates on the basis of three fundamental principles:

Agile and UX have little in common; the former is a development philosophy and the latter is a domain.
The integration of UX into the Agile delivery process was a necessity, not a choice.
Agile leaders do not usually from a background in UX (design or research).

There are, probably, examples of Agile and UX done well, and so this article is neither an exhaustive study of the application of Agile and UX nor a panacea. It utilizes the author’s point of view as a UX leader in the field to identify deep rooted challenges, and cautiously, offers some suggestions that could help better realize the potential of UX teams in Agile organizations.

I also want to stress that this article, in general, focuses on the implementation of Agile development models in larger, traditional, slow organizations, especially those undergoing transformations (and often have implemented complementary systems such as the chapter model).

What is Agile development?

It is futile to attempt to build consensus on what Agile is (or is meant to be). A brief review of the plethora of content on Agile suggests that it:

is an approach/philosophy to software development
values delivery/speed over perfection
accepts change as a constant and seeks to respond to it
proposes small, empowered teams lead by a Product Owner

I continue with this article assuming you understand Agile as it tends to exist in modern companies, and have either participated in, or have at least heard of, the popular Scrum framework (often used synonymously with Agile) as well as the typical ceremonies that constitute Scrum (Backlog grooming, Spring planning, Standups, and Retrospectives). If you are unfamiliar with Agile or would like to further your knowledge of the subject, I have suggested some readings at the end of this article.

The need for Agile

Created by a group of software developers in 2001, the agile methodology, which helps project teams achieve objectives quickly in rapidly changing or unpredictable environments, is now being used broadly throughout organizations. But being Agile and doing Agile are two different things.

By now, most businesses, new and old are familiar with Agile. While newer ones, such as Atlassian, Uber or Airbnb were born Agile, others such as Amazon, Telstra, and the major banks have been undergoing Agile transformations. The challenge of implementing Agile at scale, especially for companies that were not born Agile, is a peculiar one, and I recommend reading this HBR article that presents a balanced view on how such scale can be achieved.

I argue that Agile was born out of the frustration of changing requirements, context and technologies. In the pre-Agile world (you can think Waterfall, but it’s a little broader than just Waterfall), companies attempted to understand things fully before they built/invested in them. This caused several issues and often meant that by the time the ‘requirements’ were clear, it was too late. It is this constant frustration of playing catch up that resulted in a change in philosophy, which culminated into Agile. The way I look at it is:

Agile is a resignation to the fact that we’ll never know enough (to make sound decisions).

What is UX?

At the risk of self promotion, I suggest reading my article titled The UX Pyramid, to understand the field of UX & Design. I’ve tried to provide a framework that helps conceptualise UX as a domain, and help hold together the various facets of UX. A brief recap won’t hurt. UX, as it exists today, is the domain which deals with designing interactions between users and technology based on an understanding of the users’ needs, contexts, challenges, and eventually, goals. In the same breath, let me also stress that I stay clear of generalizations such as “UX is everything” or “UX is problem solving” etc., which while not untrue, are not helpful definitions. So, throughout this article, I am looking at UX in a narrower sense than some people believe it to be.

The field of UX has undergone a rapid transformation. Many specialisations, such as User Interface (UI) design, UX research, Interaction design and Service Design have emerged. Even seasoned UX professionals have struggled to keep up with these changes, so much so that a shared understanding continues to evade us. This is one of the primary challenges in the marriage between UX and Agile; UX professionals themselves cannot come to a consensus on what does UX mean; consequently, it is next to impossible for Agile leaders such as Scrum Masters or Product Owners to grasp it with clarity.

In most cases, the job of a UX designer (let’s assume a UX researcher + designer to keep things simple for now) in a stereotypical company is to take input from the business, add to it an understanding of the user, design fundamentals, and ideally systems/technology, and propose how something will work/be used by the end user. Very few companies start with a bunch of UX designers designing the product from the start; most of us spend time building or improving features into existing products (despite many claiming to be product designers, which in my experience is a pseudonym for a UI/UX designer).

For example, when I worked at Atlassian, a well known software giant that makes the popular Jira and Confluence suite of products, I worked on the administrator experience for Confluence. Basically, this meant that we were trying to, in conjunction with the product manager and technology lead, design the user interface for Confluence administrators as new features were being added to the product (and hence needed to be administered). We had very little say in what those features might be, a function that we can call strategic UX (that informs utility and not just usability). Rarely do UX practitioners design something from scratch, and when they do, Agile dictates that a new product be developed incrementally. So, can you design incrementally?

The typical software development process

Agile promotes the now ubiquitous idea of incremental development which limits risk and maximizes the opportunity to learn and pivot. While this idea seems conceptually sound, the reality is often very different.

In the typical modern company that follows the Agile development model, a program of work usually starts with certain themes that the business leaders want to pursue. Think of a theme as a broad idea, which when refined, will result in a series of potential projects, or what are called roadmap items. How these are decided and prioritized is a separate discussion, and again, in my narrower definition of UX, UXers have a limited role to play in this process, even though some might want to be more involved.

A case study

Let’s use an example of a telecom company to continue this this discussion. Imagine, you are the Product Manager responsible for the post-paid mobile portfolio. You want to offer a new International Roaming service to existing customers that will replace an older, clunkier system that customers could use to roam internationally. We’ll skip the reasons for why you think this is a good idea; let’s assume it is one. This could be considered a theme. It can be broken down into features, based on how users will use it (i.e. buy, use, and manage international roaming passes), as a well as several back-end features that’ll power the new offering. How do we go from this high level theme to the detailed user experience? This is where the what should happen vs. really happens starts to diverge.

What should happen

What should happen is that based on a collaborative process, an end customer vision, usually produced by a service designer or a strategic UX designer, is created. A customer journey map is a very simple idea: a diagram that illustrates the steps your customer(s) go through in engaging with your company, whether it be a product, an online experience, retail experience, or a service, or any combination. This journey map(s) explains the sort of potential experience a customer might have in relation to the theme (international roaming). In case of your theme, a journey map (or a similar artefact, such as service blueprint) might include the phases through which the customer will interact with international roaming as well as the set of tasks (based on, let’s say, the Jobs to Be Done framework), which will then translate into feature requirements) that each of those phases will support.

Requirements, at this stage, are meant to be high level i.e. the product defintion/construct will emerge. For example, some requirements for the international roaming theme might be:

Ability to use in 70 countries, split into 3 zones, which each zone having a relationship to a fee structure.
Ability to purchase for 7, 14 and 30 days with corresponding usage/data packs.
Ability to run promotions on certain packs.
Ability to cancel anytime, with prorated refunds.

These high-level requirements describe the what, not the how. I’d stress that these requirements are not enough for the technology teams to estimate or build the features. From here on, the user experience definition process kicks in, following the

user-centered design process: empathize with users, define pain points, ideate solutions, create wireframes and prototypes, test and iterate on designs. Through this process, more detailed requirements emerge, the sort that define the user experience, what developers and the technical/delivery focused Product Owner (PO) care about, and actually determine feasibility, such as:

Users will be able to search through the countries either by name or by zone. The default view will be zonal.
Pricing will be displayed both by individual countries and zones. You will be able to purchase multiple packs if you choose to, but in most cases it will make better financial sense to buy by pre-defined zone, which we’ll inform users about.
Users will be able to view their active roaming packs under My Services (imagine this is an existing view). The packs will display the price, usage and expiry information. Users will be able to renew their packs if a. their usage balance is nearly finished or b. they are two days away from expiry.
There will be a new section for available promotions to be shown. Based on a user’s purchase history, certain promotions can be prioritized and shown first.

While these are imaginary details, you can see how much detail has emerged from the business requirements that is both functional and UX driven. When the interaction designs are fleshed out, more details will emerge, which then will go through usability testing for refinement.

Not all these emergent requirements will be prioritized, to determine which tools such as user-story mapping can be utilized, but in principle, you’d want to work backwards from the envisioned experience before breaking the delivery plan down into a prioritized list leading to a minimum viable product (MVP).

What usually happens

Using the same example in the previous section, the business determines the need to offer international roaming for its customers. They want to know how much ‘it will cost’ in term of time/energy. In the context of technological corporations, the business executives need to rely on their technical staff to help figure out the cost and a delivery estimate, usually software architects, who get involved and attempt to figure out the solution, which will inform the rough ‘cost’. No design professionals, of the various flavours, are involved at this stage (a theme I will write about next). The problem is that without detailed requirements, these estimates are just guesses and worse, the ‘solution’ that is defined will often act as a constraint when UX designers do end up defining and refining the detailed requirements. A delivery date and schedule is created taking into account system complexity, build estimates and delivery team velocity. If prioritized (based on these estimates), the work is then handed over to a PO and their team (or multiple POs) who start to plan the work in sprints. Further, the PO and their team are often funded based on these commitments.

So, instead of working backwards from the customer’s experience, the team starts to work backwards from the delivery date and capacity schedule.

The work is then broken down into user stories, typically by business analysts. Examples might include a story for finding international roaming passes, another for comparing and another for adding to cart/buying. This is when UX designers tend to get involved and as you might guess, are now left with a specific piece of work; ‘design the add to cart experience’. If the UX designer seeks to actually conduct research and design the optimal add to cart experience for this new roaming pack, they will often face pushback and be requested to utilize existing components ‘as there isn’t enough time to build new ones’. Similarly, if the UX designers design a search experience to make it easier for users to find the country(s) of interest for the roaming pack, they’ll be told that we do not have a capability to power the search experience (and we don’t have the time/money/mandate to build one). If the UX designer pushes for something new, the PO would argue it as ‘scope creep’. This is, in my experience, a classic Agile and UX tension point. To counter this, I argue that:

UX does not add to scope. UX helps define and refine the scope, which then, can be prioritized and delivered incrementally. Defining and refining the details, which often will require new capabilities, is a UX prerogative; however, choosing what to build and when, is not.

So, in such cases, the user experience has been practically defined by virtue of the constraints imposed by the timelines and the existing technology and there is very little value add the the UX designers can provide. And all of this is, frustratingly, packaged as Agile, which assumes that the experience (+ features) will be improved iteratively. That sounds good on paper but has two problems:

If you don’t envision the end UX (as far as possible) to begin with, you will struggle to iteratively build because the foundational architecture, is often, not designed/built in a way that allows for such incremental addition. You’ll be stuck in an optimization trap.
More often than not, the MVP becomes what I jokingly call the practically last release (PLR) because priorities change and the team moves on to something else.

Encapsulated in this simple case study are a number of challenges, which I discuss in the following section.

Fundamental challenges — based on experience

The case study tried to highlight how the software development process typically works in many organizations, including several that I have worked with, and explained the limited role UX designers play in the process of bringing a new feature/proposition to life. This section articulates these challenges as well as explains why they contribute to poor user experiences that often never get fixed.

Philosophy

The Agile philosophy, as I have argued and exemplified, is based on the premise that products are best built and released incrementally. While there is nothing wrong with this approach, especially if deployed in a sound manner, it differs from the basic philosophy of UX design. UX seeks to be holistic. The job of a UX professional is to bridge the complexity between the users’ needs and a system’s capabilities through a digital medium. UX, by its very definition, seeks to envision and connect. My question to those who understand both these fields is: How do you envision an experience incrementally?

I argue that you cannot and should not. Stalwarts from Steve Jobs to Jeff Bezos have stressed on the need to work backwards from the customer experience; i.e., envision the end state that solves the customer’s needs and THEN figure out a way to deliver it, which can certainly be incremental. While Agile does not, in theory inhibit this, most organizations are setup in a way that UX teams only get involved when work has been defined and committed to.

Organisational design

Where should UX teams sit in an Agile organisation? I have worked with companies where they’ve resided in engineering/technology, product, customer experience, digital, and even their own vertical. The choice of where the function sits should be based on organisational maturity, for example, newer companies tend to have them bundled with engineering (and therefore the designers tend to be UI designers who are helping the front end developers code) and more mature ones might to have them sit in either product or standalone orgs.

The challenge is what follows. Most companies that are Agile tend to have cross-functional mission teams working on a product or feature. In the case study, we saw that there were two distinct teams: first, the business and architecture group and second the PO and their Agile delivery squad. Hidden behind this seemingly simple structure is much more complexity. For example, while UX teams work with the PO and their squad (who only swing into action once the work is defined and prioritized), they have a role to play, arguably a fundamental one in helping the business and solution architects understand the sort of experience that will emerge (and therefore should be considered when estimating timeframes/investments).

Even if they had a seat at the table, who decides whether they should invest their time into something that has ‘not been prioritized’? The UX manager? The Agile PO? Or someone else. Further, in many newer, flatter organizations, the UX manager has a limited role to play when it comes to such decisions (vs. companies like Amazon where they DO have a voice) as that is the PO’s prerogative and the PO has no incentive to get involved (either directly or via their proxies) into the definition process unless it is prioritized and committed to.

So, by virtue of being part of the PO’s squad, UXers are impaired in their ability to influence early stage thinking, which in turn results in improperly defined business requirements that are now sacrosanct because of the delivery schedule that has been committed to. I’ve seen companies add service designers earlier in the process to counter this, but that leads to more silos and further split loyalties.

Sources of prioritization

Even if a user-centric envisioning process is followed, which would result, as alluded to in the case study, in a set of artefacts (journey maps at a high level, wireframes and interaction flows at a more detailed level), prioritization of key features (loosely user stories that power a given feature) is hard and Agile’s solution to this challenge is the concept of an MVP. However, in most cases POs are working off a set of constraints (technological and financial) and trying to meet delivery deadlines to push things out of the door. In my experience, features are almost always prioritized based on feasibility, with little or no regard for any user research or insights that might suggest otherwise.

Scope/Requirements

There is a fundamental difference between business requirements and detailed, user requirements (hence the term user stories) that are based on how things work. UX should play a primary role in defining how things should work (within reason of course, skilled UX designers are also expected to understand the overarching constraints and not run rogue). However, I’ve often seen POs take the high level business requirements, look at existing capabilities and chart the shortest route to those requirements without allowing for an exploration of possible functionalities for an optimal UX.

This means that UX designers are often retrofitting the UX to what the PO wants or has committed to. Think of this as de facto design — design that emerges without designers — effectively meaning POs seek a final UI artefact so that the front end engineers have specs to build against. What they (and many of us) don’t understand is that UX deals with functionality — how things work from a user’s perspective, not merely how they look. And when you define how things work (such as the ability to search for countries in the case study), you are defining, or at least further refining, requirements.

The whole idea of Agile is that requirements will never be clear. I find that too often, POs use the business requirements (+ their own view of the details) to deliver the whatever is feasible and on the other hand, use Agile and it’s philosophy to push back on UX efforts, arguing about the value of an MVP, and countering any additional functional definition as scope creep, scope that they often arbitrarily decide based on the constraints we discussed.

In such cases, we really ought to point to where the problem lies. My suggestion is that:

When requirements are clear, mechanistic processes work better than just calling something Agile. If you know what you want to build and how it will work for users, you do not need a UX designer, because you have, in fact, already defined the user experience.

Measurement and rewards

A foundational component of Agile is to test and learn. However, this is easier said than done in practice, and I empathize with POs who have to continuously shuffle priorities and move on to the next big thing. What this means in practice though is that decisions, whether product or design, are released with an ‘MVP/test and learn’ approach, but marco-organizational factors such culture, priorities, resources and capabilities, inhibit the PO’s ability to effectively do so. On this topic, I recommend this HBR article for understanding the challenges organizations face when it comes to making decisions that delight customers.

Add to this the multiple kinds of POs that exist in large organisation. For example, at one of my previous organizations, there was a Business PO (who sat within the product vertical), a Digital PO (effectively someone who helped deliver the theme in a digital context, because a piece of work might not be limited to the digital channel), an Experience Owner (EO) who was responsible for making sure that the multiple, interrelated customer journeys make sense in the long term, and the Technical POs, who actually ran the Agile delivery squad. But who is responsible for measuring and testing the hypotheses that an MVP is meant to assess? And if you say, everyone, then it really means no one.

I find that the Agile view, of a PO centric cross functional team, is overly simplistic and breaks down in larger organizations. The struggle for UX designers is exacerbated by this complexity. They are closest to the TPOs (because they tend to be part of the Agile squads) but as discussed earlier, their impact should be at a stage much before the TPOs get involved or interested.

Rigour

A related challenge of Agile’s test and learn, iterative approach is that it assumes a great degree of rigour in the planning and delivery process. This would entail envisioning the user’s experience, working backwards to groom features, mapping out the user stories, and deciding on a release schedule. Along this journey, the UX designer and PO will need to diligently capture hypotheses or assumptions and either seek primary data to clarify or design a test in production as part of the next release, with the commitment to change the product, should the results point that way, in the subsequent releases.

However, roadmaps for POs is always oversubscribed and very rarely, unless something is broken, have I seen the rigour and discipline required to continuously test and pivot implementations in the real world. The lack of rigour is not down to the POs; UX designers, even when properly embedded in an organization, do not always have the necessary skill to judiciously find gaps in their own research and work with the POs to either mitigate the resulting risk or further investigate via in-production testing. Add to it, at least in Australia, the fleeting careers that designers have in an organization, which hampers their ability to truly understand the user’s needs and behaviours, as well as organizational pressures.

UX planning

An interrelated challenge to organizational design and measurement is that of UX planning. Depending on how an organization is structured, the UX team might ‘sit’ in one area or another. However, I have never seen UX integrated in a way that the UX resources in a team are part of the same planning process that other members of the Agile squad, such as developers or testers, are. One might make the case, based on my overall premise, that UXers should not be subject to the same sort of planning (measured in story points), similar to perhaps the Business Analysts or Solution Designers in the team, but certainly UI designers should?

Various methods, most commonly of having design sprints that run a couple of weeks ahead the development sprints, have been tried. However, I contend that these don’t work for two reasons:

Lack of clarity around who owns the design sprint. In the Agile squad, the Scrum Master and the PO are responsible for sprint planning, but when design sprints exist separately, in most cases, the Scrum Master or PO have little interest in taking over the planning of yet another set of activities, which in the end, are not measured when it comes to available team capacity (as reflected in a burn down chart).
UX capacity is not measured as part of the team’s delivery capacity, which means that UX becomes some sort of an extraneous, good to have, activity, the absence of which does not cause a risk/become a blocker to the delivery (in the narrow sense of delivery).

To put it crudely, there is very little incentive for POs or Scrum Masters to actually measure the efficacy of the UX resources assigned to their squads. No one asks them to do so, and no one trains them on how it can be potentially done.

Room for strategic UX

When UX is part of, at least nominally, an Agile squad lead by the PO, their ability to influence work at a more strategic level, which is usually upstream and earlier than the rest of the Agile team gets involved, is severely curtailed. We saw in the case study that by the time the UX designers start to explore design solutions and define “how will international roaming work in relation to mobile app users”, it is already too late and the existing mechanisms prevent any meaningful exploration and push towards delivering something within the committed timeframe.

Beyond the obvious impact on the quality of the user experience, this also has a more insidious effect, that of demoralizing the UX team, as often they end up feeling like they are being asked to move pixels and help visualize an already defined user experience. This not what a capable UX team or designer brings to the table, and while some might be able to don the UI hat, that is a bonus. I attribute the continuous push to be to the left on the ‘design spectrum’ down to this issue, with visual designers wanting to do ‘more UI’ and UI designers wanting to do ‘more UX’ and UX designers wanting to do ‘more service design’ and service designers wanting to do ‘more CX’. Inherent in these desires is the aspiration to work on something beyond pixels.

The role of the PO

In large organizations, as pointed out earlier, the all encompassing PO role, as Agile envisioned it, does not exist. There are multiple POs, PMs, TPOs, DPOs, BPOs. Everyone is a PO and everyone has a say in the overall CX. While CX should be everyone’s concern, the lack of clear responsibilities can cause lots of challenges for UX designers. In delivery focused Agile teams, I’ve encountered POs (who are essentially TPOs that are tasked with delivering something that has been mostly defined) push back on UX research or UX driven scope definition, often relying on the ‘PO’s prerogative’ to make the calls when it comes to what’s valuable for the customer.

Again, the issue with this approach is that when it comes to defining requirements, TPOs rely on the business to hand them over to them/their team, but if the UX designers (who are often part of their teams) seek to add any serious input into the functionality, they’d fall back on being POs who call the shots (and effectively block any such activity). Most such delivery focused POs are often disconnected from the users and the context of use, something that a proper PO should be committed to doing. As a thought experiment, ask your delivery focused PO when was the last time they participated in primary user research, or even better, campaigned for it (and beyond politically convenient asks like ‘we should do some quick and dirty testing; good research is neither!).

Summary

We’ve explored the challenges that plague the UX & design profession especially in a world of Agile-based delivery and chapter-based structural models. I used a real-world case study to help paint a picture of how feature definition and delivery works in many, Agile-embarcing, companies. Further, we talked about the a host of related challenges, ranging from organisational design to measurement and incentives, all of which contribute to this ongoing struggle between Agile and UX/design.

I suspect that much of what I have described can also be explained by virtue of UX/D being an emergent field, still trying to find its place in the value creation pipeline. As the field matures, with better leaders, more supportive organizations, and UX/D professionals sticking around longer than they tend to, the value that we bring to the table will become clearer, both for us and for our stakeholders.

In part two of this article, I will propose some possible ways to assuage these challenges and exploit the true potential of UX/D teams.

References and further reading:

Have we taken Agile too far? HBR. https://hbr.org/2021/04/have-we-taken-agile-too-far
How we finally made Agile development work. HBR. https://hbr.org/2012/10/how-we-finally-made-agile-development-work
Embracing Agile. HBR. https://hbr.org/2016/05/embracing-agile
Mapping User Stories in Agile, Nielsen Norman Group. https://www.nngroup.com/articles/user-story-mapping/
What are Chapters in an Agile Operating Model. Adaptovate. http://adaptovate.com/en-au/agile/what-are-chapters-in-an-agile-operating-model