Scrum Overview and Agile Principles

0:00Welcome to the PSM1 professional scrum master level one course. I am your host

0:06I am your instructor Bob mailer before you ask yes, I have passed this I found

0:12it to be very

0:13Reasonable and if I can pass it I promise you you can pass it

0:18I'm gonna try and keep it clean and neat and stay on target

0:22But if you've had any of my other training, you know that may not be possible

0:27Let's take a look at the agenda. We're gonna talk about the scrum overview and

0:31the agile principles very cool

0:33We're gonna go all the way back in the way back machine to 1986 when it was

0:38really first conceived and published in the

0:41Harvard Business Review

0:43We're gonna move on to roles and responsibilities product owners scrum master

0:47developers

0:48This actually comes up quite a bit on the exam and here's the real danger for

0:53the exam

0:54You need to answer questions the way they intend for scrum to be ran

0:59Not the way you've done it on your current project or at 15 companies before

1:04this

1:04So your experience your common sense can actually get you into trouble here

1:09We're gonna talk about the scrum events time boxing all of those really matter.

1:14They are clearly defined

1:15scrum artifacts and commitments the product backlog the sprint backlog the

1:21definition of done the

1:23Recriments the scrum master who obviously mastered the scrum

1:27Hey, that sounds like me and then we'll play around a little bit with scrum

1:31theory and practice some light agile metrics

1:35Burn down charts burn up charts velocity explain some of that

1:39common pitfalls exam strategies and along the way and not just at the end

1:46We're gonna talk about mock exams questions

1:49We're gonna review as much as we can because my goal is simple

1:53I want you to pass the first time like I did trust me if I can pass you can

2:00pass

2:00There is a minor danger though

2:03This is one of the fastest

2:05Certification exams that I'm aware of you have 80 questions in

2:1060 minutes and if I've done the math right I think that's about 45 seconds per

2:16But again, I used to jump out of planes

2:19Crash them into the ground with parachutes of course not the planes and I

2:24passed

2:25I'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

2:34and

2:35Reality if you can do that on the other side of this you're gonna be a PSM

2:41One 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

0:04talking about the origins of Scrum.

0:07So let's get into it. Right out of the gate.

0:09As soon as I figure out how to do this, go back to 1986.

0:13The new new product development game is published in the Harvard Business

0:19Review.

0:19And yes, I did not make that up. That is the title.

0:22Hirotaka Takayichi and Ikijiro Noenaka came up with it.

0:27And what they basically said was actually pretty interesting.

0:31Traditional development is like a relay race.

0:34Think about people running around a track. They're handing off a baton.

0:38So you might have development and then concept, or concept, then development,

0:43and then construction, and then release, and then marketing, and then sales.

0:48And all of these very stove-piped, very separate parts of development.

0:54They didn't like that. So they were looking at all these companies who were

0:57doing 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

1:04direction.

1:05And there is no rhyme, there is no reason, they're just on the same page and

1:09they're moving.

1:10So hold that in your head and we'll continue doing this. That happened in 1986.

1:16They came up with six characteristics of those companies that were using the

1:21rugby-like approach.

1:23Built-in instability. They understood that there was a lot of stuff they didn't

1:27know.

1:28They would figure it out along the way. They were not going to constrain

1:31themselves by demanding that they know all there is before they move forward.

1:36It would simply take too much time. Self-organizing teams.

1:40Instead of having management figure it out for them, management said, "Look,

1:45you are a team, that's the direction I want you to go in, figure it out."

1:50And so they did that. Then they had overlapping phases. Instead of having very

1:54clear handoffs, they would overlap so they could see what was working, what

1:59wasn't working, and adapt very quickly.

2:02Multi-learning. Everyone knew a little bit about a lot. So instead of having a

2:07quality person who only does quality, or an engineer who only writes code, or a

2:12sales person who only understands sales,

2:15these teams understood quite a bit about, well, quite a bit. So they could move

2:21back and forth in and outside of everyone's lane as they all move in the same

2:26direction.

2:27And because they're self-organizing, they were able to get away with that.

2:31Management also exercised subtle control, which is a huge exchange away from

2:38waterfall project management product development.

2:41Traditionally, management sets goals. They provide tasks. They give you

2:45direction. They monitor very closely, usually to the point of micro management.

2:50That doesn't happen here.

2:52Again, leadership was saying, "Go in that direction. This is the general idea

