Scrum Overview and Agile Principles

0:00Welcome to the PSM1 professional scrum master level one course. I am your host I am your instructor Bob mailer before you ask yes, I have passed this I found it to be very Reasonable and if I can pass it I promise you you can pass it I'm gonna try and keep it clean and neat and stay on target But if you've had any of my other training, you know that may not be possible Let's take a look at the agenda. We're gonna talk about the scrum overview and the agile principles very cool We're gonna go all the way back in the way back machine to 1986 when it was really first conceived and published in the Harvard Business Review We're gonna move on to roles and responsibilities product owners scrum master developers This actually comes up quite a bit on the exam and here's the real danger for the exam You need to answer questions the way they intend for scrum to be ran Not the way you've done it on your current project or at 15 companies before this So your experience your common sense can actually get you into trouble here We're gonna talk about the scrum events time boxing all of those really matter.

1:14They are clearly defined scrum artifacts and commitments the product backlog the sprint backlog the definition of done the Recriments the scrum master who obviously mastered the scrum Hey, that sounds like me and then we'll play around a little bit with scrum theory and practice some light agile metrics Burn down charts burn up charts velocity explain some of that common pitfalls exam strategies and along the way and not just at the end We're gonna talk about mock exams questions We're gonna review as much as we can because my goal is simple I want you to pass the first time like I did trust me if I can pass you can pass There is a minor danger though This is one of the fastest Certification exams that I'm aware of you have 80 questions in 60 minutes and if I've done the math right I think that's about 45 seconds per But again, I used to jump out of planes Crash them into the ground with parachutes of course not the planes and I passed I'm pretty sure you can pass to as long as you stay focused

2:29You do the homework and you can clearly tell the difference between the exam and Reality if you can do that on the other side of this you're gonna be a PSM One as well like me, so let's get going get ready to train

0:00In this section of Scrum Overview and Adjio Principles, we're going to start by talking about the origins of Scrum. So let's get into it. Right out of the gate. As soon as I figure out how to do this, go back to 1986. The new new product development game is published in the Harvard Business Review. And yes, I did not make that up. That is the title. Hirotaka Takayichi and Ikijiro Noenaka came up with it. And what they basically said was actually pretty interesting.

0:31Traditional development is like a relay race. Think about people running around a track. They're handing off a baton. So you might have development and then concept, or concept, then development, and then construction, and then release, and then marketing, and then sales. And all of these very stove-piped, very separate parts of development. They didn't like that. So they were looking at all these companies who were doing things better, and they found out that it was more like rugby.

1:01The entire team is fast and it's loose, and it's generally moving in one direction. And there is no rhyme, there is no reason, they're just on the same page and they're moving. So hold that in your head and we'll continue doing this. That happened in 1986. They came up with six characteristics of those companies that were using the rugby-like approach. Built-in instability. They understood that there was a lot of stuff they didn't know. They would figure it out along the way. They were not going to constrain themselves by demanding that they know all there is before they move forward.

1:36It would simply take too much time. Self-organizing teams. Instead of having management figure it out for them, management said, "Look, you are a team, that's the direction I want you to go in, figure it out." And so they did that. Then they had overlapping phases. Instead of having very clear handoffs, they would overlap so they could see what was working, what wasn't working, and adapt very quickly. Multi-learning. Everyone knew a little bit about a lot. So instead of having a quality person who only does quality, or an engineer who only writes code, or a sales person who only understands sales, these teams understood quite a bit about, well, quite a bit. So they could move back and forth in and outside of everyone's lane as they all move in the same direction.

2:27And because they're self-organizing, they were able to get away with that. Management also exercised subtle control, which is a huge exchange away from waterfall project management product development. Traditionally, management sets goals. They provide tasks. They give you direction. They monitor very closely, usually to the point of micro management. That doesn't happen here. Again, leadership was saying, "Go in that direction. This is the general idea in this chaos we're aiming for. We're here if you need us."

3:01There was a lot of empowerment, which was wild. Then you have the organizational transfer of knowledge. Once something was learned, they immediately shared it. Everyone immediately adapted to it. So if one team here learned something, they could share it with the organization over there and make them better. And if that team learned something, it could be spread over here and this team would get better. So it was actually very cool. Now this is 1986 one more time. Think back to that if you were around then, because I was. Copiers, printers were the size of Volkswagen's. They were huge. The tech was huge.

