Engineering, Product, & UX: An Agile Trinity

Justine Benoit at UXDX Community: Designing for Agile Domains. Video: https://youtu.be/y0-O840UXz0

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and what an agile team is

[00:00:00] Justine: Hello everyone, thank you for joining me today as we talk about engineering, product and UX: an agile trinity. A little bit about me. My name's Justine Benoit. I'm a UX designer at Deloitte. I am an immigrant: I was born and raised in the Philippines and moved to the States when I was 18. I'm also a mom. I made a tiny human in collaboration with my husband. And a little fun fact about me: before I was a UX designer, I used to work backstage at a couple of Cirque du Soleil shows in Las Vegas as an automation technician.

[00:00:43] But enough about me. Today's journey is going to be about how we work as a cross-functional agile team. We're going to begin by defining what an agile team is. Next, we're going to elevate that definition and define what an empowered team is. With that in place, we're going to establish and define clear roles and responsibilities among the cross-functional teams. And finally, we're going to put all that together and explore that trinity in agile action.

[00:01:33] We begin by defining what an agile team is. One of my favorite UX people in the industry, Laura Klein, describes an agile team as a single cross-functional team that is working together, taking complete ownership of their area of the product, in order to produce better outcomes for both the users and the business.

[00:02:03] Let's explore what agile teams really are. One is that agile teams are cross-functional. When you say cross-functional, you have your functional team, you have your design team, you have your engineering team, and they are working together collaboratively, closely and in partnership. They have an advantage over siloed teams because they are communicating constantly. They are working together rather than in their separate little silos, and this allows them to move much faster and work more effectively.

[00:02:45] Next, agile teams work autonomously. Autonomous teams are handed outcomes rather than simply being handed outputs, and so they are entrusted to drive decisions in order to accomplish those outcomes.

[00:03:03] Next, agile teams iterate. Teams that are truly committed to agile methodologies iterate and work to improve their user experience and codebase constantly. At first they might ship something that is not perfect. It's going to be flawed. But the team collectively understands that they are shipping something, bringing something out there, so they can engage with the community, with the users, gather feedback and learn something from that, and then go back and lean in together to improve the product based on the things they've learned. And you rinse and repeat.

[00:03:53] Finally, agile teams enable excellent communication. Teams that are clearly and constantly communicating are more likely to address problems and identify solutions from the get-go, because they are working in partnership. So from research, ideation, development, and so on and so forth, everyone is involved every step of the way, and that's what keeps the team ahead of the game.

From agile team to empowered team

[00:04:26] Now that we have an understanding of what an agile team is, let's elevate that. What is the definition of an empowered team? Marty Cagan is the author of Inspired and Empowered, two separate books, and he's also a product leader and the founder of Silicon Valley Product Group. He's a great person to follow as well. He describes an empowered team as one that's not just assigned problems to solve, but one that's entrusted to drive the solutions to those problems.

[00:05:07] So what separates an empowered team from just a simple agile product team? A product team is output-driven. They're working to deliver features because they can, and so accountability is low, because the team is operating over a checklist of features rather than outcomes.

[00:05:46] What separates an empowered team is that an empowered team is outcome-driven and focused on problem solving, and therefore accountability is high. Why? Because the team is collectively responsible not just for the outputs, not just for the features and releases, but most importantly for the outcomes. Any KPIs, any metrics you've established, whatever defines success in this product, that is what you're working towards together.

[00:06:25] We can summarize, and please remember this, because I think it's really important: empowered teams are entrusted to take ownership of their craft and work in partnership to develop solutions and deliver meaningful outcomes.

Clear roles and responsibilities

[00:06:49] Knowing what an empowered team is, and how it's an elevated version of an agile product team, let's establish what these clear roles and responsibilities are. One of my favorite quotes, and really one of the quotes I like to live by, is from Brené Brown: "Clear is kind. Unclear is unkind." To me, what that means is complete transparency, and providing each other a safe space, especially for difficult conversations.

[00:07:30] It also means that as an agile product team you are constantly and openly communicating. You allow each other a safe space to express your concerns and share your ideas, to feel safe, to be able to disagree in a healthy way, and to support each other in providing alternatives when there are moments of misalignment or disconnect. But the point being: always communicate clearly and honestly. Be transparent with each other.

[00:08:25] So let's talk about what these clear roles and responsibilities are. In your product team, you have your functional team, your design team and your engineering team. Establishing clearly defined roles enables both the individual and collective accountability of the team for risk.

[00:08:48] Let's explore each individual role. We'll begin with the functional lead. This is your PM or your PO. Their role is to take the lead on the product or solution's viability: do the solutions meet business requirements, and are they within the scope of the release we're working towards? Their specialty is helping the team understand business goals and requirements. They're responsible for leading the strategy in delivering viable solutions that deliver value to both the people and the business, and they are accountable for business strategy, economics, prioritization and risk management.

