 Scrum. It's going to be about an hour, going to take questions at the end, but if you have a question, and I'm going to work to pause at pretty much every slide, pump your hand up, you can talk, and I'll take that. So, love it to be interactive, but we will also have a Q&A at the end, okay? So, as I said, Scrum Foundations. This is part one of that series. There's going to be four parts to it. Later parts are actually going to be, have some interactive kind of almost team activities that we'll be having. And we can take advantage of the carousel facility here to do that. My name is Jordan D. Matson. I'm the VP of Engineering here at Carousel. I come to Carousel after working in Silicon Valley for a number of years. My claim to fame is I wrote the first line of code I wrote and was paid for before basically anybody at Carousel was born in the engineering department. So that's my claim to fame there. So it was in 1981. So, we'll talk about, and no, I wasn't a child prodigy. I was actually 18 at the time. So, principles and elements of Scrum. I'm going to start off. So, one of the things I think is very important is to talk about first principles. Otherwise, we're just doing something that we don't understand. And a process you don't understand in engineering has a term called Carboculp Engineering. This is a nod to a talk that Richard Feynman, who you may have heard of, very famous physicist, gave as a valet Victorian address at, excuse me, a commencement address at Caltech many years ago. It was called Carboculp Science. Papers reference here, you can look it up. But basically, what this is in reference to is post World War II. If you went to Papua New Guinea or Irian Jive, you people know where that is, both of those. You would find places where the local inhabitants had built airstrips. They built it, they had cleared the ground, built an airstrip, put up control towers, built replicas of the planes out of local materials. Why did they do this? Because during World War II, those air bases existed. Okay? What's going on here? No problem. Okay, those air bases had existed and there were cornucopia. Lots of wealth came, things were much better. And people were like, hey, you know, what if we make those air bases again, maybe all the goodies will appear and come again? And this term has been called, come to apply, be called Carboculp Science or Carboculp Engineering. Which is where you do something, you go through the motions without understanding underlying principles and why the thing works or doesn't. And you can see this in terms of engineering practices. The most famous version of Carboculp Engineering is, well, just restarting it. Okay? I don't know what's going on, but just restart it. That always seems to fix things. Or have you ever been on the tech support line and they said, well, I need you to reinstall your operating system. What does that have to do with the fact that your DHCP server is not returning an IAP address to me? Well, just reinstall your operating system. I mean, I got to the point where when I was dealing with a lot of these people, I'd like, oh, yeah, yeah, let me, you know, I don't wait for 10 minutes. Yeah, I've done it because it was not worth it arguing with them. Okay? So I think it's to avoid doing this, to avoid Carboculp Engineering. I think it's really important that we go to first principles. We understand why we're doing what we're doing. Agile manifesto. Agile is great. Agile does a lot of things. Agile has a lot of values that are great. And I remember when the Agile manifesto was first published, I was reading it and going, yeah, this is what I'm trying to do, you know, to, you know, that people were more important than process, that software was better, you know, that the FEST documentation was working software, that, you know, working with customers and really getting into their minds was really much better than kind of a very ironclad, defined contract. And that sometimes it's really important that you respond to change and that you not just be following a plan. Okay? And sometimes following a plan could lead you right off a cliff because circumstances have changed. Agile is great. So Agile is a good thing. I recommend you read the Agile manifesto, write a lot of the stuff around Agile. But it's good, but it's distinct from scrum. It's separate and you need to understand both. There are analogies out there. People may have heard of XP. You may have heard of crystal, et cetera. These are all Agile methodologies that are good, that are helpful. But again, Agile isn't scrum. And Agile to itself is not sufficient. So I said it isn't scrum. It is a very important distinction. It's the distinction between defined process versus empirical process. Now what do I mean about defined process? What do I mean about empirical process? So a defined process, Hey Mickey, could I ask you to go in advance for me please? Why we get a battery change? I think it's just a handle. This is how I'm handling it? Yes. Okay, it's just me. Okay. So here's the distinction. The distinction between defined versus empirical process. Defined process. This is the way you build a car. This is the way that you manufacture a pharmaceutical. These are defined processes. You have a well-defined set of steps. If you give it the same inputs, you run it through this defined, the same process. You should get the same output every time within variances. This is what the Toyota production system was all about, which was one of the biggest, biggest accomplishment of the last century. Okay? Toyota production system, lean manufacturing, all this, is all around defined process. Very, very powerful about how software is built. Software is one, you don't always have the same set of inputs. It's every time you're building software, it's a different set of inputs. And the process of creation is different. The process of software creation is different between things. It's not like manufacturing a car. It is not like manufacturing a pharmaceutical. But it's more like discovering a pharmaceutical or designing a car. It's an empirical process. It's a process that involves experimentation and technically defined. It exercises control through frequent inspection and adaption for things that are imperfectly defined and generate unpredictable and unrepeable results. I don't know about you, but that describes every software project I've ever been on. I mean, even the ones when I was in school matched this definition. Anything that's beyond a toy program. Anything that is beyond a hacker rank or top coder exercise. And many of them fall into this thing. So it's about experimentation. It's about collecting data. And the key thing about Scrum is stepping back and saying... I was actually going the other way down. No problem. It's actually admitting that it's not a defined process. That it is not a defined process that we're dealing with. But an empirical process. To paraphrase, know the truth and the truth will set you free. That's what we're going with here. It's knowing the truth that it's not a defined process. It's an empirical process. Any questions at this point? Come on, please, it's a soft one. Okay, no problem. Good empirical process. Well think about any time you've done a scientific experiment. What do you do? You frame a hypothesis. You design an experiment for it. Okay? And what's important is that there be transparency. That you can actually examine what's happening in the experiment at any time. That you can look at the state of the system and understand it. So that's the first thing. Is that you can do that. It's possible to look at the system. Next is about inspection. And then finally about adoption. So transparency here and open to all of those who are responsible for the outcome. If you're a part of the project, you should be able to have the access to the data to understand the state of the project. That's key to an empirical process. What does that imply? It means that you have to have a common language. It means that you have to have common standards so that you have a shared understanding. Okay? It means that you're using the same units of measurement that those units of measurements make sense. You know, if we're talking about something in a particle accelerator experiment and I express things in MPH and you do it in KPH, the answers aren't going to make sense. Okay? We're not going to be able to talk. We'll be talking past each other. And this is one of the things that happens in a lot of software projects. Is people are talking past each other because they're using different language. And this is one of the reasons that some of us can be real language Nazis and say, no, don't use that term. That term doesn't make sense. Okay? And it's where it's really important as a team that you have a consensus on language but also on the common standards that you're using. And we'll talk about some more about that in a little while. Okay? Inspection. So, transparency. You can see what's going on in the system. Now, what you need to do is you need to inspect it. You need to inspect it frequently. This is about the length of your feedback loops. Okay? You need to inspect it and inspect your progress. We're going to talk about it later but this is why you have daily stand-ups. This is why you have split planning meetings. This is why you have split reviews. This is why you have retrospectives. It is because you need to inspect your artifacts and figure out what your progress is toward what you're trying to do and to detect any places where you're buried which are at odds with what you're doing. So, I once worked with a team that was adopting Scrum or said they were. And they said, you know, but those stand-ups, they're just too much overhead. So we're just going to do it once a week. They just cut the legs out from under themselves. And they wondered why things didn't change. They're only touching base once a week. Things were still not getting addressed. They weren't getting feedback. They didn't know if they were making progress. So, this is where some of the things about understanding the foundations of Scrum, the principles behind it, first principles, is important to you so that you don't do things like, we're going to do stand-ups once a week. Okay? Or nobody has to attend stand-ups. They're not important, you know? But we're not going to do retrospectives. I've heard teams do all of these things. Yes, you can adapt Scrum, and you should adapt it to your environment and to your work style. But that doesn't mean that you give up on things that are rooted in the first principles. Okay? And later, later session, we will talk about how do you adapt Scrum, how do you work with it to meet your needs. The other thing, oh, excuse me. Sorry. Is, notice this term. So, this is all out of the Scrum book by Shwever. Diligently perform skilled inspectors at the point of work. This here, one of the biggest reasons why I have a problem with distributed teams. Because people aren't in the same place. They can't get together, and they can't do that diligent inspection at the point of work. And finally, you've got transparency, you can look into the system. Then you inspect the system. And finally, you adapt based on what you see. You modify your behavior. You run an experiment, you figure out that something needs to be changed, and you change it. Again and again and again. Anytime one of your processes deviating outside of the acceptable limits. And in this case, that acceptable limit is usually quality or time to completion. But it could be things like run time complexity. It could be, you know, that you're making a poor time space trade off in terms of your system. Could be the cost of running it. Okay? These are all things that you need to think about in terms of acceptable limits. So that you know whether it will be unacceptable or not what you're doing. And then, if you figure out that you're outside of that window, that envelope, you adjust. Okay? Now, here's a key thing. And again, this goes back to why do you want to have a daily stand up? Why do you want to have small, white-sized sprints? Because the adjustment must be made as soon as possible if you're going to deal with the deviation. I worked on a project at Apple called Mac OS 7. Mac OS 7 was a version of Mac OS well before Mac OS 10 that was done in, started in the late 80s and shipped in the early 90s. Okay? So, now this was supposed to be an 18-month project. It ran out to several x-stats. Okay? It was supposed to be a very small, compact type team. It grew to be hundreds and hundreds of people. Okay? In terms of the project. What was one of the problems? Well, the problem was, people would come into a status meeting once a week. And someone would say, yeah, we didn't get the x that we needed. We're blocked. You come back the next week and they'd say, yeah, we still haven't got an x, we're still blocked. Okay? What were they doing there? They were raising impediment. Kind of standard, scrum or stand-up, 101 type of stuff. But the delay in that getting addressed was so if I walked out of that meeting and found out there was a problem blocking it, it was going to be seven days until I could get it in front of someone to deal with it. Whereas if you have a daily stand-up, I walk out of the daily stand-up, I encounter a problem. And 23 hours later, I've got someone looking at it. Tighter feedback groups. Adjustment must be as soon as possible. As soon as possible. So why do you have very, you know, why do you have daily stand-ups? You have them so that you can find those problems as soon as possible and adjust them. Think about it. You're building a system. Oh, I haven't been able to get allocated the servers I need. So-and-so has not given me the keys, the key I need to provision in AWS. Oh, I don't have the Google Cloud credentials I need to make this happen. You know? These are all examples. Oh, no one is giving me access to the-to the-to our Apple account so that I can get the SDK so I can build for iOS 11. All of these are things that you will hear in a stand-up. Okay? So it's about that adapting and adapting quicker. Any questions? So, going back, it's about transparency. It's about inspection. It's about adaption. Transparency. Is it visible? Why is it a good idea to post a burn-down chart? Because it helps you visualize how you are or not tracking to what you need to do to make that spring go well. Okay? Transparency. Inspection. Why is it good to have a daily stand-up? Because you need to inspect frequently. You need to be looking at the system. Okay? It reminds me of when I was in uni I lived in a dorm as a freshman with a whole bunch of grad students, people doing their PhDs and there were a bunch of them who were bio PhDs. Okay? And remember, these people would get up in the middle of the night to go check their cultures. You know? They'd either stay up really late or they'd set an alarm, get up at four in the morning, walk over, check their cultures, come back, crash, you know? And then go back at noon because they needed to inspect frequently to see any deviations, to see if things had moved across. So that frequent inspection. And then, adaption, final step is you've got to do something with the data. You just sit there and look at it. If day after day you're raising an impediment and no one gives you those credentials for Google Cloud. It doesn't matter. So transparency, inspection, adaption. Key of an empirical process. These are the key of an empirical process. Thanks. So, let's talk about the elements of Scrum. You can go. Advancing. So this is the Bible of Scrum. This is the very famous book. Ken Schweber, agile software development with Scrum. Also known as the red, yellow, green, blue book. Which is the ideas you're supposed to, you know, when you save it, when you look at this and I ask you to say what the color is, what do you, read it to me, what do you say, or tell me what color it is, you get mixed up. And it's about perception and perceptional things like that. This is the Bible. Now there's a short guide available, basically a condensation of probably what you consider the introduction, which is a very, very powerful document to read. Recommended, highly. But this book, this is it. If you get one book about Scrum, get this one. There are a lot of other good ones out there that are good compliments, but this is the good one. Now one of the anecdotes in this book is about when Schweber went and met with the process engineers, the process scientists at DuPont. DuPont, you know, the big chemical company. These people were at the center of the creation of process engineering and studying process and understanding process. So he had a meeting with them and they were in the meeting and these guys knew nothing about software. They knew nothing about software. But started asking them questions about the kind of problems, the kind of issues they had. But mm, okay, mm, okay. And then they started telling him the kind of things that he was seeing. He said, hold it, you guys don't know anything about software development. How are you coming up with these things? He said, well, it's clear. You're running this like it's a defined process, but it's not. It's an empirical process. And this is what you would expect if you tried to drive an empirical process using defined process. Now this was at the time when a lot of things were coming out in terms of early software engineering, waterfall development, a lot of the work that Harper in the U.S. found it, a lot of the work that was done at CMEU and the Software Engineering Institute. And very powerful things were being learned. Things that we've come to learn and how to apply and work with in some great ways. But what they kept coming back to was, oh, this must be some variant of defined process. If we define it better, it'll work better. We'll just figure out that process, we'll put the inputs and we'll get a predictable output. Trouble is, is that's not what you were dealing with. And the guys at DuPont understood this. Like that. Because they studied the process again and again and again. And as someone said to me once, there's three types of process. There's defined process, there's empirical process, and there's no process. Which are all types of process. So what is scrum? So first rate, scrum is lightweight. Scrum is designed to be as lightweight as possible and still do the job. Now, this really starts to make sense when you start applying also the principles of CMEU, which we're not going to get into to this. Because anything that doesn't contribute to code that's used by users, nothing, anything that's not aligned to code is waste. You might call it overhead, but it's waste. So you want to make that as lightweight as possible. You want to have as low overhead on the process as you do. It's also actually, it's incredibly simple to understand. I remember explaining scrum to my daughter when she was nine years old. She went, oh daddy, that makes a lot of sense. And we kind of played with it and applied it to something she was doing. Which is also a thing. Scrum is not just about software engineering. It's not just about delivering software. It is a way to organize work, to do projects where there is uncertainty. And guess what? When you look at the world we're in and the business that we work in, doesn't matter what field you're in, there's uncertainty. Things are not well defined. And we need to cope with that. But here's the key thing. It's difficult to master. It's like a kata in karate. It's a very simple move. It looks very simple. But there are people who literally spend decades mastering those. Those very simple, simple moves in karate. Because it's difficult to master, but it's simple to understand. And that's why it's about discipline. If you're not disciplined in the approach to scrum, it's not going to be successful. And I've seen this again, teams which start out, they get some actual impressive improvements. And they go, that's great. And then they just call it fall back into what they were doing. And it tanks. Okay? So, lightweight, simple to understand. My nine-year-old daughter could get it. But difficult to master. Now the scrum team. The scrum team is one of the first elements, one of the first components. And it's key. It's kind of like in soccer, the laws of the game. You know, what do you have to have? You have to have a team. You have to have a referee. You have half a ball. That's all you need to have to have a soccer match. Okay? Team referee ball. So what do you need to have a scrum team? Well, first, you need a product owner. What is the role of the product owner? The product owner is to decide what's in and what's out. The person that makes the decision. Quite often, it's more important you make a decision now than you make the best decision. As someone said the other day to me, I guess he was quoting something from Chinese, 6677 is better than 7788, which is 60 to 70% on target. Now is better than 70 to 80% later. A decision now that allows the team to move forward, even if it's not the best decision, is better, is good. That's why you have a product owner. The other person who says, yes, this is more important than this. This is what we're prioritizing. A good product owner is worth their weight in gold. A good product owner is worth their weight in gold. And should not be something that you underestimate the importance of. What's next? The development team. The development team. The team of people that have come together to do this work. Now that's the key thing. If you look at scrubbing, you look at what you need in an effective development team. Is it all resources? You don't go and put things off into buckets. You don't say oh well it's just the people who write the software, the software engineers. No, it's the product manager. It's the product designer. It's the world we live in now. It's the data analyst. Who's going to think about the data you need to be collecting and how you're going to analyze it. It's a software engineer. But it's not, it's your back end engineers. It's your front end engineers. It's your full stack engineer. You need everybody in there. Your mobile engineers. If you go and have a centralized team that you go out to, you've just created a dependency, and this team is no longer in control of its destiny. If you must have dependencies between scrum teams, they have to be between sprints. They cannot be within sprints. They have to be at a boundary of a sprint. Do not. This is the way to fail. Is to say here's two teams, and oh you're going to deliver something to us in the middle of a sprint. Well because this development team gets to decide how it's tackling the work. And yes this may be the priority, and we're going to work to deliver this priority. But it may turn out that that fifth item you have on the list is actually a prerequisite to everything else you want. We've got to deliver that. You don't know that. You cannot predict that at the beginning of a sprint. So development teams have got to be fully integrated, have to have all the resources they need to tackle the project. They have to be able to be responsible for their destiny. As I like to say, is you need to empower those teams so that they can be responsible so they can be held accountable. And then finally the Scrum Master. What does the Scrum Master do? The Scrum Master has really two really important roles. One, they facilitate, and they clear impediments. They facilitate the process. They make sure the discipline is maintained. And then they also make sure that impediments are clear. Now notice it doesn't include stakeholders. It doesn't include the CEO of your company. It doesn't include the VP of Engineering. It doesn't include those stakeholders. And there is an analogy or a story that is often used to make clear the difference between the pieces of a Scrum, of who's inside the Scrum team and who's out. And it's a little story about that a chicken and a pig decided to get together to open a restaurant. And the chicken says, hey, let's call it eggs and bacon. And the pig says, no, no, no, no. It needs to be bacon and eggs. And the chicken says, why? Well, because one of us is committed and another one of us, you, is just merely showing up. Okay? Because the pigs in the chicken isn't. So you will sometimes hear, because of this little story, which doesn't make all that much sense and isn't terribly culturally sensitive, that people will refer to, oh, are you a pig or a chicken with respect to a Scrum team? Pig meaning you're an insider, chicken, you're not. And many Scrum teams will enforce a discipline which is pigs can talk, chickens can listen. Chickens cannot say anything during the stand-up. They cannot say anything during the retrospective. They cannot say anything during the split planning. All that stuff has to happen outside of those avenues. So chickens must be quiet, pigs need to talk. So this is an important thing. An important, important thing. Okay. So what's the next element? We've talked about the Sprint team. The Scrum team that's going to make this happen. What's the next element of the Sprint? What's the Sprint? What is a Sprint? A Sprint is a time box period in which you're going to do some amount of work. Simply what it is. You know, traditional people have done two weeks. I've been in one week sprints. It seems it was one week sprints. I've been in ones that did three weeks. Does that give them four to a quarter? Okay. I've been in ones that did four weeks. Okay. It doesn't matter how you do it. I did ones that actually did 28 days. I'm literally four weeks, you know. But not counting the weekends in there. So that is a Sprint. It's just a time period in which you're going to do some amount of work and deliver some customer value. Now, in the Sprint, no changes are allowed that are going to engage in the Sprint goal. The Sprint goal is where you're going. Once you've said, hey, here's the goal. Here's the things that lead to the goal. Actually what it is, is that here's the things that lead to the goal. This is what the goal is. Then you don't make any changes. Nothing that will endanger the Sprint goal. That means that, yes, the VP of marketing just met with a whole bunch of customers and realized what we're building is wrong. Or that there's this really awesome feature that we could build and comes rushing in. Sorry. No. Now, there is a mechanism. We'll talk about that. That's right. Apologies. So there is a mechanism for what's called abnormal termination or cancellation of a Sprint. It's advanced. We'll talk about it later. But it is. The other thing is you do not decrease your quality goals. You do not along the way say, oh, you know what? Yeah, we said that we had to have this level of quality. And quality can be about features that you've delivered. It can be about performance. It can be about memory usage. It's not just about bugs. Oh, but you know, we're going to drop that. It's not that important. Now, that doesn't mean that things are static. Because we said that this is a dynamic process. Yeah. Scope may be clarified or renegotiated. As long as it supports this Sprint goal. So how long does that Sprint goal? Because you are going to learn things along the way. A common tool which we'll talk about is something called a spike. A spike lets you go in and investigate something without having to ship a feature. And that learning, that knowledge, lets you then figure out what the scope may need to be. Okay? It is perfectly fine going back to that whole enough abnormal termination or cancellation of a Sprint to realize that the goal is unreachable. We did not know enough when we planned this and that the goal is unreachable. And the best thing at that point is to cancel, re-plan and re-launch. We had that recently happen with a team here that realized the tool that they were going to use to achieve their goal was not the right tool. So what did they do? They were great. They were an awesome team. They said, we're terminating this Sprint because we've got to re-plan. Plan A is dead. So let's not continue to pursue Plan A. Any questions about the Sprint? Let's talk about the Sprint events, the events that make up a Sprint. That Sprint planning, you've got the date, the daily scrum, aka stand up. Does everybody know where the term scrum comes from? Football. Not football. Rugby. Rugby. Not football like that. And not God knows how to help us, not American football. When they come together and they walk arms and they're getting ready to start the play, that's the scrum. And that's the idea. It's the beginning of the play. Every day you get together, you walk arms, and you make the play. Now, I tend to think that actually scrums at the beginning of the day are a very good idea. But there are teams that do them at the end of the day. Kind of finish off the day, and then they're ready to rock in the next morning. In particular, if you have people who come in at very different times, watch their days at very different times, that's a really good idea. Because you don't have people just sitting there going. Okay? But again, what I would say you don't do is to not have a scrum in the middle of the day. Okay? That's just not a good idea. Beginning or end. And really where the team is most aligned. Okay? But there is a certain pleasure, there is a certain benefit to, you know, kind of coming together before you start the play. You know, if you do this, and then you step apart, and you go home and go to sleep, there is some energy that disappears. Can you just imagine, you know, the rugby team, you know, okay, let's go home. Come back the next day. Okay, let's do that. Let's do that play now. You kind of break your momentum. But again, this is a place where people can develop as they need to. And then finally, two events that are really intrinsically tied to each other, which are the sprint review and the sprint retrospective. Now this is a circle. You start at the top, you have sprint planning. Then throughout that process, you have a daily scrum. Then you come to the bottom, you have a review, and then you have a retrospective. It's feedback loops. Sprint planning. Really, you're just asking, you're asking and answering a set of questions in your sprint planning. The first is, what can we do in this sprint? And we'll talk about the sprint planning process in a later session about the estimation process. How do you figure out how much you can do? Again, it's an empirical process of figuring that out. Something that you do over time. Then that is, how is this work going to get done? How are we going to tackle this? How does this get broken down? How does this story, and we'll talk about what a story is later, and how to put a story together in a future session, how does that get broken down? And we'll talk about that. How do you do task breakdown? And figure that out. How is that going to get done? And this here is a feedback loop. Because you say, oh, yeah, we can do this. You draw a line, and then you start doing breakdown, and you go, oh, my God, that is so much bigger than we thought. Or, oh, it's much easier than we thought. Okay? And then out of this process of the work you're going to do and how you're going to do it, you come up with a sprint goal. It's defined. Okay? Now, sometimes it's good to say, hey, what's our goal? Our goal is we want one user to be using this feature in production. That's a reasonable sprint goal. Okay? And if we're familiar with OKRs, sprint goals as OKRs is a great way to do it. Okay? It's a very good, positive way to do it. Thank you. Now, there's some artifacts that you have in Scrum. Things that kind of make the whole thing work. These are the things you inspect. Remember when we talked about back-end inspection? We talked about artifacts? Things that need to be transparent? These are the things. And then these can drive things like burn-down fronts. Okay? Which are just metrics against those. Scrum artifacts. The product backlog. This is the stack-rank list of things you want in the product. You notice I said stack-rank? So if someone tells you, oh, well, we have seven priorities. Well, that's not possible. If you actually go to the Latin root of priority, it means singular. You can only have one priority. So your sprint goal is your priority. The things that get you to your priority to get your goal, those are what are going to be in your backlog. Now, you may have, you know, a list of things if I know most product owners and product managers. Probably longer than I am called. Probably lay three or four of us. And to end it will be longer than that. Hundreds of items. Now they don't all have to be well-defined. What has to be defined is the tip. What are you going to do with this sprint? What are you probably going to get to this sprint, next sprint, maybe the third sprint after that? You start defining things any more than that. It's waste. Okay? It's waste. So, but what you do want is a product backlog. You want an idea of where you're going. One of the criticism about the scrum is, oh, well you're always trying to manage things within a single sprint, which means you never take a look of a long view. You never think about what's going to be out there longer term. You know, in terms of how some people run scrum, valid, valid criticism. But, if you've got a product backlog that is, kind of gives you a road map out a long three months, okay? Then you've got a pretty good idea. And the thing is that's going to fall out based on your learning. If you shift feature A, and nobody uses it, you really need to do the optimization of A. You really need to do the enhancement of it, enhancement one of A, enhancement two of A, enhancement three of A, which I guarantee you, we're all in a bad backlog. No, you pull them out, you drop it, you move on. Here's the thing. A lot of us don't like to admit that we were wrong. We believe in the fallacy of some cost. So, we keep going forward and doing something that doesn't make, that has been proven to be wrong. It is said that Albert Einstein said that sanity is trying to do the same thing and expect different results. It doesn't appear we ever said it, but it sounds really good. So, don't be insane. But that's the product backlog. It gives you a view. Then what's the sprint backlog? The sprint backlog is where that team sits down in the sprint planning unit, and he goes down and draws a line. He says, this is what we can do. This is what we have confidence we can do. Okay? It's fine. That's your sprint backlog. And then you have to figure that out and break it down, and you may kick things out, you may move that line, but you have to start with setting the line at some point. One of the other scrum artifacts we need is the definition of done. What does it mean? Does it mean it compiled on my machine? Does it mean it executed the union tests? Was it built by your build server? Is it deployed to a staging environment? Is it actually in customer stands being used? I can't tell you what your definition of done is. I've actually seen all of these as definition of done, some poorer than others, but the closer you get, the further you get towards the right-hand side, i.e., it's in a customer stand being used, or being used by all your customers. That's probably a better definition of done, but it's going to be a multi-bullet point. It's going to be things like, the code has been merged to master. All tests are green, with at least 80% test coverage. It has been reviewed in a staging environment. That's a reasonable definition of done. That's a reasonable definition of done. Different components will have different definitions of done. For example, if you have a CD environment, a continuous delivery environment, your server code being running your production is probably a pretty decent definition of done. For that, one of your requirements. Now, if you're working on an iOS application, and you have to go through the Apple review process, which is completely non-deterministic and you have no control in under, saying in use by customer is probably not a good definition of done. Because that review period can take up to two weeks. It can take a whole sprint. So there, it might be submitted to Apple. Now, on the other hand, if you're Google Play, and you can get out much faster, then being used by customers is a reasonable definition of done. And again, it doesn't have to be all your customers. You could say, hey, must be being used by 1% of the target base for this. Here, okay? When I was working on the deployment of Chef at Yahoo a couple of years ago, one of our early goals was that we had 100 boxes being managed by Chef. But you know how much you have to do to make that happen? There's a lot. And then from there, it's just scaling. Okay? So, again, it's, you know, one of the things that I love to see in the engineering organization is what I call day one, day five onboarding. Day one says that on day one of your employment, you actually push, no matter how small it is, a change through the build pipeline and either, and how it's done. Okay? So, you know, if that means that, but what does that mean? That means you've got to have your whole tool chain working. You've got to get those certs sorted out. You've got to be able to do all of this. You've got to be able to go, push to get the get-rebo. You need to be able to trigger a bill. You need to be able to get it deployed to production, all of it, or to the staging environment, whatever that definition of done is. Now, it could be fixing a typo. It's not like it's more about the tool chain is working. Now, that's great for you as an engineer because that forces you to like, I just got to get this stuff working. But it's also a forcing function on the company, which is, can someone do that? How do we, is it that, how do we automate it? Is it clearly documented? Is it easy to do? And it's an iterative process of improvement. Now, day five is push a small story or a bug fix through the pipeline. So, get something, get something much more comprehensive than what you did on day one. So, day one, day five. That's an example of an application of definition to done to the process of onboarding. Any questions? And finally, finally, it's about customer value. We do this to deliver value to customers. That is the ultimate Scrum artifact. Customer value delivery. That's where you sit down in your Sprint review and you demo a feature and everybody sees it. That is it. Okay? That is it. Questions? That's it for tonight. Just under an hour. This is our target for these sessions. Do you want to see? I'm a customer value expert. What do you do? I change it up based on the things that we cannot define as a customer value. Give me an example. Give me an example. Right here on the course. We back to your code. So, what does refactoring your code get you? What does it get you? There's a couple of reasons for refactoring. One, you've got a bug or a set of bugs that just cannot be fixed without refactoring. Well, bug fixes last time I checked for customer value. Too often teams forget that bug fixes are customer value and they don't include them in Sprints and they kind of treat bug fixing as this off the book's activity that happens. You should be including those in the backlog. You should be forcing the product over to say, what's the most of these sets of bugs, what's the most important? Okay? What's another reason that you refactor it? You refactor to make the code more mod-filed. Why? Because you're going to deliver more customer value. It's a foundation. Okay? That's like saying, you know, fixing a bug in a compiler is not customer value, you know, or getting a bug fixing the code. Well, yeah, but if it means that we can actually write the code we want it to, that ultimately leads to customer value. Now, what are things that aren't customer value? Me forcing you to sit in a meeting for eight hours. A status need me. That is not customer value. Okay? That's not customer value. There's a lot of things that aren't customer value. But that, but refactoring code, if, now, if you do it because you want to do it, you know, just because it'll be cool, because, well, I've heard that this is the pattern everybody's using, and we don't use that pattern. And all the cool kids use that pattern, and I want to be a cool kid, so I'm going to use that pattern. That's not customer value. Okay? I was watching a discussion the other day between two people that were iOS developers, and one said that, oh, I'm refactoring and rewriting in Swift. Okay? The other person, I think, very legitimately challenged them. I actually don't have a dog in this fight. I don't have a thing on it, but it was a great discussion. And they were arguing the right thing. They weren't arguing that Swift is cool or Swift isn't cool. They weren't arguing, you know, they were arguing, would this allow them to move faster? Would this prevent them from having certain bugs and certain classes of bugs? Those were the discussions they were having. Legitimate discussion, they had legitimate different opinions on it, but they were having the right argument. Okay? Now, make sure that you're always having the right argument. Okay? You know, but like I said, just because all the cool kids are doing it, I was never a cool kid. I was a nerd. Never understood being a cool kid. Yes? I'm curious. And this is a little strange because this talk was about Scrum, but have you ever been involved in a design process or did I know software whereby Scrum just wasn't fit for the job? I have not yet been involved in such a project. And I've done things as varied as medical devices and operating systems, compilers, user-facing applications, B2B applications, B2C applications, inventory management, enterprise software, the whole range. I have not yet been involved in a project that doesn't do that. If you actually go and find the original waterfall paper and if you want to contact me later, I actually have it and I can send you the PDF of it. It essentially sends in the last paragraph that this methodology is applicable to only the smallest software engineering projects. That's essentially what it boils down to. Things that are well understood, completely well understood. And yet there are so many companies that will still use waterfall and to get by somehow. Yeah, I know you can make it work. But can you deliver value faster with better quality using Scrum? Yeah. But it also puts a burden on people and the team. There's a level of ownership and responsibility you have to take in a Scrum team. I'm not telling you exactly what to do. And so this is really where it comes down to and the rubber meets the road. Are you a software engineer? Are you a programmer, developer, coder? I eat a code monkey. Okay? I got to tell you I want to be a software engineer. Much, much more interesting thing to be doing than to be a coder, a developer, a programmer. Okay? That's, you know, that's, I mean, what is the origin of coder? Do you know what the origin of coder is? It was people that actually basically took data, incoming data, and encoded it manually. Okay? To do a problem. No creativity. Okay? Essentially, you could think of it as the person sitting at a punch, at a punch. You guys even know what a key punch is? At a key punch. And, you know, getting census data and punching it in. Okay? Getting demographic data and punching it in. That's where it came from. No creativity. Okay? That's the origin of it. Okay? You know, now, is that what you want to be doing? Or do you want to actually be involved in definition, design, development, and delivery in the world of the software engineer? I think that, yes, there are organizations that use waterfall methodologies. And they result in projects that, again and again, are failure to deliver value over budget, behind schedule, have lots of issues in the software. The closer people get to, the closer a team gets, whether intentionally or unintentionally, to an empirical process, the higher the success of the project. Okay? Hirelessness. And I'm talking, and people are like, oh, well, yeah, it's, you know, because you can ship, you can break stuff and ship, and you know, it's all that internet stuff that you can do. Yeah, but I worked at a medical device company where we built software that controlled linear accelerators. For the delivery of radiation therapy. Now, if you go to Comp.Risks, you know, you know, the Comp.Risks group, and you look for one of the first kind of, you know, big computer failures that's called out in Comp.Risks was the control of a Linux, or as we sometimes call them affectionately, death rays, for the delivery of radiation therapy. Which, because of a bug in it, resulted in the over-treatment of around 100 patients. Killing it. Okay? Because of a software bug. So, you know, now, do you, does that, does your definite efficient of done become more rigorous? Does your, does your test, does your, you know, does your test coverage have to be higher? Does the number of test cases you've thought through have to be more rigorous? Yeah. So, you're going to be taking smaller quantities of work? Yes. But there's nothing that says it can't be done. We did it. We adopted it. And the team that adopted it did better, moved faster. And you can do this in a framework that is completely auditable by the FDA, or by ISO, you know, by the European Health Agency, all of those, those different people that, you know, need to look at medical software. It can be done. How do you deal with tickets, where it's not a, stories, where it's not clear the amount of effort? Bounce it back. Need further definition. Have a conversation with the person. You know, go and grab them. I mean, that's why you have backlog grooming. Where you go, yeah, this sounds like a really great story, but here's some questions we need to answer. Okay? That's why you do backlog grooming. That's why you have a spring planning movement with a product owner in it. And it's like, you know what? We don't know what you're asking for here. This is also where tools like GERCAN for very, very clearly defining acceptance criteria, and then being able to turn those into tests. If you haven't looked at GERCAN, take Cucumber GERCAN, take a look at those. Great tools for, you know, kind of BDD or behavior-driven design or behavior-driven development. Okay? If you have something that's completely unclear, I mean, here's the thing. If I told you, you know, the first step in a process was go to Woodlands, and you had absolutely no idea how to get Woodlands. Or better yet, I do a lot of cycling. A lot of cycling. When I'm able to, I'm usually clocking two, three hundred kilometers a weekend. So around the island, maybe a couple of times. If, you know, we were going on a ride and I said, hey, yeah, the first step, we're starting here. And, you know, at Panjong Pagar. And Woodlands is the next stop. It's like, well, how do I get from there to there? You know, you would say, give me some clarity. You know, do I go east, west, north, south? You know, which, you know, give me an idea. You know, give me, you know, give me, you know, what you need is the broad outlines, which is, you know, head out, head out, Keppel, you know, West Coast Highway, Pioneer, you know, you know, Crunch Road, Crunchy Road, up around Woodlands. You know, that's a basic outline. Now that doesn't capture a return. That's not, you know, my new discussion. You know, you know, description of things. But it gives you a basic outline. I mean, I can describe how to circumnavigate Singapore in about 10 steps. Now, does that mean you're going to have to be careful? You're going to realize, oh, I just passed that intersection. I need to go back and come back. Yes, but that's okay. But if it's like, I literally do not know whether to go north, south, east, or west, then that is a bad story. And that's part of your job. But again, it's not, again, it's the, are you a software engineer? Are you involved in that process of definition and design? Do you have a dialogue with your product manager? Or do you reject it? You know, you know, that's not helpful, okay? Because again, it's about this team. It's the group of people working together to deliver customer value. Having a dialogue, having a conversation. It's about going back to what we talked about earlier. It's about the responsibility, the empowerment, the responsibility, and then the accountability. But great question. So I'm going to just talk about some of the things that will be in future lessons. And I think, you know, that how you, you know, we'll need to figure out a way to start giving feedback. So maybe we'll get a, like a formal format so we can get some feedback and have some questions. We should have thought of that before, but empirical process. So what we're going to be covering in the future is we're going to be feeding some food dives into some of these things. Next week, we're going to be talking about stories, acceptance criteria, definition of dialogue. Okay? That's the broad outline of what we're going to be talking about. After that session, we'll probably do a few, some things that will probably be break up into like groups, small groups of three, and maybe write some stories. Okay? And then maybe think about past breakdown for those. And then the weeks after that, third and fourth week, will actually be more, almost more simulation. I'll give you some tools, break you up into a scrum, and have you tackle something. We will probably do a simulation sprint planning. We'll probably do a simulation stand-up. We'll probably do a simulation retrospective. Okay? Unfortunately, I don't have what we used to use at Yahoo, which were these big Lego sets, which we would use for sprint planning. I'm trying to see if I can get them, and if we can, then we'll use it, and they'll be Lego-based. But if not, it might just be abstract in your brain. This is, this is a series, okay? So this is a series. Yes, you can drop into any one of them, and people are welcome to come to the next one if they were here, but you will get the most value by hitting all four sessions. Okay? Other questions? So, what do people, what is people's reaction to this format of us actually opening up what essentially is internal training to the rest of the world? Is that something I hear? You like it? Yeah. Well, we're hoping to do it. You know, well, obviously there are things that will be closed because they're, quote, proprietary or confidential. But to the degree that it is possible, we're going to use tech, you are tech talks, tech talk level up, or our level up tech talks in this kind of open format. So, helping, trying to help build the community. Carousel, as a company, is really committed to building a vibrant software engineering community both within the company, but also within Singapore. We see that as a big thing. It's one of the things that attracted me to the company and why I'm really glad to be here. It's something that I'm committed to doing. But every one of the people that I work with here is committed to that. That is something that we, that excites us. You know, yeah, we want to produce a great product. We're going to be a successful company. But if we did that and we didn't help build a vibrant software engineering community, we would feel poorer for it. By the way, we're hiring. Now, we may not be the right place for you, but you may not be someone that is. So, you know, if you've got referrals, send them to us. Encourage people to apply. We're doing some great things. We're having a lot of fun and they're great people to work with. You know, well, I could say they're all great if I can't talk about myself. Okay, thank you very much and see you next week.