3:40Laptops, not in your average household. Desktop, not in your average household. You were a big business. You were a NASA. You were a federal agency. And you had something large and clumsy. And it was based on traditional development. So you probably have more processing power on your Fitbit than the average company computer had back then. But let's not get hung up on that. Let's move on. So what happened after 1986? Well, fast forward to 1993. Jeff Sutherland's working at Ezel, Ken Schwaiber's working at ADM. Software developers, big thinker guys, really, really smart people. They meet in 1995 and they have similar ideas. Holy cow. They decide to collaborate and publish a paper at Oops la.

4:28Now I had to look this up because I couldn't remember it. You probably won't either. But Oopsla stands for Object Oriented Programming, Systems, Languages and Applications. Very exciting stuff. So what happened after that? Jump to 2001. 17 thought leaders, developers including Schwaiber and Sutherland. They're part of the 17. They get together at a ski lodge in Utah. Yes, a ski lodge. Because if you're going to change the game forever, you may as well do it somewhere comfortably.

5:02They developed over the course of a couple of days the Agile Manifesto and there are 17 signatories. There are 12 total principles, 4 core values. Let's take a ride over there and check them out. So hang on.

0:00In this nugget, we're going to talk about the 12 principles in the Agile Manifesto. I'm going to show you what they are and then I'm going to translate. Let's go. The first one, highest priorities to satisfy the customer through early and continuous delivery of valuable software. Early, continuous delivery. What are they talking about? Well, they're talking about delivering value. Often, early, and then get feedback. And don't worry, I will post these below.

0:30I'm just trying to make it quick, easy, memorable, and trust me, we're going to go over these principles over and over in many different ways throughout this entire series. So trust me, you're going to understand it quite well. But let's move on. Welcoming change requirements, even late Agile processes harness change for the customer's competitive advantage. What are they talking about? Well, this one is actually pretty simple. Embracing change. However, in the Harvard Business Review, the new new product development game, built in instability, they recognize there's going to be change.

1:05They recognize you're not going to know everything up front. So you need to get to work understanding that things are going to change. And as soon as you accept that, the easier it's going to be. But let's keep going. Deliver working software frequently from a couple of weeks to a couple of months with a preference to a shorter time scale. What are we talking about? Releasible versions. And we'll talk about this many times. We're talking about increments. At the end of every sprint, there should be something usable.

1:37What's usable is normally called an increment. An increment, not an increment. I'm not quite sure what happened there with my brain, but it happens. Business people and developers must work together daily throughout the project. What are we talking about? And I really like this one. Stop the silos. We talked about this a little bit early on. You cannot have stove-piped areas within your company and expect to move fast.

2:08Think about waterfall, their handoffs. You have concept, then design, then construction, then delivery, then operations and maintenance, and then sales and marketing. That's a really long process. It cannot happen here. If you want to move fast, everyone has to be integrated together, which is why agile is so, well, agile. Fast, adaptive. Let's keep going. Build projects around motivated individuals. Give them the environment and support they need and trust to get the job done.

2:41This is a really good one. And this is broken down to a simple word. Empowerment. Give them the direction. Give them their authority. Get out of the way. It's efficient and effective method is face to face. Talk often and directly. Now don't get wrapped around the idea that I'm working from home so I can't be as productive and I don't want to do the return to office thing. Remember, this is the theory of agile. Back then, when it was started, we didn't have a global pandemic.

3:13We didn't have Zoom. We didn't have teams. We didn't have any of that stuff. Everyone was going to the office. And everyone was largely face to face on these agile teams. And that's what they're talking about. You might be the perfect team remotely now with 95% functionality, success, whatever it is. But I promise you, there's a lot that can be gained from a rapport building, from an esprit de corps standpoint by being face to face.

3:44Just keep that in mind. The exam. Reality. We're in the land of the exam. Working software is the primary measure of success. This one is also very easy. Show results. It's all fun and games until you produce something. Show me the money. Show me results. Agile processes promote sustainable development. Sponsors, developers, users should be able to maintain that pace indefinitely. What do they mean?