[00:09:44] Next we go to the design lead. Your design lead's role is to take the lead on the desirability and usability of the product or solution. Are the solutions we're presenting going to connect with our end users? Are they going to be effective in supporting users in completing the tasks that involve this product we're working on? Their specialty is to bridge the gap between business goals and user needs. The design lead is responsible for leading the creation of compelling and thoughtful solutions that deliver value to both the people and the business. Therefore the designer is accountable for activities like UX research, and interaction, service and visual design.

[00:10:41] Finally, we go to our engineering lead. They lean in on their expertise to make sure the product or solution is feasible to deliver and reliably maintain. Their specialty is ensuring we have the right technology, tools and engineering talent to deliver and reliably maintain our solutions. They are responsible for leading the development and execution of solutions that deliver value to the people and the business. So they are accountable for the technical discovery during the discovery phase, the engineering solutions, and the implementation and development of the product.

The trinity across the double diamond

[00:11:34] Now that we have a definition of what an agile team is, what an empowered team is, and what the roles and responsibilities are for each cross-functional team, let's see the trinity in agile action. We begin with the Double Diamond framework, which is a design thinking approach to agile product delivery. In the Double Diamond, you notice that at the beginning, during the discover phase, there's a diverge, and when you get to define, you converge, and as a unit you go into develop and deliver.

[00:12:23] What does that look like? We have the four phases here. You have your discover phase, where the goal is to develop an understanding of the problem space. You have your functional team gathering business requirements and business input through our stakeholder engagements, and maybe some market research. You have your design team conducting user research to develop an understanding of the problem space from the user's perspective. And you have your engineering team conducting their tech research to identify what technologies are available for the team to leverage in order to build our solutions.

[00:13:11] So you diverge, and then you get to define, and you converge all those findings to define the problem based on the information gathered during the discovery phase. You have your functional team guiding and defining the scope for the release and prioritizing features and functionalities. You have the design team facilitating a story mapping workshop to define the end-to-end experience of the platform from the perspective of the end users. This is both a story mapping and a user journey mapping activity. And you have your engineering team working to define the best tech stack to support the solutions we are looking to develop for the product.

[00:14:13] We've converged, and now we begin to develop and deliver as a unit. When we get to the development stage, we work together to ideate and develop solutions. You have your functional team ensuring the solutions meet business requirements and are within scope. You have your design team ensuring the solutions are developed with the end users at the forefront. And you have the engineering team ensuring the solutions are feasible to deliver and can be reliably maintained. Later we're going to walk through a couple of moments where you can see this in practice, where the three teams, functional, design and engineering, come together and align on decisions and a path forward.

[00:15:17] Then we get to the last stage, which is deliver. I say last, but it's more like a cycle. When we get to the deliver phase of, let's say, this release, this sprint or this product increment, this is when we test and iterate on solutions. You have your functional team guiding everyone in prioritizing the refinement work streams identified during testing. You have your design team doing the usability testing and iterating on the design solutions, based on what we gathered from the usability test and on what functional has told us would be the priority for that release.

[00:16:08] And engineering would do their UAT, their QA/QC testing, and iterate on implementation. Any bugs found during UAT and QA/QC, we bring back to the table and work with functional: "Hey, what's the priority here? What's going to be high impact, low effort, that we can deliver to refine the product before it's released?" And everything else can be put in the backlog.

Kickoffs, design reviews and decision making

[00:16:46] As I said earlier, there are some moments where you can practice this as a team, and we're going to walk through three of them. The first one is a kickoff workshop, a design kickoff or project kickoff. This is cross-functional collaboration from the get-go. You have your functional lead ensuring the team has a clear understanding of the business requirements and what's within scope. You have the design team ensuring the team has a clear understanding of the user needs within the context of the task they're performing using the feature or capability we're designing. And finally, we have engineering, who are there to ensure the team has a clear understanding of the technologies involved in supporting the capabilities.

[00:17:48] Another moment for collaboration is during design reviews. This is an opportunity for the cross-functional team to align on solutions and design decisions. During a design review, you have your design team sharing, let's say, the latest design artifacts, and it's up to the design team to advocate for the user's perspective and ensure the team keeps the users at the forefront of their minds while solving for the problem space. We have our functional leads, who ensure the design and engineering solutions meet business requirements and are within the scope of the scheduled release or sprint. And you have your engineering team, who ensure the design solutions proposed by the design team can be feasibly implemented and reliably maintained.

[00:19:01] When you get into a situation where the design is a high LOE, level of effort, for implementation but is also high impact to the business, then engineering and design will have to work together and offer each other alternative solutions to support each other.

