Tips for UX leadership in an enterprise agile environment

Implementing agile in large corporations can be messy and complicated. Departmental structures and organizational dynamics are often at odds with the small, autonomous, “two-pizza team” spirit of agile. Yet many organizations have successfully adopted some form of the Agile methodology into their software development practices. Some have well-established product teams and certified Agile PMOs. And while there is typically some UX presence, it can be challenging to successfully integrate thoughtful, strategic, human-centered design into the mix.

In our webinar, UX in an Enterprise Agile World, Ryan Killeen (our moderator), Abby DePrimo, Elina Yudelvich, and Chris Hungate discussed some of the tools and techniques our team has used in the past to enable successful UX leadership in enterprise environments. Here’s an overview of the conversation with our tips for working with people, implementing a process, and using the right tools to help you along the way.

UX in an Enterprise Agile World

Moderator: Let’s start out with a quick description of what we mean by “agile,” just to make sure we’re all on the same page and have a shared vocabulary around it.

Agile is a development methodology that boils down to four key principles:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

All of these are decidedly not typical enterprise ways of doing things. But there are all kinds of different Agile methodologies—like SAFe (Scaled Agile Framework)—that are built on top of those principles as frameworks to try and make agile possible in large organizations. We’re going to talk a little bit about how UX fits into those different types of processes.

Moderator: What are some of the common challenges that you notice when we first start user experience work with an enterprise client, in regards to agile?

Abby: Ultimately, it always depends on the environment. Something we see often is that clients who are newer to agile can have a fear of doing something that isn’t “Agile” with a capital A. So, I think it’s important to know that it is just a framework. And ultimately, what you’re trying to do is increase collaboration, transparency, and communication across the team. The process is agile just as the product is, so figure out what works for the team instead of sticking to certain things that you think fit into the paradigm of agile. We often work with our stakeholders so they understand that over time, and they can craft how they’re working with us in a way that’s going to benefit everyone.

Elina: Some of the challenges start with the definition of agile. We set one today for this conversation, but this doesn’t always happen on projects. Many people describe themselves and their working styles as “agile-ish,” and as soon as you bring the “ish” into the picture, you’ll notice that there are differences in processes, expectations, and role definition. Challenges become overwhelming when a team can’t connect and learn to speak the same language.

Chris: In my experience, agile methodologies tend to start out in the engineering team. Those teams are often doing a great job with Scrum and sprint schedules, but there are some challenges with integrating that into the rest of the business—like design, marketing, sales, and other departments. So, when you do have some successful agile teams running, how do you integrate areas of the business that are not traditionally agile into a team that’s already doing it well?

Moderator: To that point, what are some ways to try to integrate UX into an agile process? What have you found to be successful?

Chris: One of the things we’ve talked a lot about at Think Company is that when engineering teams are working in an agile framework, and then UX is attempting to integrate into that and start working as quickly as development—without having a unified design vision—the further we get into that, the more we see things start to break, like design systems and user patterns. This kind of cross-disciplinary integration can work at smaller companies, or when teams are given a lot of autonomy, but in large organizations, the agile development track is often a few levels removed from the larger, program-level decision making.

To solve for that, we’ve integrated dual-track agile and tri-track agile, which allow for design, research, and strategy to run on parallel tracks with development releases. This allows UX teams to take the time to do proper discovery and research, and to think about things more holistically—working ahead so that designers are a little more confident about what’s being built, the business is confident that they’re getting the value they want, and then development can keep moving at the pace they need to move.

Tri-Track Agile with three distinct tracks

Abby: In terms of how a design lead may play a role in tri-track agile, I’ve found that design is most effective when we’re being paired at the product owner level. We need insight into how the product is working and what decisions are being made. Design is either supporting or driving all three of the tracks here—and research is as well. This involvement is getting everyone’s feedback throughout the lifecycle of the product development. This isn’t just at the “Understand” level (above)—you’re doing up-front research to understand what you need in order to create the backlog, you’re doing design validation to test early ideas, and when things are built, you’re doing user testing. So, design is involved at all stages.

Chris: And often, a designer in a Lead role can be the thread between these tracks. Designers can be involved at the research and strategy level, and do their best to integrate that into development by bringing them into the process early, just to be sure that all three tracks aren’t becoming their own silos.

Elina: And keeping everyone aligned is not easy. That’s where a great product owner can come in to be the connective tissue between all of the work, and making sure that they’re unblocking each team, but also connecting the dots—knowing how the work of each team affects another.

Moderator: We talked a little bit about the customer feedback loop. When developers like me are building, then release a product, the feedback loop is often forgotten. Can you speak to the benefits of using feedback to learn and grow?

Abby: It’s very easy to do lots of upfront work on a product or feature, then release it, but not focus on how it’s going because you’re so focused on the next thing you have to get out. It’s critical to build in a process to get feedback—especially in small chunks, via smaller releases. That way you can collect pointed feedback on the product in the environment that it’s living in, which is the most valuable feedback you can get. If you can’t do that, there are other ways to get feedback—like through staging environments or prototype designs. Either way, it’s critical to get that feedback.

Moderator: Every developer in the room cheered when you said small releases!

Elina: From my perspective, it’s also important that product owners are involved in the research efforts to understand the user and to help make decisions on their behalf. The PO is responsible for taking into account business and technology constraints as well as advocating for the user, so letting product owners into that process is essential.

