Integrating UX Into The Development Loop: Breaking Down Team Barriers

Rory Madden at UXDX Community: Helsinki. Video: https://youtu.be/udXiAIn670o

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.

From waterfall to a failed startup

[00:00:48] ...was always, I thought we were doing it right. We were following best practice. Waterfall was the way to do things. It was great. I was working for some big-name brands and everything was going according to process, but it was just very slow. This is probably my internal feeling of how things worked: it was moving at a snail's pace. And it wasn't just that we were moving at a snail's pace; there was a lot of aggression back and forth between the business and IT, because they specced something a year in advance and they were supposed to get everything right, but they didn't. This process just didn't seem right.

[00:01:29] Five or six years ago, I was thinking, okay, there's this agile thing and it's getting a lot of traction, more so in startups. My background, as I was saying, is more enterprise rather than startups. So it's like, okay, this is how we can do things faster. I did a lot of research into DevOps, and particularly the early stages of agile delivery, moving into those continuous integration, continuous delivery models. Then I said, okay, I've got this. What I'm going to do is my own startup. So we set up a startup. We had a group of about eight of us, and we kept it going for quite a few months.

[00:02:03] We were applying all the practices that we had learned. We were taking all of that learning around how to get a product out quickly. We were doing MVPs, we were doing A/B testing, regular testing with the market. But one thing that was still missing, because we were very much focused on the DevOps delivery side of things, was the UX side of things. What I quickly realized is you can be going very fast, but unless you hit your targets, it's going to become a bit of a mess. This was basically what happened to our startup. We were going very fast, we were iterating, we were going out to the market, but we were never quite getting that product-market fit. So the startup basically fell apart.

[00:02:46] But it was a great learning, and what it taught me was: how can I make sure, before I spend all that money and effort in delivery, that we're going to hit the right market, that we're going to actually build something that people want to use? What struck home with me, I don't know if you've heard of Peter Drucker, he's the father of management science, or the science of management, and he said there is nothing so useless as doing efficiently that which should not be done at all. That was my thinking of what we did in the startup. We were doing it very well, but we shouldn't have been doing it at all. There wasn't the product-market fit.

Linking UX with DevOps, and where to start

[00:03:23] Then I was going through all the design thinking. I did a lot of research into UX, reading about the best practices, lean UX, and how we can use design thinking: empathy with your customers, quick iterations, prototyping before you actually build, and then how we can get that through to market quickly. I really struggled with trying to figure out how to get that linked in with the DevOps stuff that I'm more familiar with from an IT delivery point of view. That was the real challenge that I faced, and that's where we came up with this model. What we've been doing is rebuilding the roles and responsibilities behind this, what events are taking place, what actions are taking place. So that's a very quick background and what the model is.

[00:04:08] But I guess what's more important is how we turn this into practice. I think over here I'm probably standing in fewer people's way of the screen. It's all very well and good having a theory, but how do you actually deliver on that? How do you put this into practice? What I was thinking about with the UXDX model is that the key thing is it touches so many different parts of the business, or parts of delivery, that you actually need to step back and figure out where to tackle first. Because there are so many things, so many people, so many groups involved, if you're trying to implement this in a company, you need to figure out where to start.

[00:04:55] It's all about identifying the bottlenecks. Look at each step in the process. The really important thing to keep in mind is optimize the whole, not the parts. What I've seen happen badly is that people go, "Well, I've got a problem in my area, I'll fix that." That gets really efficient, but the bottleneck is somewhere else, and it makes everything worse. And then be a champion of change. You're one person, or maybe there are three or four people from your organization, but you're not going to change the world alone. What you need to do is become a champion of change: get everybody to agree on the bottlenecks, get everybody to agree on the solutions, and then almost hand off to other people to let them do the delivery.

[00:05:34] The concept is: if there's no vision, people are going everywhere. If you try to enforce a vision on people, they might follow for a bit, but they're going to reject it; they're going to push back. Until you get everybody agreed on what's needed and the vision that they need to go towards, that's when you're going to be able to deliver.

Consistent problems at Ryanair and Aer Lingus

[00:05:54] As Catherine mentioned, I've spent the last four years in the aviation industry. I've been a program manager at both Ryanair and Aer Lingus. I'm from Dublin, if the accent doesn't give it away, and my Finnish is pretty poor. My background there was really about how we could implement this model in both Ryanair and Aer Lingus. My roles there were a little bit different. I was in a back-office role where I wasn't looking at front-facing systems; I was looking at systems that the organization used internally. That was a very different model to Aer Lingus, where I'm working on the mobile apps, the mobile website, the UI-facing elements. So it's interesting, the contrast between the two.

