5 Guidelines for Integrating UX Design Practices into Your Agile Team's Culture

If you are a software engineer on a product development team, you might already know firsthand how difficult it can be for organizations to build awesome, high-quality products fast while catering to ever-changing user trends — even more so if your product team is composed only of highly technical engineers. Those who have the technical skills to build great products many times may lack business-specific expertise or simply don't know the users well enough to understand their needs. Your team might already be well-accustomed to working under an Agile development paradigm, and perhaps you are even using Scrum, but:

• Are you learning enough about the product you are building and its users?

• Are the features you're building having an impact on your users?

• Are they using the product, and are they happy with it?

• Do you know what to do next in order to continue having impact on your users?

• More importantly, do you know what avenues of product creation NOT to pursue?

If your answer to most of the previous questions is no, it's likely that you'll greatly benefit from getting to know your users and customers a lot better. However, as those groups scale up to the hundreds, thousands or more, it gets trickier and more difficult to make sense of things. Though it can be really frustrating, you are by no means alone, as many teams like yours struggle with this very same challenge. There's a flipside to all this though, since most modern organizations (and most likely your company) may already have personnel that excels in navigating those aspects, such as: product managers, subject-matter experts and designers. The latter can be particularly useful throughout the iterating cycle between product discovery and delivery, since design practices base most of their work on user research.

You might already be wondering: Is there a better way to connect our product-creation skills and prowess directly to those customers and those users that use our products, so we can help them reach the desired outcomes and create something with impact? This is a question that perhaps has already been asked within your team or even your organization at different levels. The good news is that the answer is Yes! There may be a broad range of options that your team or your company could experiment with in order to evolve.

Strategically speaking, the most logical approach you can pursue would be to align your product teams with potential design teams (or specific designers) at your orgnaization. The catch is: how can you do it effectively?

Here are 5 general guidelines that can help your Agile development teams and designers play well together so that the product creation lifecycle can be enriched and better outcomes obtained:

1. Focus on highlighting the commonalities between Agile and UX Design teams, rather than their differences.

Having both developers and designers work together can be quite challenging, mostly because of how they mutually perceive each other: on one hand, developers tend to think of UX as a lengthy process external to their development work, where there's in-depth user research that yields over complicated and unrealistic requirements that could — and should — be simplified and polished. Developers also dread dealing with ever-changing designs and tend to push to get final design sign-offs before starting development work.

Designers, on the other hand, stress over the fact that developers demand final designs and that their ideas are usually vetoed on a development team. Also they tend to feel out of place during daily scrums and that it's hard to make their work fit on the product backlog, apart from sprints being too restrictive for them to finish it all on time.

In reality, both Agile — especially when using Scrum — and UX design focus on efficiently creating successful products that are user-centric and of high quality. There's a myriad of principles and ideas that both Scrum and UX share at the core. Here's a brief list of just a few of them:

• An emphasis on continuous learning

• Putting the customer first

• Valuing great user experiences

• A need and respect for feedback loops

• The cadences and events prescribed by Scrum actually create a lot of opportunities for learning and adapting

• UX design brings the tools, techniques, and rationale for building learning into software delivery

Understanding what brings us together as developers and designers definitely paves the way for smoother work while navigating both the discovery realm (which usually happens during UX Design) and the creation realm (i.e., developing products). Here's a simple example (not meant to be prescriptive at all) of how UX Design practices could fit within the Scrum framework:

2. Look for guidance by going back to the Scrum principles & values.

Though I won't go into much detail here, we already know that Scrum, as a framework, is built on top of the three pillars of empiricism: inspection, adaptation and transparency. The main underlying idea is the importance of experimenting with our assumptions in an open way, so we ensure we're learning what we need. User Experience Design is pretty well aligned with the latter, given its focus on framing work as problems to solve and achieving outcomes over outputs to have significant impact. Empirical thinking is at its very core.

