How To Build An Agile UX Team: Integration
Email Newsletter
Weekly tips on front-end & UX.
Trusted by 200,000+ folks.
Take a break with a 3D game built on Netlify!
Click here to kickstart your project for free in a matter of minutes.
Check the frontend report!
Start with a free demo —This is the final part 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.
Part 1 in this series discussed how an agile UX team should fit in your organization in order for it to succeed, and part 2 went over how to hire designers who will propel their scrum teams to success. In this third part, we’ll discuss how to integrate the UX designer into the agile process and team structure.
Further Reading on SmashingMag: Link
- How To Build An Agile UX Team: The Culture
- How To Build An Agile UX Team: Hiring
- How To Build An Agile UX Team: Integration
- Fitting Big-Picture UX Into Agile Development
For many designers, coming into an agile environment feels like settling in a new country. There are different dialects and new rituals. Furthermore, design is treated very differently than they are used to. It is, in fact, through ritual that a UX designer is able to integrate in their agile team. In addition, it is incumbent on the designer to open up the design process for collaboration and critique from other members of the team. Together, these tactics have the potential to yield a successful agile team.
Rituals Are Critical To Integration
Developers, designers, product managers: all need to work together.
First and foremost, participation in agile’s rituals is imperative for the designer on your scrum team. It doesn’t matter so much what those rituals are or how well (or not) you stick to the agile playbook. Whatever the team’s regular practices — such as the “stand-up” (a daily 15-minute meeting in which the team meets, standing up, to discuss yesterday’s work, today’s efforts and anything that is blocking progress) — the designer must attend them.
At first, this will feel awkward and potentially a waste of time. Most of the conversation will undoubtedly skew tech-heavy, yet the designer should still attend. These are the bonding moments when it becomes evident to both the developers and the designer that they are on the same team. Just spending those 15 minutes together every day will begin to break down the walls of mistrust that were created through years of departmental silos and will instill the level of camaraderie necessary for the team to excel.
Any other rituals that the team has — including iteration planning (a once-an-iteration meeting in which the team plans its work for the next cycle) and retrospectives (a post-cycle meeting in which the team discusses what went well, what went poorly and what to try next time) — must include the designer. It is imperative that they participate in those meetings as well, not just attend them, because it is at these meetings that the designer gets a sense of where they fit on the team and how best to influence not only the work, but the process.
Fewer Secrets, Bigger Impacts
Secondly, the designer needs to meet their new team halfway by demystifying the design process and opening it up to their new teammates. Instead of showing finished work, the designer should bring in sketches and ideas for review. Get the team’s input and buy-in at a much earlier stage of the design. Having some input a bit further upstream than they’re accustomed to will empower the rest of the team. It will also reveal to them the amount of effort and the consideration that go into each design and will show the work’s evolution from idea to sketch to pixels.
Another team-building tactic is cross-functional paired design. Accelerate the integration process by sitting a developer and the designer down on the same machine to create the experience in real time, using code, pseudo-code, design tools and sketches. Whatever it takes to get the end result during that session is fair game. By just spending time together, the teammates will begin to understand each other’s strengths and weaknesses. The transparency now afforded to them will reveal to each the challenges and value of the other’s discipline. As a bonus, some technical skill will naturally get cross-pollinated, enhancing the knowledge of both parties.
Bring The Pain To Everyone (In A Good Way)
Part of successfully integrating UX into an agile team is to make the team acutely aware of the usability challenges that its product currently faces. Nothing is more effective at this than having the entire team view users with the product. This could be done in various ways, but the point is to make it easy. Conduct the testing internally, and broadcast it over the office network; or use a screen-sharing tool. Bring the user’s frustration to the team. Let the team discuss what it saw, and plot together how to overcome these challenges in the coming iterations. These discussions are golden opportunities for the UX designer to showcase their expertise and their value to the team.
Ultimately, integration is driven by inclusion. The developers need to include the designer in their world, while the designer needs to open up their practices, processes and, most importantly, thinking to the developers. The more time the team spends together, the greater the transparency will be between the members. This transparency is what builds the trust that enables inclusion to take place. This transparency is what creates a safe place for conversations to happen and, most critically, for mistakes to be made. Knowing that their team is behind them and that mistakes will be forgiven and learned from allows the designer to let down their guard and integrate effectively in the agile team.
Conclusion
Agile was not conceived with user experience or design in mind. But the changing nature of software development has forced these disciplines together. In many cases, forcing traditional design practices to fit with these newer philosophies and methodologies has led to disaster. This three-part series has focused on how to set up an infrastructure that enables the user experience and design teams to integrate into the agile process. In addition, we’ve covered what to look for when hiring designers to work in agile environments.
Finally, we laid out a very practical approach to actually integrating UX into the world of agile software development. These elements should provide a solid foundation for getting your team working more effectively in this world. What have you tried that’s worked well? And because we learn much from our failures, what have you tried that’s not worked so well?
(al)
