Hello and welcome to lessen 5.2.
Executing our agile project. Part two. I'm your instructor cane, and let's go ahead and wrap up this whole execution thing.
So we talked about in the last video that
you plan your sprint. You kind of overload to the best of your ability. You take that weight trainer mentality
and then the sprint comes to an end. You have production readies features for your software,
you push that to production and then you have some sort of sprint retrospective or sprint after action review. They call it different things, but the idea is sprints over. We get together, we want to talk about it. We want to see what we did,
and we talk about
both the positives and the negatives. I was able to do more than I thought I could, or less than I thought I could. Whatever the case might be,
I really kind of depends. But
the key is is that we have a formalized, functional review, and it's built into our sprint process,
so you're forced tohave it, and that's a good thing because you want to be able to focus on what you did right and improve on it.
Improve the the sprint velocity, improve our productivity, improve our process every single time.
So part of that is
what's called a self correction. So if you look at the picture here on the right hand side of the side, we've got different velocity across to different sprints.
And the point of this is to show that for the first sprint, the one on the left hand side of the picture,
achieved what we set out to achieve. Nothing more, nothing less. Okay, that's fine. Nothing wrong with that. But that shows us that we could push ourselves a little bit more so in the second.
This friend, we actually
we're able to produce rescheduled ourselves for more work,
and we were actually able to produce
MAWR effort points than what we had actually scheduled. So it goes to show you that as the team
builds their capability, they're going to be able to not Onley overproduce
from the previous sprint and improve their their capability. But they're also going to sometimes overproduce
what their own esteem estimation waas. And that's where the estimation self correction part comes into play.
So in this example that I have on the slide here.
It says that you know, our average velocity is 13
but in Sprint number two we were able to complete 17 units of work when we only had playing for 15. So in this example, spread number three. We would want to schedule potentially even more effort in order to continue to push the team to
B is efficient and effective as they possibly can. So that's what I'm I mentioned a couple times before.
That's what I mean by self correction.
As we see the team improved their performance, we continually challenge the team
produce at the level
we're at the highest level of their capability so that we get maximum value for our investment.
It is also illustrates the advantage of the poll vs push work system. So had we relied on a push work system
in Sprint number two, we would have probably only accomplished 15 units of work
as opposed to the 17 because there would have been no mechanism available for the developers to get additional work. One state already completed the work that they had scheduled for them, So
going back to that hybrid we want toe take advantage of all the systems that are available to us kind of thing. That's where it really starts to to show value for the organization, because by having a pull system
we scheduled 15. We self corrected all that kind of stuff.
But then we were even more efficient than we thought we could be in that sprint. And so we pulled additional new work into our environment, completed that new work gotta into production, and actually created more value for the organization than we even thought that we were going to be ableto
And that's just a good example of
sort of that
multiple flavors of agile where it becomes
a good thing for the organization. So
at the tail end of the sprint, we want to look and see what we've done. We want to challenge ourselves to be
challenge ourselves plural,
to be as productive as we possibly can be.
At the same time, we want to make sure that we have systems in place to eliminate bottlenecks so that we don't have any wasted effort within the project. And if
the developers are able to add more work than go ahead and add more work now where the
the challenge comes
in This environment is we did 17 years of work for that last sprint.
So let's say we schedule 17 years of work for the follow up for a sprint number three,
and we were only able to get done 16 or rescheduled 20 and we only get 17 done.
There has to be some mechanism within the organization to prevent that from being viewed as a negative externality. We don't want us to look at failure as a bad thing,
so we have to have something in place to show that
we are over producing
and we are pushing our team to the limit of their capability, and any potential
failures are really mawr of.
I hesitate, even use the word failure because there's such a negative connotation around failure. But we look at this as we're trying to find our happy spot. We're trying to find our velocity that we're capable of maintaining throughout the course of the project, so there might be
15 17 and 16 2030 off wherever it is, you know. But it's all about trying to figure out what the average velocity of the group is, and not
somehow look at them negatively based on their production. So
what happens traditionally, if you, if you create some sort of negative reinforcement for failure, is that the estimation process
doesn't self correct, And that's really what we're trying to avoid. If you Onley reward success and you punish failure, then I promise you that what you're gonna have is a lot of
sprints where we estimate 10. We accomplish 11. We estimate 10. We accomplish 11 or 10.
If you don't fail,
then you're not actually executing an agile project at the level of
productivity that is capable of doing so. That's kind of we want to avoid. And that's why I keep bringing this whole thing up,
and I use the weightlifting analogy in the in the previous video. The goal is to continually push the team to produce what they're capable of producing without punishing them for over estimating and things of that nature. The good side about this is that
as you can see from the previous videos,
a team that's not very good, estimating will become very good at estimating history, Will will allow them to adjust their metrics in such a way is that you will be able to estimate future productivity based on past performance
look at it as a constructive process and you don't punish anybody for not being able to achieve what they had originally estimated.
So that's the idea of X shooting. Is the trying to find
middle ground between
underestimating and overestimating? And if you follow the process is correctly, it does self correct. But if you don't follow them or you create some sort of, uh,
to behave one way or the other than unfortunately, you don't get the benefits of agile. And as I mentioned before, there are certain situations where agile gets a bad
reputation for lack of documentation. Lack of perform is it's a black hole where we just pour money, and I think my goal for this course is to kind of illustrate areas where that kind of behavior creates that perception. So if you want Angela to be successful,
these are the areas to avoid,
so thank you very much and I will see you in the next video