Time
3 hours 55 minutes
Difficulty
Intermediate
CEU/CPE
4

Video Transcription

00:02
Hello and welcome to lessen 5.2.
00:06
Executing our agile project. Part two. I'm your instructor cane, and let's go ahead and wrap up this whole execution thing.
00:14
So we talked about in the last video that
00:18
you plan your sprint. You kind of overload to the best of your ability. You take that weight trainer mentality
00:26
the heart,
00:29
and then the sprint comes to an end. You have production readies features for your software,
00:36
and
00:37
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,
00:51
and we talk about
00:54
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,
01:03
I really kind of depends. But
01:06
the key is is that we have a formalized, functional review, and it's built into our sprint process,
01:17
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.
01:25
Improve the the sprint velocity, improve our productivity, improve our process every single time.
01:33
So part of that is
01:36
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.
01:45
And the point of this is to show that for the first sprint, the one on the left hand side of the picture,
01:52
we
01:53
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.
02:05
This friend, we actually
02:07
we're able to produce rescheduled ourselves for more work,
02:14
and we were actually able to produce
02:16
MAWR effort points than what we had actually scheduled. So it goes to show you that as the team
02:24
builds their capability, they're going to be able to not Onley overproduce
02:31
from the previous sprint and improve their their capability. But they're also going to sometimes overproduce
02:38
what their own esteem estimation waas. And that's where the estimation self correction part comes into play.
02:46
So in this example that I have on the slide here.
02:49
It says that you know, our average velocity is 13
02:53
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
03:14
B is efficient and effective as they possibly can. So that's what I'm I mentioned a couple times before.
03:19
That's what I mean by self correction.
03:23
As we see the team improved their performance, we continually challenge the team
03:29
to
03:30
produce at the level
03:32
we're at the highest level of their capability so that we get maximum value for our investment.
03:40
It is also illustrates the advantage of the poll vs push work system. So had we relied on a push work system
03:52
in Sprint number two, we would have probably only accomplished 15 units of work
03:58
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
04:11
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
04:26
we scheduled 15. We self corrected all that kind of stuff.
04:30
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
04:50
to do.
04:51
And that's just a good example of
04:55
sort of that
04:57
multiple flavors of agile where it becomes
05:02
a good thing for the organization. So
05:05
at the tail end of the sprint, we want to look and see what we've done. We want to challenge ourselves to be
05:13
challenge ourselves plural,
05:15
to be as productive as we possibly can be.
05:18
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
05:30
the developers are able to add more work than go ahead and add more work now where the
05:36
the challenge comes
05:39
in This environment is we did 17 years of work for that last sprint.
05:45
So let's say we schedule 17 years of work for the follow up for a sprint number three,
05:50
and we were only able to get done 16 or rescheduled 20 and we only get 17 done.
05:58
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,
06:13
so we have to have something in place to show that
06:16
we are over producing
06:20
and we are pushing our team to the limit of their capability, and any potential
06:28
failures are really mawr of.
06:30
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
06:51
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
07:05
somehow look at them negatively based on their production. So
07:11
what happens traditionally, if you, if you create some sort of negative reinforcement for failure, is that the estimation process
07:24
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
07:36
sprints where we estimate 10. We accomplish 11. We estimate 10. We accomplish 11 or 10.
07:44
If you don't fail,
07:46
then you're not actually executing an agile project at the level of
07:54
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,
08:00
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
08:18
as you can see from the previous videos,
08:22
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
08:41
if you
08:41
look at it as a constructive process and you don't punish anybody for not being able to achieve what they had originally estimated.
08:52
So that's the idea of X shooting. Is the trying to find
08:58
that magic
09:00
middle ground between
09:03
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,
09:16
incentive
09:16
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
09:28
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,
09:46
these are the areas to avoid,
09:48
so thank you very much and I will see you in the next video

Up Next

Agile Project Management

This course will introduce the history, applicability, and techniques used in various Agile project management methodologies. Agile has become one of the fastest growing and most popular project management methods throughout IT.

Instructed By

Instructor Profile Image
Kane Tomlin
Executive Consultant at FDOT, Professor
Instructor