Executing an Agile Project Part 2
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Transcription
00:01
>> Hello, and welcome to Lesson 5.2,
00:01
Executing an Agile Project Part 2.
00:01
I'm your instructor, Kane.
00:01
Let's go ahead and wrap up this whole execution thing.
00:01
We talked about in the last video,
00:01
that you plan your sprint,
00:01
you overload to the best of your ability.
00:01
You take that [NOISE] weight trainer mentality to heart
00:01
[NOISE] and then the sprint comes to an end.
00:01
You have production-ready features for
00:01
your software and you push
00:01
that to production and then you have
00:01
some sprint retrospective or sprint after-action review.
00:01
They call it different things.
00:01
But the idea is that the sprints over we get together,
00:01
we want to talk about it and want to see what we did.
00:01
We talk about both the positives and the negatives.
00:01
I was able to do more than I thought I
00:01
could or less than I thought I could,
00:01
whatever the case might be it really depends.
00:01
But the key is,
00:01
is that we have a formalized functional review,
00:01
and it's built into our sprint process,
00:01
so you're forced to have it.
00:01
That's a good thing because you want to be able to
00:01
focus on what you did right and improve on it.
00:01
Improve the sprint velocity,
00:01
improve our productivity,
00:01
improve our process every single time.
00:01
Part of that is what's called a self-correction.
00:01
If you look at the picture here on
00:01
the right-hand side of the slide,
00:01
we've got different velocity
00:01
across two different sprints.
00:01
The point of this is to show that for the first sprint,
00:01
the one on the left-hand side of the picture,
00:01
we achieved what we set out to achieve.
00:01
Nothing more, nothing less. That's fine.
00:01
There's nothing wrong with that. But that
00:01
shows us that we can push ourselves a little bit more.
00:01
In the second sprint, we actually,
00:01
were able to produce a rescan it ourselves for
00:01
more work and we were actually able to
00:01
produce more effort points
00:01
than what we had actually scheduled.
00:01
It goes to show you that as
00:01
the team builds their capability,
00:01
they're going to be able to not only
00:01
overproduce from the previous sprint
00:01
and improve their capability,
00:01
but they're also going to sometimes overproduce what
00:01
their own estimation was and that's where
00:01
the estimation self-correction part comes into play.
00:01
In this example that I have on the slide here,
00:01
it says that our average velocity is 13,
00:01
but in sprint number 2,
00:01
we were able to complete 17 units of
00:01
work when we only had planned for 15.
00:01
In this example, sprint number 3,
00:01
we would want to schedule
00:01
a potentially even more effort in order to continue
00:01
to push the team
00:01
to be as efficient and effective as they possibly can.
00:01
I mentioned it a couple times before
00:01
that's what I mean by self-correction.
00:01
As we see the team improve their performance,
00:01
we continually challenge the team to produce at
00:01
the highest level of
00:01
their capability so that we get
00:01
maximum value for our investment.
00:01
This also illustrates the advantage of
00:01
the pull versus push work system.
00:01
Had we relied on a push work system in sprint number 2,
00:01
we would have probably only accomplished
00:01
15 units of work as opposed to
00:01
the 17 because there would have been no mechanism
00:01
available for the developers
00:01
to get additional work once they had
00:01
already completed the work that
00:01
they had scheduled for them.
00:01
Going back to that hybrid,
00:01
we want to take advantage of
00:01
all the systems that are available to a kind of thing.
00:01
That's where it really starts to show value for
00:01
the organization because by having a poll system,
00:01
we scheduled 15,
00:01
we self-corrected all that stuff.
00:01
But then we were even more efficient than we
00:01
thought we could be in that sprint,
00:01
and so we pulled
00:01
additional new work into our environment,
00:01
completed that new work got it
00:01
into production and it actually created
00:01
more value for the organization than
00:01
we even thought that we were going to be able to do.
00:01
That's just a good example of
00:01
multiple flavors of Agile
00:01
where it becomes a good thing for the organization.
00:01
At the tail end of the sprint,
00:01
we want to look and see what we've done.
00:01
We want to challenge ourselves plural,
00:01
to be as productive as we possibly can be.
00:01
At the same time,
00:01
we want to make sure that we have
00:01
systems in place to eliminate
00:01
bottlenecks so that we don't have
00:01
any wasted effort within the project,
00:01
and if the developers are able
00:01
to add more work then go ahead and add more work.
00:01
Now where the challenge comes in
00:01
this environment is we
00:01
did 17 units of work for that last sprint.
00:01
Let's say we schedule 17 units of
00:01
work for the follow-on for sprint number 3,
00:01
and we were only able to get done 16.
00:01
Or we rescheduled 20 and we only get 17 done.
00:01
There has to be some mechanism within the organization to
00:01
prevent that from being viewed as a negative externality.
00:01
We don't want to look at failure as a bad thing.
00:01
We have to have something in place to show
00:01
that we are overproducing and
00:01
we're pushing our team to the limit of their capability
00:01
and any potential failures are really more of,
00:01
I guess, I hate to even use the word failure because
00:01
there's such a negative connotation around failure.
00:01
But we look at this as we're
00:01
trying to find our happy spot.
00:01
We're trying to find our velocity that we're
00:01
capable of maintaining throughout
00:01
the course of the project.
00:01
There might be 15,
00:01
or 17, or 16,
00:01
or 20, or 30,
00:01
or whatever it is.
00:01
But it's all about trying to figure out
00:01
what the average velocity of the group is,
00:01
and not somehow look at
00:01
them negatively based on their production.
00:01
What happens traditionally if you
00:01
create some negative reinforcement for failure,
00:01
is that the estimation process
00:01
doesn't self-correct and that's
00:01
really what we're trying to avoid.
00:01
If you only reward success and you
00:01
punish failure then I promise you
00:01
that you're going to have is a lot of
00:01
sprints where we estimate 10 we accomplished 11.
00:01
We estimate 10,
00:01
we accomplish 11 or 10.
00:01
If you don't fail,
00:01
then you're not actually executing
00:01
an Agile project at the level
00:01
of productivity that is capable of doing.
00:01
That's what we want to avoid and that's why
00:01
I keep bringing this whole thing up and
00:01
I use the weightlifting analogy in the previous video.
00:01
The goal is to
00:01
continually push the team to produce what they're capable
00:01
of producing without punishing them
00:01
for overestimating and things of that nature.
00:01
The good side about this is
00:01
that as you can see from the previous videos,
00:01
a team that's not very good at
00:01
estimating will become very good at estimating.
00:01
History will allow them to adjust their metrics in
00:01
such a way is that you will be able to estimate
00:01
future productivity based on past performance.
00:01
If you look at it as a constructive process and you don't
00:01
punish anybody for not being able
00:01
to achieve what they had originally estimated.
00:01
That's the idea of executing,
00:01
is trying to find
00:01
that magic middle ground
00:01
between underestimating and overestimating.
00:01
If you follow the processes
00:01
correctly, it does self-correct.
00:01
But if you don't follow them or you create
00:01
some incentive to behave one way or the other,
00:01
then unfortunately, you don't get the benefits of agile.
00:01
As I mentioned before,
00:01
there are certain situations where agile gets
00:01
a bad reputation for lack of documentation,
00:01
lack of performance,
00:01
it's a black hole where we just pour money,
00:01
and I think my goal for this course is to
00:01
illustrate areas where
00:01
that behavior creates that perception.
00:01
If you want Agile to be successful,
00:01
these are the areas to avoid.
00:01
Thank you very much and I will see you in the next video.
Up Next
Similar Content