4:14Find a steady pace and maintain it. Contain a steady pace. This goes back to team velocity and we will talk more about this throughout this course. Continuous attention. Technical excellence. Good design. Enhances. Agility. What are we talking about? Clean code. Why do we care about clean code? It makes it easy to grow. You're going to learn about something called technical debt at some point in this course. And I'll just give you a preview now. Technical debt is when you take a shortcut, perhaps during a sprint to deliver that working increment that you know you're going to have to go back fixed later on.

4:54If you have too much technical debt to fix, excuse me, not technical depth, but it can get really deep. If you have too much technical debt, you can't progress forward. You are only moving backwards to fix what is stopping you from moving forward. And it can really add up. Clean code. No technical debt or less technical debt. It becomes easy to grow if you find that sustainable rhythm, that velocity where you can deliver clean code so you're always moving forward.

5:29And when you're moving forward, you're always pulling those items out of the product backlog, which we're going to talk about, all of those features and characteristics that your customer wants, and you're moving them into the sprint backlog, the items you're saying you're going to deliver, part of your increment. Well, technical debt can get put in the backlog as well because you have to fix it. The less technical debt you have, the more features, characteristics, and clean story points, if you will, that you're able to produce.

6:04That's what we're talking about here. Simplicity is essential. This one is very easy. I like this one because it simply means the kiss principle. Keep it simple. Seriously. Now I've heard keep it simple, stupid, but this is a family-friendly show and I don't like to call people stupid. So keep it simple. Seriously. We're almost done. Let's keep going. The best architecture is requirements and designs, merge, emerge, excuse me, self-organizing teams.

6:35What are we talking about here? Trust. Earlier, I brought up empowerment. Here we are talking about trust. If you can't trust them, you can't empower them. And if you don't empower them, you never learn to trust them. They kind of go hand in glove. And the last one at regular intervals, the team reflects on how they can be more effective, adjust its behaviors accordingly. This is very important because you are always improving.

7:05Why is this important? Because one of the scrum events is called the Sprint Retrospective. The Sprint Retrospective is all about the people and the process. What got in their way, what made it better, what do they need to fix. And remember, a sprint can't be more than a month long. I actually haven't told you it yet, so maybe this is the first time you're hearing it. And you're not going to remember it, but you're going to hear it a lot. You look at the product, the increment during the sprint review, you look at the people.

7:37And the process is during the retrospectives. We're going to talk about the 5 scrum events real soon, but this one is very important. Imagine if you had an opportunity as a team to improve every single month. That is why Agile can be so fast, and that is why it is so adaptive.

0:00In this nugget we're going to do some comparisons. We're going to figure out what the differences are between Agile, yes I'm using air quotes, Scrum and Waterfall. And I think this is going to lay the foundation so you can tell the differences between the three. One is kind of like the other and one has nothing to do with the other. So let's get into it and check it out. Let me grab Mr. Penn here. So let's talk about the type. What are we talking about? Agile is really a mindset along with some principles .

0:33I almost wrote Pringles because I like Pringles. Whereas Scrum is an actual framework. It's very loose. There are some time boxes and we're going to talk about this quite a bit but it 's a framework within Agile. Waterfall is more of a linear methodology. I'm not saying one is better than the other. I'm simply saying there are some differences. If you're in a heavy construction environment, heavy engineering environment, heavy oversight environment with tons of documentation, you're going to see Waterfall.

1:08Agile and Scrum, not about that. And let's keep going. The approach in Agile is iterative and incremental. And yes as always I will post these. I'm sorry for the writing. It's just how I am. Uh-huh. Scrum is also iterative but with sprints. Now those sprints are going to become very important. Whereas the approach in Waterfall is very sequential. And we've talked about this many times. Concept design, construction, release, etc. Pretty easy.

1:41The structure in Agile, you'll like this one, is flexible and adaptive. In Scrum, it's time-boxed. Meaning things are done in certain amounts of time. And they are very important. There are five Scrum events. They have specific no greater than times. And we're going to talk about it quite a bit. Whereas Waterfall is more of strict phases. Let's talk about some planning. In Agile, as a mindset, it's merely continuous and evolving.

