Developer Tea

Interview with Lauren Cutrell (part 1)

Episode Summary

In today's episode, I interview Lauren Cutrell. Lauren is the Director of Interactive at Whiteboard, and she also happens to be my wife! We talk about agile, scrum, and how to make those things simple for developers and clients. Today's episode is brought to you by Linode. Linode Provides superfast SSD based Linux servers in the cloud starting at $10 a month. Linode is offering Developer Tea listeners $20 worth of credit if you use the code DEVELOPERTEA2017 at checkout. Head over to spec.fm/linode to learn more about what Linode has to offer to Developer Tea listeners .

Episode Notes

In today's episode, I interview Lauren Cutrell. Lauren is the Director of Interactive at Whiteboard, and she also happens to be my wife! We talk about agile, scrum, and how to make those things simple for developers and clients.

Today's episode is brought to you by Linode. Linode Provides superfast SSD based Linux servers in the cloud starting at $10 a month. Linode is offering Developer Tea listeners $20 worth of credit if you use the code DEVELOPERTEA2017 at checkout. Head over to spec.fm/linode to learn more about what Linode has to offer to Developer Tea listeners .

Episode Transcription

Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode I'm interviewing Lauren Cutrell. Lauren is the director of Interactive at Whiteboard. That is where we both work together and obviously we share a last name. We'll get into why and whenever I start this interview with her. We're actually doing this in my house right now and I'm really excited to do a live interview. I don't get a chance to do that every single time because we do so many episodes and the live interview is not always feasible unless the person is in the area. Of course Lauren happens to work at Whiteboard. We're going to be talking about things like Agile and this concept of team weeks and we're going to discuss a lot of things around this idea that you're probably called it project management before and talking with Lauren before the episode. We were talking about project management how that's not really a term that we want to use going forward at Whiteboard. We're going to get into all of that in today's episode. It will probably go into a second episode like normal with all of our interviews. We end up usually opening up discussion more than we do on the monologue style episodes. I'm really excited to talk about this stuff. I think developers don't get a chance to talk about project management with the project managers very often. A lot of times we hide in our caves. We don't really come out because the client is often treated like the enemy for most developers and it's not the way it should be. That's what we're going to talk about in today's episode with Lauren. Lauren, welcome to the show. Thanks for having me. Really excited to have you on the show. I've waited quite a while to do this. We do share the same last name and the reason for that is because Lauren and I actually got married in 2013 in June of 2013. Lauren, what did you start at Whiteboard? January of that same year. Back when we were engaged. Lauren technically started at Whiteboard full time before I did, although I was working contract for Whiteboard for many years before that. The reason I'm excited to have you on the show, Lauren, is not just because you're my wife and it's a lot of fun to have your own wife on your podcast. Also because you have a lot of insight into how projects should be managed. You've learned from mistakes. You have this background and I have a little bit more knowledge than the person who's listening to the show right now. You have this great background in watching projects be mismanaged and then discovering new ways of managing them correctly and the history that your dad has in project management and more specifically in the Agile world. We're going to talk about all of that. First, I want you to share where you came from, your educational background as well as where you came from to get to where you are today. Sure. In high school and college, I did just enough to become a freelance graphic designer and front-end web developer. I never learned anything more than HTML and CSS. I primarily worked in Photoshop and Illustrator and Dream Weaver back in the day as painful as it is to admit. The whole Adobe Suite. It's wonderful. I took that with me and in entering into college, decided to pick something a little bit more applicable and adaptable as far as not really knowing exactly what I wanted to do getting out of college. I picked communications in the media and actually getting straight out of college. I found a job off Craigslist because I was tired of being a freelance designer working in my pajamas in my living room. I'm too much of an extrovert to not be around people at some point in the day. From there, I got that job on Craigslist and it was actually a sign company. I was able to use most of my graphic design skills, apply that to a little bit more of the architectural world and build signage via my designs, also did customer service. That's actually where I stumbled into project management as it was called there. They had a few national accounts like pet boys and trimming tarley and I just saw a lot of disorganization and wanted a higher touch than they were providing and said, hey, can I help out with this? What kind of disorganization were you seeing that you decided to step in? What were some of the common problems that you saw? It was a family owned company so there wasn't a lot of clearly defined assignments as to who was going to follow up with the client, who was actually going to manage permitting, the status of various pieces of paperwork or from designs to approval. There was just kind of a lack of visibility in the process and probably a lack of documentation really at the end of the day. Did it affect timeline, is that the most common issue or was it a knowledge sharing thing? What was the biggest deal? Yeah, I would say it's probably a little bit of each of those. These were everything from design to approval to permitting to then actually fabricating it in house and then scheduling installation or even contracting out installation in various cities for these places where we weren't, where the signs were going up at a big mall or something like that. A lot of those, there were break points at each of those at different times and there wasn't really just one person really owning the higher profile account. I kind of just stepped in and helped out without really being asked to. It's really interesting because you're identifying all these systematic issues that are in this physical space and so many of these issues that you're finding in a sign company, you can see in a development company, sharing of documentation, the timeline stuff, obviously the deliverables themselves. Ever since you worked there, I've had this fascination with how similar some of those problem spaces are and I really think that this isn't just like, it's not just a phenomenon that these two things are similar. I think pretty much every industry has something like this. Obviously with something like a sign design or I'm sorry, not a sign design but like a fabrication of a known sign, style or a known, you have plans and you've built the sign before so you're replicating the same sign. That may be significantly different from writing brand new software but you're still going to have some of those same problems. The multiple links in the chain and something early on falling behind and like having a cascading effect on later issues, it's so interesting to see that parallel in the software world. It's production in both scenarios. Visibility of status communication, documentation, all of these checkpoints along the way, I mean there's so much correlation there. So you started working on these projects and how did you manage, what did you step in, what were the first things that you decided to change at the sign company? Documentation was a big one and assignment. I made sure that whoever needed to participate at various junctures, it was clearly communicated and documented and we actually had a system for it versus the owner or is the brother going to take care of it, who knows. That was what we were dealing with. Yeah, so I happened to, once again, I know where the story is going here, unlike the listener. I know that eventually all of this experience feeds into what you do at Whiteboard each and every day but when you first got to Whiteboard, we didn't have all of this stuff figured out. Nope. So can you talk about the state of things when you arrived at Whiteboard in relation to the state of things when you decided to take over project management at the sign company? Yeah, it's amazing the parallels, even just thinking about it today. Whiteboard felt much like a family-owned all-in-one pop-up shop kind of thing that was so similar to the sign company that worked at. It was about five or six of you guys. I was the first female and you guys were trying to share the role assignment of client communication in an email and task management. There wasn't really a tool or clear checkpoints or handoffs or baton passing and I came in and said, hey, I'm willing to do all of these things and explore where we're doing things and where we could do where we could do it better effectively. It was really interesting how that happened because in the early stages of a company and this is not just for our company, especially for agencies but in the early stages of a company, you have this effect of quite literally being in the same room together. If there's something that needs to get done, you can almost tap somebody on the shoulder or if they have their headphones in, throw a ping-pong ball at their head to try to get their attention and get them to do whatever that thing is that you need done. It's very, the communication is so open and there's so many people, or they're so obvious, literally audio happening around you and you see over people's shoulders, that visibility creates the sense of ownership of all of the problems that the company is experiencing. Definitely. As a result of that, we don't have developers in that room who aren't in the know. You almost have to literally put your hands over your ears and close your eyes to not know if there's something that is going wrong or to not know the status of a project or whatever, but we were growing at that point to the stage where we started having people in two rooms and we started having people working remote and we, all these different scale issues that happen as the company is bigger. It's not just a text thread worth of people, a group chat. That doesn't cover it anymore. We were experiencing those growing pains right at the time that you stepped in and took over this communications role. You were a developer, but you would design sometimes. That was some of the state of the situation at the time. The CEO was also the primary, one of the primary developers. He held onto that role for a very long time. Hopefully he listens to this episode by the way. We've tried to fire him a few times from that role and let him really be a CEO, but he loves it too much. It's a sign of a good thing, I think, just as this is a total side note. I'm really excited about that particular fact in our company that we have people who are at higher levels of leadership if you want to call it a higher level. They're still so connected to the nuts and bolts of the work that we're doing. Even if all the management books in the world tell us that you should delegate or you should hand this off to someone else. We still have that level of, on the ground, to use a terrible metaphor I guess, but we have this gritty sense of connection to the work and sense of involvement in the work. Maybe that's not super unique necessarily. I think that anybody who starts a company from their living room like Waipoor was started, that there is some level of love for that bottom. It's like the Mark Zuckerberg still codes. He's last year. He created his smart house and he's still coding in PHP and still has a love for engineering. I think that that's a mark of a good business person maybe or a good leader is that they have some love, some deep love for that initial thing that kicked off their business, which in our case was the power of technology being used to create design that makes companies better. Yeah, definitely. You came in and you see this somewhat disorganized, shared load for client communication. What's interesting to me is that we almost, we were still almost able to manage it, which is kind of a miracle looking back at it. What were some of the first things that you started doing when you got to Whiteboard? I fell in love with how we can work better together. Call it process. That was an evil word at the time, especially for startups and creatives, processes, just taboo, but call it strategy or working together the way that we work together. There were ways to improve always on the daily, on the weekly, and that became really my passion. It's working with clients in the same capacity, so it's not just communication. How can we work better with a client? How can we connect the client to our team? How can the team have more autonomy and also connection to the client and not be walled away as if they're in a dark room and they don't have the power and the ability to communicate with the client, rather let's connect them as the expert, the solution builder, with the client themselves and let them work together. That's a lot of what we've been doing and continuing to try and try again and try in a different way, four years of doing this really. I want to make a point to show how effective Lawrence leadership has been in this scaling, because really when she came in, she lifted the load and allowed whiteboard to scale. Whiteboard has grown from those initials. I think it was four people, maybe five people working when Lauren first joined the team, to 25 people. Now we have people on Lauren's team specifically. We have more than one project leader. We've actually got four of us now. I'm still an active role myself. I'm not just, hey director, helping with strategy and process, but I'm on the grounds with you guys specifically in web applications. That's the types of teams that I help coach. I want to roll back a little bit and talk about some of the inspiration that you've had in your life that has helped get you to where you are today. We've talked about the sign company, but there's actually a really interesting part of Lauren and my story together and more specifically of Lawrence family. Lauren's dad has been active in the Agile world. The Agile methodology, I guess is what you would call it. Is that the correct terminology? He would even say we don't use that word anymore, but yeah, Agile framework, Agile value, so on and so forth. Lauren's dad has done work for companies, major companies like Sprint and he worked at NASA, and he's been doing Agile coaching work well before I met him. In fact, when Agile was just becoming a thing. Through all of these years, Lauren was going on this journey of finding the wrong way of doing project management in some ways and then eventually refining that project management concept and learning more about this Agile stuff. That's what I want to get into now. When you talk a little bit, first of all, talk about some of the things that you would hear growing up from your dad about Agile. Yeah, so he was working on things like the Mars Rover project, not too long ago. He was working with the team of engineers, coaching them on how to work better together and primarily through Agile values and frameworks. He just talks about the people and the momentum and the value of what they're working on. He talked about focus. It was never about a process. I think that's where I had many light bulbs go off over the course of my time at Whiteboard was realizing entering into the web world, it was waterfall. Tell me what waterfall is. Waterfall is a segmented older project management style of one discipline working on their own and then passing it off to the next discipline. Another piece of this is also that budget, time and scope are all effectively fixed, which doesn't allow for change. It doesn't allow for the client to spend less money or more money. It doesn't allow the product that a team is building to change from the beginning plans to the end execution. It also creates longer timelines, deadlines are this thing that happened over months. A lot of these are what we have come to learn about waterfall. Yeah, as I've understood it and you've clarified it to me, as I've understood it from the developer perspective, the waterfall approach is designing the whole thing in your mind or designing it on a piece of paper or in a trello board or trying to figure out all the specifications for something all at the beginning and then locking in a contract that like a four month contract or something crazy like that where you have a fixed end point in mind that's way off into the distance and you have all of these specifications and all this upfront design and you shake on it with a client or whoever is paying you to create this thing. And ultimately in the end, the reason waterfall, well, we'll get into the reason why waterfall doesn't work. But hopefully all of you have experiences. It's a very common thing because the way our minds work and the way we wrap our brains around a deliverable, like selling something, a lot of the time it ends up looking like stuff that we buy at the supermarket. So if you go to the supermarket, you don't buy one ingredient at a time and then go back in a couple of hours when you need the next one because the amount of time that you need between now and the time that you're cooking or the amount of ingredients that you need, you know exactly what you need. Yeah. And it's relatively controlled. There's not really a lot of variance there. If you go to buy a car, you're not going to buy the door and then buy the engine and then buy the windshield. You're going to buy it all at once. There's a huge difference in the way we approach creating software because for a lot of reasons, once again, we'll get into that in just a second. But we have to shift our brains away from thinking about a website or an application. We have to shift our brains away from thinking about those things like a thing that we would buy at the supermarket and instead think about them more like research and development projects. Right? We've got new things they've never existed in the world and they're not exactly specified from day one. There's no way to do it. Even in the most simple scenarios, there's no way to specify it properly. Yep. Like if someone was to get a truly custom car made for just their family, I mean that's kind of the metaphor here. If it was to be custom, you really have to have that time for change and variance. Even on something that you might know how to build. I love this metaphor actually because what you have in this metaphor is you have a thing that looks a lot like the things you've built in the past. It has doors. It drives. It has an engine. There's no reason why you wouldn't look at that and say, oh, that's a car, right? But the fact that it is customized makes all the difference in the world. And that's the, those were the types of things I was hearing from my dad and where Agile was kind of birthed out of he was friends with some of the founding fathers as they may say that wrote the manifesto, the values for Agile. This was really software development that created this aha moment. And it was a lot of governmental projects where they were locking budget, time and scope. And in the end, spending millions of dollars and the thing wasn't working. And they just knew something was missing, something was lacking. So how could we shorten that timeline? How could we allow for more change? How could we allow the experts to create the specs on shorter cycles and produce something really awesome and working sooner and spend less money and then test it and keep building? Yeah, all of this sounds like pipe dreams to me. Like as a developer, I hear that in my, you know, my reasoning machine kind of spins up and says, yeah, that's not, that doesn't make any sense. Like there's too many good things in one sentence to be realistic, right? Yeah. But the truth is, so I want to do a little thought experiment with our listeners for a second. And I think Lauren, you will agree with this. If we were to look at a single problem, let's say we're looking quite literally at one function, right? And I specify to you what that function should do. It's not unreasonable to think that you can look at that specification, commit to doing that thing and then go and write that function, right? It's not that difficult to comprehend a single function. Now what makes this, what makes this difficult is when you add multiples upon multiples of functions to that same conceptual model, right? So a single function is not difficult to commit to. A thousand functions or a hundred thousand functions, right? A hundred thousand routines in your code saying that I'm going to give you a specification for all of those and that you need to commit to a certain amount of time to finish though that hundred thousand different things. Well, that is totally unreasonable. Now what did I change in that scenario? The only thing that I changed was the number of things you're committing to. Let's think about that for a massive difference in the way our brains work and the way commitment works and the way work works. Because really what we're talking about is limiting to this one thing because our brains can actually conceptualize one thing very, very well. Yeah, and if I can interject here, it's true that we can only truly work in an order of things. One thing is to come first. There's effectively the first step that we have to take. And in the other ways of working or project management styles, we're sort of cheating ourselves and lying a little bit to ourselves in the client in saying that we can do a bunch of things all at the same time. And that's not the case. So. Oh, yeah, that's a common theme on the show. We've talked about the myth of multitasking so many times. It's completely impossible. Yep. And I'm actually, if I can go there reading a book tomorrow, it's a children's book that my father has gifted our future son. And it's called the Scrum Princess. Well, he didn't know it was a girl or boy, but either way, the story is really great. It's actually about a princess who wants to make her kingdom the most wonderful place in the world and everyone will be happy to live there. And she encounters a wizard who is the one who teaches her more about these agile practices and says, well, I can form a team, but our team can work on one thing. What's the one thing you want to work on first? Is it the fence? Is it the carriage? Is it the roof on the castle? And asks her and takes her through these practices and ceremonies and teaches her the roles? And it's really neat to see the outcome because of course, they all live happily ever after with a kingdom that was actually repaired and is sparkly and wonderful. And the carriage is fixed and the fence is fixed and oh, wait, she thought she wanted a hippo, but she ended up being able to change her mind. She didn't have to spend the money up front because it wasn't fixed or waterfall. And she decided not to get a hippo in the end. And she got to use those resources elsewhere to build a moat. It reminds me for some reason of progressive dinners. So this concept of changing things as you go along, right? A progressive dinner, if you're not familiar, you can Google it and probably find tons of Instagram pictures of these things. And basically, a progressive dinner, you have a different course at each place that you go, right? So if you go to your first friend's house, it usually is done by a group of friends. And friend number one creates, they cook the appetizer, then friend number two cooks the main course and so on and so forth. So you can go to the first friend's house and eat the appetizer. And then when you get to the second friend's house, you can choose like, do I am I hungry? You don't have to eat that second course. And instead of up front ordering everything all at once, you're kind of going progressively. The metaphor kind of breaks down because you're not really paying for the food anyway. But regardless, I can imagine this like conceptually working in things like gift giving, right? So for a family that has children and they're trying to decide, how do we want to do, for example, our family is going to be celebrating Christmas. And how do we want to do presents with our children? It may be that if we allow our children to get presents over the course of the entire month, that they'll realize that they want a different thing rather than making them list their entire group of presents, right? We're literally brainstorming on our podcast right now about how we're going to parent our child. But if we allow our child to, and hopefully this will help everyone who's listening to this podcast, understand the value of progressive decision making rather than trying to make all the decisions way early on. And then experiencing all of the downfalls of that, right? Yeah, for all of you developers and designers who are wanting to learn something new, start small, start with a daily goal and then a weekly goal and allow for change in between those weeks. Today's episode is sponsored by Linode. We're talking about being agile and one of the core ideas being agile is being able to change quickly. And that is something that Linode supports because it's built on a very simple ideology. And that is to have Linux in the cloud. The same concept that made agile so so useful, the idea of doing one thing at a time and doing it well, that's exactly what Linux does. And Linode is providing you access to Linux and the cloud. There's so much you can do with these boxes and it starts at $10 a month. Now you may think, well, of course, I'm not going to be able to get anything good for $10 a month. I'm going to have to go with a higher plan. But that's not true. Your $10 a month gets you a two gigabyte, two gigabytes of RAM on that $10 box. It's an excellent beginner tier that Linode is providing there. Linode is built on eight different data centers. They have Intel E5 processors in their stack and it's a 40 gigabit internal network. So the quality of Linode's infrastructure is not even a question. On top of that, they're going to give you a seven day money back guarantee. And if that's not enough, Linode is providing you with $20 worth of credit, which is equivalent to two months on that intro tier. $20 worth of credit just for being a Developer Tealistener. You can use the code Developer Tea2017 that's Developer Tea 2017, all one word at checkout for that $20 worth of credit. Thank you so much to Linode for sponsoring today's episode of Developer Tea. If you want to know more about Linode, head over to spec.fm slash Linode. Thank you again to Linode for sponsoring today's episode of Developer Tea. So there's a big difference between committing to a particular set of technologies to learn and committing to a timeline. So I want everybody to understand this real quick because in the past on this show, I've talked about committing to six months in a given language or something like that. And it's important that we find our footing as developers because we have our heads on swivels all the time as developers. There's so many tools swirling around. There's brand new stuff coming out all the time. Hopefully you've heard this on the show before. I'm going to reiterate it because I think it's one of the biggest downfalls of the developer world right now is that we constantly feel like we have to pick up brand new stuff all the time. That's not what we're saying here. I'm not saying that you need to progressively always pick up a new framework every single time. You turn your head and decide that you want to. What we are saying is that you commit to a schedule, commit to a direction. And then as you go along, modify that direction slightly. It's all about balance. If you go along and you find out, hey, you know what? As I'm going down this road, I think slightly shifting my JavaScript training to also include ES6, like an extra syntax, right? Or it slightly shift my JavaScript training to also include a framework that also happens to be written in JavaScript. These are the kinds of adjustments. It's not changing direction and turning around, like doing a 180 and going the opposite direction. No project we get done that way. So let's talk about how that would affect. So when we're talking about agility, which is, you know, the root word is obviously agile, agility is the ability to make changes, right? Or the ability to shift direction. Think about a really high performing athlete. A high performing athlete is highly agile. They can shift directions very quickly if they need to. So how do we, you know, how do we implement agile in such a way that we prevent from doing constant 180s and basically spinning in a circle? Yeah. So as an organization or an individual, you have a mission statement, you have values, and ultimately what you need to derive from that is an objective. So if it's to learn, you know, X language or to produce X project in learning, you know, X, Y and Z or a client comes to the table, you know, they know they need a website or they need a web application so that their users can do X. So they have an objective now being careful to not be prescriptive too early as you just discussed is key here on delivering on those values that they have and also being open to the expertise of the team. So the designer, the developer may even have knowledge or explores knowledge to find a solution for the thing that the client didn't even know as possible. So or, you know, even the strategist didn't know as possible. So this is the power of the team, you know, working together and not siloed away from each other in a waterfall way. Yeah. I'm glad you mentioned this idea of them not even knowing what was possible, right? Because one of the valuable things that developers bring to the table, one of the most valuable things that developers bring to the table is our perspective on technology or maybe our knowledge of specific types of technology that can be used to accomplish goals better than a solution that's been presented by the client. So for example, there's many examples that we could throw here, but a very simple example would be a client coming to whiteboard and saying, we need a mobile application. Like we need an app in the app store because we want people to be able to find our store easily from their phone. And what we could tell them is, hey, look, like there's a lot of other options that you can go with, right? You could, for example, we could do a whole marketing campaign, not even build any kind of application at all, do a marketing campaign and really drum up a lot of business through something like Yelp, right? We can use something that already exists. We could, instead of doing a mobile application that lives in the app store, we could actually just create a mobile website. Instead of doing an application in the app store, we could do something as simple as a response of web design, right? So the website just simply loads well on a phone. And they may not even know what a responsive web design is, right? There are still tons of people, still tons of websites that aren't even updated to that point. So the superpower of a person in technology, in particular, the superpower of a person who's working on behalf of other people who are not in technology. So in the agency world is this awareness and the problem solving ability. We've talked about this on the show before of clients coming to the table with the solution in mind. And we have to remember that clients, we always have to direct clients to stating their problem or stating their goals, not in terms of the deliverable, right? That's a very important aspect of this because if we make any assumptions, again, another huge theme on Developer Tea is avoiding assumptions and only making the right kinds of assumptions. But if we make any assumptions about the ultimate deliverable, then we could be boxing ourselves into a corner. Going back to the episode that we did just this week on Wednesday, we talked about the Einstein-Lung effect, right? The way that we've solved something in the past is the way we're going to solve it in the future. We have this tendency to solve problems the same way. We'll have the tendency to solve problems with the wrong solutions very often because they've seen that same problem or a similar problem solved with a particular solution. So they may assume that that solution is the best one for them. And it's part of our job, after my long spiel here, I'm going to hand the mic back over to Lauren. But it's part of our job as agency professionals or this goes for the product world too for those of you working in startup land. It's your job to remember and remind the product owner or to remember and remind the person who's really at the top driving this ultimate goal, remind them to stay focused on the goals rather than the deliverables. Yeah, and that's really the role that I play a lot that is effective and needs to be a part of any truly agile team or scrum team is the coach. The coaches necessary, I mean, we know this from sports and really this was birthed out of the idea of scrum from sports. So yeah, the coach has to help remind the client and the producers and the strategists and product owners of these very things and highlight those strengths and remove barriers and make communication so much more easy. But we're really the role too of a product owner is to challenge the client and challenge the team on these decisions. Is this truly a priority? Is this the most valuable thing? Let's make a decision together and is there another way we could go about solving this in our brainstorming sessions? Having a coach there to encourage us to ask these kinds of questions and to really kind of push the team in the right direction is a super important thing, I think. Can you tell me like what are the coaches, what is the coaches job practically speaking in a meeting? Facilitating communication, removing barriers that stand in the way of the team members doing their jobs effectively. The most important thing truly is for the work to be done on a daily basis and at the end of a sprint for it to be working and testable. So really the coach is there to say, hey team, let's make sure we're communicating really great together. Do we need to be higher touch or lower touch in communication? Do we need to be higher in our documentation specs or could we lessen a bit to be more agile? Just begging these really thoughtful questions at every juncture and also truly the role of a coach is a servant leader. So not, hey you need to do this, but what can I do for you? And I know it sounds silly, but it is the make or break of this equation. So you're saying that being a servant leader is the make or break of the equation of agile working or not correct? Yes, absolutely. And we'll talk a little bit more about what servant leadership may actually look like on a case by case basis in the rest of the interview. For a second, I want to kind of delineate and clear up what may be a little bit of confusion about two terms that we're using sort of interchangeably in today's episode. And Lauren and I have done a little bit of study together to kind of figure out the difference between these terms. They have been mixed up a lot and really culturally and in practicality a lot of people do use these interchangeably. And I want to delineate or make the difference known between scrum and agile. And Lauren, if you want to talk a little bit about the difference between scrum and agile, that'd be great. Yeah, agile is more of the philosophy, the overarching umbrella in which people have implemented scrum. Scrum is a way, you know, a little bit more specific way of delineating roles and types of ceremonies and patterns, but it's all based on the values and the framework of agile. So it's kind of like a way of doing agile, right? Absolutely. So a scrum master is the scrum's version of an agile coach. That makes sense. So the coach really is the scrum master actually because what we're saying here is that in agile, you have a coach and that coach can be in any of the multiple methodologies that are practicing under that agile umbrella, where agile is the thing that we saw earlier that was compelling was scrum is agile, but agile is not necessarily scrum. Correct. So some of the other things that may be implementing agile are things like extreme programming. There's one called crystal. I don't even know anything about crystal. I've done very little research into extreme programming. You know, it has something to do with pair programming and doing, you know, feature development on one single vertical slice, you know, doing all the way up and down that slice until that one feature is completely done and completely integrated. So there's some really interesting stuff out there, but the way that whiteboard is implementing scrum and the way that it's actually working very well at whiteboard as a developer, I'm very happy with this process is through this scrum methodology. So I want to talk to you about, we started talking about it a little bit earlier and we decided to go back and reform at this discussion a little bit, but I want to talk about team weeks. This is kind of the way that scrum is being implemented at whiteboard. How are we doing this weekly iteration, weekly sprint kind of thing at whiteboard? The way we're implementing scrum is at the weekly interval. So an iteration can be a week or two weeks, those are pretty standard, but we have chosen week. So any kind of iteration be like a month? It's not typically suggested. They try to, they say two week, three week is kind of the sweet spot. Okay, make sense. And what is the reason for that, by the way? Other life cycles between the things that you are committing to complete, the things you're estimating to complete, impediments that you experience, communication, breakdowns of the team, the shorter the cycle, the more that you can hone in, learn it's smaller increments and not reproduce them cyclically for too long. That makes sense. I mean, the smaller the learning cycle, the more you're going to be able to remember whenever you're trying to, whenever you're going through the next learning cycle. And that much quicker for recovery and improvement. It's kind of like the thing we're talking about earlier, where it's one function versus a thousand functions that longer that cycle gets the harder it is to actually plan for. Yeah, like our old way at whiteboard was a four to six month project process. So that's very different than delivering in a week. Sure. Yeah. Okay. So you have a week as the interval. Yes. There's just a few key ceremonies. You don't have to read too many books or get a certification to learn the basics. You start with a sprint planning meeting and then you have a daily standup each of the days of your sprint. So if it's Monday, Tuesday, Wednesday, Thursday, Friday, you have a daily standup one at one time each of those days, five, ten minutes at the most. And when is that that first meeting that you mentioned? What was it called again? A sprint planning meeting. Okay. So when is sprint, when does sprint planning happen at the very beginning of your sprint? So like Monday morning, precisely. So then we have these standups. Is the sprint planning meeting basically the standup for Monday? Yes. With just a little bit more time and effort going into evaluating and breaking down and setting requirements and estimating things of that nature. It's kind of like a kickoff meeting. If you're in the agency world, we have kickoff meetings in our like all the time. But a sprint kickoff meeting, I guess you could call it. It's your weekly kickoff. Okay. So then you have these daily meetings at, is it better to do them the morning? Does it really matter? No, it doesn't. It's totally dependent on your team and when they're available and what works best for them. But you know, if you've had a meeting on sprint planning meeting on Monday morning, then your first daily standup is probably going to be Tuesday morning and then Wednesday morning, Thursday morning, Friday morning. And in that daily standup, three basic questions. And anyone can facilitate this. It doesn't have to be the coach. And you kind of learn it and you walk in and this is what you do and you're really facilitating yourself going forward, which is part of the ownership and beauty of this. So what did I complete yesterday? Explain a little bit about it. You know, a 30 second elevator pitch. What am I committing to complete today? And are there any blocks or impediments or you know issues that I am up against that I need from another teammate or that we need to resolve before moving on? So as a developer, when I hear that I'm going to have five new meetings on the books, actually more than five, it kind of gives me anxiety, right? Because immediately I start thinking like, oh, this is going to interrupt my focus or it's going to frustrate me because I'm going to want to come in in the morning, get my coffee, sit down and dive into a difficult problem. But what I've found the few weeks that we've already been doing this, which by the way, part of the reason why I asked Lauren to come on the show and this juncture is because we're getting ready to really roll this out of widespread across whiteboards methodology or our way of doing this is getting ready to adopt this pretty much unilaterally across the company. And we've been testing it out, been doing like a pilot project. If you guys remember the episode about doing a pilot project to learn something, part of the reason why I did that episode is because I saw this working so well as a pilot project instead of trying to roll it out across the company and widespread all at once. We've tested it with a few smaller teams first and that pilot has proven really valuable in helping us learn how we want to do Scrum, how we how we want to do these team weeks at whiteboard. But in the few weeks that I've done them going back to having anxiety about multiple meetings, I've found that these meetings, first of all, they're really energizing because they're with the same small group of people every day. So kind of a side benefit to this is that you're going to get to know your teammates a little bit better. For those of you who are not very social naturally, you're probably going to have to get used to this over time. But it actually has proven to be really, really valuable to me as a developer. And I am very much so kind of a closed off traditional introvert of a developer. I love my headphones and I love my quiet time. So but this is really helped because a lot of the time these stand-ups, what is really unique about these is that you can actually talk about really specific development problems that you're having. So many of the meetings that I have or had before sprint stand-ups, a lot of the time we wouldn't have the opportunity to talk about specific engineering issues. That was two quote in the weeds. We said that in phrase of view times. That was two down in the dirt of what was happening. But the point of these stand-ups is to actually go through some of that stuff. So if you're developing one feature today and then tomorrow you're developing one feature and you're having a meeting about those things, then you can talk about the specific technical implementation in a stand-up and that's totally okay. In just a few seconds, even really. I mean, they're efficient. I mean, 5, 10 minutes at the most. Yeah, it actually doesn't break my, I've found that it doesn't, doesn't break my focus. It actually helps me get into a mode a little bit quicker because I'm starting to think about the complexity of the problem. And it's almost like pair programming in a meeting format. We aren't sitting in front of a computer, but we're kind of designing the software in that meeting. Even though that meeting is not necessarily specifically earmarked to do software design, you're still solving problems in that meeting because let's say, for example, that the day before you couldn't quite figure out, you know, I don't know. If you're working with JavaScript, you couldn't quite figure out why that particular MPM package wasn't compatible with this other one, right? And so you meet with, you do your stand-up and you and another developer can talk through that problem in the stand-up and then get past your problem in that moment. It's a very, it's the right type of collaboration because it is very detailed. Yeah. And sometimes it's even just a communication like, hey, Matt, I didn't get a chance to talk to you yesterday. My thing is waiting, you know, in staging for you to review before we push to production. Boom, done. Yeah, having the all-purpose, but also very small meeting is really valuable. We all hate all-purpose meetings because so many times, if we go into a meeting without a, like a specific goal in mind, then it's, you know, 45 minutes or an hour and it always runs over and nobody knows what's going on and nobody knows who's supposed to be talking next. But these meetings, because they are limited to the people who have been working together and because they have a very specific set, start time and because they are intentionally about what we did yesterday and what we're doing today, almost every time they're successful. Right? It's actually very, very effective to do five smaller meetings rather than just one meeting at the beginning of the week and then, you know, go off into your own corners and do your own thing. Yep, absolutely. Thank you so much for listening to today's episode of Developer Tea, me interviewing Lauren Cutrell, who also happens to be my wife. Thank you again to Lauren, of course, for coming on the show and for talking with me about Agil. If you don't want to miss out on the second part of this interview, make sure you subscribe in whatever podcasting app you use. Thank you again to Lynneau for sponsoring today's episode. If you want $20 worth of credit on a Lynneau account, head over to spec.fm slash Lynneau, use the code Developer Tea2017 that's a Developer Tea 2017 at checkout on Lynneau.com. Thanks so much for listening to today's episode once again and don't forget we will be announcing the winners to the JavaScript January Developer Teacontest. We're actually going to announce them on Monday, February the 6th. Obviously we said we would announce them on Sunday, but just because most people are not going to be at their computers on Super Bowl Sunday, at least in the States, we're going to go ahead and wait until the 6th to announce the winners. That doesn't mean you have an extra day. Necessarily, you're going to be kind of cut off at the end of February 5th. And a quick side note on that. If you created the pin that you're trying to enter into this contest before the contest began, unfortunately we're going to have to mark those pins as ineligible because it's not really fair to the people who are creating brand new pins for you to use something that got popular before. Unfortunately there's some really good pins out there that were created before and people who have added the tags to those pins. Unfortunately we're not going to be able to count those. Hopefully you understand and it's just all about fairness and it's also about the entire point of this which is to get you practicing JavaScript in 2017. So any pins that you want to be eligible, they need to have a creation date of sometime this during this month, sometime in January. Thank you so much for listening and until next time, enjoy your tea.