This is the first in a three-part series on how to build and grow successful user experience teams in agile environments. It covers challenges related to organization, hiring and integration that plague UX teams in these situations. The perspective is that of a team leader, but the tactics described can be applied to multiple levels in an organization.

Building any kind of agile team is a lengthy and challenging process. Building a user experience team within an agile organization challenges not only traditional design practices but typical design team dynamics. In this first part, we’ll look at the type of culture that would support a strong UX component in the agile process and how to structure the organization so that designers are most effective and are able to thrive.

Organizations Become Supportive Through Dialogue

Teams work together to celebrate their wins at weekly team-wide demos.

Critical to the success of any user experience team is an organization that values its contribution. This is not unique to agile shops, but it becomes even more critical given agile’s rapid cycle and participatory rituals. In a typical resource-allocation scenario, no more than one UX designer is assigned to a cross-functional (i.e. scrum) team. In fact, this scenario is usually optimistic. In some cases, a UX designer will be straddling more than one team. “Team” is the core concept of the agile philosophy, and as such it must include the designer as a core member.

Development managers need to set the expectation with their staff that design is critical to the team’s success. As you begin to build your UX practice in this environment, ensure that you have frequent conversations with these managers to review how their staffs are reacting to the addition of designers to their teams. These conversations will help anticipate issues that may hinder the cohesion of the scrum team. In addition, lessons from fixing one of these issues can be applied pre-emptively on other teams.

By the same token, it is incumbent on the UX designer, their corporate champion and team leader or builder to promote the values of the craft in the organization. Again, this is not unique to agile environments, but it is critical to keeping the team focused on core UX and design issues. Key to this promotion is transparency. Let the team into the designer’s world. Let them see what they do and how they do it, and let them experience the benefits that come from doing UX and design work. When all members of a cross-functional team can articulate the benefits of design activities such as,

• speaking with customers,
• understanding the business and competitive landscapes,
• constructing the information hierarchy,
• assessing visual communication,

then they will be far more inclined to carve out time for those activities in each iteration. Include the team in the actual design exercises. By practicing participatory design, the designer’s contribution will become evident, building their credibility and crystallizing team cohesion.

How To Structure The UX Team

Organizationally, there are essentially two ways to structure the UX team: as an internal agency of shared resources or by using a hub and spoke approach, with designers dedicated to specific teams.

Internal Agency Approach

Using the internal agency approach, incoming work is routed through a central point of contact (typically the UX manager) and then assigned to the designer who is best suited to the work and who has the bandwidth to take it on. The challenge with this approach is two-fold.

First, it promotes a culture of specialization in which designers limit their contribution to particular segments of the craft (for example, mobile, e-commerce, social experience design, etc.). Secondly, with no loyalty to the scrum team, priorities become driven by which product owner can yell the loudest, typically leaving the designer in the middle, awaiting the outcome to know where to focus. Additionally, this approach taxes the UX manager heavily by forcing them to constantly assess bandwidth, availability and applicability of skills to the required tasks, all while helping the product owners manage competing needs among the design staff.

Hub and Spoke Model

The hub and spoke model, on the other hand, is the better practice. Dedicate each designer exclusively to one particular scrum team. They should feel like they are a part of their scrum team and feel connected to that team’s focus. In doing so, the designer’s priorities become clear. Their priorities are synonymous with the team’s, thus enabling them to clearly understand where to expend their energy.

Asking for a designer’s input or effort on a “quick” project or “internal need” is a fairly common occurrence in many companies. It is incumbent on your organization’s leadership to protect the one designer or team structure, so that each team’s designer isn’t peppered with these ad hoc requests. Such requests distract the designer from their team’s mission and inevitably consume already limited capacity. In the eyes of the designer’s teammates, these efforts erode any progress that has been made in confirming the designer’s permanence on the team.

Working With The New Teams

New ways of working for designers will, at first, be uncomfortable. For many design managers, assigning their staff to particular teams brings a new challenge. No longer does the design manager dole out specific work to each person on the team. Instead, the designer’s daily agenda is driven by the prioritized backlog of the scrum team. This is a duty that managers were likely used to doing in the past, and its removal may feel like a reduction in responsibility and authority. To fill this potential void, design managers should work with their staff to understand their team’s priorities and suggest methods of structuring the work in a way that allows the best user experience to get built.

Weekly one-on-one meetings with each designer should reveal any challenges unique to their situation. In addition, regular touch points with each team’s product owner will provide insight into any design challenges on the horizon. And monthly high-level retrospective meetings become a forum for managers to share successful and failed tactics across the organization. With all of these tactics in place, the driving goal should be to solidify the designer’s place on each team.

Dedicating your staff to other teams does not portend the doom of the centralized user experience team. The centralized team is still very much needed for mentorship, professional development and general design support (such as critiques). In addition, a centralized UX practice can bring learning from the individual scrum teams back to the broader group, disseminating lessons that improve the process elsewhere.

The centralized UX team also serves as a “safe haven” for designers to vent their frustrations with the agile process, commiserate a bit with their colleagues and reassure themselves that they’re not alone in their agile UX challenges. Weekly UX team meetings are the building blocks of this community. Outings to design events, talks and recreational events help solidify the bond between distributed designers. A UX-only email distribution list or other forum could also provide this safe haven on an as-needed basis and supplement discussion outside of the regular meetings.

Conclusion

Company culture and staff organization are the two fundamental building blocks of agile and UX integration. By creating an environment that values design, promotes its benefits and spreads this gospel through the allocation of UX resources across individual teams, companies will lay the foundation for successful team-building and adoption of the agile process down the road.

In part 2, we’ll discuss why hiring is such a critical part of the agile UX team’s success and how to maximize your chances of hiring the most appropriate staff.

(al)