Time
3 hours 55 minutes
Difficulty
Intermediate
CEU/CPE
4

Video Transcription

00:02
Hello and welcome to
00:04
Module five Angela Execution.
00:08
In this video, we will go over lesson 5.1,
00:11
executing an agile project part one.
00:15
Well, then, have a part to
00:17
We'll talk about daily Sanda meetings will talk about what we'll talk about in more detail, a minimum buyable project and then our minimum viable product, I should say,
00:29
And then we'll look at executing a can ban
00:32
project.
00:34
I'm your instructor cane and let's go ahead and get started.
00:38
So for part one,
00:41
we're gonna focus on
00:44
the beginning part of the execution and then in part two, will cover the tail in. But we're talking about here is
00:53
some form of it aeration, whether it's a sprint. Ah, release cycle. Whatever you wanna call it, they're all basically do the same thing,
01:03
and that is when you're actually executing the project. You have a
01:08
beginning phase off the execution chunk McCall to sprint just for brevity,
01:15
and then
01:17
you have a tail end of said Sprint.
01:19
So when we actually execute a project,
01:23
we have
01:25
another planning phase in addition to the project planning phase. And if you notice a lot of overlap, that's by design. The whole point of agile is to be
01:36
pretty consistently planning, changing, executing all at the same time so that we can be more dynamic and bring value to the business.
01:48
So we we went through some project planning on a little bit. His friend. Planning in the last video are the video prior to last video, and now we're going to dive into a little bit more detail.
02:01
So when we start our sprint noticing or Louise are his friends,
02:07
we have to plan
02:10
each friend
02:12
and try to estimate and figure out
02:15
what we can accomplish. And if you notice from the prior videos,
02:21
we wanted to
02:23
self correct. And so what that means is that we're going to try to maximize our utility were trying to maximize our productivity
02:32
in each friend. And that's why
02:36
ideally, you have a little bit of a break between each individual sprint
02:39
so people have a chance to recover because we want the intensity to be high.
02:45
This needs to be an all hands on deck major effort,
02:50
but
02:52
by being very aggressive on the planning side of each sprint, we know that we're not going to get everything done
03:00
that we put into the spring. So
03:02
in some ways is similar. Like weight training, for example,
03:07
you're not gaining strength and building muscle until you go to failure.
03:12
So
03:13
if you're a, uh,
03:16
amateur special, every if you're in the weightlifting
03:20
your life pretty much consists of failing to accomplish the thing that you set out for yourself.
03:25
It could be just hurting, but that is by design. When we do agile execution, we want to kind of think the same way. If we're not failing,
03:36
we're really not trying hard enough.
03:38
So if you're planning phase of each sprint includes, say, 15 effort points
03:44
and you consistently hit your 15 effort points every single time,
03:50
that doesn't mean you're really good at agile execution. What that means is you're not trying hard enough.
03:55
You're not pushing yourself.
03:58
So it's a different mentality tohave
04:01
and one that I think a lot of organizations struggle to really embraces the idea that failure is good because failure means that you're pushing yourself so in the sprint planning phase.
04:14
If you accomplished, say, 15
04:16
and
04:17
units of work last sprint,
04:20
then you want to schedule yourself for 17
04:24
20 where, where if it might be, but you want to constantly be pushing yourself until you reach the point of failure. And then once you've reached the point of failure, that becomes your new baseline.
04:38
So when we execute an agile project, we're going to look at the last sprint
04:46
and add to it every single time. We want to continuously improve continuously, be more productive than we were the last print,
04:54
and we will fail. And that's okay. It's okay to fail
05:00
at the sprint level because that makes it more likely that you're going to succeed at the project level.
05:06
So when you are planning phase, we load the sprint with as much stuff as we can get,
05:13
and then we start executing. We start developing, we start writing code
05:16
once we once the code is written and compiled and put into some sort of unit test or uh, test box or where we want to call it there. There's different terminology, But the idea is, once we think we have functional features,
05:33
then we go into a code reviewed phase because we know at the end of the sprint
05:39
we're going to be putting code into production so it could be a code review. You can call it unit Tasked. You can call it user acceptance testing. Whatever the case might be, they're all sort of the same thing. So let's say that we have 15 individual features
05:55
then we've built during this
05:57
agile sprint.
06:00
We want to then create enough time within the sprint to test and review those
06:08
items
06:09
before they actually go to production. The last thing you want to do an agile is send code to production and treat your customer as your beta tester.
06:18
That is always a recipe for success. Um, if you you follow technology, especially with the some of the new releases of both Windows and Mac, O asked everything else.
06:31
You hear a lot of accusations off. They're treating the users as beta testers, and that's because they're so focused on getting new features to market. But they're not adequately doing user acceptance testing, so you want a plan you want to overload.
06:47
But then you also want to do good user acceptance testing and good code review so that if something is not adequately tested, it comes out of the sprint.
06:56
We don't want to send defective
06:59
features to the end user
07:02
In addition to that, we also like we talked about in the previous videos. We need to have some kind of release schedule. So let's say we're doing two weeks friends.
07:13
Our sprint planning meaning is on the Friday afternoon before the next friend.
07:18
We sprint all week, building new features the following week. We have a code freeze
07:26
whatever day it will call it Tuesday. So we have a code freeze on Tuesday, and then
07:30
user acceptance testing happens between Tuesday and Thursday night. And then
07:36
once we have user acceptance, then we push to production Thursday night or Friday morning. So that's kind of an example of of the tempo,
07:46
the optempo that an Angela team can have based on a two week sprint. So
07:51
within the execution phase, what we're doing is where
07:57
overloading this print. We're building
08:00
new software, features and functions, and then we are pushing those two production after they've been tested by the user Adequately.
08:09
If your organization can't do that
08:13
successfully
08:15
within a two week period,
08:16
then you go to a three week period or four wherever that the release schedule that happens to be, it doesn't really matter. It's what that organization can deal with on on a day to day, week to week basis.
08:31
But at no time do you want to underestimate. And that's really the difference between
08:37
agile and waterfall.
08:39
Hey,
08:41
is accepting the failure because we pushed ourselves as hard as we possibly could?
08:48
That's the mentality difference.
08:56
All right, So in summary,
08:58
we began the process of talking about agile execution. And in the next video, I'm gonna go into the back half of said Sprint. When we talk about how do we handle
09:11
the spring? When is that his tail in? So we planet, we execute it, we build stuff were aggressive. We really try and do as much as we can with the time frame that we have. We know where time boxed in, but we're motivated and we're ready to rock and roll.
09:26
Well, then, at the tail end of that, then what do you do for the next time? So I will see you in the next video. I hope everybody has a great day

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