2:57in 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

3:04organizational transfer of knowledge. Once something was learned, they

3:09immediately shared it. Everyone immediately adapted to it. So if one team here

3:14learned something, they could share it with the organization over there and

3:18make them better.

3:19And if that team learned something, it could be spread over here and this team

3:23would get better. So it was actually very cool. Now this is 1986 one more time.

3:30Think back to that if you were around then, because I was. Copiers, printers

3:35were 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.

3:45You were a big business. You were a NASA. You were a federal agency. And you

3:50had something large and clumsy. And it was based on traditional development.

3:54So you probably have more processing power on your Fitbit than the average

3:59company computer had back then. But let's not get hung up on that. Let's move

4:04on.

4:04So what happened after 1986? Well, fast forward to 1993. Jeff Sutherland's

4:11working at Ezel, Ken Schwaiber's working at ADM. Software developers, big

4:27thinker guys, really, really smart people. They meet in 1995 and they have

4:28similar ideas. Holy cow. They decide to collaborate and publish a paper at Oops

4:28la.

4:28Now I had to look this up because I couldn't remember it. You probably won't

4:32either. But Oopsla stands for Object Oriented Programming, Systems, Languages

4:39and Applications. Very exciting stuff. So what happened after that? Jump to

4:452001.

4:4617 thought leaders, developers including Schwaiber and Sutherland. They're part

4:52of the 17. They get together at a ski lodge in Utah. Yes, a ski lodge. Because

4:58if you're going to change the game forever, you may as well do it somewhere

5:02comfortably.

5:02They developed over the course of a couple of days the Agile Manifesto and

5:07there are 17 signatories. There are 12 total principles, 4 core values. Let's

5:14take 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

0:04Manifesto.

0:05I'm going to show you what they are and then I'm going to translate.

0:09Let's go.

0:10The first one, highest priorities to satisfy the customer through early and

0:13continuous

0:14delivery of valuable software.

0:17Early, continuous delivery.

0:20What are they talking about?

0:21Well, they're talking about delivering value.

0:24Often, early, and then get feedback.

0:27And 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

0:34go over these

0:34principles over and over in many different ways throughout this entire series.

0:39So trust me, you're going to understand it quite well.

0:42But let's move on.

0:43Welcoming change requirements, even late Agile processes harness change for the

0:48customer's

0:48competitive advantage.

0:50What are they talking about?

0:51Well, this one is actually pretty simple.

0:54Embracing change.

0:56However, in the Harvard Business Review, the new new product development game,

1:01built in

1:02instability, they recognize there's going to be change.

1:05They recognize you're not going to know everything up front.

1:08So you need to get to work understanding that things are going to change.

1:12And as soon as you accept that, the easier it's going to be.

1:15But let's keep going.

1:17Deliver working software frequently from a couple of weeks to a couple of

1:21months with

1:22a preference to a shorter time scale.

1:25What are we talking about?

1:27Releasible versions.

1:29And we'll talk about this many times.

1:30We're talking about increments.

1:33At the end of every sprint, there should be something usable.

1:37What's usable is normally called an increment.

1:41An increment, not an increment.

1:44I'm not quite sure what happened there with my brain, but it happens.

1:49Business people and developers must work together daily throughout the project.

1:54What are we talking about?

1:56And I really like this one.

1:58Stop the silos.

2:00We talked about this a little bit early on.

2:02You cannot have stove-piped areas within your company and expect to move fast.

2:08Think about waterfall, their handoffs.

2:10You have concept, then design, then construction, then delivery, then

2:15operations and maintenance,

2:17and then sales and marketing.

2:19That's a really long process.

2:21It cannot happen here.

2:22If you want to move fast, everyone has to be integrated together, which is why

2:27agile

2:27is so, well, agile.

2:30Fast, adaptive.

2:32Let's keep going.

2:33Build projects around motivated individuals.

2:36Give them the environment and support they need and trust to get the job done.

2:41This is a really good one.

2:42And this is broken down to a simple word.

2:45Empowerment.

2:46Give them the direction.

2:48Give them their authority.

2:50Get out of the way.

2:51It's efficient and effective method is face to face.

2:55Talk often and directly.

2:58Now don't get wrapped around the idea that I'm working from home so I can't be

3:02as productive

3:03and I don't want to do the return to office thing.

