 Hey, so let's pull it all together everyone, grab a seat please if you would. So this is the fourth, this is the fourth in our series about scrum, our, as somebody said today, scrum-dementals session, this is the final session. What we've tried to do here is give you an overview of scrum and its foundations so that you can apply it effectively. Now very early on in the sessions I talked about that scrum is a lightweight process, it's an easy to understand process, but it's difficult to master. So we're arming you, we're giving you the basics to go forward, but the reality is is that you, if you start working with scrum, you start applying scrum, you probably will spend the rest of your life working to master it. Okay? So tonight what we're going to be talking about is apply inspection and adaptation as well as some advanced topics. When I say inspection and adaptation, what do I mean? So let's do a real quick recap of kind of what are the first principles of scrum. Those of you who've been here for the, for all previous sessions are probably getting a little sick of this, but it is important. What makes scrum work is it's an empirical process. At the foundation of empirical process is that you have transparency into the system that you're working to manage. What does that mean? Transparency means that you can inspect it, that anybody who's involved in working with this can go in and look at it and understand what's going on. What does this mean in terms of scrum? Well, it means things like the daily standup that provides transparency into the system. If you have, if you have a task board, that provides transparency into the system. If you provide, if you have a burn down chart, it provides transparency. Transparency is all well and good, but to make it work, you have to inspect it. You have to actually look at it. This is why you have a standup meeting so that you can inspect things. You can inspect the state of things and where they're at. And then, based on that inspection, you have to adapt. So this has got to happen frequently. You have to, you have to inspect, you have to see what you're doing, and then based on that, you need to adapt. You need to change the process. And that's why we're going to talk about today, because it is the application of inspection and adaptation. Now, scrum, this is the basic of the cycle. It's very simple. You start with a sprint plan. From that, you get a sprint backlog. You go into the sprint. You do your daily scrum, which is giving you feedback. It's providing a venue for inspection. It's provide, and then you adapt based on that. You go to the sprint review, you go to the retrospective. What are the things we're going to talk about tonight? Where are the places where we're applying, very strongly applying inspection and adaptation? Well, first, the first place is in terms of the daily scrum, the sprint review, and the retrospective. This is really where it all happens is here, where you do inspection, inspection, inspection, and adaptation. Excuse me. Did I go forward? And again, underlining it, it's about inspection and adaptation. You're going to be sick of hearing those words, but this is the key. If you take nothing else out of the four weeks that you've been here, nothing else, take out that the key to empirical process is inspection and adaptation. Frequent inspection and adaptation based on that data that you gather. If you look anything else, if you're like, well, how should we handle this as you think about scrum and applying scrum? If you remember inspection and adaptation, you'll be okay. Okay? So let's hear it. Inspection, adaptation. Wash, rinse, and repeat. Okay. Any questions at this point? If not, while we're going through the talk, if you have a question, feel free to raise your hand. We'll stop. We can take it. We can chat. Okay? So where's the first point of inspection and adaptation? Where is the first point of transparency in this process? Well, it's the daily stand-up scrum. Now, does anybody here know where we get the name scrum from? Anybody ever watched rugby? In rugby, when they're putting a play together and the players come together like this, what we in the U.S. call an American football a huddle. It's actually called a scrum. They're actually planning out what they're going to do, and then they go and do it. But if you think about rugby, the model is you kind of look at the situation, you discuss it, and you adapt and you tackle it, and then you do it again, and you get it again. And that's what the scrum is about. So the daily stand-up or the daily scrum is our most frequent point of inspection and adaptation. So really think that this is your inspection point. This is where you're taking the pulse beat. So if people on your team ever say, suggest, well, you know, maybe we should only have the stand-up once a week. Or maybe every two days. Well, you know what? Let's just not even have a stand-up. It's probably the wrong answer. It is probably the wrong answer. I'm not saying that there aren't situations where not having a stand-up is not the right thing. If you're all sitting around the same table, probably don't need to have a daily stand-up. As long as people know, hey, this is what I've completed, this is what I'm going to try to complete, this is what's getting in my way, then maybe that makes sense. But if you're in a team of 15, 30, 45 organization, yes, you should have it. So the first question you're asking is, what have I completed? What have I completed? Since the last time we got together, here's what I've completed. Or another way of saying this, what do I have in progress? Now, here's the thing. If you've gone two days and nothing's been completed, that should be a signal. If you're at three days and nothing has been completed, that is a really strong signal. But that also goes back to your stories. And have you formed your stories well, so that they're not too big, that they're not, that they make sure that they are fine grain enough. That is key. If you do that, then you're okay. And then you'll be able to every day say, yeah, I finished one story yesterday. Or every two days. Yeah, we finished that story, we're moving on. So the question here is, what have I completed? Or what do I have in progress? Real basic, this should not take more than a few seconds. It's not a laundry list of everything you've done. It's the stories or tasks. And you know what, it can often be accompanied with taking that sticky and moving it from in progress to done. Okay? That could be that part of what you do. And there is nothing more satisfying than doing that. To take that from in progress to done. Okay? The next question is, what do I expect to complete? What do I expect to complete? What do I think, looking at where I am and what I'm going to do? What do I expect to complete? And if this is always, well, this is what I'm working on, not what I expect to complete. That again is not a, that is a strong signal that you should be looking at. Okay? So what do I expect to complete? Or what will I be working on? It's the other question. Again, this isn't, you know, if somebody talks about five things, then probably they're doing too much. In fact, they are doing too much. Okay? Do not, do not get caught up in the myth of multitasking. Humans cannot multitask. It is actually a demonstrated fact. In fact, computers can't multitask. How much computers multitask is they swap things in and out. Well, guess what? Your swap is a lot more expensive than their swap. You're going to thrash a lot faster. It's just not possible. Okay? So don't believe this myth that I can do me doing five things in parallel. You're actually doing them each. You're doing each of them serially. You may be doing them very quickly, serially. You may have five things underway. But the reality is if you every day are giving a laundry list of five things, I bet you at the end of the sprint, you're not going to have finished any of them. Okay? That's a bet I will always take because I will win it 80% of the time. And the final question is what is slowing me down? Is there something you need? Did you not get access to the servers you need? Now, if the same thing gets mentioned, day after day after day, strong signal, something's broken. Because your scrum master should be jumping on this one. They should be saying, hey, make a note of that. Now, you don't need to get the details of that at that point. But somebody better be, yes, we're going to track that. We're going to jump on that. We're going to deal with that. Okay? That's the thing. And then they need to do that. Okay? So going back, inspection, adaptation, key, inspect, adapt. Do you see how each one of these steps is tied to? This is inspection. And if people are not making progress here, then we need to adapt. Inspection. If people are not making progress here, we need to adapt. Inspection. We need to adapt here. This is going to lead to a failure in the project. You're going to miss something if this keeps going on. Okay? Inspect, adapt. If you remember nothing else, inspect, adapt. Before we go on, any questions at that point? Just talking about the daily stand-up or the daily scrum. Okay? My usual question answer, askers are being quiet tonight, so we'll move on. I actually like the questions you guy asked. Don't be embarrassed. The sprint review, another point of inspection. The sprint review. How many of you have ever been in a sprint review? Well, a sprint review. Again, think inspection. It's a point of inspection. Okay? What do we have working? It's the end of the sprint. What do we have working? What potentially shippable customer value do we have in hand? Let me show it to you. Okay? Not on some special machine, not on some, you know, you know, kind of put together to make it work set up. But what do I have working? What could we potentially ship tomorrow if we want to? And what does it look like? Show it to me. Okay? Show it to the team. This is a, this is, there's a couple of things going on here. First, is this is a step of validation. Excuse me. This is a step of verification. Okay? This is, hey, this is what we, you know, we said we would do and we got it. But it's also a time of celebration. Look. See, it's working. Hey, you product guy, if you want to ship it, you can. It's ready. Okay? And then the final step is this is where you want the product owner to formally accept things. For them to look at this and say, yeah, we met our sprint goal. I accept that this sprint was completed, that we finished these stories, that this sprint goal has been reached. That's what you want to do. So, you know, hey, what do we have working? What could we potentially ship? Great one. What does it look like? Show it to me. I really want to see it. I want to touch it. I want to feel it. I want to use it. Now I've got to say that if at this point you say, oh, sorry, we can't put it on your machine. Oh, I can't put it on your phone. That is not a good sign. That is the wrong signal. That is a bad signal, a strong bad signal. So, again, so now here, this is a point of inspection. We don't really adapt from this, other than the product owner could go, oh my god, that doesn't look at all what I thought it looked like. But honestly, that conversation should have happened much earlier in the sprint if that's what we're having. But if it happens, you know, you've got to deal with it. But this is primarily inspection. Inspection and celebration, okay? And next we come to the sprint retrospective. The sprint retrospective is where we step back and we say, hey, we ask ourselves some questions, some very, very basic questions. We're going to ask ourselves three questions. The first question, it's not there. There's supposed to be a smiley face there. I actually, for the first time in my life, used emojis at a presentation and I have been failed. There should be a smiley face here, okay? Should be a smiley face, smiling out at you. This is what went well. What are the things that if the next sprint was full of them, you would be very, very happy about? What are the things that if the next sprint was filled with them, you would be happy about? This also could be phrased in terms of the classic start, stop, continue. What are the things we should continue doing? What are the things that made this better? This is a process, this is part and parcel of a process of continuous improvement. Identifying those things that made this worth doing. And this could be, hey, what went well is I finally was able to work with you effectively, okay? We figured out how to communicate. Well, let's keep figuring out how to communicate, okay? Our PO gave us great stories, well-defined stories and acceptance criteria and worked with us during story time to make sure they were ready. That made this a fantastic sprint, okay? Identify those things. Now, how do I recommend you do this? I think you need to think about bias and cognitive bias and how it comes into play, how people look for confirmation, how people anchor on things. So one of the best ways to do this is have each person sit for five minutes and write little post-its and then go up and put them on the post-it board, the first one being what went well. So put your post-its there. But the next set of post-its you're going to look at are, and that is not the emoji I picked out, but it works. But it works. It was a frowny face, okay? It was the frowny face. What didn't work? Or in the stop, start, continue, what is this, excuse me, what is this shit we should stop doing? What is this shit we should stop doing? What is the stuff that just made this uncomfortable, that made this icky, that was not made it unfun? What didn't work, okay? Again, you don't want to bias people, so have people put it on stickies, put them up on a board, okay? And how can we approve things? Now this, this was a very thoughtful guy doing his chin, you know, he was thinking, you don't see it, but you know, that was what it was. What can we approve? How can we improve things? And this isn't, oh, do more of the good stuff, do less of the bad stuff, this is, hey, you know, I think that if we did x, you know, if we, if we added these test cases, it would improve, it would improve our sense of the quality of it. If, hey, you know, if we actually had a more stable staging environment, that would be a great thing, it would help us out. You know, if we switched compiler versions, I think we'd leave a whole bunch of bugs behind, and we'd be better off. That's the kind of stuff here. Now once you have these up on a board, once you have these up on the board, one of the things you want to do is you want to cluster them. You want to find the related themes. So you're going to, as a team go, and you're going to start, oh, well these all seem to fit to here, and these seem to fit here, and these seem to fit here. Boy, there's this outlier here, he always has the outlier. I usually always have an outlier. The people are like, what? And then you start looking at the themes, and you start thinking about how can you address it. And one of the things I really recommend you do, especially for these, is whatever your issue tracking system is, open issues here. If these can be captured as issues, as tasks, then don't do them. Get them there too. Get Jordan and Stephanie talking to each other so they better communicate. That might be a task. You know what? Just put it in there. It may seem silly, but hey, is it keeping you from being effective? Or what went well? Continue to go out to drinks every Friday night because it works. It makes us work well. So for each one of these, go through and as appropriate, if you're using Jira, open Jira tasks, or bugs, do that. If you're using something else, you're using Trello, put Trello cards in, have a card for an improvement. We actually, here at Carousel we have, in Jira we have a project called CPI, Carousel Process Improvement. You shove stuff in there. We identify things in retrospectives. We get it, we capture it. Now, this isn't the only time you can have a retrospective. And it's probably not the only time you should have a retrospective. If you have a production incident, I highly recommend you have a retrospective. But combine that with a root cause analysis. Use the five Ys to figure out the root cause. And then go after that and kill that. I'm not going to talk about root cause analysis. That's another topic for another night. But, something for you to think about, okay? Got to keep you guys coming back, right? If I highly recommend whenever you finish a major release cycle, okay, like we just did, you may have noticed we shipped a new feature called Bumps, which allows you to basically promote your listing after it's already been made. We have both paid Bumps and what we call price drop Bumps. Great stuff. Check it out in the Carousel app. You all have the Carousel app, right? Yeah, of course you do. Your phones will be inspected on the way out. So download it now. The Wi-Fi is good. The guest works. What's the guest password, Victor? Hello, welcome. Hello, welcome. That's our guest password. So if you haven't had a chance, download the app. Now get it installed. You'll be inspected on the way out. So, now that has been a project that has run over multiple sprints. Big release. So we're going to have a retrospective that we're going to ask these kind of questions. What went well? What didn't work? How can we improve things? Identify things that we can take action on to improve, to make the world better. Okay, going forward? So that's what we want to do, okay? Any questions here? I see the Carousel app is being downloaded. Yes, go ahead. Even if we're using websites on one, how do we... So there's a couple of ways that you could be... So first off, in terms of the sprint and how you did in a sprint, there's a couple of things you can look at. First is have a burn-down chart, which is a very simple chart, which is a chart that each day, however many story points, you've done, take that off, and look at the trend line. Products like Jira, they make it easy. But you can do it manually. All you need is a piece of paper, a piece of graph paper, some markers, and a ruler, okay? It's very doable. There. In addition, you could start computing the velocity of your team. So how many points from sprint to sprint and tracking that? So we did this many points in this. A metric we've implemented here at Carousel, which I think it's not one out there in the world, but is a very, I think a very useful one, is delivery against commitment. And how we calculate delivery of commitment is it's a 0 to 10. It's a 0 to 10 scale. We first look at how many story points did you deliver divided by how many story points did you commit, and then convert that to a 10-point scale. Then the next thing we ask is how many stories did you deliver to how many stories you commit it? Again, convert to a 10-point scale. Average that, and you give yourself a scale. Why do this? Well, it really makes it clear that it's not cool to game things, because if you, I mean, you could imagine, oh yeah, let's have one story of 99 points and nine stories of one point each. Hey, we get that big one, we got 99 points, you know? We do fall into these traps, we do this. This makes it, but oh, well, let's just have lots of big little stories and we'll just knock out as many as we can. Well, you get the balance in both places, and it helps. These are metrics that you can track. There's lots of metrics that you can track, but these are some very basic ones, and I'm talking about the ones you can do without having a big, you know, there's flow velocity, there's all these different ones that have been come up with over the years. Just pick a few and use them. Again, it's a lightweight system, easy to understand, but yes, it's difficult to master, okay? Yes? So if it's enough pain, you'll fix it, okay? I mean, I firmly believe that human beings are motivated by pain, and I mean, it's, you know, there's two things we're wired for, pain and pleasure. They run through our system, and they drive our behavior, and they have since the Plains of Serengeti, and so, and they will continue to. So I think the thing is, if something is a big, if you identify something, and it's a big enough pain, you will fix it, but you need to work with your product owner to say, hey, this is something we need to have in the backlog. We need to take time to work on this. Now, one of the things you can do is you can start having what are called hip sprints, which are hardening, improvement, and planning sprints. So, you know, if you're on a quarter system, the last sprint of every quarter is a hip sprint, and you work on hardening, improving, and for that sprint, the backlog is owned by the team. The product owner doesn't own the backlog there. They cannot, no customer value delivered, or no direct customer value delivered. Our product owner hate this, which he hears this. But you do that, and you make it happen. But here's the reality. If something is not a big enough pain that you're going to move on it, then just throw it away. There are bugs you will never fix. Close them, won't fix. Be honest about it. If you're not going to do something about it, be honest about it, be clear, be explicit. Bug closed, won't fix. Why? Because the customer is an idiot. There are bugs that deserve to be dealt with that way. Now, I would argue very few, but there are. Or this customer is not important to us. You know? Because if they were, you'd fix it. It's the reality. We all make trade-offs. We all make decisions. Let's just be explicit about them. There's nothing that a customer hates. I'll tell you, having been on the other side, there's nothing I hate. We'll get to it someday, and someday never happens. Tell me up front. Because then I can go, you know what? I really don't want to use your product anymore, if you're not going to fix this. Or, okay, I guess I can work around that. Those are all the ways we can do it. But again, you want to build this backlog of, hey, here's the things we want to do. Here's the things we want to improve. Here's the things we want to stop doing. The classic start, stop, continue. Start, stop, continue. Ask yourselves that. Make that happen. Is that an answer? Actually, I'm referring more specifically to cases such as food, ingredients, stuff. I like factors in the fridge, things like that, for those who bought. Eventually, some of it is, I still don't know why I'm keeping them there. Well, no, no, you put together and you said, hey, we like to have sweets around. Okay, so maybe as a team, you decide you have a candy jar. Okay? But then, you don't pull these along forever. Some of it might just be, hey, we just had a really, there were just some, but I think you really should be focusing on, what are behaviors we want to continue to make this a better team? What are behaviors we want to end? And what are things that we can do, behaviors we can adapt, processes, patterns, et cetera, that will make our lives easier? I mean, some teams talk about, and I kind of did it here where, I talked about, oh, this is a smiley face. People are many happy, made me sad. At the end of the day, whether we're happy or sad is not important. It's whether we were effective and at the end of the day, I just want to be on a winning team. I mean, that's the reality. Now, being on a winning team takes care of so much. It does. It really does. I mean, I remember how hard we worked on the Power Macintosh team at Apple to get the Power Macintosh, the PowerPC migration of the Macintosh app. It was killer, but we were a winning team. We were successful. We did something the world didn't think you could do and we delivered it. Hey, that was great, even though it was a bitch. Okay, so we're going to talk about some advanced topics right now. Really just two advanced topics that I want to talk to you about. First, when good sprints go bad. There are times when your sprint constraints get blown out of the water that you basically realize that the path you were going down was the wrong path and that takes courage to admit. There are times when you realize that the sprint goal, all the information we've gathered, the sprint goal no longer makes sense. Now, what are the rules constraints of the sprint? You can't change the sprint goal. So, what do you do in that case? Well, in that case, you terminate and replan. You terminate and replan. Again, be explicit. Okay, say, okay, yeah. The plan we were pursuing doesn't make sense. This is not the plan we should be going on. Let's just stop and replan. Let's rework it. Yes? So, what happened to the branch? What? What happened to the branch reached which was being worked on? You need it? Okay, so, I give you a scenario. We were working on a branch and then... Well, first off, that was probably your mistake right there. No, but we couldn't have... No, you were giving the branch rather than committing to master, but that's okay. Oh, okay. So, we were working on a branch and then M.A.S. announced something and we cannot do it anymore. Right. So, would you throw the branch away? Yeah. Oh, wow. It's waste. Yeah, it's waste. Or you can go selectively merge the commit. This is why if you're working against master, you know, your stuff's already there. Okay? If you've got a system where... And, you know, this is not easy. Not everybody has this. But if you are working against master and your things are behind a feature flag and then later you could just pull out the stuff that doesn't matter. But by and large, if you decide that you're going to terminate because you're not going down that path anymore, that code is irrelevant. Be honest. I know. But it's like taking a draft of an article and saying, this is crap. I'm just getting rid of it. Okay? The whole approach on this article is wrong. Okay? I have to restart. Okay? Now, it's not something done lightly, but there are times when it is the right action. Now, usually it won't be your whole thing. Okay? It might just be a piece of what you were doing in your sprint goals. But still, when you basically say, we fundamentally changed the focus of this sprint, terminate and replant. Okay? All you're saying is we've got new information and we're acting on that information. To move things forward and to be effective. We're being explicit about that fact. Because how many times have you been on a project in a team that they knew that where they were going was the wrong way? And they didn't say that they were going to change direction, but they changed direction. And then one day someone would say, well, where's the XYZ? It's like, oh, yeah, we kind of decided that that wasn't important. It's like, but we didn't have a discussion about it. I didn't know that's what you're doing. You know, be explicit. Call it out. Okay? And that requires a level of courage. It does. I'm not saying that it doesn't. I'm not saying that it's easy. You know? But it is often the best thing to do. And this is a terminated replant. You know, if you do one or two of these a year, that's probably the right frequency. One or two of these a year. And I've seen teams that have gone literally just because things have just been really well aligned. They've gone years without having to do this. And I have seen teams that were like doing this every couple of months because there was just so much uncertainty in what they were doing and the problems they were tackling, the problems they were working to solve. But again, manage it, okay? Any questions? Any other questions? Yes? Actually, no question making. Are you referring to specifically like where we do team changes or custom team kind of changes? For mine, we also do team changes. Because sometimes, even for me, it's really just too bad. Yeah. So I was actually thinking about if it actually can work, then I want to keep it. So then, but then... But what? Eventually, when I, I think the problem is eventually when I revisit the branch, I forget everything of like, Well, that's why you don't want to stay on the branch. Yeah. Long live branches are evil. I mean, I think that by and large, branches should not exist more than a few days. I have a problem with branches that exist for a sprint, okay? You know, if it's not in your master, if it's not in trunk, if it's not, you know, along that axis, it will be forgotten. And here's the thing. You said, oh, but it works. Yes, it works. But what's the value of it? Okay. I have a number of things in my apartment that work that I'm going to be carouseling. So, you know, carousel the code, okay? Get rid of it. You know, go read Marine condo and get rid of that, that code, okay? You know, that's, I mean, if, you know, just because something works, just because we've put time and effort into it, doesn't mean that it's customer value. It doesn't mean we should keep it around. And the fact is, is I can make the argument that by you putting code that's not being used into things and keeping it around, you're actually increasing the complexity of the system unnecessarily and probably introducing bugs through side effect. Okay? You want to keep it, but we just don't get the number of other things. So, but you're just going to be in there. Is this going to happen? It's going to be worse. Yeah. Yeah, but at least get rid of it. Just get noise in the bin. Yeah, it's noise. And branches are noise. I mean, if that branch stays around for six months, there's something they're going to go, what the f- is this branch? Who made this branch? And you won't even remember that it was you. And then what's going to happen is six months from now, someone's going to say, fine, let's kill this branch. Rip it out of the repo. So, you know, pull the Band-Aid off sooner rather than later. Other questions? So do your sprints get interrupted? Then maybe Scrum isn't the right model for you. Okay? Maybe it isn't. There are other empirical, there are other empirical processes for software development other than Scrum. So we don't want to throw away empirical. But what we may want to do, or if you're operational, are you an operational team? Operational teams don't control their destiny. They're event, they're interrupt driven. Okay? If you're an SRE team, you don't control your destiny. You know, it's whatever turns up that day. So how do you manage that? Well, there's a system that has many, many of the aspects of Scrum. It's called Kanban. And in Kanban, what you do is you have a backlog. You do many of the things that you do in Scrum of maintaining that backlog and managing it. But you don't break things into sprints. You literally go day by day. You may even go hour by hour. And what you do is you manage what's, you maintain what's called a whip limit, work in progress limit. And the whip limit, you know, depending on how your team is structured, could be as much as one thing per person on the team. Or as little as maybe the team size divided by two. Because you have people pairing on things. Okay? So that's kind of your bounds. You know, N, where N is the size of team to N over two, where that's the size that, you know, half the team size. And you maintain that limit. And you literally, so you still have a stand-up. What you do is you come in beginning, because some, quite often, Kanban teams are part of like 24-7 teams. It's come in, beginning of shift, beginning of the day for you. And you say, hey, what's the top priorities? You still have a product owner. You still have somebody who's mediating that traffic. And he says, oh, we've got an outage in zone seven. Well, guess what? That's the most important thing. It goes to the top of the backlog. It gets put to work in progress. We have a disk about to die on this box. Well, that's boom. Put it there. What this allows you to do is deal with interrupts, okay, while still maintaining a path forward. Okay? Because the reality is, and here's the other thing is, I would also recommend that you seriously consider, using Kanban, whenever you've shipped a major feature. So let's say you've been heads down for eight sprints. You've been moving out potentially shippable customer value. And now marketing has said, yes, we want to bring it together. We want to get it out there. We want to make the intro. Like what we just did with bumps, okay? It's all together. All the pieces are together. Well, you know that once that meets the customer, no feature survives contact with the customer. Kind of like no plan survives contact with the enemy. It's going to kind of, you know, there's going to be things that you're going to discover. You're going to need to do. Don't kid yourself that you're going to, oh, we're going to walk into and plan another sprint and do it. Just be upfront. Again, be explicit, be upfront. Say this sprint will be Kanban. We will deal with this stuff as it comes in. Okay? Yeah, we have stories here. And you know, if we have time, we'll start moving on those stories, but we may have more things that come through. That, what it does is it lets you have a much, much more fluid backlog, a much more responsive backlog at the cost of focusing on long-term goals. Okay? But that's okay for certain situations. That is the right thing in certain situations. So use the right tool for the situation you're in. Sometimes that tool is Kanban. I'd say that probably the split of how I would do it is 80% scrum, 20% Kanban in terms of teams, but that's okay. At least have a structured process that acknowledges the empirical nature of software development and work with it. Okay? And always remember, what do we remember everyone? Inspect. Yes. Run that cycle. Always run that cycle. That's what you want to be doing. Okay? Do you see how everything in scrum goes back to this? Everything in scrum goes back to this. Inspect, adapt. It's the reality. It's the core. So roll with it. Okay? So questions. Last, last of this series, we're going to take a break next week and then we'll be announcing another series. Probably another multi-parter and kicking it off. Something we want to continue doing here at Carousel. But any questions? Is it only for software that we can use? No. Anything that has an empirical nature. I was talking with someone today that was this people like executive, what some people call HR, at a software startup. Just have your recent Kanban in America to all of our tasks there. So everything from, oh, we've got to get somebody on board it to get me to give out employment contract out to someone that, oh, there's a problem with some of those benefits. They're using that. It's completely, I mean, it is a way of organizing. I know someone who scrummed their wedding. They built a backlog for their wedding. They had sprint goals. Though I remember when she was doing the sprint goal, the sprint goal was have a wonderful reception. That was the sprint goal. All the things in there were like, get the caterer signed up, select the cake, order the cake, all that stuff that she put together. I was like, she scrummed her wedding. She had, I think she did it over, she did monthly sprints just because that was what worked for her. She and her fiance had stand-ups every day. Where they discussed what was coming and what they needed to do. She even, I remember her once saying, yes, I have an impediment. He can't make up his mind what he's going to wear. I can't pick my dress because he won't decide on what colors he wants. It's like, okay. But yes, you can. You can use it. I mean, think about, it's about organizing work. I mean, where you're not going to do, this is not going to work. Is if something is a defined process. That's where it doesn't work. But that's not what it's for. It's for empirical processes. But it turns out that a lot of what we do, I would argue that unless it's being done by a machine, or should be done by a machine, it's an empirical process. You wouldn't organize the workflow at Starbucks with scrum. Down here at the local Starbucks. I'm not talking about product development, you know, that kind of stuff. You wouldn't do that. But designing an ad campaign, marketing campaign, yeah, all of that. Perfect. It works. So yeah, it's not just about software. You will hear it quite often. It's agile project management with scrum. Those projects, we know that software is, that is an empirical process. We know that from what we've learned. But there's a lot of other things that are empirical processes, and we should work with them. Great question. Fantastic work. Thank you. Did I pay you for that? Any other questions? Or am I going to, people are all going to come and ask me questions afterwards and they're going to have to go ask them in front of other people. I've been doing talks since I was four long and I have to learn the third couple. One thing on that whole topic, before I take your questions in. Again and again, when people have done that, I'm like, why didn't you ask that question in front of everybody? Because all these people would have benefited from the answer. Okay? So I encourage you to, you know, even if you're a little shy or it seems like, oh, maybe it's a stupid question. The minute number of questions that were like, why did you ask that in front of a bunch of people? Versus the questions that, you know, everybody else would have really benefited from hearing that question. It's so out of proportion that, you know, your payout ratio is incredible. You know, and you know what, people are just going to appreciate that you asked a question, even if it was kind of like, huh? So I encourage you because 99.9% of the time, other people are the same things in their mind and they will benefit. And it may spark them to ask a question. So you have a question? No, they did not. I'm sorry. Your first opinions are generally shy about asking questions in front of the camera. For me, for me, I'm running this data collection. So we are automating website testing and what we increasingly find right is we somehow end up being entering the role of, yeah, this is how you set up agile and scrum in your company. And it's actually kind of a big struggle because some of these companies are really old fashion methodology and you're trying to migrate over to a new methodology and it gets even harder if all I have is Skype and email. So how can we get them on board in slower chunks? So I think what you do, I mean, yeah, the ideal thing would be that you could put them through like eight hours of training. You're not going to get that. They're not going to pay for it. They're not going to do it. So you just tell them, this is how we work. We break the work up into sprints. You don't even have to explain. And, hey, we did this thing called a backlog. It's just a to-do list. But it's a to-list organized in priority order. And this is what we have. Would you add to this? Would you subtract? Okay, let's talk about the first thing. So help us understand what you really want here. And what will it mean for this to be done? What does it take for you to say this is good and to sign off? What are the sign off criteria? Okay, and just do that. Just apply it with them. Hey, let's have a daily touch base so we can review what's moving along. But the thing is always ask yourself, do you need to expose your process to them? Or is it just, hey, this is how we organize the work. We're going to do it. You don't have to buy into this. It's just this is how we manage our work. I'm hoping that when you do this, you're negotiating outcome-based contracts, not things that mandate the process. As long as you deliver the output, they'll be happy. Now, if they ask you, hey, how come you guys are so organized? How much did you get so much stuff done? How can you go, hey, well, we use this thing called scrum. But at the end of the day, they're interested in results. The thing is, it's harder to adapt a waterfall traditional enterprise model into scrum. It's easier for people who are doing scrum to interface with that traditional waterfall because you're like, hey, here's our quantum work that you wanted. This was the milestone, milestone A. This is how we organized it. We are actually trying to merge waterfall with scrum because the way we work, we can't fill our platform. Whatever we put up, it cannot fill. And it must scale also. So you've just set yourself up to hit both of those criteria? Why? If you go back and read the original waterfall paper, the original waterfall paper basically says that essentially the waterfall is appropriate for toy projects. Now, if you're saying that you need to be able to verify high quality in your system and you need to have high scalability, well, that's part of your definition of done. Figure out how you're going to verify that. Because you're going to have to do that. Whether if you're following waterfall, you're still going to have to verify that. Build the tests, build the frameworks to verify that. Verification's OK. Testing's OK. These are all legitimate things. But I've seen people talk about merging. You're talking about taking, you're talking about crossing a elephant with a blue whale. It's not going to happen. They're totally different environments, totally adapted for different things. They are literally, you're talking about taking defined process because that's what waterfall is. It's defined process, which literally is saying that the nature of software is not what it is. And you're taking empirical and trying to put them together. But if you want to talk about how do you apply Scrum, how do you apply Scrum in an environment where you have to have high availability, highly available and highly performant, HAHP, classic edge. RobinMQ was built using Scrum. HAHP. Do you think that Google has, says, oh, we can fail? No. It doesn't happen? Yes. So I'm assuming you're in some kind of regulated market, maybe securities, medical, something like that. I've applied Scrum to these. But what you have to do is you have to say, what is the acceptance criteria? What is done mean? So done may mean that you've run a test where you've basically teed traffic, production traffic, and run it against your text instance in parallel for three weeks. That's fine. That's okay. That's still Scrum. You may say that we must have, I would disagree with you, but you might say we must have 100% code coverage at the unit and functional level. Now I would probably argue that you're actually, that that's not worth it, but maybe that's where you come to. It's hard for me to say this sometimes, but it's like sometimes, no, please don't write that test. You're actually making things worse by writing that test. I saw someone write a test once for an accessor, and I'm like, what? Well, I need to mock this. I'm like, you're mocking an accessor. Excuse me, this is ludicrous, but they wanted 100% code coverage. It was a mistake, but they did it. But you can come up with what though, you'll figure out what does definition of done mean. Perhaps what you say is, we teach traffic for five trading sessions, for trade traffic, and every anomaly is investigated and resolved. So you understand what I'm saying. You teach the traffic, you see if something happens, if something anomalous to your production environment happens in your experiment environment, then you're like, okay, we have to resolve that. And you resolve all of this. You might say, hey, and frankly, if you're teaching production traffic between environments, then you're probably, you're covering your HA, your HP, you're dealing with anomalies. So you've got a really good environment there. You validated and do this. Google doesn't use waterfall, it doesn't. Ericsson has used scrum or a variant of scrum on telephone switches, which is one of the reasons they have Erlang. I know, Erlang's, I mean, I don't know if you know, but you can actually run multiple Erlang instance versions of an application in parallel, hot execution. Because that's what you have to do with a telephone switch. You can't, oh yeah, we're going to update the telephone switch. Not in the way they do telephone switches. It has to always be, so you put the new version of the software in and then you drain the traffic. They have one, they have one switch that's been running nonstop for 20 years. Great stuff. Just make sure you're buying, you're taking the right tool and you're applying the right tool. You're also probably going to want to look at, I'm guessing for your kind of needs, you probably want something that has a single binary deployment that doesn't have dependencies on external packages unless they're compiled and packaged together with it. Something like Go, Go makes a lot of sense here. You're probably not going to want to use Ruby with gems. Okay, just to meet your needs. But you can sit down and you can say, again, there's nothing about this that says, oh, but this won't give you HA. This won't give you high availability. This won't give you high performance. There's nothing here that says that. In fact, I will argue that this gets you there faster. Okay, now, sometimes people confuse, you know, scrum with, oh, move fast and break things. That's a different, that's a whole different methodology. Now, but here's the thing. If time to detection, if time to repair is zero and time to detection, does it matter, does it matter how many bugs you have? If time to repair, meantime to repair is zero. Does it matter how many bugs you have? No, it doesn't. So, I mean, even CD, continuous delivery, is not a theoretical, the high availability, high performance systems. You just need to make sure you have all the right, you have all the right gates in place. Okay, that your, that your red-green is solid, that you can trust it. Okay, you know. Now, will I agree with you? There are people out there that use the excuse of we're using scrum or we're agile to be, to be, excuse me, but effing lazy, yes. Okay? But there's no reason. If you know what your requirements are, then you set the bar there and you make sure you meet them. Everything you need, you will do would be the same thing you do in a quote, waterfall model. So, if you want to have that conversation in more depth where you like, help me understand the system and everything, we can have that. Okay? We can make a time for dinner or coffee and do that. Cool. Other things? Other questions? Cecilia, you're not going to have any questions for me tonight? You're always good. Yes. Can you share more about how you would deal with spikes? How would I deal with spikes? How would I deal with spikes? So, the spike is a concept in scrum. And it's right, I didn't put it here in advance, because I'm sorry. Should have been. I'll make a note of that in the revision. A spike is a tool for gaining knowledge. Okay? There are things that going into a sprint, you know you don't know the answers. That you can't build the customer value. It might be a question as fundamental. Are we going to use Postgres or MySQL? It might be a question like that. So, would you step back and you say, okay, the task here is to evaluate what is the outcome here? A decision on whether we're going to use Postgres or MySQL. Okay? That's it. So, what's the acceptance criteria? How are you going to measure that? Define that. And then measure it. And the outcome is a decision. That's one way that a spike is used. Another way is just knowledge, being informed. Understand the relative differences between MongoDB and Cassandra in our problem domain. Understand the price performance characteristics of GCP, Google Cloud Platform versus Azure versus AWS. These are all legitimate spikes. But what you need to do is put together a set of acceptance criteria, which is really, how are you going to make your decision? And who's going to make the decision? Is it Stephanie that makes the decision? Is it Andy that makes the decision? You know, somebody else? Who's going to make the decision? And on what criteria are they going to make it? Okay? That's what you want to do. I mean, ideally it's so, you've nailed down the criteria that really the decision makes itself. Okay? But in life such things are rare. Okay? Does that make sense? So, where are you looking at using spikes? I'm curious, we had a lot of difficulty trying to know how, is this really like mapping? Okay, it was a healthcare scenario. So, like, we want to know how lab partners can be met into our system. So, we have to look into the integration process as well. Right. So, that's something that we spent a lot of sprints trying to understand that, but it was still a lot of issues. Yeah. Because I don't know, maybe at that point we should have done something similar to figure out. I think, yeah. So, I think the thing is if you don't have a sense of things, it's hard to build it, you know? So, that's where gaining that knowledge can be really, really helpful. Okay? So, yeah, do that. Step back and look at it that way. Mm-hmm. That, it's a great tool. It's a very, very helpful tool, Stephanie. So, and it's because the thing is, if you say, oh, this is a story, it's, well, then what's the outcome of that potentially shippable customer value? But here, this is not what we're going for. Again, it's this whole B explicit thing. And how do you drive it from there? Other questions? Well then, I think we're going to call it a night, everyone. Thank you for coming. As I said, last in this series of our Scrum Dementals, we're going to be probably kicking off another series, not next week, but two weeks from now. If you have ideas, feel free to email me, but I'm working on some stuff and laying out some plans for what the kind of the delivery path would look for. But we'll be doing that. If you have any questions, feel free to email me. It's Jordan. So, J-O-R-D-A-N at thecarousel.com, not carousel.com. In addition, if you've liked it, let us know. We'd appreciate that. In addition, carousel is hiring. If you'd like to work in an environment that's striving to put these principles into practice every day, and failing quite often, we'd love to talk to you about it. Okay? Thank you, and have a good evening. And a good national holiday.