Agile Is not Easy for UX: (How to) Deal with It - NN/G

Find the training option that fits your learning style.
September 24, 2017 2017-09-24
Agile has taken over the software-development world. In recent years, it’s become the most popular software-development methodology. Agile development has a lot of benefits: an incremental approach, the ability to change direction based on customer and stakeholder feedback, short timeframes that keep the teams focused.
However, Agile methodologies are focused on developers. They grew out of programmers’ attempts to solve common pain points experienced during big software development projects. Notoriously, the Agile Manifesto (still the primary document delineating Agile principles) did not include UX people, nor did it account for the time, resources, and research that UX professionals need in order to create excellent designs.
Under an Agile paradigm, the entire team works on the same elements of a project simultaneously in order to avoid “throwing it over the wall” (i.e. hand it off from one team to another, waterfall-style). The work is done in “sprints” — commonly 2-week periods when the team focuses on certain features, and then moves on. As a result, designers are under enormous pressure to create, test, refine, and deliver their output unrealistically fast, and with little of the context and big-picture thinking that suits consistent, user-centered designs.
There's is nothing wrong with you if are a good UX person having trouble making Agile work in your organization. It's difficult. The rigid way in which Agile is often implemented in large organizations (typically, using Scrum or similar methods) can make things even more challenging. 2-week sprints can force tunnel vision on the design team, who may be so focused on a particular feature or the user story at hand that they may ignore the large-scale product and design implications, such as integration, omnichannel consistency, or user-interface architecture.
However, all is not lost! Over the years, we have spoken to many UX professionals who work in an Agile environment, and many of them have not only survived, but thrived. A few common themes have emerged from conversations with those who have happily and successfully embraced an Agile workflow. There is no playbook — most of these are large-scale, strategic, and organizational factors that an individual UX contributor can, at best, only moderately control.
When Agile works for UX people it's because of a few key factors in the organization:
Numerous successful Agile UX professionals say that the managers and leadership in their organizations “get it” — they understand what UX really is, why it is valuable to the product-development process and how it provides a key competitive edge. This is another way of describing UX maturity, a concept we have long been arguing is key to UX success (and consequently, business success). Decision makers in these organizations know that UX is not just an extra coat of paint; rather, it’s the careful and user-centered approach to product strategy, features, structure, interactions, content, and aesthetics. These managers and leadership don’t just ask UX designers to take features and user workflows that have already been decided upon by the rest of the team and make them look nice; instead, they bring the UX person in from the beginning to determine how these things should work.
On these teams, managers also understand that building truly user-centered products requires research with users, and that the type of research must go beyond simply A/B testing (which does not give the behavioral insights necessary to understand why one design or another works).
Managers and leaders in these organizations embrace uncertainty and understand that a “lean” approach means always hypothesizing, testing, and iterating on product ideas. The rich insights that UX designers need for their work require qualitative user-research methods. Whereas organizations that integrate Agile and UX poorly are often biased toward quantitative data as being the most important or most persuasive evidence for decision making, in Agile organizations where UX thrives, managers and leadership understand that qualitative insights are just as valuable as quantitative insights, and that teams learn different things from these different types of data.
While having managers and stakeholders that understand and support UX is extremely important, the reverse is also true: UX people that succeed in Agile environments exhibit leadership qualities. They point out assumptions about user behavior that could prove disastrous if wrong. They make time to reach out to colleagues to help explain UX process and principles, and why they produce better products. They bring their coworkers to usability tests to build empathy and observe users struggling. They fight for getting time to do user research, and to design something right. UX pros that thrive in Agile push the team back towards the bigger picture, and the context in which humans will actually use these products that are being built.
Agile was not originally conceived as a series of rules and ceremonies, it was invented as a set of principles that guided teams to achieve agility, or the ability to respond gracefully to the change around them. The group of developers that penned the Agile Manifesto realized that they spent an enormous amount of time and energy managing change: changing stakeholder expectations, changing market landscapes, changing requirements, and so on. If change is a constant, why try to fight it? Build a process that takes that change into account, and treats it not as chaos, but an expected input.
Agile is a mindset about radical transparency and admitting that the team doesn’t know all the answers at the beginning of a project. In practice, many organizations implement it using Scrum, a well-known, widely used Agile methodology. Organizations often adopt Scrum not because it’s right for them, but because there is a wealth of resources t