Hey, everyone, and welcome to today's episode of Developer Tea. My name is Jonathan Cottrell, and in today's episode, we're going to be finishing up the interview with Lauren Cottrell. For those of you who don't know, Lauren is my wife, and she works at Whiteboard with me. She is the director of interactive at Whiteboard. In today's episode and in the previous part of today's interview, we talk about Agile. We talk about how it applies to developers and how we are implementing Scrum at Whiteboard. I hope you enjoy this interview with Lauren Cottrell. Okay, so we've gone through these first two ceremonies, that kickoff meeting, as I'm going to call it. I'm never going to get the name right. The sprint planning meeting, as we call it. And then the continuous ceremony, I guess, is a better way of putting it. But the second ceremony is that stand-up meeting every day. Yep. What is the third ceremony? It's the exciting sprint demo or iteration demo of what you've done over the course of the whole week that is actually involving the client and or product owner, where you are demoing all the working software or the working web or the executed design in browser or in MailChimp or whatever you're working in. Okay, so this is basically showing the client what you've created. Or showing the product owner is a better way of putting it, right? Sure, it can be either or. In our situation, there is a client and a product owner. So I like to think about movie credits when I think about this. So a product owner is like the director on a movie set, right? So they're much more involved. They have really specific preferences on how things look, how things feel, how they match up to a brand. And they're going to be the most, once again, to use the metaphor, boots on the ground kind of role in the sprint process. Whereas somebody like a client is going to play more of the producer role. Now, we're using the term producer in the movie sense, not in the developer as a producer in the sprint world. But in the movie world, a producer is kind of hands-off. Usually... They are involved in some distant way. They had an idea for the film, or maybe they were involved with some people who had the idea for the film. Or typically, they're going to be hands-off. And a lot of times, they have maybe some money wrapped up into the film. And that actually describes this relationship really, really well. You have the director who is much more artistically involved, much more bought into the individual decisions. The way that a movie feels is typical. Typically, because of the director. The way that a movie is funded is typically because of the producer. Right? So think about that in those terms. And I think that kind of gives you an idea of how a product owner should be interacting with the sprint team throughout the week. They're going to be doing a lot of hands-on. They're going to be giving feedback throughout the week. Is that how it's supposed to work? Should they be having kind of impromptu meetings, for example, with developers? Yeah. If they see fit. But really, that's only a question of if the task or requirement isn't quite fulfilling the values, or if something got off track, or if they have more insight to fuel the direction of the thing that a developer is working on, that's more than acceptable. What isn't prescriptive about the way you implement Scrum or Agile is that the team should really define when and how they communicate. And the coach helps them do that. This is actually probably my favorite thing about Agile is you no longer have to feel bad about saying, hey, let's jump into this conference room and talk about this thing. Right. And you're not interrupting someone. Or typically, because you're all working on the same project, the interruption is welcome. Right? Because you know, hey, they're working on something really important. And as long as you're respecting each other. Right? And you don't need a project manager to do. All of that overhead for you. And to compare this to a non-focused week is what I would probably prefer to call it. Without this kind of singular focus for a given team, a lot of the time you're going to have somebody coming up to your desk and asking you to work on something that's totally unrelated to what you're working on. That's not what we're talking about with this. What we're talking about here is having someone come up to your desk and ask you a question that is actually relevant to what you're doing. And that's actually relevant to what they're doing. And you're all working towards this singular goal over the course of five days. Yep. It is a powerful feeling to have focus once again. This is literally like one of the very first things we talked about on Developer Tea. Focus is a superpower almost. The ability to focus is so important. And if you build your processes, if you use something like Scrum, if you if you subscribe to the philosophies of Agile, then you can accomplish focus. I know it sounds like we're almost preaching this. There's no money involved in this for us. We aren't trying to sell you a product that you can go buy about Agile. All this stuff is as open source as it gets. Yeah. And this all comes from the desire for people to be happy and effective. That's client and producer the same. That's a developer. They're feeling fulfilled. And they met the focus and the task as it was defined. And they felt the reward of that on a daily basis. And then at a weekly in the sprint demo, they're like, look at this. What we did as a team, it's already working. It's launchable. It's effective. Now, it might not be the whole site, but it's working. And you can move on to the next thing to create the full solution and maybe launch it all together. Yeah, absolutely. Absolutely. So we're going back to our film metaphor for a second, because we just mentioned. This third ceremony, which is the demo, right? And that's almost like the initial screening, if you will. There's a weekly screening. It's almost like you're screening a scene. Absolutely. You're not going to look at the entire application. You're going to look at a subsection of the application, whatever you worked on for that week. And then, so that's the third ceremony. What is the final ceremony in the scrum process? This one is internal. It is for the betterment and the growth of a team. And it's the sprint retro. Or the iteration retrospective. You are, as a team, identifying three things. What worked really well? Let's do it again next sprint. What didn't work so well? Cool. We identified that. And then let's pick one or a couple achievable things to try on this next sprint. Learning what didn't work. I love this. In our team right now. And hopefully other people experience the same thing. I assume they do. But in our team right now. This is almost an exercise for our team to start practicing how to be both positive and critical. Right? So. Yes. We look at what we've done. And sometimes it's really difficult to come up with one side or the other. Like if you feel negative about something. Yeah. You're going to have a hard time coming up with something positive. And vice versa. If you feel positive about something, it's really difficult to come up with something negative. Yeah. So. I found that this is a really good exercise. Exercise in critical thinking for our team. Because it's easy to kind of fall prey to group think. But what you have to do in this particular meeting. I'm talking a lot about this. Even though I'm interviewing Lauren. But I feel very strongly about the retro meeting. What you have to do on the retro meeting. Is ensure that everyone comes up with something. Both. On both sides of that fence. Yeah. It's easy to fall prey to the. You know. The negative. That. Happens. The bug that occurs. The unknown that pops up. That we know is inevitable in software. In web design and development. And this really coaches you just as a practice. To identify something positive as well. Because you've worked as a team. Something has gone well. And this keys you up to do something well again next week. As well as improve something. Not just identify all the negatives. But actually choose to isolate that thing. And say what we could try differently next time. So this is. This is actually a pattern. That we see in like super high performing athletes. We've used some sports language in this episode. But most specifically. Athletes that are trying to get better. A lot of the time. What they will do. If you go and listen to any of these podcasts. About like these. These incredible athletes who have won. Multiple championships. Or. Episodes of coaches talking about how they coach. And how they've won. Multiple world championship kind of things. Pretty much across the board. The way that bettering happens. Is you have a coach. And you iterate. And for each iteration. You identify things that you need to do again. And you identify things that you need to improve on. Right. So the exercise itself. Of identifying those things. Is a part of the process. And then going through it. Is the exercise. Like it's the actual. You know the building of the muscle. Or the building of that memory. Of that particular skill. And so you're not going to get it right at the beginning. You're not going to get agile right. You're going to estimate things wrong all the time. One of the things that is so important. In agile is this idea of accepting. That you're bad at estimation. Right. Yeah. And the power in this. The truth be told. That I have witnessed. Is that. Even after. What two weeks we worked on a project together. In this team weeks model Jonathan. I was a coach. And you were a developer. You guys. In less than two weeks time. Estimated. Higher than it actually was going to require. Of your time. And you completed more. Than you took on. In a given sprint. And we had that much more to demo. And that's just incredible. I mean. You're learning that quickly. Even on the day. Yeah. It is. It is really interesting. To see how. How you start to expect. To not get as much done. Just because of either. Some previous bias that you had. Like I. I have a tendency to believe. That. To basically underestimate. Every single time now. Because of so many times of being burnt. As a developer. Of overestimating what I could complete. In a given amount of time. And so I'm very wary. And I'm very careful. Realistically speaking. I'm very careful. About what I promise. That I can get done. And yeah. This has shown to be. To be a really effective way. Of increasing. The word. The agile. Like buzzword. Is going to be. The velocity of what we do. Yeah. You guys are more productive. And the momentum is greater. And that's the win. But I want to talk about. This estimation thing real quick. Because. Yeah. Estimation. Obviously we talked about it on the show before. The sandwich problem. You can estimate pretty easily. You can estimate. How long it's going to take you to make one sandwich. But if you tried to gut estimate. How long it takes to make a hundred sandwiches. You're probably going to be wrong. Right. If you were to multiply. One sandwich times a hundred. You're going to see. A much much higher number. Than you probably. But this is most likely. You're going to see a higher number. Than you would have gut estimated. A hundred sandwiches at. Right. Yeah. A very simple proof. Let's say it's six minutes. Just because that's an easy round number. If you. If it takes you six minutes. To make one sandwich. Well it's going to take you six hundred minutes. To make a hundred sandwiches. And you would have never. Probably guessed. That it would take you ten hours. To make a hundred sandwiches. That's without any breaks. Right. Yeah. And estimating in. You know this agile. Philosophy. Is. Really I think a breakthrough idea. That you can say. Does a PB&J. Take me less time. Or more time. Than making a. Baked panini. With Swiss cheese and ham. Well hopefully. It would take you. Significantly less time. To make a PB&J. Exactly. And that's the answer. You can. Without having to put a number to it. Without having to put hours to it. Or. You know. A budget to it. You can say this will take more. Or less. Than this other task. We're kind of going outside of agile here. Because. The discussion starts to center around. This idea of degrees of confidence. Right. So. And I talk to my developers. About this all the time. I don't know if I've talked about it. On the show or not. Actually. But degrees of confidence. About something. That you're stating. So for example. I've talked to. Customer service representatives. And. I would ask them. You know. For example. If something had not been shipped. To my house. On time. I would ask them. When is this item going. When is this item supposed to arrive. And. Way too many times. The customer service representative. Will say something along the lines of. We have no idea. Right. And this to me. Is. Is one of the most infuriating lines. That I can hear from a customer service representative. Because. They do have. Some idea. Yeah. Right. In other words. They do. If I were to ask them. So. Is it possible. That this is going to be delivered. In five years from now. Yeah. Right. Well. Obviously not. Right. So. They have a very high degree of confidence. That is not going to be delivered. In five years from now. They have almost a 100 percent degree. Of confidence. That is not going to be delivered. In five years from now. Yeah. On the flip side of that. If I were to ask them. Is this going to be delivered. Between nine. And nine thirty. On Tuesday. Right. They would have. Almost zero confidence. In answering that question. Yeah. They would. And. That's kind of. The way to think about. The agile way of estimating. Don't. You know. Make it a comparison. And then narrow it down by. Well. That. Definitely wouldn't take me longer than two days. But. I'm not sure if it would be a half day. Or a full. Well then put it somewhere in that. In that realm. Then to be safe. Slightly. Overestimate what you think it's going to take. You know. Say it's going to take you the whole day. If it could take a half day. And you're not quite sure where that's going to land. Well. The best case scenario. You over deliver to the client. So. All of this estimation. Is really for. A bigger picture. Goal. That. Gets our team to. Understanding. And measuring. Our own velocity. Without having to. Have an expert. Who runs. Numbers all the time. The coach actually looks at our estimations. And. What we were actually. Able to do. What we were able to accomplish. In a given sprint. And then over a few sprints. We actually figure out. Our real velocity. So putting these estimations. They're sometimes referenced as a complexity point. You know. From one to five. How complex is this task. That is what we add up. And then begin to average out. So that when we. Say something's a one. We start understanding more and more. What a one is. And how long a one is going to take. And then we understand that our whole team. Can accomplish say. Twenty points. In a given sprint. It's really powerful. And it doesn't take rocket science. And. I've just been so energized. And excited to play the role of this coach. I mean for. For moments like these. And here's the reality. There's a lot of people who are listening to this episode. And you've heard all of the stuff. About agile. And you've probably heard of burn. You've probably seen the burndown charts. You know. This hip hop. Like mainstream media. When it was on Silicon Valley. On HBO. They had the burndown chart. And. And. They actually show it. Working. Which is really cool to me. That. That this show would actually like. Somehow. Throw a bone. Back to the. To the agile world. But. It's very interesting to me. To see this stuff. In a practical light. Right. We've read all the books. And really simple. It's not that. Hard. I haven't studied really long and hard. I haven't. Practiced this for 20 years. I didn't go and get my scrum. Master certification. And. Here we are. And it's effective. Yeah. And to be fair. Lauren's dad. Does have like. Every certification. Under the sun. But at the same time. And how many programming languages. Yeah. He knows so many things. That we. We respect Lauren's dad. Quite a bit. A lot. Hopefully he's. He's going to hear this. Episode at some point. But. But yeah. I think that. I think you're right. I think the. The best way. To make agile work. And I want you to talk about that. I'm going to ask you. Kind of a really. Specific question. But I think. Just to. To tee this up. I think that. The best way. To make agile work. Is to start. With the simplest. Most. Direct. Valuable. Thing. That you can implement. From agile. And. I want you to talk about. Like. If I were to do. A single thing. To test. Agile methodology. What would that thing. Be like. For myself. I don't want to take it. To my team yet. I don't want to. Force everybody. To adopt it. In order to test. To see if it's going to work. Yeah. I don't want to. You know. I don't want to go. And read about. Complexity points yet. I don't want to. Have all these ceremonies yet. I just want to see. If maybe this is going to be. For me. What are the. Like. One or two things. That I can do. This week. To test out. Some of the philosophy. In my own life. I would say. Take the to-do list. That you already have. And organize it. In some way. Whether it's post-it notes. Or Trello. Or Google. A Kanban board. That's K-A-N-B-A-N. And put it in. Just a simple. Arrangement. And. Put all the things. You haven't done. In the do column. Have a doing. Column. And a done column. And limit. Your work in progress. To one thing. At a time. And. Be it in a couple days. Or a week. See what you accomplish. So this is kind of like. The user stories. Organizing the user stories. And putting those through. The process of doing. One thing at a time. And then going. Into the done column. So that we can see. Exactly what we've done. In the. In the past week. Or so. I've. I'm wondering. If this would be. Something that I could try. Like maybe at home. With my. Like the stuff. That I have to do at home. I think that's a perfect idea. And. And that way. You're validating. Like. For example. Lauren and I. This is. This is a. A married moment. Here for a second. We often talk about. What can we get done. At night. And I have this tendency. To think that I'm going to get. A hundred things done. At night. And she has a tendency. To think that I'm going to get. Like one thing done. At night. And neither of us. Are totally right. Right. Like. And. And. And part of this is because. You know. The variability. In. In doing a developer tea. Episode. For example. And. And so. It's really. It's really like a. A perfect. Place. Where we could actually. Try this. In our personal life. To validate the concept. Of. Of measuring. And figuring out. You know. Because. The reality of. Of human behavior. Is that we. Often act. The same. Like. We don't change. A lot. Yeah. And so. We're probably going to do. I probably take. About the same. Amount of time. To do a developer tea. Episode. Even if it feels like. Some of them. Are significantly longer. Or significantly shorter. Than others. Most of the time. They're probably going to fall. In like a standard distribution. From an average. An average. Amount of time. That I have to put into it. And so. If I'm actually measuring. That time. Then I can. Make a pretty good. Again. A pretty good estimation. With a pretty high degree. Of confidence. That it's going to take. About this amount of time. To do this thing. Yeah. So start with. Your off hours. Don't make it about work. Make it about your personal life. When you're at home. In your weekends. Your pet projects. Whatever you want to do. Yeah. I've seen this implemented. In like a hundred different places. Outside of work. Like for example. I've seen it done. For like wedding planning. Is a really big one. There's books on. Agile wedding planning. There's also. For example. Using this. To get your kids. To do their chores. Properly. Or. In the most important order. Right? Yeah. And even in the classroom. Structure. Like elementary schools. Are using this. Do doing done. Concept with. Post-it notes. Or. You know. Three by five. Note cards. And it's really incredible. What's happening. Today's episode. Is sponsored by. Flatiron school. Now we talk about learning. On this. On this program. All the time. And. Flatiron school. Is about learning. But they're more than just. About learning. Flatiron is. A. Premier coding boot camp. For launching developers. Into proven. Jobs. Okay. Not. Not only. Are you going to learn. A ton. From Flatiron. Obviously. You're going to get prepared. For your career. But. Flatiron also has a job. Guarantee. If you do your part. You'll receive a job offer. Within 180 days. Or your money back. So you have. Very little reason. To worry. About going into this program. Because you're very likely. To get a job. In fact. 98% of Flatiron. School. Grads. Find jobs. They love. Within six months. Including internships. Apprenticeships. And full-time roles. With starting salaries. Over. $74,000. And that's. Pretty competitive. Pretty much anywhere. That you go. Flatiron has placed. People. In companies. Like. Google. IBM. Facebook. So. If you want to. Join the ranks. Of Flatiron school. Alumni. Who are now. Working at companies. Like that. Then go and check out. Flatiron boot camp. Prep. Dot com. Or you can go to. Spec. Dot. FM. Slash. Flatiron. To learn more. About what. Flatiron is doing. Flatiron's. Boot camp. This boot camp. Prep. Is totally free for you. Okay. There's free. Online resources. To get you ready. For Flatiron. They're providing that to you. Not only is it free to you. But if you then. Go on. To go to Flatiron. You. You're going to receive. $500. Off. Your first month. Of tuition. So head over to. Spec. Dot. FM. Slash. Flatiron. To learn more. About what. Flatiron. School. Has. To offer. To you. As a. Brand new developer. Or even if you have a little bit of experience. As a developer. And you're just wanting to step up your game. Or. Get into this. Guaranteed. Job placement. Program. Flatiron. Is. The type of boot camp. That you want to be looking at. Thank you again to Flatiron. For sponsoring today's episode. Of developer tea. You know. That's actually a really. Really cool idea. Because. We were talking about this concept. Of. Of. Meta education. The other night. And we. We discussed. The fact that. And I think I've talked about. I talked about this with. Khaled Azad. On the show. In the interviews that I did with him. But we discussed the fact. That we. We don't really learn. How to memorize things. But so many of our classes. In school. Require us. To have memorized. A large amount of information. For. My example. Was Spanish. But. Another example. In high school. Was. Was. History. All these random dates. Or random people. That I didn't really put together. Into a story. I didn't really understand. How it all fit together. And so. If I had had this meta education. On how to memorize things. Then maybe I could have memorized things. Better throughout my years. In school. And I think that management. Of. A list of things to do. Management of my tasks. Management. Of. My. My workload. If we can teach children. How to manage their. Their tasks. Better. You know. Especially. This limiting work. And progressing. I think this is. Really. If you walk away. With nothing else. From today's episode. This has really been more like. A collaborative. Episode. Than it has been. An interview. I think. I like it. If you walk away. With nothing else. Limiting your work. And progress. It does so many things. For you. Both. At an actual. Practical level. But also. At like a mental health level. Right. Like. If. If you feel. A sense of. Anxiety. Because. You have a hundred things. And you're doing a hundred things. And nothing ever seems. To get done. Oh yeah. If. If you've ever felt that. Then. This is. Definitely for you. I actually. Have experienced this. With Lauren. At home before. And we have to remind each other. Hey. Take a second. Decide what you think. Is the most important thing. To do right now. And then go do that thing. Yeah. Absolutely. Or. Document it. Write it down. Prioritize it. And then go do it. I mean. It gets the. You know. Oh. We need to do this. Oh. We need to do that. Oh. We need to do that. Out of. Out of the way. And. You're actually feeling accomplished. And. Things that are actually needing to get done. Ultimately make it to the top of the list. You said something there. That actually reminded me of an experience we had last week. You said document it. You know. Both of us had this. Distinct feeling last week. Both of us. Had this. On separate days too. I had this feeling that I had not finished everything I was supposed to do. Like. I felt like. I was still in go mode. Like. I hadn't finished my day out. Yeah. And I didn't know what the thing was that I was supposed to do. Like. I had no clue. Why I felt that way. I just kind of had that. That. Sense of urgency to go. And get something done. But I had no idea what I was trying to get done. Yeah. And you had the same feeling. Didn't you? Yeah. I did. And. Never really quite put my finger on it. Because we didn't document. What it could have been. Or. What it should have been. So. There's. There's actually. So. That's actually. A really good point. Taylor. The CEO. At Whiteboard. Has mentioned this. As well. He said. One of his favorite parts. Of. Of Scrum. Is. That you have this. Like. This end point. At the end of the week. You feel accomplished. Right. So. On the emotional side. Just. If we're just talking about the emotional side. You have this. Moment. Of like. Of celebration. Of. Retrospective. Of. Looking back. At what you've done. You actually did. What you said. You were going to. Do. And sometimes more. And you're. And you're validating. That it's done. Yeah. And you're showing it. To someone else. To validate. That it's done. And the whole team. Has a shared definition. Of done. Right. And. And you can look at the documentation. Say yes. We did these things. And there's. There's a sense. There's this. There's another idea. I can't remember who it came from. It's another famous podcaster. Out there. In podcast land. But they talk about. The. The concept of a shutdown. Right. So every day. At a certain point. And their work day. They. They start their shutdown sequence. And. That. Let's their brain know. It's like a. It's just a habitual thing. Right. They have the same rhythm. They have a sprint. They have. The start and end. To each day. And to each. Week. Right. And so you have a shutdown. That lets your brain know. Hey. Now you can chill out. And you can go into this other mode. Whatever that mode is. So if you're headed home. To spend time with your family. Now you can. Actually fully be present. With your family. And there's some of this. Some of this. Some of this stuff. You guys know. Headspace. Is a sponsor of the show. Some of this comes back to. You know. Being mindful. And being in the moment. You know. If you're doing one thing. And your mind is on another thing. Not only. Are you not going to do the. The thing you're doing well. But you're also not really serving. The thing that your mind is on. Very well. Either. Right. And this. This puts beautiful boundaries on things. Like. You can walk away. At five. Five thirty. Even if something isn't resolved. Because. You know what. Literally. What is on your plate. For the rest of the week. And unknowns. Are sort of accounted for. And your. Your estimations aren't. Perfectly exact. So. You can still close your computer. At five thirty. And not work till nine o'clock. And miss dinner. Yeah. There's like a sense of closure. In the day. And. A sense of like. We all. Have come to the table. And agreed. That the work has been. You know. This week. Has completed. Yeah. Without ignoring. The unknowns. And change. Are inevitable. Which. I think. For being someone who. If you've. You know. Done the strengths finders test. Adaptability is like my number one. And even though I'm type A. And organized. I mean. That's like. Empowering. And. Truly. You can organize. For yourself. In this framework. Yeah. Absolutely. Okay. So let's. Let's do like a. Very fast. Recap. Of what a scrum week. Looks like. And then we're going to wrap up the show. With the two. Questions that I ask. Every. Every guest that comes on the show. But. Let's. Let's do a very fast. Recap. What is a scrum week. Look like. It's a dedicated team. Of varying disciplines. One or more of each. And. Together you. Establish. A rhythm. That you are going to repeat. Call it a sprint. Or an iteration. You have a. Sprint planning meeting. Where you've. Taken big ideas. And features. And broke them down. At tasks. And you estimate them. You queue them up. And order them in priority. And then. You get working. And then on the daily. You have a stand up. And say what you did. The day before. What you're going to do. Today. If there's any impediments. Get to. The end of the week. Or the sprint. And. You actually demo. The work you've done. As a team. And then you have. A little retrospect. And learn from. What worked really well. And what didn't. Very simple. And. If you want to try this. In your daily life. Then you're just going to set up. Some kind of. Way of tracking. The things that you need to do. The things that you are currently doing. Or better yet. The thing. That you are currently doing. That's right. And then finally. The things that you've already done. And. A very. Simple way. To limit your work in progress. By the way. Is put a number. Above that column. The number of things. That are allowed to be. In that column. Yes. It's a very effective way. So that you know. You're visually. Reminding yourself. Of the rules. You'd be surprised. At how strong. That visual reminder. Can be. If. If you see that reminder. As you are managing. That board. And. Lauren mentioned earlier. I think it was. In between takes. Lauren mentioned. That you can even use. Like post-it notes. For this. Right. That's where it all started. And the agile methodology. You mean. Absolutely. Post-it notes. On a big wall. Yeah. If you go Google it. I think. Now that you mentioned that. Lauren. If you go Google this. I think you'll see. A bunch of people. In a room. With a bunch of. Post-it notes. All over the wall. Yep. This is even a great way. To. Have. Even. Meetings outside of work. Like say coffee talks. Where you want to just. Talk about. Topics. Or learn something together. You can even apply it there. So. Look up. I. Would say. Do a little bit of homework. And look up something called. Lean. Coffee. Yeah. Lean is another part of that. Like the agile philosophy. That we aren't going to get in. Like deep into. Nope. Now. There's. There are. It's also very. Like hot word. The lean startup. Is a. Is a book that. Has. Rave reviews. I actually haven't read it yet. But. I know. Lauren. Your dad has read it. And he is a huge fan of it. Yes. And have you read it. As well. I have not. Okay. But that's all my. Objectives for this quarter. There. You go. So. We've. We've covered scrum. I think. Hopefully people. Who. Have heard it. Spoken. In their. In their firms. Or in their agencies. Or startups. Or wherever they're working. Hopefully. It's a little less intimidating. A little less. Like process. And HR. You know. Process. Speak. And all that. Hopefully. You're. You're seeing now. How. A developer. Can actually. Be a champion. Of. Something like. Scrum. And. The agile philosophy. But. I want to ask you two questions. That ask all of the guests. That come on developer tea. The first question. That I like to ask. Everyone who comes on the show. Is if you had 30 seconds. To give developers. Advice. Just 30 seconds. What would you tell them? That's a great question. I know. Today. It sounded like. You know. I'm talking mostly about. A process. And. Strategy. And tools. And. A way to manage. Projects. And people. But. I would say. Remember this. Out of everything else. Is. Focus on individuals. And your interactions. With them. Over processes. And tools. Because. This is. I think this is what was. Eye opening for me. In learning what I have. And just seeing the. Effectiveness. Of it. So individuals. And interactions. Over processes. And tools. Any day. And isn't this. That sounds. Familiar to me. And I'm pretty sure. It's because it's in the agile. Manifesto. Isn't it? It is. That's the. Kind of the pioneering value. And I think. In my own journey. To try to. Teach it. And. Incorporate it. And infuse it. In. An industry where. It's sort of taboo. That's the thing. That has won. Strip away the jargon. Focus on the people. And the way that you're. Interacting with them. In order to. Try it. Or teach it. So that could mean. That. Like. If the. If the language. Of agile. Or the language. Of scrum. If somebody has. Like a bad experience. With. A poorly implemented. Agile. You could. Abandon. Abandon. All of this language. All together. And still. Get. The value. Out of. The underlying. Processes. Right. Yep. And. Really. Through this. You and the people. That you're interacting with. Are discovering. The best way to work together. It's not. You know. Prescriptive. You don't need to go read. And research. And implement it. Focus on. The people that you're working with. And how they want to work with you. In this way. And you guys define. What that looks like. So what that means. Is just because. It's working for us. In the way that we have. Implemented. And experimented. And tried it again. Doesn't mean. That it's going to work for you. Exactly the same way. Or maybe. In most ways. That I've described today. So. It's adaptable. It's shapeable. And. You know. If you need to have a sprint. In a half a week. Or you need to chop up your sprints. In two days. Every week. And only do a stand up. One of those days. We've done. Each and every one. Of those. Of these. That I've. Just mentioned. And we're going to find new ways. To work. In the future. Be it. The client has less resources. Than. The other client. Or. The team needs to be bigger. Or smaller. Based on the project. It really is adaptable. Yeah. I think the. The thing that I've heard you say. Over and over. Is that. The most important part of this. Is the iteration of it. And learning. From the. From the previous iteration. Like what. What are we doing. And what could we do better. And. You know. For example. What. What if. What if we threw. Two product owners. Into the mix. Rather than just one. Right. You know. What if. What if we. We didn't have a daily stand up. How does that change things. Or what if we. What if we did daily stand up. Over. I don't know. If we did it over Slack. Or something like that. Yep. We've done it before. Love it. Do it. And there's no reason why you can't. Can't experiment. That's very cool. And hopefully again. Going back to this. This thing of like. Trying to get developers. To champion this cause. The. The whole point. Here. Is. To create. A. A way. Of evaluating. What you're doing. Now. We. We see other people. What they've done. And what has worked for them. And the whole point. Of. Of Agile and Scrum. Is to give you. An evaluation. Method. Right. Like. That's. That's the whole point. Value delivery. Is really. The whole thing. You know. Like. Do something valuable. With your time. And. Be able to account for it. Yeah. And then go back. And learn from a measure. Absolutely. Value driven work. And we've come. Back to. To Agile again. In. In your. In your. 30 seconds of. Of. Advice. Here we are back at Agile again. What's that other question? The next question is. What is one thing. That you wish. People. Asked you about. More often. Can I go. Two ways. With this answer. Yeah. Absolutely. Let's go serious first. I wish more people. Would ask me. About what it's like. To work. With your husband. And. How that actually. Impacts. Your relationship. And friendship. People have the tendency. To reduce. Their idea. Of us working together. To. That of our marriage. Or the way we interact. And I would say. At work. It is. It is different. But it has. Built. And strengthened. Our marriage. Conversely. I think we. Chose. The. Harder route. By choosing to work together. As peers. You know. Neither of us. Are bosses. Of one another. And. Learning. The proper. Forms. For. Having emotions. And feelings. And being the wife. Of someone. Who's either proud. Or stressed out. By their spouse. At work. And. Channeling it. And doing the right things. With it. So that we. Had a really killer. Or have a really killer. Relationship at work. And similarly. So that our. Marriage. Is. That much. Cooler. In the end. Do you have a. A story. Of like an assumption. That somebody has made. About us. That you can share. A specific. Assumption. That's been made. About us. You know. Maybe I got hired. Because of you. But that interview. Process was really. Taylor. And Eric. Did such an incredible. Job of. Bringing me in. By my own merit. And interviewing me. Pretty. You know. They were. They were tough on me. And it was a. You know. Two hour conversation. Three hour conversation. It was awesome. And. Made the delineation. And. Very. Clear. Directive. That if I didn't think. I could do it. We shouldn't work together. And I thought that was really powerful. So. We've been charged. By great leadership. But we also had to make a decision. Personally. To. Be better friends. To be better peers. To be better co-workers. And I think that's spilled over. Into our marriage. I think it's made our marriage. Really cool. Yeah. I would say that. If she got hired. Just because of me. That that would be a. Really horrible business decision. Right. Like. And Whiteboard. Has succeeded. After. That decision. And Lauren has leadership. That's way outside of. My. Like. She has her own. Entire. Set. Of leadership. That I have no. Bearing on. Like. That's totally. That would be completely. Easy. To. Remove. Like. Remove all doubt. It was. It was as if. I had brought. Like. Just. A person from Atlanta. Yeah. Right. To. To. To. To. To. To. To. To. To. Whiteboard. Totally. But. You know. We're still humans. And sure. We fought over slack. But. We've learned not to do that. Oh. Yeah. We've. We've definitely fought over slack. Like. Once or twice. But. It was something that we. That we eventually learned. How to. Avoid doing. I do think it's important. That. That we're. At least. Honest. With the idea. That relationships. Are still important. Like. There's. There's no way. That going into that interview. That it was totally removed. Like. Just because. It was. They were aware. That. At the time. You were only my girlfriend. Or we were engaged. Rather. Yeah. Yeah. But. But. Just because. They were. Aware of it. I think. That. That. That can't be removed. From their decision making. But at the same time. Relationships are always important. In hiring. Right. Like. Having a good relationship. With the company. That you work with. Or with someone. On a personal level. That really is. What it comes down to. Yeah. It's culture building. Many times. Yeah. Absolutely. Culture building. For sure. But. I think. It becomes. Really important. To. Draw the line. Between. You know. Showing favoritism. Because of the relationship. And actually. Just knowing. Someone is going to be good. For a job. Because of the relationship. Right. Yeah. I knew you. Very well. Because. Obviously. We're engaged. I knew you. Very well. I knew your personality. And I could see a fit. For you. In the company. And. And so. That relationship. Began. From the perspective. Of. Of seeing a fit. Oh yeah. We shared values. I mean. We were in a relationship. With. Value. Alignment. And that spills over. Into. The culture. Of a company. And the values. That they promote. You know. So. We. We aligned. There as well. Yeah. And I think. I think a lot of people. Unfortunately. They don't see. Perfectly. Eye to eye. In a relationship. In a romantic relationship. And also. In a work relationship. And. And so. We're very blessed. We're lucky. To be able to do that together. Every day. Yep. Okay. So. Talk about your. The. The other. The second answer. That you. Have to this question. I love. The fact that I had these. Really vivid. Obscure. Childhood nightmares. And they were repeating. Enough for me. To remember. About five of them. You know. Vaguely. I can say. That they repeated. But. Enough. That I can. Still envision them today. One of them. Involved. Jeffrey. The giraffe. Shooting me. With a shot. So I could never. Go to the bathroom. Again. And it's the most. Horrifying thing. I love. Retelling these stories. From my. Childhood. Of my crazy. Vivid nightmares. My guess is. That you will probably. Pass that on. To Liam. Our son. I hope not. One of them. Involves. Fud ruckers. Another one. Involves. Floating down. The stairs. Lots of weird ones. That's great. Yeah. So if you ever see. Lauren. At a conference. Or something like that. Then walk up to her. And. Say thank you so much. For teaching me about scrum. Also tell me about. Jeffrey the giraffe. It's perfect. Lauren. Thank you so much. For coming on the show. And. And for being a part. Of developer T. All of you. Who are listening. By the way. Let me just say. Lauren has been. Behind the scenes. By the way. She. Just trivia. For everyone. Lauren designed. The developer T. Logo. I did. I had the honors. And somehow it. Made it. Yeah. Yeah. It's. It's. The same one. From two whole years ago. We've cut the same one. But yeah. Lauren. Lauren has been. Such an integral part. Of. Of what the show is. Just because she's supported me. And throughout all of it. You know. This show isn't done. Like. As a full-time. Day job. Hopefully. Hopefully you all know this. Obviously. We've been talking about whiteboard. This whole time. But. This show is done. At night. Right. Or on the weekends. And Lauren has supported it. Throughout. Throughout this whole. This whole process. So. You all. We heard. A huge thank you. For. For it being. For. For being so gracious to me. As I. Go through the process. Of making this show happen. Each and every week. So. Thank you. So much to you. Lauren. For. For being so gracious. Thank you. And thanks guys for listening. Thank you so much for listening. To today's episode. Of developer team. I interview. With Lauren Cottrell. My wife. I was so excited. To do this interview. I hope you enjoyed. Listening to. To us. Discuss this. The type of stuff. That we're doing every day. A whiteboard. Discussing scrum. And agile. And hopefully. Hopefully. Demystifying. Some of these terms. For those of you. Who are. Either new to the industry. Or. Maybe disillusioned. By some of the project management. Stuff that you've heard. Over the years. Thank you again. To Lauren. If you want to. Follow Lauren's progress. And. See what she's up to. Go and follow her on Twitter. At Lauren McKay. That's L-A-U-R-E-N. M-C-C-A-Y. Thank you again. To today's sponsor. Flatiron. Flatiron School. Is the premier. Coding boot camp. For launching developers. They give you. A guarantee. A guaranteed. Job. Or your money back. 98% of. The. The. Developers who go through. Flatiron's program. End up getting a job. In. Within six months. So. Go and check it out. Spec. FM. Slash. Flatiron. That'll take you to their boot camp prep. Which is totally free. And if you go through that. End up. And end up. Going to Flatiron. You'll get $500 off. In. In your tuition. Thank you so much. For listening to today's episode. Of Developer Tea. And until next time. Enjoy your tea. Bye.