2:12I like that. Whereas in Scrum, there are sprint planning before each sprint. Now this goes back to what I said a moment ago. There is sprint planning that's sprint planning since we're already talking about it. It can last no more than eight hours for a one month sprint. There are two events right there. Sprint planning and the sprint. And let's keep going. We're going to talk about this quite a bit. Whereas in Waterfall, there's a ton of upfront planning.

2:44Which is why it takes so long to get anything done. Let's talk about documentation. Usually it's very minimal, which is fantastic. In Scrum, it's minimal as well. And you typically see it in the form of backlogs. Not that big a deal. In Waterfall, very heavy and formal. So there we go. There are the first five categories. Let's keep going. Let's clear the screen and let's move on. Let's talk about delivery style. Small working increments in Agile.

3:17Here you have Per Sprint. Your delivery style is Per Sprint in the form of increments as well. Now there's a nuanced difference here. Scrum produces a working increment. Excuse me at the end of every sprint. The Agile as a mindset means we can back off of that and have a working increment. But it's not necessarily confined to that one month. And in Waterfall, your delivery style is at the end.

3:49Customer involvement is frequent along with feedback. Feedback is the breakfast of champions. Thank you, Ken Blanchard. The interesting thing about Scrum is the product owner represents the customer. Let's just go with product owner reps. He is the voice of the customer. And in Waterfall, it's normally at the beginning and the end. Now that can change depending on the kind of project, the kind of industry, etc . But typically in Waterfall, you see it largely at the front, largely at the end .

4:21Change embraced, which is fantastic. Expected. Now for Scrum, it's accepted within the backlog. There is no arbitrary change. It must be done through the product backlog and the sprint backlog. In Waterfall, it is very formal and very often discouraged. I think this is a good place to take a break. We've talked about eight of them. When we come back, we'll finish the other seven. So I'll see you in a moment.

0:00Welcome back to the next part of this. We're still comparing. I'm still here. I still have Mr. Pen. Let's go. Let's talk about the team structure cross-functional. They know a lot about a lot. They move seamlessly among these. They are also self-organizing, which is very cool. In Scrum, you have a product owner, you have a Scrum master, and you have developers or devs. That's it. There are no other team members. In waterfall, they are siloed. You might have analyst, engineers, project, manager, salespeople, marketing people, etc.

0:41They are siloed. Meetings, as needed. I like that one. Now in Scrum, there are defined meetings. You have planning, Sprint planning at the beginning of every sprint. You have the daily Scrum, which we're going to talk about. You have the reviews and the retrospectives. Let's just call them retro. These are very defined. They are Scrum events. There are any other... How do I want to say this? Any other meetings held during the sprint are not formal. They are informally held among the self-organizing team members. Now, meetings in waterfall. Let's just go with all of them.

1:22You can have milestone meetings, status meetings, change meetings, client meetings, whatever it is. So there are lots of meetings. So we have five more of these. Let's move on. Let's wrap this up. So success measures in agile, value. And when I say value, I mean customer value. Does the customer find value in it? Because if the customer does, great, you are delivering on whatever those success metrics are for the customer. It's not what you believe. It's what they believe. And can the customer change it based on feedback from external to the company, perhaps with the end users or internal to the company with, you know, leadership?

2:04Absolutely. That can be changed at any time, but you are always seeking value. Value has to be defined though. Let's move on. Success measurements here are increments at the end of every sprint. If you are delivering a working increment, you are moving towards some sort of success measurement. And in waterfall, it's at the end. Hopefully you are delivering whatever was in the document or approved scope because if you didn't, you're not going to be successful. Let's talk about risk.

2:37It's ID'd early and through every iteration. That doesn't surprise me because risk can change. Now in Scrum, it's adjusted every sprint. This will make more sense when we talk about that. And in waterfall, risk handling is all the way through. You can have risk events early. You can have risk events late. You can have risk events on the very last day. It really does depend. Let's talk about quality. I love this because it is built in. Quality is not inspected in. It is built in. In Scrum, it is the definition of done.

