Hello and welcome to Module four.
Lesson 4.1, which will cover in the video in this video is agile planning, pure, agile planning.
Then we'll talk about hybrid planning, and we will have to video labs one. Developing an agile schedule, a pure, agile schedule and then one. We're gonna develop a schedule using either what's often called Wah Giles from ball, which are two different connotations of
the hybrid between agile and waterfall.
They mean the same thing, but people just tend to use one or the other, or they use them interchangeably.
I'm your instructor cane, and let's go ahead and get started with
It's a lesson 4.1 is agile planning
waterfall style project. We always want to start off with some kind of a charter.
If you have taken my Enterprise project management class, you'll remember me saying that the charter is the who what, when, where, why, without the house and then we do the how and waterfall during detailed project planning.
In agile the project, Turner still has the same stuff in it, but we're actually pushing the how even farther out much more into project execution.
We don't want to get bogged down in the details because that slows
the delivery of the value to the organization, which is the whole point of doing agile in the first place.
So once we have the charter determined
either in the charter or in the very initial stages of your agile project, you need to determine what the minimum viable product is.
And the minimum viable product actually has to be
the minimum viable product. Meaning, if you think about the talk about the Moscow method, the system must have, should have. Could have won't have.
This would even be a smaller list than the must haves, because typically the must haves
reference the completed project.
So you almost would say, if you're assuming that you were using Moscow, you would say OK, the system must have this. But must it have this day one,
or can it wait for a little while? And that's the difference between a minimum viable product and your normal Moscow or other type of
prioritization matrix that you might build.
So we're gonna determine I'm gonna use a Web store as an example, because everyone's used one
if we decided that we wanted to build a Web store.
things that that Web store needs to be able to do Day one? So if I don't need, say, pay Pau, but only if I don't need to be able to take PayPal payments in order to fulfill the transaction and get money for my customer. That's not a minimum buyable product. That still might be something that I need to do very quickly.
But it's not something that I need to go live on my store.
So that's we're gonna determine
what are actual riel. Minimum viable product is, then we're gonna determine our methodology. In the previous module, we talked about different flavors of agile, and if you recall,
I said quite often that each methodology does not exist in a silo. They're not
pick one and ignore the others is
different techniques and frameworks that you can use combine or customized to your desire. So we we do want to do some methodology determination,
because what we need to do is make sure that the project team is on board and understands how this agile project is going to work. I've seen quite a few agile projects, have some problems. When they started off all gung ho in,
we're going to be scrum. Everything's from scrum scrum
and then they find out that the structure doesn't really work for them or they're creating their own bottlenecks unnecessarily. And so they try to add some different stuff, like maybe kon bon boards so that they can eliminate some bottlenecks. But without
good project team communication. If you're already pretty deep into the execution phase of your project, you can have a lot of pushback from your project team. So you want to develop their methodology and understand
how you're going to structure the work
and get the work done.
even though with an Angela Project we still have to deal with the Iron Triangle,
it's, you know, not the good idea of project management is the law product management.
So we still have a driver. Now, remember, what we've done is we basically made the performance criteria the week constraint for an agile project that's by design. We want to be flexible. We want to be able to change, so we're not gonna get
real hung up on that.
But between the schedule and the budget. You still have some different competing
opportunities there, and a driver does need to be established. For example,
if my schedule is is actually the driver, and I end up in a situation where I have, I can raise my budget and hire more programmers and get more work done
that I would do that to meet my schedule
and the opposite. As also obviously true. If my budget is my driver, I have no more money. That is the least flexible constraint. Can I extend my schedule or shortened my schedule depending upon how your funding your project?
So you still have that negotiation? You still want that information on your project charter and a signed off on by a sponsor, and you want everybody on the project team to be well aware of what the driver is.
Once you've got all that stuff worked out, then you're going to come up with an iteration plan. What a iteration plan has to do is
what is your organizational capacity to absorb change?
I did a project relatively recently where we were trying to go with one week sprints because we thought we could
deliver at that pace based on the tool that we were using and the changes that we were trying to make.
And we realize that while the project team could deliver new functioning
features in a software system weekly, the organization just could not absorb that level of change. So we weren't getting user by and we weren't getting good. User tests were putting things into production that even though they worked as designed,
the customer did not actually like it that way. They wanted it something different. So we switched over to two weeks. Prince. Everybody was LA happy. So a lot. Appier's some some places we'll go to quarterly. You get too much past quarterly. And then, of course, he begs the question of Why am I doing? And I'm only doing one sprint every year
for every six months. You know that kind of defeats the purpose, but you want to sort of figure out what your iteration plan is. And like I said, it's
the organization's capacity to absorb change, not your project teams capacity to create change.
Um, some. Some places
they'll do, you know, like that, using the extreme programming model where they will push a lot of stuff every week or whatever to test and give the users more time to test. So that's the difference. It's like a two step federation plan. But either way,
figure out what generation plane is going to be, and then that starts to structure your overall project and you'll know kind of what your delivery cycles look like.
Then the next thing you're going to do is start your backlog. And, of course, the first things that go in the backlog are the minimum viable products, because that's gonna absorb
all of your energy until it's actually in production. But from there, you want toe, start adding items now you some places they'll use user stories or use cases.
Some places will call it epics,
and then underneath each epic or feature features another one that's used. Then you have different items of work, but basically what they are, they're high level requirements. So depending on how you want to structure him user stories, arm or narrative in nature, so you would look at somebody
doing their day to day job and kind of make a narrative on how they want to interact with the system and what the system can do for them. Vs
your backlog items and some of those smaller, more tactical level backlog items, work items or bugs. They're more.
They're detail. But there were smaller in scale, so depending how you want to do it. There's different ways to structure the work and on the tool your using sometimes.
But you basically want to start building your to do list,
and you don't want to get hung up on
how it's going to get done. And that's why I mentioned that we don't do the how during project planning we do the how during execution. So you're just taking things. Wouldn't it be cool if our system could do X, Y and Z? Yep, at to the backlog. Hey, can we make this green instead of red yet added to the backlog? I mean, it's kind of running joke at work.
Whenever somebody bring something up, we go at it to the backlog
because we're not going to spend a lot of time addressing it until we get to the point where we're actually gonna build that thing.
Once you add things to the item to the backlog,
then you start toe workout estimate efforts and, like I showed you in that Dev Ops Spring. These aren't efforts, as in this will, taking four hours or six hours, because what you end up doing is you end up taking all your time estimating instead of building. So you're just gonna simply figure out a way to score these things.
You know, if I want to do facial recognition on my Web stored for log in and payment, that's probably more complicated than taking a credit card number.
So that's the difference in effort, and I would scale them accordingly.
And then, finally, we want to think about
the different types of investments that an agile project has versus a regular project. So a regular project we're looking at R A Y
long term after the systems live 3 to 5 years out,
we still look at those things and and job, but you also need to think about cash flow.
And the goal, especially for doing like a lean project, is for the thing. To pay for itself so quickly as possible and then pay for improvements. So you have a different type of investment mindset, but we're still thinking about investments. Agile has a bad reputation
for being a black hole that companies pour money into. And you don't want to be one of those people. Adding to that bad reputations always focus on your investment.
I always think about your r a y you and if you're our ally, is actually more of a cash flow type set up.
So in this video we discussed all the elements of a pure, agile planning exercise.
Thank you very much, and I will see you in the next video.