Agile Planning

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:01
>> Hello, and welcome to Module 4, Agile planning.
00:01
Lesson 4.1, which we'll cover in
00:01
this video is pure Agile planning.
00:01
Then we'll talk about hybrid planning
00:01
and we'll have two video labs.
00:01
One, developing a pure Agile schedule, and then one,
00:01
we're going to develop a schedule using
00:01
either what's often called Wagile or Scrumfall,
00:01
which are two different connotations
00:01
of the hybrid between Agile and Waterfall.
00:01
They mean the same thing,
00:01
but people just tend to use one or
00:01
the other or they use them interchangeably.
00:01
I'm your instructor Kane,
00:01
and let's go ahead and get started with the first lesson.
00:01
Lesson 4.1 is Agile planning.
00:01
Much like a typical waterfall-style project,
00:01
we always want to start off with some charter.
00:01
If you've taken my enterprise project management class,
00:01
you'll remember me saying that the charter is the who,
00:01
what, when, where, why without the how.
00:01
Then we do the how in
00:01
waterfall during detailed project planning.
00:01
In Agile, the project charter
00:01
still has the same stuff in it.
00:01
Well, we're actually pushing the how even further out,
00:01
much more into project execution.
00:01
We don't want to get bogged down
00:01
in the details because that
00:01
slows the delivery of the value to the organization,
00:01
which is the whole point of
00:01
doing agile in the first place.
00:01
Once we have the charter determined,
00:01
either in the charter or in
00:01
the very initial stages of your Agile project,
00:01
you need to determine what the minimum viable product is.
00:01
The minimum viable product actually has
00:01
to be the minimum viable product.
00:01
Meaning, if you think about
00:01
the talk about the Moscow method,
00:01
the system must have,
00:01
should have, could have, won't have.
00:01
This wouldn't even be a smaller list
00:01
than the must haves,
00:01
because typically the must haves
00:01
reference the completed project.
00:01
Assuming that you are using Moscow,
00:01
you would say, okay, the system must have this,
00:01
but must it have this day
00:01
one or can it wait for a little while?
00:01
That's the difference between
00:01
a minimum viable product and your normal
00:01
Moscow or other type
00:01
of prioritization matrix that you might build.
00:01
We're going to determine, I'm going to use a web store
00:01
as an example because everyone's used one.
00:01
If we decided that we wanted to build a web store,
00:01
what is the minimum things
00:01
that that web store needs to be able to do day 1.
00:01
If I don't mean to be able to
00:01
take PayPal payments in order to
00:01
fulfill a transaction and get money for my customer.
00:01
That's not a minimum viable product.
00:01
That's still might be something that I
00:01
need to do very quickly,
00:01
but it's not something that I need
00:01
to go live on my store.
00:01
We're going to determine what are
00:01
actual real minimum viable product is.
00:01
Then we're going to determine our methodology.
00:01
In the previous module,
00:01
we talked about different flavors of Agile.
00:01
If you recall, I said quite often
00:01
that each methodology does not exist in a silo.
00:01
They're not pick one and ignore the others.
00:01
It's different techniques and frameworks that you
00:01
can use combine or customize to your desire.
00:01
We do want to do
00:01
some methodology determination because
00:01
what we need to do is make
00:01
sure that the project team is on board and
00:01
understands how this Agile project is going to work.
00:01
I've seen quite a few Agile projects have
00:01
some problems when they started off all gung-ho in.
00:01
We're going to be scrubbed
00:01
everything scrum and then they find out that
00:01
the structure doesn't really work for them or they're
00:01
creating their own bottlenecks unnecessarily.
00:01
They try to add some different stuff,
00:01
like maybe Kanban boards
00:01
so that they can eliminate some bottlenecks.
00:01
But without good project team communication,
00:01
if you're already pretty deep into
00:01
the execution phase of your project,
00:01
you can have a lot of pushback from your project team.
00:01
You want to develop your methodology and understand
00:01
how you're going to structure
00:01
the work and get the work done.
00:01
Then again, even though it's an Agile project,
00:01
we still have to deal with the iron triangle.
00:01
It's not a good idea of
00:01
project management is the law of project management.
00:01
We still have a driver.
00:01
Now, remember what we've done is we've basically
00:01
made the performance criteria,
00:01
the weak constraint for an Agile project.
00:01
That's by design, we want to be flexible.
00:01
We want to be able to change.
00:01
We're not going to get real hung up on that.
00:01
But between the schedule and the budget,
00:01
you still have some different competing opportunities
00:01
there and a driver does need to be established.
00:01
For example, if my schedule is actually the driver and I
00:01
end up in a situation where I can raise
00:01
my budget and hire
00:01
more programmers and get more work done,
00:01
then I would do that to meet my schedule
00:01
and the opposite of that is also obviously true.
00:01
If my budget is my driver,
00:01
I have no more money.
00:01
That is the least flexible constraint.
00:01
Can I extend my schedule or shorten my schedule.
00:01
Depending upon how you're funding your project,
00:01
you still have that negotiation.
00:01
You still want that information
00:01
on your project charter and
00:01
signed off on by a sponsor and you want everybody on
00:01
the project team to be well aware of what the driver is.
00:01
Once you've got all that stuff worked out,
00:01
then you're going to come up with an iteration plan.
00:01
What an iteration plan has to do is,
00:01
what is your organizational capacity to absorb change?
00:01
I did a project
00:01
relatively recently where we were trying to go
00:01
with one-week sprints because we thought we
00:01
could deliver at that pace based on
00:01
the tool that we were using and the changes that
00:01
we were trying to make and we
00:01
realized that while the project team could deliver
00:01
new functioning features in a software system weekly,
00:01
the organization just could
00:01
not absorb that level of change.
00:01
We weren't getting user buying,
00:01
we weren't getting good user tests.
00:01
We were putting things into production that
00:01
even though they worked as designed,
00:01
the customer did not actually like it that way.
00:01
They wanted something different.
00:01
We switched over to two-week sprints.
00:01
Everybody was happier.
00:01
Some places will go to quarterly.
00:01
You get too much past quarterly and then of course
00:01
you beg the question of why am I doing Agile?
00:01
I'm only doing one sprint every year
00:01
[NOISE] or every six months.
00:01
That defeats the purpose.
00:01
But you want to figure out what your iteration plan is.
00:01
Like I said, it's specific
00:01
to the organization's capacity to absorb change,
00:01
not your project team's capacity to create change.
00:01
Some places they'll do like that using
00:01
the extreme programming model
00:01
where they'll push a lot of stuff every
00:01
week or whatever to
00:01
test and give the users more time to test.
00:01
That's the difference. It's like
00:01
a two-step iteration plan.
00:01
But either way, figure out what
00:01
your iteration plan is going to be and then that starts
00:01
to structure your overall project
00:01
and you'll know what your delivery cycles look like.
00:01
Then the next thing you're going to
00:01
do is start your backlog.
00:01
Of course, the first things that go in
00:01
the backlog are the minimum viable products,
00:01
because that's going to absorb all
00:01
of your energy until it's actually in production.
00:01
But from there, you want to start adding items.
00:01
Now in some places,
00:01
they'll use user stories or use cases.
00:01
Some places we'll call it
00:01
epics and then underneath each epic or feature,
00:01
AI features another one that's used.
00:01
Then you have different items of work.
00:01
But basically, what they are,
00:01
they're high-level requirements.
00:01
Depending on how you want to structure them,
00:01
user stories are more narrative in nature.
00:01
You would look at somebody doing
00:01
their day-to-day job and make a narrative on how they
00:01
want to interact with the system
00:01
and what the system can do for them
00:01
versus your backlog items and some of those smaller,
00:01
more tactical level backlog items,
00:01
work items are bugs.
00:01
There are more detailed,
00:01
but they're smaller in scale.
00:01
Depending on how you want to do it,
00:01
there's different ways to structure the work.
00:01
It depends on the tool you're using sometimes.
00:01
But you basically want to start building your to do list.
00:01
You don't want to get hung up on how
00:01
it's going to get done and that's why I mentioned that we
00:01
don't do the how during project planning,
00:01
we do the how during execution.
00:01
You're just taking things wouldn't it be
00:01
cool if our system could do X, Y, and Z.
00:01
Added to the backlog, hey,
00:01
can we make this green instead of red?
00:01
Yes, add it to the backlog.
00:01
It's running joke at work.
00:01
Whenever somebody brings something up,
00:01
we go hey added to the backlog.
00:01
Because we're not going to
00:01
spend a lot of time addressing it
00:01
until we get to the point
00:01
where we're actually going to build that thing.
00:01
Once you've added things to the item to the backlog,
00:01
then you start to work out estimate efforts.
00:01
Like I showed you in that DevOps screen.
00:01
These aren't efforts as in,
00:01
this will take me four hours or
00:01
six hours because what you end up doing is
00:01
you end up taking
00:01
all your time estimating instead of building.
00:01
You're just going to simply figure out
00:01
a way to score these things.
00:01
If I want to do facial recognition on
00:01
my web store for login and payment,
00:01
that's probably more complicated
00:01
than taking a credit card number.
00:01
That's the difference in effort
00:01
and I wouldn't scale them accordingly.
00:01
Then finally, we want to think
00:01
about the different types of
00:01
investments that an Agile project
00:01
has versus irregular projects.
00:01
Regular project, we're looking at ROI
00:01
long-term after the systems live three to five years out.
00:01
We still look at those things in Agile,
00:01
but you also need to think about cash flow.
00:01
The goal, especially if you're doing like a lean project,
00:01
is for the thing to pay for itself as quickly as
00:01
possible and then pay for improvements.
00:01
You have a different type of
00:01
investment mindset but we're
00:01
still thinking about investments.
00:01
Agile has a bad reputation
00:01
for being a black hole that companies pour money into,
00:01
and you don't want to be one of
00:01
those people adding to that bad reputation.
00:01
Always focus on your investment.
00:01
Always think about your ROI,
00:01
even if your ROI is
00:01
actually more of a cash flow type setup.
00:01
In this video, we discussed
00:01
all the elements of a pure Agile planning exercise.
00:01
Thank you very much and I will see you in the next video.
Up Next