3:14Whoops, that's Department of Defense. The definition of done and we're going to talk about that. Now the quality focus here. How do we know we've achieved it with quality assurance and quality control. Quality has to be defined. It has to be measurable. It has to be tracked in any of these. So I always love talking about quality. Now the best use for agile are those projects that need flexibility and they are evolving. The best use case for Scrum is when the team needs structure. And by structure, I mean Scrum events that are time-boxed.

3:53In waterfall, you're talking about stable predictable requirements. Let's just call those wrecks. And yes, I forgot how to spell predictable for a moment because my brain was being unpredictable. Let's talk about some quick examples and wrap this up. When you talk about the broad use case of agile, you're talking about can-ban. You're talking about extreme programming. It can be used for lean projects. Now when you talk about Scrum, you're talking about software development. Easy peasy lemon squeezy, no problem on that one.

4:27And some easy examples of waterfall, construction, manufacturing, government R FPs. There you have it folks. 15 ways to compare agile, Scrum, waterfall. Again, there is a nuance here. Think of agile as this big idea about being adaptive and flexible and being able to evolve. Add a little bit of structure to it for software within it and you get Scrum. So, agile, waterfall.

4:58Within agile, you have a more solidified framework called Scrum, which is what professional Scrum Master 1 is all about.

0:00So what is empiricism anyway? I don't know, but I bet we can figure it out together. And I have a bunch of examples to explain it. So let's get to it. And to be fair, I actually do know. I just want to make it feel like we're learning together. All right, let's stop all that nonsense. Let's get to it. What is empiricism? Well, at its core definition, it means making decisions based on what is known. Facts, observations, experience, not assumptions, not predictions, not trusting your gut.

0:34What is known? What has happened? I love this. People get mad at me all the time on a project because they're losing their mind, their hairs on fire. We have to do this. We have to do that. And I will always say, well, what exactly happened? Not what you think. What exactly happened? And until we know exactly what that is, we can't do anything. So I love this right out of the gate, making decisions based on the facts, the data.

1:04But let's move on. I'm going to get off my pedestal and keep going. Now, from the Scrum View, Scrum is built on empiricism with three pillars. And this is very, very important. Transparency, inspection, and adoption. So start thinking about this. Tia, transparency, inspection, adaption. Say it to yourself 2,700 times by the end of this course. And you're probably going to pass. And no, I'm not making that up. Transparency, inspection, and adaption.

1:35And let me give you some examples. Now, think about predictive thinking. Where predictive models plan everything upfront, obviously, empirical methods adjust based on what has actually happened or what is happening. I think there's a typo there. Don't hold it against me. I think I miss-spoke-ified, as we say in Tennessee. But again, we're not planning everything upfront because it takes forever. We are reacting to what has happened or is happening right now. And a project level application.

2:08For empirical project management, you inspect frequently and adapt based on what's happened. The plan cannot expect to be unchanged. That is ridiculous. Why would you plan a route to go anywhere and suddenly there's traffic or an accident or a street light out or Godzilla, some other calamity and go, no matter what, we're staying the course. That is ridiculous. You don't do that.

2:39You are going to inspect what is happening. You are going to adapt to it. The only one we're missing is transparency. And we're going to get to that pretty quick. Think about risk management. Empiricism reduces risk by shortening the feedback loop. In predictive project management, sometimes you have to wait a long time to see if something's going to work out. That doesn't happen here. A sprint can be no more than one month long. We haven't talked about the Scrum events yet, but it's coming.

3:11So think about that. If you were doing anything and you could adjust every one month or less, your risk level is going to come down compared to having to wait three, four, five, six months. This is fantastic. This is why the risk level is so low usually on Scrum projects. Now, there are a lot of variables out there, but by far they are less risky by their very nature, by their processes, by their framework, than predictive projects.

3:43Think about leadership. Leadership would ask, what does the data show before jumping to conclusions or trusting your gut? What are we doing here? We are inspecting. We're also being transparent. If you jump to conclusions, you're not following the rules. Remember, TIA Transparency, Inspection, Adaption, I'm going to say it until you are sick of it, and it is going to serve you well, I promise you. Let's take a look at some real-time evidence.

4:14Empirical teams, Scrum teams are looking at burn-down charts, velocity trends, and user feedback. Data, replaces, guest work. What are we looking at? If you look here and here and here, you have transparency. And I mostly spelled it right, but that's crazy cursive as I call it. We are not guessing. We know. We can see it. We can see it. We can hear it. Transparency, Inspection, Adaption.