3:06Remember, this is the theory of agile.

3:08Back then, when it was started, we didn't have a global pandemic.

3:13We didn't have Zoom.

3:14We didn't have teams.

3:15We didn't have any of that stuff.

3:17Everyone was going to the office.

3:18And everyone was largely face to face on these agile teams.

3:22And that's what they're talking about.

3:24You might be the perfect team remotely now with 95% functionality, success,

3:31whatever it

3:33is.

3:34But I promise you, there's a lot that can be gained from a rapport building,

3:39from an

3:40esprit de corps standpoint by being face to face.

3:44Just keep that in mind.

3:45The exam.

3:46Reality.

3:47We're in the land of the exam.

3:50Working software is the primary measure of success.

3:53This one is also very easy.

3:55Show results.

3:57It's all fun and games until you produce something.

4:00Show me the money.

4:02Show me results.

4:04Agile processes promote sustainable development.

4:07Sponsors, developers, users should be able to maintain that pace indefinitely.

4:12What do they mean?

4:14Find a steady pace and maintain it.

4:17Contain a steady pace.

4:19This goes back to team velocity and we will talk more about this throughout

4:23this course.

4:24Continuous attention.

4:26Technical excellence.

4:27Good design.

4:28Enhances.

4:29Agility.

4:30What are we talking about?

4:32Clean code.

4:33Why do we care about clean code?

4:35It makes it easy to grow.

4:37You're going to learn about something called technical debt at some point in

4:41this course.

4:41And I'll just give you a preview now.

4:44Technical debt is when you take a shortcut, perhaps during a sprint to deliver

4:48that working

4:49increment 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

5:01it can

5:02get really deep.

5:03If you have too much technical debt, you can't progress forward.

5:08You are only moving backwards to fix what is stopping you from moving forward.

5:13And it can really add up.

5:15Clean code.

5:16No technical debt or less technical debt.

5:18It becomes easy to grow if you find that sustainable rhythm, that velocity

5:23where you

5:24can 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

5:34product backlog,

5:35which we're going to talk about, all of those features and characteristics that

5:39your customer

5:39wants, and you're moving them into the sprint backlog, the items you're saying

5:44you're going

5:45to deliver, part of your increment.

5:49Well, technical debt can get put in the backlog as well because you have to fix

5:54it.

5:55The less technical debt you have, the more features, characteristics, and clean

6:01story

6:01points, if you will, that you're able to produce.

6:04That's what we're talking about here.

6:06Simplicity is essential.

6:09This one is very easy.

6:10I like this one because it simply means the kiss principle.

6:14Keep it simple.

6:16Seriously.

6:17Now I've heard keep it simple, stupid, but this is a family-friendly show and I

6:21don't

6:21like to call people stupid.

6:23So keep it simple.

6:25Seriously.

6:26We're almost done.

6:27Let's keep going.

6:28The best architecture is requirements and designs, merge, emerge, excuse me,

6:33self-organizing

6:34teams.

6:35What are we talking about here?

6:37Trust.

6:38Earlier, I brought up empowerment.

6:41Here we are talking about trust.

6:44If you can't trust them, you can't empower them.

6:47And if you don't empower them, you never learn to trust them.

6:50They kind of go hand in glove.

6:52And the last one at regular intervals, the team reflects on how they can be

6:57more effective,

6:59adjust its behaviors accordingly.

7:01This is very important because you are always improving.

7:05Why is this important?

7:07Because one of the scrum events is called the Sprint Retrospective.

7:11The Sprint Retrospective is all about the people and the process.

7:16What got in their way, what made it better, what do they need to fix.

7:21And remember, a sprint can't be more than a month long.

7:25I actually haven't told you it yet, so maybe this is the first time you're

7:28hearing it.

7:29And you're not going to remember it, but you're going to hear it a lot.

7:32You look at the product, the increment during the sprint review, you look at

7:36the people.

7:37And the process is during the retrospectives.

7:40We're going to talk about the 5 scrum events real soon, but this one is very

7:44important.

7:45Imagine if you had an opportunity as a team to improve every single month.

7:50That 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.

0:02We're going to figure out what the differences are between Agile,

0:07yes I'm using air quotes, Scrum and Waterfall.

0:10And I think this is going to lay the foundation so you can tell the differences

0:14between the three.

0:15One is kind of like the other and one has nothing to do with the other.

0:20So let's get into it and check it out.

