I think it's important to have at least some type of background, right? Some context around what engineers or software engineers are up to these days. And I would say day in the life that we're going to share here is pretty common for Yeah, a lot of the companies out there, especially the ones that are disrupting industries these days. So it starts out with breakfast for us, we're going down the street to Shamane's, it's really about the conversation, what areas of the project might folks be working on, but also, breakfast is a little bit more about just kicking off the day together and understanding who might be at a dentist appointment in the afternoon or if there's an event in the evening that folks might want to attend. So that's breakfast and yeah, the original reason that we kicked off breakfast was simply to get folks to work on time, which is, reasonable. Alright, stand up is quickly followed by breakfast for most and I guess the thing to be careful here is stand ups for some companies have turned into just readouts for your product manager or project manager. And the intent of stand up was really about coordination, so figuring out who's doing what, what area of the code base you might be working in, if you're going to be working in the same area, how do you navigate that? Or if you're standing up a new database, right? What that might look like or migrating a database. It's also an opportunity to talk about maybe new tools that are out there that maybe the team wants to explore. And sure there's the traditional, what'd you do yesterday, what are you going to do today? And then what's stopping you from doing work? But I think the small reminder here is it's really coordination and not as much the readout. Thoughts on that one? >> Yeah, I think it's even more important to remember that now that things are becoming more and more remote. When we were all in the office together. Someone next to me was setting up a new database. I might overhear and go and ask them a question about it. Now that we're remote, we don't really have that chance to overhear. So focusing stand up on those areas of overlaps between people working within a team is pretty key. >> Awesome, awesome. So then after that, it's really about work, getting done a handful of different techniques, whatnot, right? You could practice something like pair programming, which is two people, same keyboard or two keyboards to monitor same machine, I should say. But after that, morning kickoff, it's fairly common for folks to go from, call it nine to noon or eight to noon just simply getting work done. I think the one thing to call out is trying to reduce meetings, right? So if you're writing software, if your architecting a software system, if you're bringing in maybe message queues or big distributed databases, you want to get work done, right? You don't want to be spending your time in meetings. So remember about just simply getting work done throughout the day. Naturally folks need to take breaks. There's the ping pong tables that have been out and about, there's also foosball and then even, things as crazy as maybe crews getting together and playing hockey on xbox or something like that. But breaks are important, right? And I think maybe to your point Tyson on us being remote more these days, it's even more important to get some of these ceremonies in place and take those breaks. Okay. So then naturally we're going to replenish at the end of the day. I think it's also important to push the keyboard away, right? It's so easy to get trapped into a place where you just, continue throughout the night. You might take your laptop to bed with you and in a matter of no time at all, you're working 10, 12 hours a day. So we'll push folks, to that eight hour day, and try to get people away from the keyboard when we can. >> Yeah, definitely true. >> Alright. And so why are we doing this, right? We're running this playbook if you will, but it's all about a sustainable pace. So when you think about software and architecting systems, right? You want to be able to predict when things are going to get done and in order to do that you need to work at a sustainable pace. And so there's a few things maybe. And the biggest thing maybe to talk about is just what it does for you is it reduces execution risk. Right? So if you're thinking about, the day to day. And if I did, do you know something where, I'm working 3, 12 hour days in a row naturally, I'm going to get burned out and need to go watch a movie or something like that. But if I work at a sustainable pace, right? I could better predict when we're going to ship software, right? We could foster a learning environment. We could do experiments and I would say, I guess it's all about finding people who kind of in some ways thrive for that environment. Anything else on your side there? >> Maybe just to add it is really what makes you be able to go fast for extended periods of time, right? Going fast for short bursts is only so useful. Going fast for, years is really what we want to target. >> Yeah, there's a couple of folks that we've worked with over the years and they might have coined the term go fast forever, which is pretty interesting. All right. So maybe one or two more slides here, to talk about kind of day in the life. So in practice, right? There's a handful of things going on. I guess one thing that we mentioned is the single team, right? Where we're bringing product and engineering teams together, whether it's called a squad or a balanced team or a mission team, you'll see these teams of 4-8 people doing the stand ups, thinking about the week in terms of an iteration and then having either bi weekly or even weekly retrospectives. We mentioned planning meetings. So this one is important, right? It's all about getting work done, getting to small stories. I used to mentor some of the crew at techstars and interesting enough, they simply just didn't have a backlog most of the time. So I was, there to help with big architecture and solving hard technical problems. But when I would ask folks, they just simply wouldn't even know what they're building or even just have a list of things written down that they were trying to accomplish that week or that month. I would say the bulk of what Tyson and I are up to as consultants is getting folks into the rhythm of stories and getting stories flowing through the system. Anything on there? >> Yeah, I might just add that. It's not unique to small companies, right? Big companies have this problem too where they don't have a backlog or they might have a backlog, but the stories are so big, that really, they're epics and, it's hard to tell what's going on at any point in time because stories might take weeks. >> Yeah, I think the one interesting thing, there's a book called the phoenix project and I've used that at CU a handful of times. And one of the things that talks about is reducing batch size, right? So that you can get insight into what's going on day to day. And I would say the art of, getting stories flowing is getting them small, right? Such that your product owner, product managers have insight into what's happening, day to day, week to week versus, waiting that 30 days, that was, the original scrum duration. And realizing that after the 30 days you built the wrong thing. So planning meetings are important. Part of that, right? Is having your immersed product owner, if you think of environments where folks are like, my gosh, we have to get this done, let's get everybody in the room together, let's bring product design and engineering in a room together. It's amazing what happens, right? A lot of work gets done. And I would say if you could find teams, balanced teams that just worked that way all the time, it'll feel fast paced, but remember there's a sustainable pace. So it's not a fast pace of 14 hour days, it's a fast pace of eight hour days, but you really do get a lot done, especially having your product owner nearby so that they could react to, a new database table that you're putting in or if things might be eventually consistent if that's okay or not. So immersed, product owners are important. Test driven development I think a decade ago, this was pretty new to folks. But I think these days test driven development is fairly common. I think maybe the one thing to call out and we'll practice some of this right away. As we're thinking about architectures and starts at a micro level and then we'll go a bit macro as the course continues. But there are people who still test during or test after and I would say if you really want to push on the design and make sure the code that you're writing or the data that you're moving around is testable. You have to do it early. Refactoring. So if you haven't heard this term, it's really cleaning up your intentions, cleaning up duplication, right? Its restructuring the code that you have without changing any external behavior. So, if you're thinking of maybe a small algorithm, maybe the intent is simply to get the algorithm to move faster, but the input and the output is the same. So that's refactoring and re factoring ruthlessly, I think it's just the way to go and remembering to refactor your tests as well is also important. So don't just focus on the code that's sitting within the method that you're improving the performance of, focus on also getting the test suite to move fast too. And the reason there is so you get feedback faster so you can continue to go faster. >> And I think it's important to call out to that refactoring isn't like a separate step, not a separate story, like every piece of code that you write once your tests are green, you should be refactoring it and that's within the story. Simply because we want to write high quality code and this is the way to do it. >> Yeah. So that's where that mantra Red Green refactor comes up. So write a test, have it failed. It's red, get it green and then refactor. Alright. So that's re factoring continuous integration I would say there's a lot of folks who are doing this these days. But it's simply just running the test suite every time you commit code. And more often than not you're committing code to git repo these days and with tools like git lab or git hub, there's actions that trigger and we'll run that test suite for you. And you might be integrating truly with databases, message queues or other apps that you're firing up within possibly docker containers that's part of those continuous integration environments. Continuous delivery a little bit new, I would say for folks. But this is simply just being able to hit a button and deploy that now tested application that you built to production and again not sending a cd to QA or that then team sending another disk or a file to your info sec team or your network operations center, the folks that are monitoring and keeping prod healthy but the balanced team being able to deploy. Right? So there's self service environments these days, if you think of some of the public cloud providers like google or amazon or Azure that let teams deploy and deploy continuously. So it's continuous delivery. Retrospectives, you want to mention something here? >> Sure. So retrospectives we typically do at the end of every week, at the end of every iteration and this is really a chance for the team to kind of review what we've done over the past week, kind of the processes and practices and what's gone well and what hasn't gone well. So this is really where we say, whether things are working or not for the team and how the team gets better over time. So I'm a big believer in every retrospective ending with a list of action items and starting viewing those action items. Lots of different formats in the middle, but this really makes sure that, we're looking at ourselves as the team and taking action to improve. >> I've heard what about what about companies that have beers during retrospectives. Heard four o'clock retrospective with the beer is pretty common is that you stay away from that or what's going on? >> I think I've heard that before, and I think it's a great idea and, it helps people to maybe relax a little bit and just kind of create an open environment. So, beer wine snacks, even the same. >> Effect from retros are great. So whether it's weekly or every other week, we had encourage them.