4:46I feel like there's a trend going on here, Bob. Well, you would be correct. And look at team dynamics. They inspect their own performance in retrospectives and adapt how they work. So let me just go ahead and let this cat out of the bag. At the end of every sprint, there's a sprint review. You review the working increment with the customer, either internal or external, or both. It does not matter. You're focused on the product, the increment, the software, whatever that is. Then you have a retrospective, which is all about the people and the processes.

5:21What did we do well? Where are our opportunities for improvement? What are the blockers, if any? You are inspecting, and then you are adapting to that. And once again, imagine going to the gym every day. And on the third day, you took a look back at the previous couple of days, and then you adapted how you were going to do the next couple of days. Now I know that's kind of fanciful. But with that kind of quick adaption from that inspection, imagine how quickly you could course correct to stay on track doing anything.

5:58It's amazing. And the interesting part of this is, anyone can do this. What we don't have while we have a pile of transparency inspection and adaption, what we really lack, lack, excuse me, is discipline. That's why we're not all yoked up at the gym, because pizza does not make me feel good about my workout. It just makes me feel good about life. All right, I'm off the pizza soapbox, too. Let's keep going. Let's do one or two more, and we'll take a little break.

6:29And when we look at it in action, it is a requirement for empiricism. Transparency. How can you adapt if you hide bad news? And you've heard me say this before. Bad news does not get better with time. So when you have a burn-down chart that shows the team's velocity or the product backlog that shows how many story points are there, or how many story points are in the sprint backlog, it's transparent.

7:00Everyone can see it. Or if you have a can-band board to show what's waiting, what's in progress, what's finished, you have transparency. What do you have when you have transparency? You have trust, and that is the only way you can get it by being transparent. Let's do one more, and then we'll take a little break. Talk about testing and learning. Empirical processes encourage experimentation. Try it, observe it, learn from it, and adapt to it.

7:31Why would we do that? Well, let's think back to it. Tia, transparency, inspection, and then adaption. If we don't understand it, we're not going to rush blindly into it. We're going to figure out what we might do, test it out, AKA inspected, and based on what we learn, we are going to adapt to it. And if anyone asks what we've done or what we're doing, we're going to add that T there and be transparent about it. All right, I think this is a good place to take a break.

8:02When we come back, we'll wrap it up.

0:00Welcome back. Let's wrap up these empirical examples and just keep going because I'm having a really good time. And did I mention to remember Tia, Transparency, Inspection, Adaption? Yes, Bob, you did, and we're sick of it. Let's talk about client communications. Through empiricism, we show the client a working increment at the end of each sprint. And I love this statement that I said, "These aren't promises on a Gantt chart ." What are they doing right here? That would be Inspection.

0:33And oh, by the way, we are also being transparent about it. And based on their feedback, we are going to adapt to it. I feel like there's a pattern here. I really, really do. Well, you would be correct. Transparency, Inspection, and Adaption. Think about value delivery. Empiricism prioritizes based on actual user feedback. It's not based on what we think is valuable. It's based on what they, whoever they are, think is valuable.

1:08Now we are adapting. I'm already sick of Tia, but you're not going to forget it. I promise you that. And here's the Agile Tying. Agile principles, and we talked about it before earlier in this skill, Embrace Empiricism by Favourying, Working Software, Face-to-Face Conversation, and Regular Reflection. Well, hmm. If we are face-to-face, what do we have? Well, we have conversations, but we are being transparent.

1:38Alright, I can put up with that. If we have Working Software, we are obviously inspecting. And if we have regular reflection, like Retrospectives and Reviews, we have Adaption. Yep, I'm just going to keep saying it. These are the Pillars of Empiricism. I say they are the Pillars of Scrum, Tia, Transparency, Inspection, and Adapt ion. And when we get to the five Scrum Events, and it's coming really fast, you are going to see Tia play out over and over and over. It must be so.