0:22Let me grab Mr. Penn here.

0:24So let's talk about the type.

0:26What are we talking about? Agile is really a mindset along with some principles

0:33.

0:33I almost wrote Pringles because I like Pringles.

0:36Whereas Scrum is an actual framework.

0:41It's very loose.

0:42There are some time boxes and we're going to talk about this quite a bit but it

0:46's a framework within Agile.

0:49Waterfall is more of a linear methodology.

0:54I'm not saying one is better than the other. I'm simply saying there are some

0:58differences.

0:58If you're in a heavy construction environment, heavy engineering environment,

1:03heavy oversight

1:04environment with tons of documentation, you're going to see Waterfall.

1:08Agile and Scrum, not about that. And let's keep going.

1:12The approach in Agile is iterative and incremental.

1:18And yes as always I will post these.

1:21I'm sorry for the writing. It's just how I am.

1:24Uh-huh. Scrum is also iterative but with sprints.

1:28Now those sprints are going to become very important.

1:31Whereas the approach in Waterfall is very sequential.

1:34And we've talked about this many times.

1:37Concept design, construction, release, etc. Pretty easy.

1:41The structure in Agile, you'll like this one, is flexible and adaptive.

1:47In Scrum, it's time-boxed. Meaning things are done in certain amounts of time.

1:54And they are very important. There are five Scrum events.

1:57They have specific no greater than times.

2:00And we're going to talk about it quite a bit.

2:02Whereas Waterfall is more of strict phases.

2:05Let's talk about some planning.

2:07In Agile, as a mindset, it's merely continuous and evolving.

2:12I like that. Whereas in Scrum, there are sprint planning before each sprint.

2:19Now this goes back to what I said a moment ago.

2:21There is sprint planning that's sprint planning since we're already talking

2:26about it.

2:26It can last no more than eight hours for a one month sprint.

2:31There are two events right there.

2:34Sprint planning and the sprint.

2:36And let's keep going.

2:38We're going to talk about this quite a bit.

2:40Whereas in Waterfall, there's a ton of upfront planning.

2:44Which is why it takes so long to get anything done.

2:47Let's talk about documentation.

2:49Usually it's very minimal, which is fantastic.

2:53In Scrum, it's minimal as well.

2:56And you typically see it in the form of backlogs.

3:00Not that big a deal.

3:01In Waterfall, very heavy and formal.

3:04So there we go.

3:05There are the first five categories.

3:08Let's keep going.

3:09Let's clear the screen and let's move on.

3:12Let's talk about delivery style.

3:14Small working increments in Agile.

3:17Here you have Per Sprint.

3:20Your delivery style is Per Sprint in the form of increments as well.

3:25Now there's a nuanced difference here.

3:29Scrum produces a working increment.

3:34Excuse me at the end of every sprint.

3:36The Agile as a mindset means we can back off of that

3:41and have a working increment.

3:43But it's not necessarily confined to that one month.

3:46And in Waterfall, your delivery style is at the end.

3:49Customer involvement is frequent along with feedback.

3:53Feedback is the breakfast of champions.

3:56Thank you, Ken Blanchard.

3:57The interesting thing about Scrum is the product owner represents the customer.

4:03Let's just go with product owner reps.

4:05He is the voice of the customer.

4:08And in Waterfall, it's normally at the beginning and the end.

4:12Now that can change depending on the kind of project, the kind of industry, etc

4:16.

4:16But typically in Waterfall, you see it largely at the front, largely at the end

4:21.

4:21Change embraced, which is fantastic.

4:25Expected.

4:26Now for Scrum, it's accepted within the backlog.

4:30There is no arbitrary change.

4:32It must be done through the product backlog and the sprint backlog.

4:36In Waterfall, it is very formal and very often discouraged.

4:42I think this is a good place to take a break.

4:44We've talked about eight of them.

4:46When we come back, we'll finish the other seven.

4:48So 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

0:04still have Mr. Pen.

0:06Let's go. Let's talk about the team structure cross-functional. They know a lot

0:11about a lot. They move

0:13seamlessly among these. They are also

0:16self-organizing, which is very cool. In Scrum, you have a product owner, you

0:23have a Scrum master, and you have

0:27developers or devs. That's it. There are no other team members. In waterfall,

0:34they are

0:34siloed. You might have analyst, engineers, project, manager, salespeople,