Chris: I’ve seen first-hand how powerful it is for product owners to sit in on a user research session and see a user struggle with something. Hearing this feedback straight from the user… there’s just no substitute.

Moderator: I’ve also been on projects and realized too late that I’m supposed to be tracking something, or that something important needs to be measured. We need to have product owners and research aligned on what needs to be measured in terms of both user goals and business goals. Knowing that ahead of time is important so that we can build that out in analytics proactively.

Abby: I think that’s also important from a design perspective, because if there’s business value in tracking something, we need to know that. This information can help ensure we’re making design decisions that will address business goals.

Chris: And the more you’re tracking, the less you need to rely on one source of user feedback. That combination of qualitative user research and looking at the data in the application you’re tracking can help you make better product decisions.

Moderator: We’ve talked a lot about the research track, but let’s talk more about the next track down—design and development exploration. What does that track look like in practice?

Chris: Yeah, the “middle track,” as we affectionately call it, is sort of where the magic happens—in my opinion. Of course, I’m a UX designer. But track two is where product owners, stakeholders, and designers are all talking about the user research that happened in the previous track, and are trying to solve the problems and hash out the details—and working with developers to figure out what’s feasible. That’s really where most of the integration is happening on a day-to-day basis, and it tends to be where we focus a lot of our effort. That’s where we’ve found success with squad models where product owners can pair with designers and developers and solution architects to streamline communication efforts and move several things along at once. Also, looking across those squads and doing things like discipline guilds to make sure we’re not building silos through squads, and everyone’s maintaining a holistic view of the entire product, and sometimes several products.

Moderator: You would think I would disagree because I am usually part of that third development track, but that is where a lot of the fun is. The churn and the prototyping, and the real meat of the collaboration.

You mentioned squads and guilds, and some of our audience may not know what those terms mean. Can you explain that?

Chris: Yeah, those are really just organizing models. Instead of treating all of the work as a pool of work that you divvy up, it can help to have cross-disciplinary squads with designers, developers, product owners, and business analysts in some cases working together as a team to move certain features forward. Squads are essentially mini teams within the bigger team, and that structure helps to build efficiencies and communication. Some of the things we do to make sure that squads don’t get siloed, and that designers don’t get sent off to a squad and work in isolation, is to have guilds for disciplines—like a design guild, or a developer guild. Guilds can come together on a regular basis to share the work that they’re doing for a group crit, look at the design systems and make sure they’re not introducing patterns that are different from another squad’s patterns, and things like that. So, we’re trying to build consistency across the product while still reaping the benefits of the squad model.

Abby: And squads do need to work together really well to be effective, because there’s a risk of fragmentation in squads. You need to have a strong guild model and carve out the time for it, or you’re going to end up misaligned.

Moderator: We talked a lot about the top two tracks. What is the role that design plays on that third production track, where the development is happening?

Abby: Design is always going to be involved for support on that track. You’re always going to need designers who are working with developers to talk through the intention of designs, questions, and QA.

Chris: To build on that, the way I look at tracks two and three is like the 80/20 rule for designers and the 20/80 rule for developers. Designers are spending 80% of their time in track two, and 20% of their time working with developers to flesh out additional details that developers have uncovered, or (addressing specific) technical limitations. Some things are just better served with a conversation between designers and developers. For developers, 80% of your time is spent building in track three, but we want 20% of your time, too, where you can have input into the design process so that we’re not designing in a vacuum.

Moderator: We’ve talked about managing time and collaboration. What are some of the challenges of making all of that happen? Time is money, so how do we juggle the need for people’s time for various efforts?

Elina: A project manager always has a secret budget, if they’re a good project manager. No one knows about it, and the story we tell might be different, but it’s always there. It’s just good planning. And the 80/20 rule is really important. If you are responsible for filling a sprint and understanding capacity, not filling someone up to full capacity and leaving them time to hop into something else is important. At all times, your team will need design support and development input.

I think the other part about planning is to be realistic. We are working with human beings and not robots or machines. Can someone really be at their computer coding for 40 hours a week? Maybe it’s more likely that they are at their computer for 36 hours a week, and also at scrum ceremonies. We need to keep in mind that filling someone up to capacity is going to end up in an incomplete sprint almost every time.

Chris: That’s a great point. Capacity planning and estimation often goes overlooked. From a design perspective—and Abby, this is something that I learned from you—design estimation and T-shirt sizing is crucial, because then you have something to plan against and track against. If you’re tracking a designer at 32 or 36 hours a week, and you know how much effort something is and how many hours it might take, you can actually plan out that capacity and set appropriate expectations for when a design might be complete.

And certainly estimation is estimation for a reason—things will always change. But you need to account for the variability in how long a design takes to do, and how long something takes to get through the approval process. That’s something to consider in larger organizations. A lot of these approvals can happen among larger groups, and they want to see things before they’re going out the door, so that’s one of the “agile-ish” things about large organizations—it’s very difficult to get through those long review cycles.

Learn more in the Q&A

At this point, our panel had a conversation with the audience during Q&A. They discuss how much time to allocate to specific tracks, goal tracking through quantitative and qualitative measurements, effective ways to maintain holistic knowledge of a product, and more. Check out the recording of UX in an Enterprise Agile World (Q&A starts at around 43:40).