2:14Think about Change Responsiveness. Teams respond with facts, not fear. Why? Transparency, Inspection, and Adaption . And remember, Instability is built in. They know they are going to change. And the sooner you embrace that change, the easier it is to respond. We are getting there. We are almost there. Look at the Cultural Impact. A Culture of Empiricism promotes honesty, learning, continuous improvement.

2:44It also rewards curiosity without blame. And once again, without transparency, you cannot have trust. If you don't have trust, you don't have honesty, you have low learning, and there is not going to be any improvement. What are we going to have? The blame game. Over and over and over. I know you folks have seen it in the past. Remember, Transparency, Inspection, and Adaption. When we come back, I'm going to give you some examples of all three until you are sick of it.

3:16But I promise you, you are not going to forget it.

0:00Okay, let's do something fun. We've made it to almost the end of the skill I'd like to do a practical exercise related to Tia Transparency inspection and adaption. So here's what we're gonna do ladies and gents. We're gonna go through I'm gonna give you 10 examples I'm gonna give you a few seconds to think about it, and I want you to decide is it transparency? Is it inspection? Is it adaption? I will explain each one Let's go the first one the product backlog is visible to everyone What does that feel like it's visible to everyone?

0:38Well, that one is definitely Transparency hope you got that one. It's visible. It's transparent. That was a an easy one I hope let's move on to another one you check the increments and you're getting feedback from the stakeholders You're checking the finished sprint deliverable if you will the increment and you're getting some feedback What are you doing? It sounds like inspection Excellence I hope this isn't too difficult I know it's the very first skill, but by the time you get midway through this series you're gonna be rocking it So let's move on You're clearly communicating the sprint goal is that transparency inspection or adaption Clearly communicating it feels to me like you're being Transparent if you got transparent you are correct the next one Adjusting the next sprint based on the past team velocity that should say past Sprint velocity, but I had one of those Bob moments and you know who knows?

1:49Adjusting the next sprint. What are you what are you doing? Excuse me if you are adjusting? You are adapting. That's exactly right. Let's keep going the product donor Reprioritizes the backlog after losing a developer. Well, why would you lose a developer? People get sick people go on vacations people quit their job people get fired Hopefully not in this case people get assigned to other teams if you Reprioritize you are doing what I bet you're adapting Reprioritize adapt is it transparency doesn't sound like it is it inspection?

2:30It doesn't sound like it. It sounds like adapting to something that happened if you got adaption You are correct, but it does feel a little bit like inspection, but it's really adaption. Let's go on sharing the definition of done The definition of done can be thought of as some sort of quality standard You're trying to hit and if you share that with the team, what are you doing? Are you being transparent? Are you inspecting or are you adapting to some event ?

3:00It sounds like you're being transparent if you got transparent you are correct Let's keep going holding the daily scrum to discuss sprint progress If we hold the daily scrum to discuss sprint progress, what are we doing? Are we being transparent? Well, maybe are we inspecting? Well, what would what would we be inspecting excuse me the daily progress the sprint progress excuse me in the daily scrum Does it say we're changing anything because of it? I?

3:34Don't think so this one is inspection We are discussing the sprint progress Inspection and again, I know some of these are nuanced. This is only the first set of these we've done We're gonna do a lot more of them displaying the burn down chart for everyone to see that would really should be a no-brainer If we're displaying it everyone can see it. We're providing not hiding that is Transparency implementing actionable improvements from the retrospective. We're implementing we're changing Something and you know that if we're changing we are adapting. What are we adapting to?

4:12Whatever happened in the last sprint and once again? Their sprint retrospective is the team's opportunity to discuss what went well What were the blockers? What ideas do they have to improve the next sprint because remember one sprint starts right after another You come right out of a retrospective and then go right back into sprint planning and we're gonna talk about these events very very soon A few more and then we're done reviewing the list of backlog items think of the backlog as your list of Characteristics or items or once in needs for this particular software if we are reviewing we are Inspecting excellent and once again Remember Tia Transparency inspection Adaption if you have transparency you have trust you have empowerment if you have inspection You can adjust I know it's a lot. I hope you've enjoyed this particularly with Tia one more time What's it stand for?

5:20Transparency inspection and Adaption and yes those three will become very very important throughout this entire series and very important on the PSM1 I'll see you in the next skill and thank you for putting up with me in this first one