Executing an Agile Project Part 1

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.