Hello and welcome to
Module five Angela Execution.
In this video, we will go over lesson 5.1,
executing an agile project part one.
Well, then, have a part to
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,
And then we'll look at executing a can ban
I'm your instructor cane and let's go ahead and get started.
we're gonna focus on
the beginning part of the execution and then in part two, will cover the tail in. But we're talking about here is
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,
and that is when you're actually executing the project. You have a
beginning phase off the execution chunk McCall to sprint just for brevity,
you have a tail end of said Sprint.
So when we actually execute a project,
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
pretty consistently planning, changing, executing all at the same time so that we can be more dynamic and bring value to the business.
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.
So when we start our sprint noticing or Louise are his friends,
and try to estimate and figure out
what we can accomplish. And if you notice from the prior videos,
self correct. And so what that means is that we're going to try to maximize our utility were trying to maximize our productivity
in each friend. And that's why
ideally, you have a little bit of a break between each individual sprint
so people have a chance to recover because we want the intensity to be high.
This needs to be an all hands on deck major effort,
by being very aggressive on the planning side of each sprint, we know that we're not going to get everything done
that we put into the spring. So
in some ways is similar. Like weight training, for example,
you're not gaining strength and building muscle until you go to failure.
amateur special, every if you're in the weightlifting
your life pretty much consists of failing to accomplish the thing that you set out for yourself.
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,
we're really not trying hard enough.
So if you're planning phase of each sprint includes, say, 15 effort points
and you consistently hit your 15 effort points every single time,
that doesn't mean you're really good at agile execution. What that means is you're not trying hard enough.
You're not pushing yourself.
So it's a different mentality tohave
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.
If you accomplished, say, 15
units of work last sprint,
then you want to schedule yourself for 17
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.
So when we execute an agile project, we're going to look at the last sprint
and add to it every single time. We want to continuously improve continuously, be more productive than we were the last print,
and we will fail. And that's okay. It's okay to fail
at the sprint level because that makes it more likely that you're going to succeed at the project level.
So when you are planning phase, we load the sprint with as much stuff as we can get,
and then we start executing. We start developing, we start writing code
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,
then we go into a code reviewed phase because we know at the end of the sprint
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
then we've built during this
We want to then create enough time within the sprint to test and review those
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.
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.
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.
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.
We don't want to send defective
features to the end user
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.
Our sprint planning meaning is on the Friday afternoon before the next friend.
We sprint all week, building new features the following week. We have a code freeze
whatever day it will call it Tuesday. So we have a code freeze on Tuesday, and then
user acceptance testing happens between Tuesday and Thursday night. And then
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,
the optempo that an Angela team can have based on a two week sprint. So
within the execution phase, what we're doing is where
overloading this print. We're building
new software, features and functions, and then we are pushing those two production after they've been tested by the user Adequately.
If your organization can't do that
within a two week period,
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.
But at no time do you want to underestimate. And that's really the difference between
agile and waterfall.
is accepting the failure because we pushed ourselves as hard as we possibly could?
That's the mentality difference.
All right, So in summary,
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
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.
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