[00:06:41] One thing I noticed, though, even though they were quite different, is that there were consistent problems between the two, and I've seen this in pretty much every organization that I've worked with. The first is a shared vision. There are silos of vision. There are people who know roughly what they need to do, there are people who have bits of information, but what was always lacking everywhere I've been is that you could ask anybody what the vision is and they should be able to answer that. People should be bought into and aligned on what the vision is, but often that's not the case.

[00:07:17] The UX and dev barriers are another big problem. There are still some organizations out there that don't even have UX yet, so if you're fortunate enough to have a UX team, you're definitely ahead of a lot of organizations. But very often UX might sit in marketing and development sits in IT, and because of the differences there, barriers get set up, just from politics or hierarchies [?] or structure. So overcoming those. And then quick feedback. This is about implementing those DevOps loops, getting your experiments out there, finding out what's happening. A lot of companies are moving towards quick delivery, but they're still quite a bit away.

Building a shared vision with workshops

[00:08:01] Talking about shared vision, how did we tackle that in both Aer Lingus and Ryanair? As I was saying, the UX team might have a better understanding of the shared vision, but even in those teams there are silos of information. Very often there'll be people who know a good bit about it, there'll be people who know other sections, but there isn't that joined-up vision about what is needed. Then when you get to the development teams, they just get told, "Here's a feature, go build that feature," and they don't really understand why they should be building that or what the background is. That leads them to, I guess, frustration, pushback and all the challenges that I'm sure you face.

[00:08:41] What we did was take from the design thinking approach: get everybody into a room and run an all-hands workshop. What I mean by all hands is all the stakeholders involved, whether that's your marketing team, your customer services team, anybody who's interacting with the system that you're using, and then also the people building it: your BAs, your QAs, your devs, your data analysts. Anybody who's involved, get everybody into a room. That gives you quite a few people in there, but the idea is that using these workshops (and I'm going to step into a little bit more detail about what types of workshops we've done) really helps get that shared vision and shared buy-in from everybody.

[00:09:25] The two things that we've focused on most actually aligned to whether I was working on the front end, user-facing, or the back end. With the front-end users, it was really around the Jobs to be Done framework. Has anybody heard about Jobs to be Done? Yeah, a handful, so not that many. I'll just explain what it is. The concept is that people don't buy your product. If you're working in a company, you're very much focused on, "This is the product that we're building," but people don't buy your product. You don't wake up in the morning going, "I'm going to buy a..." I don't know. There's a famous example with a milkshake. They don't wake up thinking that.

[00:10:07] What they do is: "I'm on the go, I'm hungry, I need something that I can have in my car. These are the options. A bagel might be too messy, a hamburger might rip everywhere, but the milkshake is great because that fits the job that I need to do at this point in time." So what you do is shift from thinking about your products to thinking about the jobs that the customers are actually trying to achieve. That really opens up the options for where you go with your products as well. It's been really successful for us, and the outcome is that it shifts people from thinking about products to the customer.

[00:10:44] The other session we've done, and we did this more on the back-office ones, is what's known as event storming. From the outside, it looks like you're sticking stickies up on a wall; that doesn't look very different to anybody on the outside. But really what we're doing here is looking at an internal process and getting all of the people involved in the process. You start with events. You have a particular color sticky for your events, and you stick those up for anything that can happen: an order gets fulfilled, an order gets shipped, or something like that. You stick them all up, and then you work out, okay, who's involved in this? Who are the people? That's a different color. What are the triggers? That's a different color.

[00:11:19] By the time you've finished mapping that, one of the surprising things is that the owners of the process sit back and go, "Is that really how it works?" Because they can see the bottlenecks. They can see that something just sits there for two weeks because somebody else doesn't have time to look at it. So it was great for getting an awareness of the problems in the process that were already there that people just didn't know about. We were able to get two things from it: awareness of the problems in the process, but also the developers then got the full end-to-end view of what they were trying to develop.

Breaking down barriers and shifting to outcomes

[00:11:57] Moving on to breaking down the barriers. The ideal answer, if you follow agile [?], is just get everybody into the same team: put your UX people into the same scrum team. That's great, but there are often a lot of problems in companies. You can have different departments, people have different priorities, and there's politics at play. If you're in a company like Usition [?], where they have UX in their team, well done, you're great. But if you're in one of those companies that's really struggling with this because of those departmental barriers, there are other ways of trying to break it down.

[00:12:34] In particular, in my experience with Aer Lingus, we haven't been able to get that full cross-coverage that we had hoped for. We're making steps, but we're just not there yet. What I've found is that just by doing that shared vision, people start getting that empathy automatically. They start communicating more frequently anyway. Even if they're not in the same scrum team, they just start talking to each other more, and that breaks down all the miscommunication barriers that were there previously. It's not perfect, but it's a way of getting there.

