I have lost count on how many blogs and articles I’ve read about how UX and Agile can play nice with each other but no matter what “solution” was suggested, it always left me with a strange aftertaste. It turns out that almost everyone who writes about this topic has a UX rather than Agile perspective on the issue, which shows itself in a number of different ways:

• Agile is confused with Scrum
• Agile is thought not to be user-centric
• Agile is believed to only cover how to create code
• Agile is defined by practices
• The goal of Agile is seen as increasing productivity

Let’s be clear: Agile is a mindset and if you think you understand it without having it, you are most likely wrong. It’s like Morpheus tells Neo: No one can be told what it is – you have to see it for yourself. Nevertheless, I will point to two principles that are fundamental to Agile. This will not reveal the UX-Agile solution but it may explain why Agile practitioners are reluctant dance partners when well meaning UX practitioners proudly presents one attempt after the other at how to make it all fit together.

1. Avoid hand-offs
   When management as we know it came about with Taylor more than a century ago, one of the breakthrough ideas was division of labor, which in turn required hand-offs, standardization, thorough planning and command & control. When IT development became a thing, the production management culture quickly led to waterfall.
   Agile is based on a fundamentally different approach that aims to eliminate hand-offs by including all competencies needed to iterate on a product in a cross-functional team. This leads to end-to-end responsibility for the product. Even within the team, hand-offs are minimized by working together on few or only one task at a time rather than working in parallel or sequence. Firmly believing that the potential disadvantages of this approach are significantly outweighed by the benefits, is at the core of the Agile mindset.
   I am not going to go into details about the benefits here but just say that they can be counter-intuitive/difficult to measure and therefore hard to convince people about. Still, Agile practitioners will work to avoid hand-offs like the plague because they understand how important that is.
2. Deliver value as quickly as possible
   In a complex system, no one can predict with certainty what will happen. So until a product is actually being used, we have no real knowledge of the value it will create. Instead, we have assumptions and risk. Studies indicate that assumptions about the value of our product ideas are wrong disturbingly often. Further, we would rather have some of the value early and the rest of it later than all of it later.
   As a consequence, work should be segmented into the smallest possible chunks that we think will be valuable to the user and then deployed as quickly as possible so we can validate our assumptions and feed learning back into the next iteration. The more effort we invest in pursuing bad assumptions before they are validated, the greater the loss. Even worse, we will have a harder time accepting we were wrong, which could lead us further down a doomed path. That is why e.g. architecture and design needs to emerge as we learn and not be done up front.
   Again, there are undeniable drawbacks but also significant benefits from this approach. However, an Agile practitioner is convinced that the pros will overshadow the cons and that is why any attempt to systematically conduct work in phases will be met with strong opposition.

So, where does that leave us? I believe that UX and Agile need each other and in stead of waiting for the perfect solution, we should embrace the awkward and sometimes clumsy dance as long as we continuously work hard to improve. In my mind, the end-state is UX integrated with all other disciplines. Nobody thought it was possible with e.g. testing or operations but look at us now. UX is next.