Getting design to work with agile methodologies can be a real challenge because agile is a software methodology that works well at iteration and struggles with creation. In this episode, we will walk you through the basics of agile methodologies, the most common problems for creative teams, and share some tips for how you can make agile work with your design process.
SHOW NOTES:
http://thecrazy1.com/episode-24-process-making-design-work-with-agile-methodologies/
FOLLOW THE CRAZY ONE:
Twitter, Instagram, LinkedIn, Facebook
Getting design to work with agile methodologies can be a real challenge because agile is a software methodology that works well at iteration and struggles with creation. In this episode, we will walk you through the basics of agile methodologies, the most common problems for creative teams, and share some tips for how you can make agile work with your design process.
SHOW NOTES:
http://thecrazy1.com/episode-24-process-making-design-work-with-agile-methodologies/
FOLLOW THE CRAZY ONE:
Twitter, Instagram, LinkedIn, Facebook
What's going on everybody, and welcome to the 24th episode of The Crazy One podcast. As always, I'm your host, Stephen Gates. And this is the show where we talk about creativity, leadership design, and a whole host of other things that matter to creative people. So, apologies for those of you who subscribe to the show. I know we, we took a week off last week, which was not my intent. I spent Thanksgiving in Europe landed on Saturday afternoon, had every intention of recording a show on Sunday, and dammit, just the the jetlag Gremlins got the better of me. And I just didn't have the energy or the focus to be able to do it and have it be any good. So I decided to take the week off. Apologies for that. But we're back and we roll on. And so today what I want to talk about is something I've been getting asked a lot about lately, so I wanted to do a show focused on just this. And it's how do we make design and how do we make creativity work with agile methodologies. This is a new way of working it's kind of become all the rage but it is riddled with challenges. If you're a designer, you're creative, so So we're gonna focus on that today. But before we jump in, there were a few quick housekeeping things that I wanted to catch everybody up on. The first was at the end of the most every show, I say, hey, if you have any questions, shoot me an email. Well, it did occur to me that if you're trying to build a community, if you're trying to share information, a bunch of these one on one conversations might not necessarily be the brightest way to do it. So I went and created a Facebook page for the show. So if you go onto Facebook, search for The Crazy One podcast, and there's a page there, and this is the place where I'm going to be sharing updates. I want to try to answer any questions, and really just kind of create a bit more of an open community around the show so that if you have a question, other people can benefit from the answer that it isn't just just kind of like one off conversation between the two of us. So if that sounds like something you'd be interested in, if it's something you want to participate in, head over to Facebook, do the Quick Search, give the page a like and we're going to build the community there. The other thing was that coming off of two shows ago, so the replay of the talk that I did at Adobe max That show and the reaction since then has been absolutely phenomenal and that the show actually broke into the top five design podcasts on iTunes, which is bananas to me, I think for a show that's only basically four months old. We just hit 15,000 total downloads, it's in the top five shows. I can't say thank you enough, the response, the emails, I've been getting the people who come up to me and talk, who post stuff on social media for the things that they're doing or create graphics or do stuff like that. I can't thank you enough, because the show is work. I'm not gonna lie. I mean, I've got a lot that goes on in my daily life. It takes effort to be able to put this stuff together to share it with you guys. And that's what keeps me going. So I can't say thank you enough because that is just bananas to me. So like I said, thanks for that. But on with the show. And so like I said today we want to talk about how do you make design and how do you make creativity work with agile methodologies and if this is something you've been trying With and I know that a lot of you have been because as I've been talking more and more conferences lately, more and more people are coming up and asking these questions. So this is something you're struggling with. Today, I'm going to be your new favorite person, because this is something that I've been doing for about the last 10 years. And so what we're going to do is we're going to talk about three things. The first is if you don't really work in Agile, but if this is something your company started to talk about, your team started to talk about, just a basic conversation of just what the hell is agile, this has kind of become all the new rage in companies in design shops and agencies and consultancies. So as it rolls out, just what the hell is it? Next we want to look at and just kind of point out what are the most common problems that I've seen and there are a lot of them because the challenge that we're going to have is that agile is a software development methodology that works really well on iterating something once it's live in the world. What do you do in all those other times? How do you fit design into a development methodology So we're going to talk a bit about that. And then finally, I want to share what are some of the tips, some of the tricks, some of the things that I've done to really get the two to work better together, because I think there are some very simple changes, some just fundamental things that you can do that will just get it humming. And whenever you do that, you'll find that design an agile can work incredibly well together, you can work incredibly fast, it fits in with design thinking, and so many of the other things that we do. So those are the three things that we're going to focus on. Let's just start with what the hell is agile if you don't work in it, if you have no idea what it is. So most companies for forever have done what they call waterfall development, which is really one group works on something and then it kind of flows and falls to the next group strategy will flow into wireframing flows into design flows into development, just a basic kind of one after another sort of way of working well. A lot of the things that are being done right now. Around the methodologies, whether it's design thinking that brings everybody at the table, or whether it's agile, really tries to accelerate that tries to get everybody to participate. How to define agile is always a little bit tricky. So I guess I did probably the most cliched thing possible and went to Wikipedia because I thought, well, the the hive mind is probably got a good way of describing this. And so Wikipedia will define agile as Agile software development describes a set of principles for software development, under which requirements and solutions evolve through the collaborative efforts of self organized cross functional teams. So obviously, somebody spent a lot of time putting that sentence together, because there's a lot that's in there. But I think there are a few things to call out as positives and a few things to call out as challenges. So the upside of Agile is that it lets you work and evolve collaboratively. It lets you work and evolve quickly that they're cross functional teams that everybody works together in what are called sprints that can be of any length, it can be two weeks, three weeks, four weeks, but basically you just side, what is the entire thing you want to build? How do we break this down into these little pieces into these sprints? And then we go about setting these kind of short term goals for ourselves so we can continue to iterate and move forward. The challenge for that is it said in the first two words, is Agile software development. Well, a lot of what we may be doing a lot of what agile gets used for may not actually be for software development. And a lot of times, it can be driven by tech minded mentality. And I think this is where the creative struggle This is where they feel like they get run over. But you know, the core of this methodology really advocates for adaptive planning for evolutionary development for early delivery, and kind of like continuous improvement, so that things are rapid and they're flexible and they respond to change. Well, that's the heart of what creativity is, it's just kind of letting more people into the tent to be able to do it. So if that's what it is, if it is disability of defining a problem, break it down to small pieces and then being iterative and quick about getting it done. Well, what are some of the problems that we see that happen most often for creatives? And I think that the first one is is what I've said all along is that it's a software development methodology. So that the challenge with this comes with. So often there's a kickoff where you define the the stories, you define what the problem is going to be, and then you set off on actually doing the work. Well, that's great. But the challenge for designers that they find is that whenever you're in these sprints, two weeks, three weeks, four weeks, however long it is, you are heads down, working with the team trying to produce something, trying to produce a design trying to produce assets. And because of that, it just simply does not lend itself to doing any real concept in your creative work, because you're focused on a deliverable. So I think that's one of the first one of the biggest problems people see is that it becomes very disconnected or disjointed, where they can't figure out how to be creative in inside of this system, because it's so delivery focused, and it's so fast. The next one that I see tons of times is that companies love to move from waterfall to agile. And they say this is going to be great, we're going to deliver faster, we're going to do this sort of thing. The one biggest thing that I see time and time again, whenever they make this move is that they don't realize that agile and waterfall take two very different levels of people. Because in Agile, it is required for teams to be dedicated to a team to a scrum to to something so you have a designer, you have a information architects, you have a writer that is dedicated to that project and to that team. Well, the challenge there becomes Well, maybe before I had a designer, a writer, an information architect, or whatever it was, they could float between multiple projects. Well, they can't do that anymore. So that if I used to have one designer who worked on three projects, well now I need three designers to work on three projects. So I think that a lot of cases you find not enough people And then design often will struggle with this because we're a group that historically is used to floating between multiple projects that this idea of dedicated resources is often new. And it can become a very serious challenge to managing talent whenever they are just simply embedded on one project. So how do you deal with stuff like that? I think they also find just inherent problems with the process itself. Because there are just some core tenants of Agile some core things that are really defined as these are some of the important things that you need to do. The first one would be something like the team must be empowered to make decisions. Well, that sounds great, right? Like this is the same thing as design thinking where you bring everybody to the table, you say that it's one of these things where, okay, we're going to trust the team. Okay, great, trust the team. But the problem is a lot of case this manifests itself really in a few different ways. The biggest one is that so often in that change, you'll find that leadership or you'll find the executives will want to do agile, but then they still want what is really a waterfall approval process. They want weekly or monthly check ins, they want the ability to see the work to sign off on it to make changes. And that's not the way it works you. If you trust the team, well then you trust the team. And so there's a real challenge and a lot of cases for creators because you're stuck in this no man's land between what we're supposed to be agile, my day to day life is agile. I'm heads down, we're producing something. But yet, I'm still being asked to do these traditional design reviews that at certain points we're going to check in and we're going to review things with with the leadership. Well, that's an incredibly hard tension to solve for. And we'll talk in a little bit about kind of why that doesn't work and maybe a slightly different way to be able to go after solving that. Another tenant would be something like complete each feature before moving on to the next one. It sounds very simple. If we're going to build something we build it in pieces. If this was a brick wall You lay one brick and then the next and stacking them all up builds the wall. The This concept is no different. But I think that the thing that you find is, well, there's a few different things that can be challenging here. The first is if you're just building an experience a piece at a time, and if you're doing it without any kind of a blueprints, well, it's kind of like imagine we're building a house and there aren't blueprints for the house. And I have one contractor who's building the roof. I have another one who's building the walls. I have another one who's building the foundation. And none of them are really aware of what the other one is doing. Because they're building each piece. They're building the Best Roof they can the best walls, they can the best foundation they can. But if there's not a blueprint to hold them all together, well, then the house falls down, it turns into Frankenstein. And I think that's so often the problem is that people will say, Oh, well, it's okay. We'll just we'll put it live and then we'll iterate against it. I think this tends to be the philosophy of where you see a company like Google who often will just put things live and then we'll iterate and tune it. Well, sometimes that's great if the initial problem Offering is strong enough. But I think if you look historically at what Google has done and a lot of their products, even on major ones like Google Plus and things like that, people don't have the patience for the iteration. They want it to work. It's, if I'm in service of a customer and a customer experience, that requires a slightly different way of thinking than a customer being in service of my experience in my evolution, a lot of times customers may not want to do that. So if you put a Frankenstein out there, yes, he's alive. It's walking around, and it's out there. But the thing I always joke about is that, yeah, Frankenstein was alive, but like, nobody really wanted to date him or spend time with him. And so your product may end up being the same thing where, yeah, it's alive, but nobody wants to go out with it. And so I think that this is one of these real challenges is to be able to figure out okay, how do we fit this stuff together? And how do we come up with a blueprint? Because the other challenge that you have is that without that blueprint, well, what do creative teams do they they have ideas, and if you don't have some of that big thinking in place, if you don't Have a blueprint or some sort of a guide in place, the experience can wander around because creatives like to have new ideas, they like to evolve their thinking. And if I'm doing it over a long period of time, and I don't have those rails sort of locked in, well, then one part of your experience may look one way another one may look a different way, they may function in one way in one area of the app and another one in a different area. And so these are real challenges. And I think that it requires everybody to also just pay attention to what's going on. Because the other challenge that you see is that so often agile works best whenever a designer creative team is really working probably at least two to three Sprint's ahead of their dev team. And the reason why you do this is because I want my creative team to have the assets done, I want them to be signed off on before I hand them over to my partners in tech, I don't want them to have to shoot at a moving target. So I want my work to be done. Well, but the challenge is going to be if I'm working two or three Sprint's ahead of what they're actually doing. Well, whenever we do reviews, we do retrospectives, we show off the work, I need everybody to be paying attention to it. Because if that doesn't happen, within the other challenge that you get is that so often whenever a dev then does come behind two or three Sprint's later and picks up the work, when all of a sudden they see a bunch of problems, they see a bunch of things that needed to be changed because they weren't necessarily paying attention, or maybe product wasn't necessarily paying attention. Whenever we reviewed that work, well, now that it's being built, now we need to pay attention. So those are significant issues about just how do you get people to focus on this? Another thing I think would be that I see a lot is that, you know, a great principle is always a testing is integrated throughout the project lifecycle that you need to test early and test. Often. This is the same thing as in design thinking where it's fail fast, fail quickly get it in front of people to be able to make sure that you know what's really going on, and that's how we're going to iterate. Well, the challenge I see here is that there is sometimes there are strategies. Organizations there are research organizations that aren't used to working in Agile because agile can kind of freak a lot of people out. Because we're asking everybody to kind of build your wings on the way down. But we don't necessarily know what the answer is. Well, some of the things with research and testing is that these can be long and drawn out processes. And as a design team, if I'm working in a two week window or three week window, I need my results quickly. I can't put something into testing and get results back 10 days later, because then I've missed my sprint window, I can't react to it. So then the challenge that I have is either I'm going to miss my deliverable, or I'm gonna make my deliverable and then in the next sprint have to do double the work because in the next sprint, now I'm doing the work I was supposed to be doing, but then I have to go back and do the revisions based on the testing that I got. So think about how and to clearly define how do you quickly iterate on this stuff. But at the same time, when you get those results back, you also have to make sure that you don't go I always call Data blind, because I think that you really can also become too much of a slave to the data. There is the story that I love to quote tons of people love to quote, which was that when Henry Ford was was building the Model T, he was asked about kind of why did he design a car? And why didn't he listen to what everybody wanted? And he his answer, I thought was perfect, because he said, if he would have listened to what everybody wanted, that all he would have done was build a faster horse. And I think that this is where sometimes, research and numbers sometimes can let you just build a lot of faster horses, that there are some parts where you have to just recognize that in a lot of cases, research is mainly solving for the present state of a consumer and their current understanding of what their problems are. If you want to do something different if you want to evolve it, if you want to press if you want to move the needle, well, then we're going to have to ask them to add to think differently, to look at things differently than what they've done historically. That can be a real challenge. So I think that there Sometimes people get very caught up in CO creation, they get very caught up in data, they get very caught up in kind of what are people telling us? And there is sometimes that is absolutely what you need to do if there is a flow that is broken, if there is something that is not working, you've got to listen to your consumers, you've got to figure out why isn't this working. But there are other times where you have to understand the data for what it is to understand the intent behind it, maybe not what they actually said. But to see how we're solving the problem. We're just going to do it in a different way than what they're used to. Yes, there may be an adjustment period to that, yes, there may be a time when people they're going to have to reconcile that the things are now different, but the change is going to be worth it. So don't go data blind. Don't do that death by 1000 cuts of just getting so blinded by the research that you're doing that you lose sight of how to create a great experience because I think that can happen so so easily. So just keep an eye on that. You also need to do things in Agile like it's really about a collection. Have a cooperative approach between all the stakeholders, because this is the same thing as design thinking. And I've talked before about how for me design thinking is the greatest Trojan horse for change because it brings everybody to the table, it brings everybody in, and lets them all sit down and work together at the same time. Well, agile is the same way. But this is a huge change. For a lot of people. We talked about this a little bit just a minute ago. Because a lot of teams, a lot of people, a lot of thinking is very used to being okay, with the creative, they'll go take the risks, they'll go figure this stuff out. And so they aren't used to having to go on that journey. They're used to the confidence of I know where I'm at, and I know what I need to accomplish and that's very well defined before I start my work. This is oftentimes why I work design two and three Sprint's ahead of development is so that, you know, the core base that the big part of the developers really still have that sort of structure that they're used to, but then I can Work with the leads, I can get them to be more accustomed to this sort of uncertainty. But this is where agile is a challenge. And I think this is where it's so many of these teams struggle, because the creative team may be used to it, the dev team may come around to doing it. But can you get the clients? Can you get product? Can you get the business to be used to this because it forces them to give up some amount of control. And that freaks some people out a lot that they aren't used to doing that. And so I think it's just, it's one of these things where, how do you define this? How do you make them comfortable with it? How do you understand that your role may be to guide everybody else in this process that maybe they're not really used to. And the last one of these that we're going to talk about is that it's one of these ideas where you can develop small incremental releases and then iterate we talked about this just a little bit. But the challenge for a lot of designers is that iteration is great. Once a product is launched, I have a website. I have an app, I have Have an experience I have something that has been created. Well, now I can easily identify what are the weak spots? What are the things we could do better? How can I go through and change that I can iterate? Well, if I'm creating something from scratch, if I'm creating something that didn't exist before, this sort of iterative approach, this sort of lack of a blueprint that we talked about a minute ago, that really becomes a struggle. Because when you need to create something new, it isn't about incremental change. It's about invention. It's about creation, it's about doing something that is very different than what we've done in the past. So I think these are just some of the most common challenges. And I think if this is something that you work in, if you worked in Agile, you probably sat there nodding your head, being able to empathize and sympathize with a lot of these. If you're new to agile, if this is something that you're trying to set up. Just be aware of these pitfalls, that these are things that can become real issues. And this isn't just for small companies like one of the most fascinating things that I saw around some of this stuff was that famously, whenever Facebook launched one of the things that they became probably best known for, were the posters that were up on the wall in their office, one of them which famously read, move fast and break stuff. This became the stay hungry, stay foolish from Steve Jobs of the Facebook generation. I can't tell you how many startups how many companies I've walked into time and time and time again. And I've seen this poster up on the wall, move fast and break stuff move fast to break stuff. It sounds so Cavalier so pirates so kind of rebellious that it's great. Well, the funny thing, though, is if that if you pay attention the way that I do, you'll notice that well, even Facebook had to change that as they grew because as their process matured, as their product matured, move fast and break stuff wasn't sustainable because you started to get more people Complicated experiences, you need to start the need to build new things. And so very famously at one particular speech that he gave, but also in all the Facebook offices, where the posters were that were very large on on the walls that said, move fast and break stuff, had other posters put over them, that read, slow down and fix your shit. Because that was the problem is everybody was getting so Cavalier, they were getting so loose and so easy with what they were doing that they were actually undermining each other. They're breaking too many things. It was becoming just too disorganized. Because everybody had this rebellious spirit. There's a time and a place to move fast and break stuff. There's a time and a place to be able to slow down and fix your shit. But this is the inherent push and pull between this so that even the best companies, the ones that are looked at as being the most progressive, well, these are the ones that struggle with it too. So you're not just alone in this. So let's look at how do we find that balance between moving fast and breaking stuff and slow down and fixing our ships so enough with the problems enough With moaning and groaning about that stuff, how can we actually make agile and design work together? That's why we're here. That's why you tuned into the show. So there's a few things that I would recommend doing. The first one, the biggest one, the one that is going to make the most difference and save your sanity, more than anything, is to inject what I call it the beginning of any project, either a sprint zero, or a design sprint, Sprint zero, meaning that this is the work that needs to take place before the full team fires up before all the work actually gets going. That we need a time just for the creative team or just for our partners to sit down and come up with what is the big idea? What is the concept? What is the blueprint? What is the thing that we're going to go build, so that we're sure that we have clarity around what that thing is that it really gives us the ability to go through and just take the time to think Because that's the real challenge in all this is that agile is great at moving fast. But ideas don't always happen fast, especially good ones, especially big ones, that those sometimes need time. They need you to sit down to think to reflect, to find the opportunity and to understand, okay, how can I make this into something? So I think that that that's the place really to start is with this sprint zero. And the other reason why I do this is because coming out of this, it really helps me get out of a couple problems. The first one is that we talked before about, okay, well, I'm doing an agile methodology, but a lot of cases, leadership still wants me to be able to deliver in kind of like a waterfall way they want the roadshow they want the top hat and cane song and dance. Here's what the agency feeling pitch is. I get it right. You will like shiny things you like design things you like things Does that look good that you can pin on a wall and you can send around and circulate like I get that. But I think this is where the sprint zero also helps save you with this because what it allows you to do is to create one or two of these key moments. So if I'm gonna set off on redesigning a website, it may be that my sprint zero only tackles the navigation. So like the header and the footer, and maybe just tackles the homepage, because we feel like those are gonna be the first key moments. Those are the big set piece things. And that once management has seen, okay, structurally, how are we handling the site and what the front door is going to be? Well, then they're going to calm down a little bit, they're going to trust us a bit more. And the reason why I think that this works, and I often or if you're also referred to it as kind of like a Northstar concept is that it also lets us lay out the roadmap for how do we move forward, because sometimes in these ideas, we can't get them all done at once that if we're going to release iterative iteratively if we're going to go through and be able to work on this stuff in pieces. Well, maybe I don't get the whole homepage, my master vision done all at once, maybe it's gonna take three, four or five releases, maybe it gets done all at once. Maybe it takes two years to roll the whole thing out. But I put a Northstar out there I put something that everybody can work towards, to keep them focused because I said that before that one of the challenges can be that you can wander around or you can evolve and so that the sprint zero and then this sort of Northstar concept, it gives us something to focus on, it gives us something for the product to stay true to it gives us something for everybody to build towards. It gives your clients something that they can see and invest in and understand. And I think that those things are really critical. And I think if you're like me if you've also struggled with tech orgs that can't always necessarily always deliver on what your vision is. It gives you the ability to demonstrate to the organization that you are about ideas that you are about a group that really can deliver a bigger idea and then you can work with a tech team about how do you get to building that vision. Because what I see so often is, I see these design teams that will only build what are their only design what they think tech can build. Well, I get that I understand why you'd want to do that because it puts a realistic goal out there. But it also hamstrings and handicaps your group and the perception of your group. Because you're limiting your thinking you're shrinking the idea down, you're, you're just putting the near term goal out there, so that maybe we wanted to do something much bigger. Maybe the Ask was for something much bigger. Well, why don't we design that? Why don't we show that why don't we sell that? And then figure out how do we back that down to then what a development team can build as opposed to just limiting our thinking to Okay, well, this is as far as we're gonna go and then then we'll think about Okay, well, maybe then we'll figure out what the next jump is. thinking like that doesn't work or it just gets abandoned too easily. But if we know that there's a bigger picture here and we can build towards that. That's where this really matters. Because it's that Northstar that everybody can follow. And so I think that that, that simple change the sprint zero, and to design the ideal experience that you can then back down to what can get built, as opposed to just starting with only what can get built. I think that alone makes a massive, massive difference for the perception of your group, the happiness of your designers, the quality of your thinking, the quality of the work that goes out the door, because it's, it's a more heads up approach to doing innovation. Because that's, that's the trap here is because most people only will innovate and think and think as far as the scope for the project that's in front of them, and no further that they've given us this much rope. So that's how far we're gonna go. And it's such a mistake, you've got to pick your head up and you've got to have a more forward looking view of where it is we're gonna go. Like one of the things that I always admired that came out whenever there was the Big Apple and Samsung trial was that if you go into the design lab, the design office at Apple in Germany, Is office in his work area? On the benches there the next five generations of every product. So the next five iPhones next five iPads, an X five MacBook Pros, whatever that is? Well, we know that in five years, the iPhone 12 is not going to look exactly the way that this one does. That's not really the point. The point is that this lets us be able to look down the road to think about where are we going? What's the experience, we want to get to? Not just what's the experience we have? And how can we mildly iterate on what that is? And so I think you can debate about how well that has worked out from the product perspective in terms of genuine innovation for them. But let's just put that to the side and just kind of say, you know, just from a thinking perspective, the heads up approach to that. They're looking down the road approach to that the Northstar way of doing that really gets you to someplace fundamentally better and different than just doing the smaller short term look at things. So think about that. Do us sprint zero and do a much more this kind of Northstar thing that you can build towards. And honestly that works even if you're not doing agile, but just to try and figure out how to, you know, like I said, pick your head up and look at this stuff. The next big thing that there is no substitute for that is a dying art now is communication. If you want to fix agile, it is amazing what happens when you actually talk to people. Because when you're working this fast, well, it's a natural thing to just say, we're gonna, we're gonna do everything through email, we're going to be able to just kind of do this. And that's not the way this should work. The whole point of Agile is to bring everybody to the table. There's a dedicated scrum team that works on this stuff. And you're supposed to do it side by side, you're supposed to talk to each other. And that's the way it's supposed to work. But that isn't always the way that it happens. So I think that there's one of these things where you have to find ways to communicate. If you're doing agile and you aren't doing a daily standup of at least 10 or 15 minutes. You're screwing it up. Because you need to do a daily standup every morning where you go around the room. Everybody talks about what they did yesterday, what did they accomplish? And what are the blockers that are keeping them from where it is they need to go, there has to be this open dialogue, you have to get your project manager, your producer, whoever it is to capture these, and to be able to keep a running Scrum board, con bond board, whatever you want to call it. There are a lot of different flavors of this, but some way of keeping that team together. Well, the other thing that you have to do if you're in a leadership position on this, or if you're dealing with a situation where there are multiple teams, is that the next thing you're going to find yourself in is this sort of meeting hell, because if you have 510 20 different scrums that are running, well now you may find yourselves in meetings from you know that need 20 different little decisions on things. So what I would recommend and the thing that I do is to say okay, instead of me having all of these little one off meetings, that once a week for however long it needs to be One hour, two hours, three hours, I'm going to have each team come in, and we're going to do a design review. They're going to get 15 minutes. And it's the entire team, the entire team tech producers, product, everybody, they all come in, and just simply review the work that's going on. And we're going to do that review with everybody that's there who is a decision maker, the head of design, the head of product, the head of tech, everybody that has a say on what's going on, we're going to come in and we're going to use this to one review the work but to to make decisions get shit done, to actually go through and to get obstacles out of people's way, too, so that we can walk out of there with decisions. This is not just some like charettes, where you're going to come in and just post up your work that is showing the progress. It's asking questions, it's raising issues and it's getting them solved in the room. So everybody knows this one time during the week, everybody that you need. Every decision maker is going to be in one place that we can come in and we can get this stuff done. So I think that the other thing with this if you're dealing with kind of multiple scrims, and you're trying to lead this, and I think this is something that I've struggled with a lot over the years, is how do you basically not end up with the Frankenstein? Right? We talked about this before that it could be alive. But the same thing with Frankenstein, it may be a lot of well created, well curated parts. But when the parts come together to form one whole experience, well, maybe it doesn't actually look that good. Maybe it doesn't hang together that well. So I think you need to dedicate some people some portion of their time, some way of watching the big picture. Because I think that if you don't do this, you get inconsistency in your experiences and consistencies in the design, inconsistent communication, and it has to all fit together. And so I think that there's a few different ways to do this. I think one is before all these scrums kickoff, keep an ongoing roadmap app map sitemap Master Layout, something that is going to define the overall experience. So if I have 20 different teams that are touching an app on 20 different projects. Well, the challenge there is how do I make sure that those all lined up and makes sense? Well, the easiest way that I know to do it is to create an app map that can define where are each of these scrims working. Where is their functionality, their piece, where is it going to surface, if we go back to the house analogy, that I have a master blueprint that lays out the house, that I know this particular team is going to work on the living room, and I'm going to tell them that the door to the living room is going to be located here, because what I don't want is I don't want each individual Scrum dictating where they fit in the experience because that leads to chaos. It leads to the last team that went into touch a page gets the top placement even though maybe it should be in the bottom that it leads to this just anarchie of things but what I want to do is I want the ability to make sure that the experience is protected the experience Good. And so I'm going to say, okay, the door to the living room is here, this is the best place for it. We agree from a product standpoint, from a business standpoint, we're all on the same page, this is where the door is, I will then go to that particular scrum team and say, Okay, this is where your door is going to go. What happens when you walk through this door, the way that the room is built, the way that it is decorated, the way that you see it and experience it is completely up to you guys. Because what I want to do is there needs to be this freedom in a framework, there needs to be the ability to have structure to have a way of looking at things, but I need to have it in a way that it hangs together is one experience. And so this sort of balance of here's your place, but you decide what the room looks like I found works really well. The other thing that you need to make sure that you're doing is really defining things like a common design language, a common interaction pattern library, so that when you look at what is a button What is a progress bar these may sound like incredibly small and trivial things. They're incredibly important when it comes to consistency and to creating one holistic experience that you need to have some way of communicating this so that everybody is working from the same page. And this is something I'm actually going to dedicate the entire next episode two is to they're called atomic design systems. It's the way that I'm designing most everything these days. And so we're going to spend all of the next episode actually talking about how do you build one of these systems, because I really think that they're just that important. So I think that you know, these are just a few simple changes you can make if you're doing agile, these are a few simple ways of solving these things. And they are the things that time and time again, whenever I have people come up and ask me questions. These are the sorts of things that they really seem to get tripped up on. So if you're doing agile and if you're struggling with it, put in that sprint zero, put in that time at the beginning of the process, where you can go through and have time just to do that normal concept where you can go through and lay out what is it that we really want to build so that we can start to get really that big idea going, then once I have that, then I can start to work through that first sprint that second sprint to start to do the design and I can be two Sprint's ahead. So when tech fires up, we have a really nice robust backlog of stuff for them to work on. That there's no substitute for communication to working together that creatives have to get over this kind of precious thing where we have to be off like in the corner wearing a braid with a watercolor, spirit animal sort of a thing like that you need to get in and work with everybody, you need to communicate that if you're working on a big team with big complex problems, you need to put structures in place, like a design review, like something that's going to give you the ability to come together to talk and solve problems. But that you also need to watch the big picture that if you're working in multiple groups, that somebody is looking at how this stuff comes together that we don't have the house of well built parts that doesn't fit together and that falls down whenever somebody tries to live. in it. And I think that, you know, the reality here is you you have to be willing to question process process can't become something that is so sanctimonious that is so revered, that it can't evolve. And I think that no matter what your process is, whether it's waterfall, whether it's agile, whether it's some hybrid of the two, you have to figure out how do you make it work for you? How does as new personalities come into the team as the team grows as you become more sophisticated at doing things that your process is evolving with that and it because it doesn't become this thing where it's like, it came down from a mountain carved into two stone tablets, that's not the way this stuff should work, that it needs to be open to conversation that yes, there needs to be agreement that no you can't change the process every day because that leads to anarchy and stupidity. But it is something where if there's a meaningful reason why we need to evolve something, you need to do it and I think this is ultimately the biggest learning I hope you take away from Because that's really what trips so many people up is that they're not willing to challenge or change or discuss what their process is. And as a result, they get kind of wedged into doing something that isn't working for them. And then they don't either have the voice or the willingness or the ability to speak up and change it. But process is a living thing. It's gotta be just because you change, your team changes, the business changes, everything is always evolving. We've talked before about how leadership is a constantly evolving concept. And this is really no different than that. So just think about taking the time to always just evaluate your process and make sure that it's still really working for you. So that's all I've got to say for that. As always, if you like the show, if you enjoy what it is, I have to say the only currency I'll ever ask you for is a review. Take a few seconds, go over to iTunes, just click on the stars if you're feeling lazy, if you feel a little bit more robust, go in, type a few words, put them in there. Because it really does help it brings more people to the show, it helps get the word out there, it keeps the show high on the charts. It keeps me motivated to making more shows. And so if you have a minute, please go do that. As always, I'm going to go through all build a lot of this information I'm going to put into the show notes. You can find the shownotes more information about the show other episodes related articles, all those goodies, head over to podcast dot Stephen Gates calm Stephen is STP HN. Like I said before, if you want to be a part of the community, head over to the Facebook page, give us a like there, the boys down and legal always want me to remind you that all of us here on my own, they don't represent any of my current or former employers. This is just me out here talking. And finally I say it every time because I mean it every time but thank you for your time. I know that time is truly the only real luxury that we have. And I'm always incredibly humbled that you won't spend any of it with me. Until next time, whenever we talk a little bit more and as always, stay crazy.