0:40marketing people, etc.

0:41They are siloed. Meetings, as needed. I like that one. Now in Scrum, there are

0:47defined meetings.

0:49You have planning,

0:51Sprint planning at the beginning of every sprint. You have the daily Scrum,

0:55which we're going to talk about. You have the reviews and

0:59the retrospectives. Let's just call them retro. These are very defined. They

1:04are Scrum events.

1:06There are any other...

1:08How do I want to say this? Any other meetings held during the sprint are not

1:14formal. They are informally held among the

1:17self-organizing team members. Now, meetings in waterfall. Let's just go with

1:21all of them.

1:22You can have milestone meetings, status meetings, change meetings,

1:26client meetings, whatever it is. So there are lots of meetings. So we have five

1:30more of these. Let's move on.

1:32Let's wrap this up. So success measures in agile,

1:36value. And when I say value, I mean customer value. Does the customer find

1:42value in it? Because if the customer does, great, you are

1:46delivering on whatever those success metrics are

1:49for the customer. It's not what you believe. It's what they believe. And can

1:54the customer change it based on feedback from

1:57external to the company, perhaps with the end users or internal to the company

2:02with, you know, leadership?

2:04Absolutely. That can be changed at any time, but you are always seeking

2:09value.

2:10Value has to be defined though. Let's move on. Success measurements here are

2:15increments at the end of every sprint. If you are delivering a working

2:21increment, you are moving towards

2:23some sort of success measurement. And in waterfall,

2:27it's at the end. Hopefully you are delivering whatever was in the document or

2:32approved scope because if you didn't,

2:33you'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

2:43risk can change.

2:43Now in Scrum, it's adjusted every sprint. This will make more sense when we

2:49talk about that.

2:50And in waterfall, risk handling is all the way through. You can have risk

2:55events early.

2:56You can have risk events late. You can have risk events on the very last day.

2:59It really does depend. Let's talk about quality.

3:02I love this because it is built in.

3:06Quality is not inspected in. It is built in. In Scrum, it is the definition of

3:14done.

3:14Whoops, that's Department of Defense.

3:16The definition of done and we're going to talk about that. Now the quality

3:21focus here. How do we know we've achieved it with quality assurance and

3:25quality control. Quality has to be defined. It has to be measurable. It has to

3:31be tracked in any of these.

3:34So I always love talking about quality. Now the best use for agile are those

3:39projects that need flexibility and they are evolving.

3:43The best use case for Scrum is when the team needs structure. And by structure,

3:50I mean Scrum events that are time-boxed.

3:53In waterfall, you're talking about stable predictable requirements. Let's just

3:59call those wrecks.

4:00And yes, I forgot how to spell predictable for a moment because my brain was

4:04being unpredictable.

4:06Let's talk about some quick examples and wrap this up. When you talk about the

4:10broad use case of agile, you're talking about can-ban.

4:14You're talking about extreme programming. It can be used for lean projects.

4:19Now when you talk about Scrum, you're talking about software development. Easy

4:24peasy lemon squeezy, no problem on that one.

4:27And some easy examples of waterfall, construction, manufacturing, government R

4:33FPs.

4:34There you have it folks. 15 ways to compare agile, Scrum, waterfall. Again,

4:40there is a nuance here.

4:42Think of agile as this big idea about being adaptive and flexible and being

4:48able to evolve.

4:49Add a little bit of structure to it for software within it and you get Scrum.

4:55So, agile, waterfall.

4:58Within agile, you have a more solidified framework called Scrum, which is what

5:04professional Scrum Master 1 is all about.

0:00So what is empiricism anyway?

0:02I don't know, but I bet we can figure it out together.

0:06And I have a bunch of examples to explain it.

0:09So let's get to it.

0:10And to be fair, I actually do know.

0:13I just want to make it feel like we're learning together.

0:15All right, let's stop all that nonsense.

0:18Let's get to it.

0:19What is empiricism?

0:21Well, at its core definition, it means making decisions based

0:25on what is known.

0:27Facts, observations, experience, not assumptions, not

0:31predictions, not trusting your gut.

0:34What is known?

0:35What has happened?

0:36I love this.

0:38People get mad at me all the time on a project

0:40because they're losing their mind, their hairs on fire.

0:43We have to do this.

0:44We have to do that.

0:45And I will always say, well, what exactly happened?

