User Experience and Agile

Working as a Team

“Product teams achieve the best results when they work collaboratively throughout the development process,” responds Pabini. “So, rather than trying to shoehorn a user-centered design process into an existing development process, organizations should devise a product-development process that fully integrates user research, iterative design, and usability testing. Lean UX is one such process. Alternatively, a company can define its own agile development process to accomplish this goal.

“We’ve discussed the relative merits of agile development versus Lean UX in previous editions of Ask UXmatters:

• ‘Are Rapid Prototyping, Lean UX, and Agile Development Good for User Experience?’
• ‘Balancing UX Strategy with Lean and Agile’

“The UX research, strategy, and design work that occurs before development begins should not be the exclusive province of the UX team. Nor should responsibility for product strategy, requirements definition, and software architecture belong solely to Product Management or Engineering, respectively. While each of these disciplines has a specific role to play, every aspect of the product-development process benefits from the balanced participation of a multidisciplinary product team, as I described in my article ‘Sharing Ownership of UX.’ This principle applies regardless of the development methodology.”

Doing Timeboxed UX Design

“This is an evolving relationship, which is both exciting and frustrating at times,” observes Mark. “Right now, a lot of agile development work is in progress where Product or Development teams are still trying to figure out how to fit User Experience into their process. Some people assume that an approach like Google’s design sprints can offer a quick solution. But a true user-centered design process should be a precursor to product development and form the foundation for any development work. This helps everyone on a product team—Business, Product, Design, and Development—to prioritize and organize sprints based on user needs. While you can certainly execute design sprints, rarely should you timebox them in the same way you would traditional agile-development sprints.”

Reasons Companies Adopt Agile Development Processes

First, here is a summary of the core principles of agile development—from The Agile Manifesto:

• Constantly produce excellent working software.
• Expect—and welcome—changing requirements.
• Enable the entire product team—including Business, Development, and Design—to work face-to-face daily, in a sustainable way. Periodically, reflect on and adjust your strategy.
• Hire strong, motivated people, then get out of their way. Let them self-organize and excel at what they do best.
• Ensure simplicity. Don’t do anything that you don’t really need to do.

As these agile principles demonstrate, agile development requires a highly skilled team that a company can trust to produce an excellent product.

Why is your company employing an agile development process? Some companies are taking an agile approach simply because they believe, “All software-development companies are agile houses now.” Others companies have adopted agile development primarily to save time and money. Then, there are companies who follow an agile approach in the belief that doing so will lead to superior products. Now, let’s take a closer look at each of these cases.

Everyone Is Doing It

It’s not enough just to call a project agile and tell the product team, “Hey, we need a working product in two weeks. Let’s get to work!” This is not a sustainable approach and won’t lead to a well-designed product—much less in two weeks. This is the worst agile scenario because there is no support of the core agile principles.

Saving Time and Money

Since businesses exist to make money, the allure of producing working software in just two weeks drives some leaders to focus almost solely on agile’s simplicity principle. Such companies think, “We do not need to do user research. We do not need to have a product design. Let’s get right to coding and forget about all those extras.” It is almost like these companies are saying, “Great! It no longer takes six months to create and implement a product plan. We just need two weeks!”

This is certainly not an ideal situation either. While some aspects of a truly agile environment may exist, there is too much focus on time, which, in turn, leads to excessive focus on the development aspect of a project. In this scenario, there is little time for the user research and usability testing that are necessary for strong UX design.

Working for companies that are agile in name only—perhaps because management wants the benefits of a rapid product-development cycle, without supporting a true agile environment—can be very frustrating and stressful. Not only does the product team have to create the product in very little time, they must do it in a harsh environment. Some companies expect their employees to work an inordinate number of intense hours each sprint. Talented employees will last in such situations only so long—before they leave to work elsewhere.

In such cases, it is important to show management that creating an agile environment requires very specific conditions that are necessary to create a strong product. You’ll need to justify why user research, the time to produce a solid design, and usability testing are important and connect these activities to the bottom line. How do good user research and UX design lead to higher profit? Show them! Words are not enough. Also, be sure to support the agile principles in your work. Are you doing anything that is not really necessary just because you’ve always done things that way?

Creating the Best Products

Clearly, the goal of agile methods is not hurriedly creating inferior software, but to empower a strong, capable product team to do what it does best. A balanced agile process supports a product team in quickly creating valuable software for the customer, in a sustainable way. One reason agile methods have been such a success is that they cut through the heavy, bureaucratic processes that have hampered so many projects. Another reason is the sustainability of true agile methods.

On an agile project, the speed of design iterations and focus on creating working products—as opposed to documentation—allow a product team to learn faster. If a project takes a wrong turn, the team can quickly recognize that and discover a better solution. One of the many strengths of agile is the constant evaluation and adjustment of strategy.

UX designers should not become overly reliant on tried-and-true approaches, but continue to challenge themselves to apply their skills in the most effective way for the current stage of a project. One indicator of the successful implementation of agile methods is that the strongest UX design talent wants to work for companies that have created truly agile environments.

Conclusion

How does all of this relate to the current state of the relationship between User Experience and agile development? That depends. Are you working for a company that says it’s agile, but does not support a true agile environment? Or, are you one of the lucky ones who works in a truly agile organization that entrusts and enables your product team to build a superb product?

Agile methods will continue to spread as more and more companies become successful in implementing them.