come toe Lesson 2.4. What was old is new again.
In this lesson, we're gonna talk about how the process crept back into agile.
Now you just spent the last few minutes learning about the history of agile and where it came from. And one of the biggest complaints with Agile was that the process of traditional project management was too slow and cumbersome and wasn't giving
or wasn't providing value to the customer
in comparison to some of these more rapid and illiterate tive development processes. So we started with the waterfall, moved into prototyping, moved into spiral development,
moved in the rapid application development and then finally made her way into agile as a cognitive framework. And if you remember from the agile manifesto,
part of that cognitive framework is that we're valued valuing flexibility.
If it's stupid and it works, it's not stupid. It's one of those old military sayings that I find very entertaining,
but it's very true in agile. If it's working,
then it's working, and then I'll be ideal or perfect. But it's working
in the throughout the nineties and ended early two thousands
we had this concept of we need to be faster when you to be more flexible. We need to execute strategy in the small bite size chunks and actually produce value for the customer as quickly as we could.
And that became an gile.
Unfortunately, what happens with something, and especially when something is as successful as agile is,
is that the process kind of becomes king again. And we'll when we discuss in module three the different flavors of agile. I want to go over this in a little bit of detail first, so that you can kind of understand where agile came from and avoid some of the pitfalls
of what Andrew Hunt calls
the slogan ization of agile. So the idea that
much like take you I total quality, quality improvement and some of those things were in the nineties.
You can accept the premise and the cognitive framework and use it to better your organization and better your project management
accepting it 100%. So you have to find the things that work. So when we start talking about the flavors of agile in the next video, I really want you to keep that in mind. So what happened after 2001 Agile takes off,
it becomes extraordinarily successful. Companies that embrace it have much higher project success rates and much better return on their project management investment than your traditional waterfall.
So in the beginning and Job brief rejected formal processes and again to a degree. Because, remember, they said, they still value planning and documentation in these things,
just not to the exclusion of business impact and bringing value to the customer.
So we had. This formal process is called waterfall, and some of in some cases they're actually encoded in government regulation.
Agile practitioners rejected them because it was too slow and too cumbersome, and and they did not provide them the flexibility that they needed to develop great software.
once agile becomes a thing,
people start developing agile processes. So
again, processes by themselves aren't bad.
But when you start creating the processes and the different flavors, you got Kon Bon and scrum and sprints and all these different flavors of lean and DSC Emery nails. There's different flavors of agile.
when they were created were really more of a best practice kind of a. Hey, this worked for me.
It might work for you.
But if you don't have the flexibility, if you don't understand the agile manifesto,
then what's gonna happen over the next couple of years as agile becomes more popular and really takes off, especially again with the government, because they're one of the biggest vendors out there for software.
it just simply becomes a different it aeration of waterfall. It's waterfall two point. Oh, so instead of having all this flexibility, we say, no,
you have to do sprints and sprints have to be two weeks long, which none of that is true. It's just what somebody figured out was going to work for them. We want to focus on the principles of agile and not the process, so we're gonna talk about the different flavors,
but that doesn't necessarily lock you in
to a specific, agile methodology.
in my opinion, that is really one of the biggest failures of the widespread adoption of agile
and one of the agile founders, Andrew Hunt says, kind of the same thing.
Agile requires, adapt, adapt iveness.
We want to embrace ambiguity. The unknown is not scary.
rare. Skill set or certainly a rare cognitive framework
with most people. And I hate to keep picking on the government because I work for the government. But the reality is the government is one of the least agile organizations in the world.
If you want a process, if you're documenting things just for the sake of documenting them,
then you're really not being agile. A lot of people
like there to just be a set of rules, a set of processes that you follow, and then part of that is because they're afraid of failure. So if I follow the rules of your organization and the project blows up,
it's not really my fault because I was following the rules. So rather than focusing on the execution and the value and the impact, you're focusing on the process. So I will caution everybody in this video.
If you're spending more time
understanding and utilizing the process rather than focusing on the execution of your strategy, you're not really practicing agile. You're just following a different version
of traditional project management.
I don't think safe now. There's some kind of running jokes about all this stuff, too,
and you can get carried away on both sides of the house. But
we were basically is. Don't follow rules for the sake of the rules. Follow the rules because they work, and if they stop working, then change the rules that you follow.
So in summary today, we discussed how the process
is creeping back into agile were purposely developing less agile, agile processes. Because it looks good on a flow chart. It's easy to discuss in a meeting is easy to do a presentation of Hey, we're doing Combine. Now we're doing sprints Now we're doing Scrum.
The point is to find things that work and implement those things that work, and if they don't work, then we want to get rid of them.
If you did take my Enterprise Project Management course, I talk about the thing called the idea funnel. And the idea of an idea funnel is that we want to gather the most
ideas or the most amount of options
and have a way of filtering them to get the options that we we actually want to do. That that's aligned with the strategy of our organization.
Agile is very similar. We wanna have this toolbox full of as many tools that we can possibly have so that
we have access to multiple options and we can pick the best one
in order to break the rules. Which, agile is kind of known as a rule breaking methodology. We first have to know what the rules are.
So now you have a pretty good idea of what those rules are.
We're gonna go into the different flavors of agile in the next video and just understand that those aren't set in stone. We can combine them. We can mold them. We can change them, weaken do whatever it takes to bring value to the customer. As part of the project management process,
I want to thank you for your time, and I look forward to talking with you in the next video.