0:49Not what you think.

0:50What exactly happened?

0:52And until we know exactly what that is,

0:55we can't do anything.

0:56So I love this right out of the gate,

0:59making decisions based on the facts, the data.

1:04But let's move on.

1:05I'm going to get off my pedestal and keep going.

1:07Now, from the Scrum View, Scrum is

1:10built on empiricism with three pillars.

1:12And this is very, very important.

1:15Transparency, inspection, and adoption.

1:18So start thinking about this.

1:20Tia, transparency, inspection, adaption.

1:25Say it to yourself 2,700 times by the end of this course.

1:29And you're probably going to pass.

1:30And no, I'm not making that up.

1:32Transparency, inspection, and adaption.

1:35And let me give you some examples.

1:37Now, think about predictive thinking.

1:39Where predictive models plan everything upfront,

1:41obviously, empirical methods adjust based on what has actually

1:47happened or what is happening.

1:50I think there's a typo there.

1:51Don't hold it against me.

1:53I think I miss-spoke-ified, as we say in Tennessee.

1:56But again, we're not planning everything upfront

1:59because it takes forever.

2:00We are reacting to what has happened

2:03or is happening right now.

2:05And a project level application.

2:08For empirical project management,

2:11you inspect frequently and adapt based on what's happened.

2:17The plan cannot expect to be unchanged.

2:21That is ridiculous.

2:22Why would you plan a route to go anywhere

2:25and suddenly there's traffic or an accident or a street

2:29light out or Godzilla, some other calamity and go,

2:33no matter what, we're staying the course.

2:36That is ridiculous.

2:37You don't do that.

2:39You are going to inspect what is happening.

2:42You are going to adapt to it.

2:45The only one we're missing is transparency.

2:47And we're going to get to that pretty quick.

2:49Think about risk management.

2:51Empiricism reduces risk by shortening the feedback loop.

2:55In predictive project management,

2:58sometimes you have to wait a long time

3:00to see if something's going to work out.

3:02That doesn't happen here.

3:04A sprint can be no more than one month long.

3:08We haven't talked about the Scrum events yet, but it's coming.

3:11So think about that.

3:13If you were doing anything and you could adjust every one

3:17month or less, your risk level is going to come down

3:21compared to having to wait three, four, five, six months.

3:26This is fantastic.

3:27This is why the risk level is so low usually on Scrum projects.

3:32Now, there are a lot of variables out there,

3:35but by far they are less risky by their very nature,

3:39by their processes, by their framework,

3:42than predictive projects.

3:43Think about leadership.

3:45Leadership would ask, what does the data show

3:49before jumping to conclusions or trusting your gut?

3:52What are we doing here?

3:54We are inspecting.

3:55We're also being transparent.

3:57If you jump to conclusions, you're not following the rules.

4:01Remember, TIA Transparency, Inspection, Adaption,

4:06I'm going to say it until you are sick of it,

4:09and it is going to serve you well, I promise you.

4:12Let's take a look at some real-time evidence.

4:14Empirical teams, Scrum teams are looking at burn-down charts,

4:18velocity trends, and user feedback.

4:21Data, replaces, guest work.

4:23What are we looking at?

4:25If you look here and here and here,

4:29you have transparency.

4:31And I mostly spelled it right, but that's

4:33crazy cursive as I call it.

4:35We are not guessing.

4:37We know.

4:38We can see it.

4:40We can see it.

4:41We can hear it.

4:42Transparency, Inspection, Adaption.

4:46I feel like there's a trend going on here, Bob.

4:48Well, you would be correct.

4:49And look at team dynamics.

4:51They inspect their own performance in retrospectives

4:54and adapt how they work.

4:57So let me just go ahead and let this cat out of the bag.

5:00At the end of every sprint, there's a sprint review.

5:03You review the working increment with the customer,

5:06either internal or external, or both.

5:08It does not matter.

5:09You're focused on the product, the increment, the software,

5:14whatever that is.

5:16Then you have a retrospective, which

5:18is all about the people and the processes.

5:21What did we do well?

5:22Where are our opportunities for improvement?

5:25What are the blockers, if any?

5:28You are inspecting, and then you are adapting to that.

5:33And once again, imagine going to the gym every day.

5:38And on the third day, you took a look back

5:41at the previous couple of days, and then you adapted

5:43how you were going to do the next couple of days.

