Editorial
Trying to figure out how user experience (UX) fits into agile inevitably brings up a number of problems. Many agile methodologies seem to have decided that UX isn't really a part of the software development team, stating engineers can “do their own UX.” Some spackled the cracks with ideas garnered from the “Lean UX” book.
The “Lean UX” book is neither Lean nor UX. The UX community mostly disregarded the book for reasons including the model deprioritizing UX research, removing UX’s autonomy, reducing UX specialists to workshop facilitators, and the wild amount of wasteful exercises and meetings the model demands.
Most companies have learned or are in the process of learning that giving specialized UX work to just anybody is a high business-risk move that leads to poor products that need fixing later. So how do we get UX and agile to play nicely together? We have to start by understanding where it’s going wrong.
Agile and UX: Square Peg in a Round Hole?
Agile sees UX as a square peg they need to hammer into a round hole. Or the square peg is being taken off the board and thrown away for not fitting in. UX is siloed and excluded, and your company is committing the lean sin of “under-utilized talent.”
UX works differently than engineering: it has different processes, goals and tasks. Engineering often wants to ignore how UX work is done, and hammer it into how engineering work is done. This makes as much sense as demanding that your heart doctor and lung doctor work the exact same way as each other. They should do the same things, their tests and processes should take the same amount of time, and they should replace each other if one takes a vacation. It wouldn’t work for specialized doctors, and it doesn’t work on our teams.
Related Article: Bringing User Experience Metrics Into DevOps Development
No True Scotsman
The second problem between UX and agile is the “No True Scotsman” fallacy, when you dismiss criticisms by appealing to the purity of something. There are great models that show how UX and engineering can collaborate and work efficiently while being respectful to each discipline’s different processes, tasks and approaches. Yet someone always shows up and declares, “That’s not agile!”
We must stop acting like agile, scrum or lean is so pure that it will be ruined if a different role with a different process joins the team. Part of agile seems to be to keep fine tuning it for what works for your teams and product.
Learning Opportunities
Webinar
Apr
23
AI: The Essential Vitamin for a Healthy CX
Join us as we unravel the mysteries of AI adoption and discover the key to unlocking a thriving CX ecosystem.
Register
Webinar
Apr
23
Navigating Market Dynamics: Leveraging Reputation to Propel Business Growth
Join us to uncover the secrets of mastering reputation management in today's competitive environment.
Register
Webinar
Apr
24
The State of Outsourcing: At the Crossroads of AI, Quality, and Cost Savings
Learn how companies can maximize the results from their outsourcing investments.
Register
Webinar
Apr
30
Supercharge Contact Center Efficiency with Generative AI
Learn practical strategies to reduce post-call documentation time by over 8 minutes.
Register
Related Article: A Scrum Master's Learning Is Never Done
'Why Can’t We Code as You Design?'
Engineers sometimes tell UX practitioners something along the lines of, “It would be more agile if we sat next to you and coded what you’re designing as you design it.” While this sounds agile, there are two key problems:
- This isn’t even done within engineering. QA testers don’t sit next to engineers and check their code as it’s written. It’s an assembly line. A developer finishes a unit of work and passes it to the QA specialist for testing. The same is true for the UX-engineering relationship. It’s an assembly line where UX passes completed, tested work to engineers.
- It doesn’t account for UX’s process, which is to research, architect, design, test and iterate before declaring something ready for engineering.
Interestingly, engineering has a generally similar process: they have research spikes, UX’s design is analogous to their coding, and UX testing is the QA of UX. Like UX, engineers iterate, correct and improve as flaws are discovered in testing. UX can’t work in small pieces and pass them to developers as they go. We need to test what the customer perceives as their full workflow or task. It’s similar to engineering doing integration tests as well as unit tests; you must test everything in its context and flow.
Yet when UX wants time for their process, some True Scotsman will bark that, “UX is not agile or lean!”
Related Article: Should We Hand Over UX to Just Anyone?
Respecting Specialties and Processes
It’s time for us to get away from these judgments and false constructs. UX and engineering both have multiple specialized roles with their own needs, tasks, processes, approaches and timing. UX can't force engineers into User-Centered Design or Double Diamond. Engineers, agile coaches and scrum masters should stop trying to force UX into engineering methodologies.
UX can fit into most flavors of agile. However, since nearly zero of these flavors were created with properly-done UX in mind, it’s going to require creativity and flexibility. We must walk away from any software development methodology whose definition of “getting UX done” includes skimping on UX tasks, or having just about anyone do UX tasks. We must walk away from any definition of lean that sounds like, “Do the least you can to move to the next step.” That’s not what lean was originally about.
UX and agile work best together when agile understands and respects what UX does, who does it, the time it needs to be done well, and makes sure that UX is included at all levels of planning so we get the time and resources we need to do a great job. There’s nothing agile about reducing someone’s ability to do their job well.
Agile is about adjusting relationships and processes so we can release quality software on a reliable cadence, gather customer feedback, and do it better next time. Welcome the square peg. And throw away any beliefs in "pure" agile that will be ruined by a teammate with different needs and tasks.
Learn how you can join our contributor community.