[00:13:04] On the quick feedback, there are two areas that I think of. Every company that I've literally gone to has been very feature-focused: "What's the feature? What are we building? Okay, just tell me the feature and we'll build it." But they don't understand the outcome. So it's trying to shift people's mindsets from being feature-focused to outcome-focused. The other one is around the actual delivery. You need your IT department to be delivering quickly in order to be able to get that fast feedback and do those learning cycles.

[00:13:38] On the feature side of things, this is a famous image, and I don't like it, because everyone looks at this and just goes, "Oh, that makes sense, but it has absolutely no relevance to my company. Our products are so different. It just can't work for us. It's great in a drawing, but I don't know how to implement that." The problem, though, if you go with the top line, which is breaking it into components (think of a big feature and what all the components are), is you have nothing until you have everything. There's no value that can be delivered over time, and the customer is basically upset the whole way until they get the end product.

[00:14:19] What I always think is a better example: you ask people to think of an eye. There you go. The feature is an eye; I want to see. An eye is an incredibly complex thing. It's very hard to break it down; you couldn't separate some features of an eye. It was one of the biggest arguments against evolution in the past: half an eye is useless; without the full eye you can't see. But then what they noticed is there are a million different variations of an eye. There are eyes that are just light-sensitive: can I see light, or can I see darkness? There are ones that can detect direction: I know the light's over there, or the light's over there, and I can retreat away from the darkness. Shapes: just being able to see shapes. Being able to focus on some of those shapes. And then having a variable focus, so that you can shift between short and long distance.

[00:15:11] That's just an example that I use. Squeamish people say they don't like the slide, but I find it gets a bit more buy-in, and then we go into actual use cases of specific requirements that we're working on, to hit it home with people. On the DevOps side, I'm going to brush over this quickly, because this could be a whole session, or a whole day or two, of just talking about how you can speed up delivery. There's a hell of a lot involved in DevOps, but it is critically important, and it is one of the things that you do need to look at to get that fast feedback.

What has changed so far, and actions to take away

[00:15:42] So what have we achieved in Ryanair and Aer Lingus trying to implement these changes? The biggest one for Aer Lingus is that the product ownership model is changing. It used to be very much around fares, around ancillaries, so seats and bikes. There was an owner for seats and an owner for bikes, very product-focused. Whereas now they're completely shifting to be customer journey-focused: when you're being inspired to take a trip, when you're searching for that trip, when you're booking the trip. It's the jobs that you're doing at each of those stages along the way. That's how they're restructuring the organization.

[00:16:18] Metrics everywhere. Previously it was, "Go build this feature because I told you to go build this feature." What's happened now is we've got the team to challenge everything: "Okay, but why?" The five whys, I guess, is the famous one. "Okay, why are we building this feature? What's the outcome that we're trying to achieve?" The biggest challenge we faced with this was that the product owners got very defensive. They felt they were being challenged the whole time to justify themselves. They had done the work, they had done the research, and now they kept getting asked the question, "Why are we doing this?" But over time they actually saw the benefit, because in a couple of instances they saw, okay, we can tweak things, we can do things a bit quicker, we can do things a bit more efficiently, and that helped win them over. Change is difficult, but there are plenty of benefits.

[00:17:13] And then problems agreed. We're not there yet. As I said, currently with Aer Lingus we're getting to the point where all the problems are agreed, which is a giant step from where we were: people agreeing on where the bottlenecks are. The next challenge is just getting agreement and alignment on the solutions.

[00:17:33] So, for you, the actions to take away. If you are looking to do any change, try to look at each of the steps of this. Go talk to people, walk around the building, figure out who's doing these functions and what the handovers are, particularly between each of these, and try to figure out where your biggest bottleneck is, because that's where you should start. Always start at the biggest bottleneck. You need to encourage other people to help you. If you try to do it on your own, you're just going to hit a brick wall eventually. What you need to do is encourage other people to buy into the problem, then buy into the solution, and ultimately then you can start delivering the change you need.

[00:18:14] My biggest learning recently is that everybody loves progress, as long as it's another department that needs to change. So it's about taking it slowly, recognizing that people don't like change, but it's necessary to take things forward. And persistence pays off. It might seem like you're not getting anywhere, but just seeding those thoughts of change actually does start delivering over time.

[00:18:41] And just on the model, I'd love some more feedback. As I said, I've been testing it out in two different companies, but part of these events and part of all the outreach we're doing is to learn more about other people's experiences. If you want to email me directly with any questions or any thoughts that you have, please do. I'd love that feedback. And that's it. If anybody has any questions, I'd love to take them.