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 »
Video Transcription
00:01
>> Hello and welcome to Lesson 4.4,
00:01
our Video Lab on developing a Scrumfall or a Wagile,
00:01
basically a hybrid schedule.
00:01
There's all kinds of different names for it.
00:01
I'm your instructor Kane,
00:01
and if you recall from
00:01
the last video when we were looking at
00:01
a schedule for a purely Agile project,
00:01
we used Microsoft DevOps.
00:01
In this case, I'm going to use
00:01
something different just to show you
00:01
some different software that's available
00:01
for these different types of tasks.
00:01
Let's go ahead and get started.
00:01
This is a traditional
00:01
waterfall-type software development project.
00:01
Those of you that have done waterfall projects before,
00:01
this should look pretty familiar.
00:01
You notice you've got
00:01
your planning phase, your requirements,
00:01
gathering things of that nature,
00:01
then you build your design phase, logic model,
00:01
physical model, start creating your database structure,
00:01
so on and so on,
00:01
do your testing, and then go on to acceptance.
00:01
Now if you notice in this type of
00:01
setup here that the customer
00:01
doesn't really get their hands on
00:01
the project until very very late in the project.
00:01
In this case, let's see here what
00:01
the dates are. Early March.
00:01
This is obviously not a very large project
00:01
here that's being scheduled,
00:01
but they don't really get
00:01
their hands on it until early March.
00:01
Meanwhile, all of this work has been done
00:01
between January and February in the Gantt chart.
00:01
That's a true waterfall software development project
00:01
and that's what we want to avoid.
00:01
However, we're limited based
00:01
on the company's culture, structure,
00:01
government regulation,
00:01
whatever the case might be so we want
00:01
to have a version of a hybrid project.
00:01
What we do is we keep the first couple
00:01
of elements and then remove the rest.
00:01
You'll see here that I've
00:01
got my normal requirements
00:01
gathering that's going to happen,
00:01
then I'm going to build the generalized design model,
00:01
what software I'm going to use,
00:01
or what codebase I'm going to use,
00:01
what platform or framework,
00:01
whatever the case might be.
00:01
But then I'm going to go into
00:01
an iterative Agile-type development.
00:01
I'm going to connect these and you'll
00:01
notice how that pushes everything out,
00:01
and I'll connect this one to sprint 2.
00:01
What we see here is I've got a true product backlog,
00:01
and then I've got several sprints.
00:01
I'm going to make sprint 1 dependent upon
00:01
the backlog and then sprint 2 dependent upon sprint 1.
00:01
This not going to do it right now,
00:01
but you'll notice that what actually should happen
00:01
is this new software, I haven't used it before.
00:01
I'm not sure why it's not playing nice.
00:01
Anyway, the idea is
00:01
that I'm doing my requirements gathering,
00:01
I'm doing all the normal planning thing,
00:01
I go to procurement,
00:01
I go get my money,
00:01
whatever the case might be,
00:01
and then I'm starting to add items to my overall backlog.
00:01
This is going to be your detailed backlog,
00:01
the same way that you saw it in DevOps.
00:01
The only difference is here that it's building the list,
00:01
but it's not actually extending the projects.
00:01
I don't want to relate these items to each other,
00:01
I want to actually relate the sprints to each
00:01
other so that the dependencies
00:01
are on the sprints themselves.
00:01
Again, I don't really know why that's not
00:01
working the way that I want it to.
00:01
But if you look at the chart here,
00:01
this is what I'm trying to get at.
00:01
I have an overall product backlog,
00:01
and then I have these time-box sprints that drill down,
00:01
and then at the end of my last sprint then
00:01
my customer is going to accept the final product.
00:01
Again, this could go on for years.
00:01
But what I'm doing in essence is the same type of
00:01
execution strategy as the earlier DevOps example,
00:01
except I'm still using my normal Gantt chart schedule.
00:01
I've got all my normal planning independency process,
00:01
and then when the time comes to plan for sprint 1 in
00:01
the same way that we were going to do
00:01
it in the previous video,
00:01
I should be able to do it.
00:01
Then in sprint 1,
00:01
I want to be able to add my to-do item.
00:01
It crashed on me.
00:01
Well, I don't have a good backup software.
00:01
Microsoft Project doesn't offer a Mac version,
00:01
but the basic idea behind it is
00:01
that I'm going to set up my structure in
00:01
such a way that I can take those items from the backlog.
00:01
Let me get another one set up here.
00:01
I've got my sprint.
00:01
It's really crashing. Well,
00:01
note to self, Microsoft Project Office
00:01
is not the best way to do it.
00:01
But I have my Sprint setup,
00:01
I do all my initial planning,
00:01
I build out my requirements,
00:01
I build out my overall design plan,
00:01
and then once I get into the execution phase,
00:01
instead of doing the normal database structure then UI,
00:01
all that stuff,
00:01
I'm actually going ahead
00:01
and building that product backlog,
00:01
and then when the time comes to plan sprint 1,
00:01
I move those items from
00:01
the backlog in this sprint 1 and sprint 2 and so on.
00:01
The important part about it is really
00:01
more about how the schedule gets developed.
00:01
It's the idea that we are doing requirements gathering.
00:01
Each of those product backlog items should have
00:01
an associated requirement that
00:01
they ''live under'' that they're supporting.
00:01
Once we get to the execution phase of the project,
00:01
we're building it the same way
00:01
that you would an Agile project.
00:01
But the difference is no new requirements can come
00:01
into the project without there
00:01
being a traditional change control process.
00:01
If I've got, say,
00:01
50 requirements for the project and
00:01
somebody wants to add a 51st requirement,
00:01
I go through traditional change control.
00:01
At the execution level,
00:01
all I'm really doing is marrying
00:01
features to those requirements.
00:01
But if the feature doesn't marry
00:01
to the requirement then it doesn't count.
00:01
That's the key there,
00:01
is that the change control process is
00:01
there in order to make sure that your scope
00:01
doesn't increase
00:01
dramatically because your procurement and
00:01
your structure is set up in such a way
00:01
that is more of a traditional waterfall style.
00:01
This is like I said, it's a good beginning step.
00:01
It's a good entry-level
00:01
into Agile project management
00:01
from a traditional waterfall standpoint,
00:01
and it tends to keep
00:01
government agencies and large corporations.
00:01
They tend to buy off on it a
00:01
little bit more than they would
00:01
for a full-blown changeover from waterfall to Agile.
00:01
That completes this particular lesson.
00:01
I hope everybody has a great day and I
00:01
will see you in Module 5.
Up Next
Similar Content
