Video Lab: Developing a Wagile/Scrumfall Schedule

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 »

Time
3 hours 55 minutes
Difficulty
Intermediate
CEU/CPE
4
Video Transcription
00:02
hello and welcome to lessen 4.4
00:06
our video lab on developing a scrum fall or were agile, basically hybrid schedule. There's all kinds of different names for it.
00:16
I'm your instructor cane. And if you recall from the last video when we were looking at a schedule for a purely agile project, we used Microsoft Dev ops. And in this case, I'm gonna use something different just to show you some different software that's available for
00:33
these different types of tasks. So let's go ahead and get started.
00:37
So this is a traditional
00:41
waterfall type software development project, and those of you that, um, have have done waterfall projects before this should look pretty familiar. So you notice you've got your
00:53
planning phase, your requirements, gathering things of that nature. Then you build your design phase Logic, model, physical model, uh, start creating your database structure so on and so on, do your testing
01:07
and then go on to acceptance. Now, if you notice in this type of set up here
01:12
that the customer doesn't really get their hands on the project until very, very late in the project, and in this case, and see what the dates are
01:23
March Early March is obviously not a very large project here that's being scheduled, but
01:30
they don't really get their hands on it until early March. Meanwhile, all of this work has been done between January and February in the GAN chart.
01:41
So that's a That's a true waterfall software development project, and that's what we want to avoid.
01:47
However, we're limited based on
01:51
the company's culture structure, government regulation, whatever the case might be. So we want to have a version of the hybrid project.
02:02
So what we do is we keep the first couple of elements
02:07
and then remove the rest. So you'll see here that I've got
02:13
my normal requirements gathering that's gonna happen,
02:19
that I'm going to build the generalized design model. What? What software? I'm going to you or what code based on my gonna use what platform or framework, whatever the case might be.
02:30
But then I'm going to go into an interactive and I'll type development.
02:37
So I'm gonna connect these. You'll notice how that pushes everything out.
02:43
Now connect this one to sprint to Okay,
02:46
so what we see here is I've got
02:49
a true product backlog
02:52
and then I've got several sprints. So I'm gonna make sprint one dependent upon the backlog
02:59
and then sprint too dependent on Sprint one,
03:01
and you'll does not gonna do it right now. But you'll notice that what actually should happen is
03:07
room
03:09
This new software haven't used it before. So, uh,
03:17
not sure why it's not playing nice.
03:22
Anyway, the idea is that I'm doing my requirements gathering. I'm doing all the normal planning thing. They go to procurement, I go get my money, whatever the case might be. And then I'm starting to add items to my overall backlog.
03:38
This is gonna be your
03:42
detailed backlogs the same way that you saw it in Dev Ops. The only difference is here that I've got
03:52
it.
03:54
It's building the list, but it's not actually extending the project. So I don't want toe relate these items to each other. I want to actually relate the sprints to each other
04:08
so that
04:11
in their own mother,
04:13
so that
04:14
the dependencies are
04:15
on the sprints themselves.
04:18
And again, I don't really know why it's not working the way that I wanted to, but if you look at the chart here, this is kind of what I'm trying to get at. So I have an overall product backlog. And then I have these time box prints
04:32
that drill down. And then at the end of all of this, at the end of my last sprint than my customer, ah
04:41
is going to accept the final product. And this might again, this could go on for years.
04:46
But what I'm doing, in essence, is sort of the same type of execution strategy as
04:54
the earlier, uh, Dev Ops example. Except I'm still using my normal kind of gant charts schedule. So I've got all my normal planning independency process. And then when the time comes to plan for sprint one in the same way that we were going to do it in the previous video, I should be able to and
05:15
let me. Okay,
05:16
so then in sprint one,
05:18
I want to be able to add Might do item.
05:25
All right.
05:26
Alright. Software's not
05:30
that's
05:30
you only crashed on me. Okay,
05:32
well, I don't I don't have a good backup software. Microsoft Project doesn't offer a Mac version, but the basic idea behind it is that I'm going to set up my structure in such a way
05:46
that
05:47
I can
05:49
take those items from the backlog.
05:51
Let me get another one set up here.
05:56
I've got my sprint.
06:01
It's really crashing.
06:04
All right, Well, note to self, Microsoft or Project Office is not the best way to do it.
06:11
Um, but I have my sprint set up. I do all my initial planning. I build out my requirements, I build out my overall design plan and then
06:21
once I get into the execution phase instead of doing the normal database structure than you y all that kind of stuff, I'm actually going ahead and
06:31
building that product backlog. And then when the time comes to plan sprint one, I move those items from from the backlog in this print one and sprint to and so on. So
06:42
the important part about it
06:44
is really more about how the schedule gets development. It's the idea that we are doing requirements gathering
06:51
you to those products.
06:53
Backlog items should have an associated requirement that they poured unquote live under that they're supporting. And once we get to the execution phase of the project, we're building at the same way that you would a an agile project.
07:10
But the difference is
07:13
no new requirements concomitant to the project without there being a traditional change control process. So if I've got, say, 50 requirements for the project
07:25
and somebody wants to add ah, 51st requirement, I go through traditional change control
07:31
at the execution level, all I'm really doing is marrying features to those requirements. But if the feature doesn't marry to the requirement, then it doesn't count. Right. So that's the key. There is that the change control processes there
07:48
in order to make sure that your scope doesn't increase
07:53
dramatically
07:55
because you're procurement and your structure is set up in such a way. That is more of a traditional waterfall style. And this is like I said, it's a good beginning step. It's a good
08:09
entry level into,
08:11
um,
08:11
agile project management from a traditional waterfall standpoint, and it tends to keep
08:18
government agencies and large corporations. They tend to buy off on it a little bit more than they would for a full blown change over from waterfall to agile.
08:31
So that completes this particular lesson. Hope everybody has a great day and I will see you in Module five
Up Next