5:46Now I know that's kind of fanciful.

5:48But with that kind of quick adaption from that inspection,

5:53imagine how quickly you could course

5:55correct to stay on track doing anything.

5:58It's amazing.

5:59And the interesting part of this is, anyone can do this.

6:02What we don't have while we have a pile of transparency

6:08inspection and adaption, what we really lack, lack, excuse me,

6:12is discipline.

6:14That's why we're not all yoked up at the gym,

6:17because pizza does not make me feel good about my workout.

6:21It just makes me feel good about life.

6:23All right, I'm off the pizza soapbox, too.

6:26Let's keep going.

6:27Let's do one or two more, and we'll take a little break.

6:29And when we look at it in action,

6:31it is a requirement for empiricism.

6:34Transparency.

6:36How can you adapt if you hide bad news?

6:39And you've heard me say this before.

6:41Bad news does not get better with time.

6:43So when you have a burn-down chart that

6:46shows the team's velocity or the product backlog that

6:51shows how many story points are there,

6:54or how many story points are in the sprint backlog,

6:58it's transparent.

7:00Everyone can see it.

7:01Or if you have a can-band board to show what's waiting,

7:05what's in progress, what's finished, you have transparency.

7:09What do you have when you have transparency?

7:12You have trust, and that is the only way you can get it

7:16by being transparent.

7:18Let's do one more, and then we'll take a little break.

7:20Talk about testing and learning.

7:22Empirical processes encourage experimentation.

7:26Try it, observe it, learn from it, and adapt to it.

7:31Why would we do that?

7:32Well, let's think back to it.

7:34Tia, transparency, inspection, and then

7:38adaption.

7:38If we don't understand it, we're not

7:41going to rush blindly into it.

7:43We're going to figure out what we might do, test it out,

7:48AKA inspected, and based on what we learn,

7:51we are going to adapt to it.

7:53And if anyone asks what we've done or what we're doing,

7:56we're going to add that T there and be transparent about it.

7:59All 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

0:05because I'm having a really good time.

0:07And did I mention to remember Tia, Transparency, Inspection, Adaption?

0:13Yes, Bob, you did, and we're sick of it.

0:16Let's talk about client communications.

0:18Through empiricism, we show the client a working increment at the end of each

0:23sprint.

0:24And I love this statement that I said, "These aren't promises on a Gantt chart

0:28."

0:29What are they doing right here? That would be Inspection.

0:33And oh, by the way, we are also being transparent about it.

0:38And based on their feedback, we are going to adapt to it.

0:43I feel like there's a pattern here. I really, really do.

0:47Well, you would be correct. Transparency, Inspection, and Adaption.

0:52Think about value delivery. Empiricism prioritizes based on actual user

0:59feedback.

1:00It's not based on what we think is valuable. It's based on what they, whoever

1:05they are, think is valuable.

1:08Now we are adapting.

1:10I'm already sick of Tia, but you're not going to forget it. I promise you that.

1:14And here's the Agile Tying.

1:16Agile principles, and we talked about it before earlier in this skill,

1:20Embrace Empiricism by Favourying, Working Software,

1:24Face-to-Face Conversation, and Regular Reflection.

1:28Well, hmm.

1:30If we are face-to-face, what do we have?

1:34Well, we have conversations, but we are being transparent.

1:38Alright, I can put up with that. If we have Working Software, we are obviously

1:44inspecting.

1:45And if we have regular reflection, like Retrospectives and Reviews, we have

1:51Adaption.

1:52Yep, I'm just going to keep saying it. These are the Pillars of Empiricism.

1:58I say they are the Pillars of Scrum, Tia, Transparency, Inspection, and Adapt

2:03ion.

2:04And when we get to the five Scrum Events, and it's coming really fast,

2:08you are going to see Tia play out over and over and over. It must be so.

2:14Think about Change Responsiveness.

2:16Teams respond with facts, not fear. Why? Transparency, Inspection, and Adaption

2:23.

2:23And remember, Instability is built in. They know they are going to change.

2:29And the sooner you embrace that change, the easier it is to respond.

2:34We are getting there. We are almost there. Look at the Cultural Impact.

2:37A Culture of Empiricism promotes honesty, learning, continuous improvement.

2:44It also rewards curiosity without blame. And once again, without transparency,

2:51you cannot have trust.

2:53If you don't have trust, you don't have honesty, you have low learning, and