The Scrum values, courage, focus, commitment, respect and openness, are also crucial to defining how development and UX design work should align. Developers and designers should understand the strength of working together and have the courage to commit to it, respecting their specific skill sets and collaborating extensively with respect and openness.

The most important thing for all of us is to satisfy our customers and make them happy with products that exceed their expectations. But how do we get there? By working together, developers and designers on the same team, learning together as much as we can from our users and the product they need, and collaborating to turn it into a reality. Scrum greatly facilitates this process for us if all of us are willing to commit to do right by our customers and users.

3. Focus on outcomes over outputs.

Though producing usable increments that sum up to the wide functionality of a living product is great, we also need to ask ourselves:

• Are we releasing features frequently enough to our users and customers?

• Are our customers and users happy with the features we are releasing?

• Do we know what direction to follow with our products?

If we are striving to create a customer-driven product, then we must be including all our customers and users on a tight feedback loop – releasing new things, measuring how happy they are with these new things, and capturing all their feedback – so we can continue adapting our efforts to produce exactly what they need. Outputs by themselves aren't enough: creating and releasing features no one asked for and most likely won't use isn't valuable at all. We need to understand – by working together with our customer base – what outcomes they are expecting to achieve and use it to power our efforts.

4. Experiment with Dual-Track Agile – but in the most effective way.

Many Agile and UX Design teams have heard or even interacted with the concept of Dual-Track Agile, which pretty much outlines that you can – and should – have both a development stream and a design stream working together. What would you think if you saw something like this?

The problem with this is that the concept was widely misunderstood: you have two teams, one for each stream, working alongside each other in a semi-synchronous fashion; design teams produce things for the development team to build, and that's it! In reality this creates dependencies, time constraints and artifacts, not to say two backlogs.

Let me be perfectly clear on this subject: that's not the ideal way that Dual-Track Agile proponents had in mind. Scrum advocates for teams that can own both discovery and delivery through appropriate cross-functionality, something more like this:

Though Scrum only has three roles: Product Owner, Scrum Master, and Development Team (and there's no title distinction between "developers"), that doesn't mean designers can't be a part of a Scrum team. Designers not only can be a part of a Scrum team, but they actually should be if possible.

Now, how can we organize design and development work together in a way that makes sense? Here are just a couple of ways:

1. You can include design work as Product Backlog items. Yes, it's that simple. The most high-level things you do, such as strategy work from a UX Design perspective – things like research, hypothesis outlining and design sessions (just to name a few) can definitely be represented as Product Backlog items to be acted upon during sprints, with team-wide collaboration.

2. You can make tactical design work part of the Acceptance Criteria or even the Definition of Done, which is even a more powerful way of integrating both streams. Given most of the work represented in the product backlog should already be expressed in terms of user/customer value, it's highly likely that you'll have research, experimentation and/or design activities for your PBI's; then, why not make sure that those tasks are represented as part of the acceptance criteria or the team's Definition of Done? This way you will be fostering team collaboration.

5. Work on making your discovery and learning efforts iterative.

There's a widely held misconception that UX Design work is a discovery process that must happen in its entirety before building products, when in reality, you'll actually want to continuously navigate the discovery and delivery streams at the same time – though in different proportions – in each sprint.

UX design brings about a lot of tools and practices that help teams understand who the user is, what they want, what pain points we should be trying to solve, and how to steer the product direction by starting from the outcomes. Scrum provides a framework for opportunities of learning and discovery; but all of this is useless if teams are not making sure that they are confirming assumptions and documenting what they learn along the way. There are great tools such as the Lean UX Canvas by Jeff Gothelf, that facilitate the process of documenting all aspects of your product initiative in a single place, and allow you to use it as a guide and primary artifact to document your initiative changes and evolution.

Hopefully these guidelines will help you get a clearer picture of how to start experimenting with bringing your development and design teams together. Just keep an open mind as you approach the different aspects and see what works best for your teams.