[00:19:35] That brings us to decision making. This is the third opportunity for the team to stay in alignment, collaborate, and arrive at a unified decision and a path forward. These are guidelines for making design decisions in a cross-functional, collaborative environment. We've used this little matrix in a few projects and it's worked really well, not just for capturing and tracking decisions, but it also shows that we made this decision because of X, Y and Z. It's not just, "Eh, that's not going to work, we're going to go with that." This keeps everyone accountable and keeps everyone informed of the decisions we've made throughout the product's life cycle.

[00:20:39] Some guidelines, and I mentioned this earlier too. If the design has a high level of effort to implement and a high business value, then engineering and design have to collaborate and find alternative solutions. If the design has a high level of effort for implementation but a low business value, then the team can consider descoping that feature, capability or component in the solution, and either explore alternative solutions or deprioritize certain elements of the product. Then you capture it in this design decision matrix. You can use this matrix to keep everyone accountable and informed. It's especially great to show leadership, and maybe your stakeholders, so you are able to provide justification for the direction your team has decided to follow.

Q&A

[00:21:52] Rory: Thank you very much, Justine. It was a great overview, diving deep into a couple of the areas around how it actually operates, so thank you for sharing. If anybody has any questions, please do put them in the chat box on uxdx.com or whichever social platform you're watching this on. But I'm going to start it off, because this is one question I always get confused about with the product team. As you mentioned, you have the functional lead, the design lead and the dev lead, and they're working on user story mapping at a high, feature level. What happens when you actually get down to it? Is it a different team doing the nuts-and-bolts delivery, or is it the same team? Is it the leads who then go and do the design work and the dev work? How does that relationship happen between the product team, as you're describing them, and the implementation?

[00:22:51] Justine: Great question, Rory. What I like to encourage design, engineering and functional leads to do is lean in on your team, lean in on their strengths and expertise, and have conversations with them as you're putting together these user stories. We go with "clear is kind, unclear is unkind". So talk to your team, lean in on their strengths and expertise: "Hey, this is what we all understand and know is the outcome we want to accomplish. Team, what are the things we need to do to accomplish this outcome we want to achieve?" That is you, as a lead, leaning in and empowering your team members to drive the decisions, to drive the solutions to that problem.

[00:24:00] Rory: Okay, so the teams are getting involved and then feeding back up into the user story mapping and into those planning sessions?

[00:24:09] Justine: Exactly, yeah.

[00:24:10] Rory: Okay, brilliant. One of the other questions I always get is how you build trust with your stakeholders. It's great saying "build some outcomes", but the stakeholders are sitting there worried: "Don't they know that we have to build something like this? What happens if they go completely left field and build something completely wrong?"

[00:24:35] Justine: That's a really great question. It can be a bit of a precarious line, a precarious conversation to have, because it's important that you maintain a strong and healthy relationship with your stakeholders. They are the ones who have the power to support the decision, ultimately. As much as we all have our own vision, at the end of the day we still need the stakeholders to be, in a way, the vehicle that takes us in the direction we need to go.

[00:25:12] In terms of building trust with stakeholders, and I cannot emphasize this enough, it's important that you maintain transparency and communicate often with your stakeholders, even when it means having difficult conversations like, "Hey, we've unfurled some risks following this solution or this technology. I think we need to start exploring alternatives. Unfortunately, this does mean our timeline's going to be affected." Just having that conversation and continuing to be in alignment with your stakeholders when it comes to decision making.

[00:26:11] Now, let's say you're the project manager, the person leading that project. It's your responsibility to advocate for your team. It goes both ways. You need to have a lot of trust and empower your team to drive the direction and the decisions of the project, and you also need to advocate for them when you're engaging with the stakeholders. At the same time, you have to find that balance: this is what the stakeholders need, so how can we find a balance with what our team can deliver, and deliver well? What can the team deliver in order to meet the outcomes the stakeholder wants to achieve?

[00:27:22] Rory: Great. So it's a lot about keeping that communication flowing, because you don't want any surprises.

[00:27:30] Justine: Exactly. It's an uncomfortable situation to be in. There are going to be moments where it's uncomfortable, especially when unpleasant things arise, when things go awry during your project. It's like, "I don't know how to tell them." You still have to. But everything is great, especially when they start to see results. Let's say your product has shipped or launched and you're getting great results. That is great stuff to show your stakeholders, your client, and say, "Hey, we are actually achieving the outcomes we established from the beginning. It was a rough road, but we did it."

[00:28:28] Rory: Great. We're actually unfortunately out of time, so I just want to say thank you very much for sharing your case study, and I hope everybody out there enjoyed it as well.

[00:28:38] Justine: Thank you so much, everyone, and thank you, Rory, for the opportunity.