2:57there is not going to be any improvement.

2:59What are we going to have? The blame game. Over and over and over.

3:04I know you folks have seen it in the past. Remember, Transparency, Inspection,

3:09and Adaption.

3:11When we come back, I'm going to give you some examples of all three until you

3:15are 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

0:04I'd like to do a practical exercise related to Tia

0:08Transparency inspection and adaption. So here's what we're gonna do ladies and

0:14gents. We're gonna go through

0:16I'm gonna give you 10 examples

0:18I'm gonna give you a few seconds to think about it, and I want you to decide is

0:23it transparency?

0:24Is it inspection? Is it adaption? I will explain each one

0:29Let's go the first one the product backlog is visible to everyone

0:34What does that feel like it's visible to everyone?

0:38Well, that one is definitely

0:41Transparency hope you got that one. It's visible. It's transparent. That was a

0:47an easy one

0:48I hope let's move on to another one you check the increments and you're getting

0:53feedback from the stakeholders

0:55You're checking the finished sprint deliverable if you will the increment and

1:00you're getting some feedback

1:02What are you doing? It sounds like

1:04inspection

1:07Excellence I hope this isn't too difficult

1:10I know it's the very first skill, but by the time you get midway through this

1:14series you're gonna be rocking it

1:16So let's move on

1:18You're clearly communicating the sprint goal is that transparency

1:23inspection or adaption

1:25Clearly communicating it feels to me like you're being

1:30Transparent if you got transparent you are correct the next one

1:35Adjusting the next sprint based on the past team velocity that should say past

1:42Sprint 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

1:53are adjusting?

1:54You are adapting. That's exactly right. Let's keep going the product donor

2:01Reprioritizes the backlog after losing a developer. Well, why would you lose a

2:06developer?

2:06People get sick people go on vacations people quit their job people get fired

2:13Hopefully not in this case people get assigned to other teams if you

2:19Reprioritize you are doing what I bet you're adapting

2:23Reprioritize 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

2:35you got adaption

2:36You are correct, but it does feel a little bit like inspection, but it's really

2:41adaption. Let's go on sharing the definition of done

2:45The definition of done can be thought of as some sort of quality standard

2:49You're trying to hit and if you share that with the team, what are you doing?

2:54Are you being transparent? Are you inspecting or are you adapting to some event

3:00?

3:00It sounds like you're being transparent if you got transparent you are correct

3:05Let's keep going holding the daily scrum to discuss sprint progress

3:10If we hold the daily scrum to discuss sprint progress, what are we doing? Are

3:16we being transparent?

3:18Well, maybe are we inspecting?

3:22Well, what would what would we be inspecting excuse me the daily progress the

3:27sprint progress excuse me in the daily scrum

3:31Does it say we're changing anything because of it? I?

3:34Don't think so this one is inspection

3:37We are discussing the sprint progress

3:41Inspection and again, I know some of these are nuanced. This is only the first

3:46set of these we've done

3:47We're gonna do a lot more of them displaying the burn down chart for everyone

3:51to see that would really should be a no-brainer

3:53If we're displaying it everyone can see it. We're providing not hiding that is

3:59Transparency implementing actionable improvements from the retrospective. We're

4:05implementing we're changing

4:07Something and you know that if we're changing we are adapting. What are we

4:12adapting to?

4:12Whatever happened in the last sprint and once again?

4:16Their sprint retrospective is the team's opportunity to discuss what went well

4:21What were the blockers? What ideas do they have to improve the next sprint

4:26because remember one sprint starts right after another

4:29You come right out of a retrospective and then go right back into sprint

4:33planning and we're gonna talk about these events very very soon

4:36A few more and then we're done

4:38reviewing the list of backlog items think of the backlog as your list of

4:44Characteristics or items or once in needs for this particular software if we

4:50are reviewing we are

4:52Inspecting excellent and once again

4:56Remember Tia

4:59Transparency

5:00inspection

5:01Adaption if you have transparency you have trust you have empowerment if you

5:08have inspection

5:09You can adjust I know it's a lot. I hope you've enjoyed this particularly with

5:16Tia one more time

5:18What's it stand for?

5:20Transparency inspection and

5:22Adaption and yes those three will become very very important throughout this

5:28entire series and very important on the PSM1

5:31I'll see you in the next skill and thank you for putting up with me in this

5:36first one