 Okay. So let's jump in. So thank you so much for coming. This of course is DevOps ICU, correctly integrating UX product design and Agile. And I call it DevOps ICU mostly for fun. ICU is the part of the hospital in America where you get the most intense care and treatment. So perhaps your DevOps is in the ICU. I will be your DevOps ICU doctor, Debbie Levitt. I've been a UX strategist, designer, speaker, consultant and trainer since the mid-90s. Who remembers the mid-90s? Anyone? Okay. Good. People of a certain age. Thank you, sir. The timekeeping man. He remembers the 90s. Good. Good. So P-Type, short for prototype, is my UX agency. I'm an American now based in Italy. So I'm just a couple of time zones away from you guys. And in addition to your typical UX projects, we also work with companies on helping them get UX up to speed at their companies, whether they need help with processes or staffing or other things. We help with that as well. Everyone's welcome to add me on LinkedIn. Just write me a note so I know I met you here. Otherwise, I think you're a salesperson. And if you have any questions, you can certainly email me or we're going to do some fun interactive polls. So get your phones handy. I use menti.com, M-E-N-T-I, M-E-N-T-I dot com. And then you'll put in code 88752. And you can use that for the interactive polls as well as asking me a question. If you use that to ask me a question, please put in your email address so I can write you back. Otherwise, I can't write you back. So my DevOps ICU program is actually a two-day workshop, but I promise I'll only keep you here for about 45 minutes. We won't do the two-day version. So also you're welcome to take pictures and tweet at me at DevOps ICU and using the conference hashtag. And fun UX moment. Some of my slides have animations and things that change. So when you see the camera icon on the bottom, that means my animations are done and it's a great time to take a picture of a slide. For those of you who are slide picture takers. So some people have asked me if this session is just a sales pitch for UX. And I say, well, that's a strange question because you're here. I didn't make you come here. You came here voluntarily. So you probably need some help or tips about getting UX to work better at your company. So whether UX is new to your company or you're dealing with some horror stories, hopefully you'll find some good concrete tips in my presentation. And of course, you're welcome to ask me questions afterwards if you need further help. So at many companies, engineering is fed by other teams. Blueprints, designs, wireframes, prototypes, whatever they might be. They come from somebody who created these and show how people are going to interact with the system. These are typically non-engineering individuals and teams who are part of collaboration throughout the process. Engineering doesn't operate in a vacuum, despite how they might prefer it at times. But too many companies are excluding or circumventing UX because they don't understand it or because their agile books or training or other things, their coaches didn't tell them about UX. And I found that it's missing from a lot of books and training. So I find a lot of companies where I've worked haven't really known what to do with UX. Or a lot of people assume UX are time and budget wasters or anybody can draw boxes on a page. So no, not the case. Expert UX architects, research, design, iterate and test, everything between, I have an idea and let's get it to engineers to be built. So DevOps is about so much more than IT frameworks and infrastructures and how developers connect with IT. It's also about recognizing how many teams are involved in software development and making sure everybody's got a seat at the table. I find that developers and engineering architects want to be involved with product designers and UX early in the process, but that's not always in the definition of DevOps. And of course the creative people want to be involved when engineering and QA are working on building and testing, but a lot of methodologies don't include UX and product design in that process. So these are old silos we need to break down. All your customer knows is your user experience. That's it. They don't know if you were agile, lean, waterfall. They don't know if you had one developer or a thousand developers. And the software and systems you use have competitors. So what made you choose the systems that you wanted? When you use a system you don't like, are you thinking, man, I wonder how many sprints that took? Well, of course not. You're probably thinking, who built this piece of junk? Who designed this product? Did anybody spend any time researching with people like you and designing for people like you to learn your habits, your motivations, your needs? And was this tested on anybody like you before it was unleashed on the public? So UX is driven by a lot of the same results that DevOps wants. We're problem finders, problem solvers, we're product designers and customer advocates who care about product quality and building things with high customer value. We care about our teams working efficiently and of course we want to create easy to learn, easy to use, tell your friends it's great products and get them to market as fast as possible. So enhancing this relationship should save time, money and sanity. Now normally when I give this talk to engineers, I have a whole section on what is UX and what is the user-centered design process. But I've heard from my agile audiences that you guys already know this. So I'm going to skip the usual introduction to what is UX on the assumption that you know that one. So come to me afterwards if you don't. So in a typical company where maybe UX isn't being used yet or it's not being used fully, your process usually looks like this. There's a client, a CEO, a product manager, someone with a vision and they come to engineering and they say, here's what we want to build. Well, okay, we'll build it, we'll test it, we'll get it on a server and wouldn't you know somebody looks at it and goes, now that I see that, I think I want something different. And now you've got to cycle back and say, okay, now what do you want? Fine, we'll build it, we'll test it, we'll get it on a server and this goes cycle, cycle, cycle until you eventually decide to release something and hope that your customers don't hate you. Hope that it's not a disaster. If you have UX in your process, it should look a little bit more like this. Where that client, product manager, person with the vision tells UX what they're looking for. UX can then cycle through the user-centered design process, doing research, design, testing and iterations. We want to make sure it is a great solution of a great idea. And at that point, hopefully, everybody's on board, the client's on board, the internal stakeholders. And certainly, if we've been doing user testing, then we can be confident in how the users feel about it. And then UX can deliver this to engineering, ready to be built once. And that way, if the client or someone wants to change their mind at some point in the game, UX can handle that. UX runs interference, it doesn't go to engineering as a change request. It should go back to UX so that it can go through the UX process or people like me can talk people out of the change. Because it's fine for the changes to happen during the UX process, since it certainly costs less and can be faster and easier for UX to make changes to wireframes and prototypes, then for engineering to have to rebuild things. So the goal is for you to build a fantastic vetted product once. Can you smell that? That is the sweet free conference food smell of only having to build something once and not worrying about people changing their mind, because someone else is going to handle that. Let's talk quickly about Lean and I've got a poll coming up. So take out your phones and if I've got internet, this poll should come up. Please go to menti.com, M-E-N-T-I. And it's going to ask you for a number, please put 88752. And this is about Lean because UX sometimes disagrees with product managers and then engineering about how much or little of a product do we release? And what should the MVP be? Well, just for fun, which is the minimum viable jogging outfit? Feel free to vote here, it should pop up live, get people involved. Is it coming up on your phones? Menti.com, 88752, all right? This guy's always the winner. I think people just like to vote for him because he went for it. So what would you say is the minimum viable jogging outfit? All right, we have a naysayer. Okay, four people, five. How many people are in the room today? Maybe 15, all right. And there's always someone who votes for number three. You think you're pretty cool right now, don't you? Where are you? Okay, you're like, I'm a rebel, I'm a rebel. It's the minimum viable product. So that's usually about how the voting looks. Thank you to the seven people who got involved and eight. And there will be another wacky poll later. So keep those phones handy. But I find that non-UX roles often vote the most for the first one. But I find that UX roles are more likely to vote for the second one because even though we believe in lean and we believe in trying to be more minimal, the reality is that we still want to create a product that has value to the user. And that usually means the jogger has a little bit more clothes on. Sorry, everybody. So you never get a second chance to make a first impression. I don't know if anyone remembers that American commercial from the 70s. But this is especially true for that first time your customer installs your app or visits your website. And if they don't like it, they uninstall it or they leave. Are they gonna give it a second chance? How often do you give companies second chances? When you've uninstalled an app, do you give them another chance and reinstall it? Very often we don't. And if people were turned off by the MVP or the beta, they're probably not gonna give you another chance. In fact, they're more likely to go out to social media and proudly tell everybody they don't like you. People love negative attention. So that's why for UX, the V in MVP stands for valuable. What's the leanest product that we can design and build that will still have the customer feeling like it's got great value? Cause customers don't care if you call it an MVP or a beta, still happy to go to social media and hate it. And take it from Eric, Mr. Lean. Even if you're not doing lean, he said, what if we found ourselves building something nobody wanted? In that case, what did it matter if we did it on time and on budget? Go to lean and minimal and you might be building something nobody wants. Your UX expert can help product and engineering prioritize stories and features to find that balance. UX and Agile. Buckle up kids. I'm going to use safe Agile in some of my examples because they're an easy target, but please know that anything I'm saying is adaptable to whatever flavor of software development that you're using or flavor of Agile with a few things that are specific to safe. Once upon a time, I went for four days of safe training in 2014. I have since recovered, but I asked them, where does UX fit into your model? And they said, we don't know. If you figure it out, please tell us. That hurt, but now UX gets a little recycle your garbage icon down here in the bottom left in this bar of the island of misfit toys of other things that safe wasn't too sure what to do with, but that doesn't tell you or me or anybody, who is UX? Who are these people? What do they do? Are they in sprints? Are they on the team? They were just in this weird bar off to the side. And when I show this slide, usually someone says, safe is a joke. And I say, well, maybe or maybe not, but it's still hard to find a lot of Agile training books, materials that are really going into, who's UX? What are they doing? How do we work with these people? So I'm trying to fill that gap. But safe said, hold my beer to themselves. And one of their more recent versions says that, while UX experts used to be in charge of the design process, this was to siloed. So safe solution is to remove UX specialists because that will solve siloing. Their website actually says they are empowering Agile teams to do their own lean UX. But they mentioned that you should get the perspectives of, product management, system architecture, business owners, information security, operations, and shared services. Sounds like the Agile team will be doing specialty UX work with everybody at the company except UX specialists. Brilliant. I'm pretty sure someone at safe had a very bad breakup with a UX specialist, but that is a hypothesis. So where else does your company like to put untrained non-experts into specialist jobs? And why would a non-specialist think they can do UX work? Well, notice the eye for design and the feel for interaction. These words are carefully chosen to kind of minimize UX. You wouldn't say an expert cardiologist just has a feel for working with the human heart. You wouldn't say the best engineer at your company, gee, she sure has an eye for programming languages. These sound a little disrespectful, but these words are here to help Agile team members self assess. Hey, I've got an eye for design. I've got a feel for interaction. I guess I can do UX work. So evidently the specialty training isn't that important. Too safe. So where does UX fit into Agile? Well, first, nobody puts UX in the corner. Did anyone see dirty dancing? Okay, one guy, two guys. Thank you guys. I find it depends what country I'm in, whether or not that gets a laugh. America, hilarious. Everywhere else, silence. So nobody puts UX in the corner. Where else can UX really live on safe, nice and non-confusing visual model? Well, we're here in portfolio land, involved in what we're building, why we're building it, and prioritizing what we're building. We also live in continuous exploration, that process of exploring the market and making sure that vision roadmap and features match or exceed those needs and expectations. We're certainly about customer solutions. That's what UX lives for. And we're hoping to make DevOps better. I like how DevOps got this weird little corner as if they're just a little add-on. We're trying to make DevOps better where we can. We want to improve and enhance the culture. We're all about decreasing failure rates, though we're probably thinking more on the human failure rate level rather than the technical bug level. And we want shorter time between fixes, but really UX wants fewer fixes. Better UX design earlier, fewer fixes later. And I don't care what SAFE says, one UX person should be on the agile team. And this person's going to represent the creative team. They're gonna represent visual designers, copywriters, and all of those creative people. So you don't have to have all of them on the team. The UX person should be one representative for that, at least that's my professional opinion. You're welcome to disagree, but disagree after I'm done talking. And so we can battle it out later. So we're all over this thing. I find that people who aren't too sure where UX fits into agile very often didn't really know what UX does or how they do it. And I don't blame you. It wasn't in any of your training materials, but hopefully it's starting to make a little bit more sense. So again, my professional opinion from the many places where I've worked, I worked at a zillion places in San Francisco. I joked I am the contractor to the stars. At the places I worked between what I saw failing and succeeding, I believe that UX should be part of sprints, but we've gotta be at least two sprints ahead of you. The place where I'm contracting now the other day said, I feel like I have pieces of a puzzle, but not the cover of the box. I don't know what I'm shooting for. And it's hard because if UX is giving people pieces, they might have that feeling of I don't know what the finished puzzle is supposed to look like. So if we can work way ahead of everybody then we can give you pieces as well as the cover of the puzzle box. And if you want engineering to build something at kickoff, we need time ahead. That's why we need to estimate our own time and be part of planning because sometimes you guys need a spike and sometimes we need time for research and other things. So again, include UX and sprints, at least two sprints ahead. And here I'm showing what I found to work best. I tend to separate UX and UI. Some people don't. They like to do UX and visual design at the same time. I'm a little bit more of a UX purist and so I tend to separate those. So typically I'm doing, my teams are doing the UX stuff first. When that's looking good and testing well, then I'll want to give it the visual design and branding because if it doesn't test well in UX, I might have wasted that artist's time. And then we have things that we can pass to engineering. So that's the approach that I prefer to take. I also suggest getting plenty of tech debt and tech evil into the backlog in case UX runs late. Hey, sometimes engineering runs late. Estimations were off. Somebody was out sick. QA found more bugs than we expected. UX can run late too. Sometimes we do our testing and it's a little bit more of a disaster than we planned. So it would be great if engineering has some low hanging fruit that someone has prioritized that they can switch to versus when engineering likes to sit and look at me like this. Say no, you've got something to do. I bet you've got something to do other than tell my manager I'm running late. So the key to the UX process is to make sure that UX has time for testing before delivering to engineering. That way we're sure this is a great execution for customers. We don't want to be surprised later by flaws in the design. We want to find them early and fix them. So it's best to keep testing in UX and make time for that. So that would be, yes. Oh, Agile Manifesto Principles. Remember the Agile Manifesto Principles? There are a few that I believe relate directly to UX even though they may not have originally been written for that reason. Principle one are highest priorities to satisfy the customer. And that's directly linked to how valuable, delightful, easy to learn, easy to use and life improving your product is. Principle five, give motivated individuals the environment and support they need and trust them to get the job done. You have to hire great UX workers and give them trust in what they need. Principle nine, continuous attention to technical excellence and good design enhances agility. Design matters. Don't just make it good, make it great. And my favorite, principle 10, simplicity, the art of maximizing the amount of work not done is essential. When UX kills or changes features we're often seen as the bad guys, but engineering should support our efforts to create less work for you by creating simpler or fewer features or by maybe killing or postponing a project that the company shouldn't do at this time or at all. Now at this point, usually someone asks me, okay, well then how do you reconcile safe Agile with wanting to use UX specialists in this method and put them on the team and get them involved and have them collaborating with product and engineering very early on? And the answer is if you're doing safe by the book you're probably not going to be working with UX in this way. They're not compatible. UX has been voted off the island by safe, which in my opinion runs against the Agile manifesto principles. And even if you embedded a UX expert on the team safe is still recommending that everybody have a say in the design because UX specialists shouldn't really be taken seriously. So I say look back at principle five, trust your experts to do the work and research and testing are so important to these other principles that we just can't skimp on it. So if you're trying to do safe you kind of have to ignore what their current recommendations are for working with UX in my opinion because otherwise you're not working with UX you're doing the design yourself and many companies are finding that's not working. Someone who saw my presentation asked me if UX is just waterfall, is this big design upfront because we're trying to get away from big design upfront. Well, imagine your company is setting up a new workflow. Maybe people are signing up and buying something. So we could break that up into five steps. Things like username and password, product selection, payment, review and confirmation. So that means developers can break this into five chunks or possibly even more even smaller chunks. And that's because in a dreamy dream world they have all of the documentation, information hopefully wireframes and prototypes that tell them exactly what they're building. They can keep other steps in mind when building earlier or later steps. But sometimes someone will ask me why doesn't UX design step one deliver that? Design step two deliver that. And the problem is that if we were to deliver these things in pieces and have engineering build them when would UX test the full workflow? Because to our customers this is a process. Probably a linear process and it is not disconnected pieces. And then if we find that it doesn't test well, does engineering want to rebuild it because now we found some flaws we have to fix? That doesn't sound like it saves time, money or sanity. So remember that for UX the smallest piece that we might measure by is probably more of a user process or a user workflow. It's hard for us to break things down into something smaller even though we know there are smaller pieces. We're aware of that and we certainly know developers are graded at seeing those smaller pieces. But for us we have to think about the big picture and the entire user's experience. Did anyone see this viral video? Does this look familiar? If you can find this, I don't know what it's called. But basically if you can see what's going on here and I don't have the video I just have a still. There is an automatic soap dispenser that shoots soap at you when it sees your hand come into view and then there is a power socket and so as someone goes to plug into the power socket they get covered in nice wet soap just before they connect to live electricity. And the caption I saw was this is what happens when you do unit testing without integration testing. But I like to think of it as this is the reason why UX designs and tests complete workflows rather than separate pieces in isolation. So remember for UX that smallest piece is the user's workflow or process we need that big picture. If the project is something smaller of course UX can be nimble and we'd need less time. But not everything UX does requires a giant runway but when it does product, project and engineering need to be prepared for that. And they can be prepared if we're involved in estimating our own time. So I often get asked why doesn't UX do fast feedback and iterate? Oh we'd love to but budgets and timelines tend to keep us from doing fast feedback and iterating. We always want that feedback. We want to improve this for customers. So before complaining that UX is a bad dog for not getting fast feedback and iterating check if we got the time and budget to do it because there's a grand canyon between yeah I'm so good at this I didn't bother testing it and holy cats I wanted to test it but no one will give me the time or budget. In 2018 a famous tech company whose screen you definitely don't recognize had to come out and admit that their redesign from the year before was a failure and they were going to be doing a redesign of their redesign. They found that once they released the product customers didn't like the new features. They found them drawbacks, obstacles, difficult to navigate and the backlash was so big the company had to go out on their own blog and basically say okay we messed this up we're going to undo it. But you have to ask yourself how much money did this company spend designing and building and releasing something that is available on multiple platforms, desktop and mobile. Now the cost to undo it and redo it did they spend a million dollars? Tens of millions of dollars? And think about the time and money they could have saved if so if they had pivoted or changed direction before the developers wrote this. We can know upfront there's no longer a good reason or excuse to just build it, just ship it and find out later it's a disaster. Companies can save heaps of time, money, staff resources and customer agony by making sure they're integrating the full UX process. I don't work at that company but my guess is they skimped on the UX process all over the place because UX specialists would have known at multiple steps that this was going to be a poor choice for customers. They would have known it's over complicated lacking simplicity, difficult to navigate. So again great opportunity for UX specialists to be working early on with product to make sure that features really are what customers want if we're not sure we spin up research we do some preliminary prototyping we can know, we don't have to be surprised later. So next is my final poll. Please take your phones out for another fun adventurous poll. Can we get more than eight people this time? I challenge you to challenge yourself. So take a look at this poll and it asks how terrible are these things for our customers? Take a look at each of these and vote on a scale from far left which is customer doesn't care at all to far right customer is so furious they might consider leaving our company. So I'll give you a little time to vote for each of these five and again it should come up live so we should see some exciting poll activity. You can do it menti.com88752. Can we get more than eight, come on. Do I have working internet? Does anyone know? It's slow, okay. But there's free conference food so it makes up for it. One person, I thank you for your vote one person. Let's get a few more before we call this. You can do it. So how much does this affect our customer? Not how much does this affect your job or that ugly meeting you don't wanna have with your boss? How much does this affect the customer using your product? And we did it, we beat our last record. Thank you guys, you guys are true friends. Thank you, especially this table over here. I know you guys are getting involved, thank you. So as you can see from how you voted the first four deeply affect the user experience. They're way off there to the right and we know that they are running the risk that they could make the customer leave us. That last one about time and budget, it does affect the customer in that if that really gets messed up at our company releases might get delayed and people might have to wait a little bit to get that next release. But the poll shows you that poor UX which is what the first four are that's enough to drive customers away which means it's important, it's make or break and we really have to make sure we're getting qualified specialists in there to do that work. And we can measure how it's working. So just like there are many metrics where we can determine if customer satisfaction is increasing or decreasing, we can also see if these desired DevOps results and goals are, they're all measurable so we can check on them. So for example, how long do stories, projects and epics take before and after your UX revolution? Well, I would hope that if nothing else estimation becomes more accurate when engineering is estimating from excellent UX deliverables like wireframes and prototypes versus what you might be doing now which might be estimating from user stories or from descriptions from product managers. And of course if UX is providing blueprints and those are being followed then hopefully engineering has less work and fewer surprise changes and rebuilds. And getting releases out to the public more quickly sounds great but let's make sure we're building the right product. Nobody wants to continuously deploy pieces of junk. Internal communication and culture are measurable. You would have to work with your manager or the people who you manage and that could be more anecdotal or you could turn it into a survey if you like to have hard numbers on that. So I want to encourage everybody to look beyond some of your traditional agile metrics. Look beyond things like velocity and efficiency and productivity. Those are important but if we're killing our culture if we're building a product that the customer doesn't want if we're burning our company's money for a product that is going to be a failure then it doesn't really matter how fantastically agile our teams were. So think about new ways to measure these things. And let's improve collaboration and culture. So let's say that your specialized database programmer is bottleneck right now. Too many stories looking for this person's specialty. What do you do? Well solutions could include pair programming, building a skills matrix so that you're better prepared for this in the future. Maybe you just have to add another programmer to the team. Maybe you allow more early testing so that there can be some fast feedback. But do you know what's not suggested in this scenario? Nobody suggests that the specialized programmer teach his or her specialty to other people on the team. Yet I've read scrum books that say your UX practitioner is probably going to be a bottleneck. Have her teach everybody on the team how to do her job. Well, I studied some basic language programming in the 70s. Hands up who remembers the 70s? 70s was I the only one there? Two, three, thank you. I did some basic language programming in the 70s so surely if your team has a bottleneck you want to teach me maybe some Ruby, some Java. I have a degree in music by the way so I'm a perfect person to teach some programming and I can code to production, right? This is a great idea, yes, blank faces, fear, no? Okay, so it's not a great solution as much as I would love to write some code for you. I'd much rather write a harmony part. But the problem is when we do this to UX it unfortunately sends the message anybody can do your job and that hurts culture. That's insulting to UX people. It's bad for the team. And side note here, conference sessions that are trying to teach you guys to do UX work. I also feel the same way about them. It's important for you guys to know a lot more about UX but when sessions are trying to teach you to do our job I feel like that's going in the wrong direction. So because nobody shows up at a UX conference and does a one hour talk on how to be a Java programmer and then says you can go back to your job and code to production. So it doesn't work in either direction. So quickly, I also wanna talk about who does the work at your company since we still have about 10 more minutes. UX and UI are often confused. I don't know how many people feel like this is a point of confusion for them. They can't quite tell what these things are. People who work in UX usually feel like there is a line here but it's an area where not everyone agrees. But one way that I found that I can help people tell UX and UI apart is to Google some universities and see what courses you have to take to get a degree in UX and a degree in UI or art or visual design. And it turns out these degrees are quite different. The UX practitioner is going to be more concerned with functions, processes, organization, layouts and usability while your visual design degrees and art degrees are more focused on the aesthetics of these elements. Color choices, typography, spacing, branding. So think of your UX specialist as your building architect. Think of your UI designer as the interior designer. These are both absolutely important jobs but they don't really overlap usually because being a talented UX designer doesn't mean you're a great artist. Being a great artist doesn't mean you have natural talent for UX. Many people think they're great at both but it's rarer than they want to admit. I've got self-awareness so I can tell you I'm a terrible artist. Somehow all of my art talent ended up in music. I'm truly a UX specialist. I'm good at Photoshop but that doesn't mean I'm an artist. If an artist saw my artwork, they would know I'm not an artist. So UX and UI, they're a cousin of the old battle of function versus form. UX is the function, layouts, processes, interactivity, features, steps and choices. It's all about psychology and natural human behavior. And UI is more about brand, mood and feel. It absolutely affects UX and usability which is why these people should be collaborators. But the visual design, at least in my world, is sometimes the last piece of the UX puzzle since if layouts and interactions aren't great or the wireframes or prototypes don't test well, who cares if it matched our brand? So, but again, these things don't naturally overlap. Make sure you're assigning tickets to UX. So if you find issues, ambiguities or the like during development or testing, get UX involved, get their names on tickets, whether you're in JIRA, version one or anything else, get UX into it. Don't create a Trello board for UX issues if everybody else is in JIRA. Bring UX into your system for communication, collaboration and documentation. It's a great way to start the conversation. It's respectful. It's better than throwing it into Slack and never being able to find it again. So best to bring UX right into your tickets. And invite your UX person to all of your standups, retro, release planning, meetings and showcases where UX might be discussed. If something comes up and UX isn't in that meeting, table it. Don't make a decision without your specialized teammate. Make sure you can track that person down and let them make the decision. And of course I can stand up here all day long and tell you UX is important. Here's how to work them in and make sure you bring them in early. But this is a graphic from a really fun document that got passed around LinkedIn a few weeks ago. Does anyone recognize this? No, I imagine not. This was being passed around mostly by Americans because this is a flowchart, a very short flowchart from a document put out by our Department of Defense. The American military released a document in 2018. It's not classified, you can find it. And it's called How to Detect BS in Agile. Does everybody know what BS is? It's a bit of an American slang word. Yes? Do I have to say it out loud? Do we know what it is? Okay, good. So, believe it or not, our government put out a document, How to Detect BS in Agile, because they realized it's become a buzzword and there's so many contractors who are looking for government money and to work with the government. But they're claiming to do Agile and they're not really doing Agile. And so I know the graphic's hard to read so I'm gonna read you a few of my favorites on here and this is, you can see the flowchart is straight to Agile BS if any of these answers are no. So this one says, are teams delivering working software to at least some subset of real users every iteration, including the first and gathering feedback? Attention and gather feedback. Is feedback from users turned into concrete work items for sprint teams on timelines shorter than one month? And of course, my favorite, are teams empowered to change the requirements based on user feedback? Well, of course this is my favorite one. I've already spoken about how I want to make sure UX is involved in the early planning and portfolio and feature decisions because we might need to pivot or make changes based on what we know about our users. And here's the American, and I wouldn't say rely on the American military for too much, but I think they've got this one right and it's a fun document worth reading because it is not classified. And of course, if any of the answers to any of these is no, you've got Agile BS. So before the project kicks off, before the budget's requested and before that treatment or plan is written, get product and project involved with UX to collaborate on what's being considered. Include UX and portfolio planning and decisions around epics and stories. Project managers need to know how much time UX needs. Don't surprise us later. I once went into a kickoff meeting and I was told, you need to give us final wireframes in two days. Obviously, a good, thorough UX process takes longer than two days, but this person thought she was being generous. She told me, drawing boxes on a page takes a couple of hours. We thought we were being generous by giving you two days. And if you need more time, we'll happily tell your manager you're derailing the project. That was at the kickoff meeting, so that was a lovely welcome. So sometimes UX does kill a project, an idea, a product, a feature. Therefore, get us involved early, just in case there are going to be those changes and product and project will need to account for that. So, ever notice that only non-UX workers are announcing methodologies and approaches that exclude, minimize, or dilute UX? At many companies, someone leads efforts to do one or more of these things and when the UX is poor and the customers react, they say, well, we tried doing UX and it didn't really work. Well, hey, whatever you did wouldn't qualify as UX to any UX expert. Did this movie make it here? Does this look familiar to anyone who isn't American? Anyone know this one? Just checking. I know my slides get a little regional with some of their memes. This is The Princess Bride. It's a movie worth watching. So, I suggest that those who have tried UX and stumbled with it a little bit, try again. But this time we've got to properly and thoroughly integrate UX specialists into the whole process end to end. We want the hospital bed to be empty because the patient recovered and is doing better than ever. If your DevOps needs critical care and treatment, if your relationship with UX feels broken, UX can't fix everything, but you'd be surprised how much great UX can improve. So, time to rewrite the book. Sorry about all the messy training or information you previously got. We're gonna fix it now. Talk to your managers and leadership about how better collaboration with UX should help culture, product efficiency, customer satisfaction, and all the things we should be measuring and caring about. Of course, work with UX leadership on how you're going to integrate that into your particular company since every company's going to be a little bit different. And of course, the path to getting your DevOps out of the ICU and seeing improved DevOps results, great product, and happy customers is the complete and correct integration of UX specialists and processes. And with that, I say take a picture and check out the website later or give me some feedback on my survey. Add me on LinkedIn, email me questions. Request the two day version if you'd like to the 41 minute version. There is the two day version. But since we have a few minutes, I'm happy to take questions or horror stories. Otherwise, please email or LinkedIn me and let me know how I can help you. Thanks for dropping by. Yeah, question. Okay. Yeah, absolutely. It's a great question. And it's one that I know a lot of people are struggling with. I'm not sure anybody's found the perfect answer. You know, and for those who didn't hear the question, it was about how there are so many specialties now. Why isn't everybody on the team? Why don't we have an agile team of 40 people who all have their specialties? And I think it has to do with how the team sets up its communication, whether somebody needs to be embedded on the team or whether someone can be like the agency model, someone is assigned to the team but doesn't have to be at every meeting and be that close a collaborator. I've just found that if you don't include UX in that, the engineers typically feel like, well, there's an ambiguity here. I'm not too sure what it's supposed to do. They forgot to wireframe it or the wireframes don't make sense or they missed a piece. I'll just make it up myself. And so I find that if we really care about product design, then we can't have the accident where sometimes we're working with UX and sometimes we're not. And I also find, especially from the job where I'm contracting now, I find that me just being in the stand-up meeting or me being in the meeting where they're walking through tickets that look a little bit stuck, the UX issues naturally pop up. And I happen to be there and I say, that's mine. Let me take that. You don't have to work on that. Let me take that and I'll design something for you and I will make sure you get back perfect blueprints. And so, oh, do you mean how you might have a UX person who is on multiple projects? Yeah, that's very true. I often recommend that a UX, depending upon the size of the project, a UX person could be on up to three projects. I have a friend who's on seven right now, but that means he goes to no meetings, he gets nothing done, he's just struggling all day long. So it is true that your UX person might, even if they're embedded or assigned to the team, they might be 50%, one third. And that's why I suggest that if something comes up in a meeting, assign it to the UX person, that don't make the decision for them because I know that not every UX person can get to every meeting. The job where I'm at now, I'm mostly on one project and so I make sure to go to every single, and I just did some talks at a UX event and I told them, when you get an engineering ticket, drop everything. I know it's hard to do, but you are now the bottleneck for the entire engineering team. Please drop everything for them. Think about how long you like to be on hold. That's how long this engineer should wait for your answer. Don't answer them tomorrow. Answer them right now. And I showed how I try to answer my engineers within two minutes. So. Yes. Yeah, it's hard. Like I was saying, my boss was saying at this new job, I feel like I have pieces, but not the cover of the puzzle box for what it's supposed to look like. And I said, well, I think you have to choose between do you want pieces from me as they're done or do you want me to build everything that's going to be in the release and then say, I've built everything that's in the release, but hey, I'm still sprints ahead of you and I'm already working on the next thing. And as you have questions and ambiguities, I'm right there for you. So I think the hard part about that is is the more desired version is where UX has designed the whole thing, which gives us the opportunity to do user testing on more of a complete feature or workflow. But then people start going, oh, well, that's waterfall. And I say, how about we just stop giving names to stuff? How about we not worry about what we call this because I think that's messing people up more than anything. If we just said UX is doing its process and it's sprinting along with us with whatever time frames it needs and UX is going to give us this at a certain time, why make up a name for it and decide that it's bad because it might be something we just kind of need to do. We might just kind of need to have UX building more things up front and delivering them in less of a two week sprint way. So I think it really depends on the product and feature because I've worked on teams that did two week sprints and it was a very experimental team. It was an app experimental team at an American department store and we were able to do little UX bites in two weeks. But that was on kind of small like, what if the homepage had an ad here instead of here? Ooh, let's try this thing. So when you have these larger features, I can't help but feel like UX ends up looking a little bit more waterfall-y because we want that time to research, design and test before we pass it to you because I don't want to give you something that we didn't test because then the live users, the paying users are what we call the guinea pigs. They're the crash test dummies and I don't want to do that to them. So I'm not sure anybody has totally figured that out yet. I don't know, there's one right way to do it but I know that engineers that I work with seem to be happier when I give them a, because I work in prototypes, I work in Aksher. So engineers seem to be happier when I say, I've built the whole thing, here's a prototype, click through it. What other documentation do you need? And they say, oh, not much, I'll just use your prototype as the UX model and I'll get the UI from the artist. But that means I've built the whole thing which makes me look a little less agile but if we can all just stop judging each other and stop deciding who's more agile than someone else, you know, we still have the same desired result which should be product quality and customer satisfaction. Yes, and then everyone gets to go to keynote. Sorry. Just to add to that, if you have not tried design sprints, it's probably the U.S. community is trying around the design sprints and actually printing along with the development and the quality of the sprints and stuff that might help as opposed to adding, bolting on a waterfall in the literature to it and confusing the technology. I'm not a fan of the traditional design sprint but that's probably a talk for another day. There might be someone here saying, design sprints are awesome, I just happened to disagree only maybe I've seen them run poorly. But what was your other question? Yeah, it's a burst of new design. So how do we actually look at and see if I have to finally say whether the U.S. design is good, bad, or ugly? Is there a method? Because there are so many aspects of U.S. Have you figured out how do we actually measure the compatibility of the U.S. design with the LV? Okay, so great question. How do we measure the compatibility of the U.S. design with the end user? Who says the U.S. design is good, bad, or ugly? And the answer should be the end user. Not the product manager, not the CEO, not the CEO's husband, not the CEO's dog, not any of the people who sometimes try to get themselves involved because if you're really doing UX right then you should have things like personas or some people call them avatars. We're building for these people and when the CEO comes in and says I want it like this I say which of these personas are you? You're none of them, then I don't care. So but I'm from America and I say these things to people so it doesn't work for everybody. But ultimately the person who says this is good, bad, ugly, desirable, undesirable is the end user and that's why UX has to do UX testing sometimes more than once before delivering to engineering. I don't want to deliver some sort of blueprint to engineering and then find out oh now that the user saw it in some sort of AB test or experiment or whatever they hate it. Like what happened to the company I'm not naming on that slide who is Skype. And so you don't want to do what they did and so the product manager should look at does it match the vision and requirements or change the requirements but ultimately the end we have to have good testing data done by UX specialists, not done by random people. UX specialists and UX research specialists should be doing that and that way they can come to you with that concrete data that you love saying we tested this on five, 10, 15 people. Here's what went well. Here's something we need to quickly fix and that's the story. So but that's why you want to test in with a bunch of people and you want to make sure your testers match your personas. So that's why we don't test with people internal to the company because if you're my coworker and we're building something for gamers who like heavy metal music, I'm not going to test it on you. You don't fit into that bucket well. I'm going to go test it on my ex-boyfriend. So then we want to make sure we're testing on users who are either our real users or match the archetype and we want to see how the users respond to it without asking them biased or leading questions like did you like this? Because everyone wants to say yes, I liked it. You know, it's like do I look fat in this? No, of course you don't look fat in this. Of course I look fat in this. So anyway, of course this shirt makes me look ridiculous but you won't tell me that. So always the voice of the user should be first no matter what role you are in your company because if the user doesn't like it or we didn't ask them, we're headed for expensive disaster. Debbie, can I put in a floor? I was going to say, do you want to put something in here? This is great. I want to thank you for starting this conversation. Sure. And if any of you aren't coming to Thursday which is the design innovation day, there's going to be a lot of topics that will continue this thing and address product and UX and integration with Agile. So if you weren't considering coming on Thursday and this fascinates you, sign up for Thursday. And listen to this guy. There's going to be a lot of people who have different perspectives and different experiences. And again, thank you for bringing this conversation into today's conversation. Sure. I'll be around a little bit if people have more questions but I know there's a short break before the keynote. I'm going to skip the keynote. I'll just hang around in the hall if people have more questions. So thank you. Thank you so much. Keep the questions coming.