The Agile Manifesto

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

3 hours 55 minutes
Video Transcription
Hello and welcome to lessen 2.3, the agile manifesto
I'm your instructor cane,
and in this lesson, we're going to cover the difference between complicated and complex problems
and discuss the infamous Snowbird meeting in 2001 and probably the last year that I had hair.
So complicated. Problems are those problems that are, by definition, complicated,
but they can be modeled and eventually solved. So if I use an example of making ah pot of coffee in my enterprise project management course, and it's the idea that if you develop a certain number of steps and you have enough, if then statements or loop statements,
then you consort of model this
problem or the solution to this problem
kind of your standard busy oh flow, uh, flow chart or something along those lines.
So the idea is that while it might be complicated and might take you
quite a number of steps to solve, it is solvable. You can build a what's called a deterministic model
that shows the solution for that problem, and that was very common in the 19 nineties.
Once we entered the new millennium, we started to see that problems that we thought were complicated.
We're actually more complex and complex problems are those problems where
there really an infinite number of variables, an infinite number of inputs and outputs, and things just become so difficult to model that you can't really build a good deterministic model for them. So if you think about trying to predict
the direction of a flock of birds or a school of fish, that's an example of a complex problem. There's just so many variables going on. The fish know what's going on. You're never gonna build a model to determine whether the Fisher turning left or right, attend any given moment.
So when we got into this Web based world and we kind of moved into this rapid application development, spiral method and so on,
our problems became evermore complex. The problems that we were trying to solve with technology required a change in our project management philosophies. So we talked about the 80 20 split in the last video. We spend 20% of our time building a solution and money
and the other 80% of our time and money maintaining, enhancing and refining the solution. So really, what we needed was a methodology that could cover this complex world
at 100% levels. Right? So while we were planning and executing and learning and shifting and changing,
we were addressing all of these complex variables as they arose. So you remember from my previous video, we talked about the idea of ready aim fire
with the traditional waterfall, single shotgun
and the ready fire aim concept. Now the reason why that that's a good analogy is first of all, I like guns. But second of all, the
if you think about the difference between being on the ground laying, insist they laying down on the ground with the rifle and you're aiming and everything steady and static. And then you aim on the target. So you know where you're at. You know where the target is. Everything is kind of a known variable you can solve for all the normal
variables that exist, like breathing and so on.
You can take take your shot and odds are pretty good. If you know what you're doing, that you're going to hit the target. Maybe not the first try, but probably the second or the third. That is a complicated problem. Is a limited number of variables that you have to solve.
Compare that to firing a gun from a moving helicopter at
a target that's on the ground. That may also be moving, so you're moving at 100 plus miles an hour. You're changing altitude, your banking, your shifting and all these kind of things. And now all of a sudden, this problem has so many variables that the human brain is not capable of solving them.
So I'm gonna show you a real brief video because, honestly, it's a cool video. And who doesn't like cool videos? But this is what the military developed to address that conflict complex problem.
And this is a mini gun that's firing out of a helicopter. Now you notice all the red lines here. Those red lines are referencing what are called tracer rounds, and they glow versus regular boys that you can see and notice what that the helicopter gunner is doing.
So as he's moving. That's a lot of bullets,
but as he's moving toward the target, he's
ready, firing and then adjusting his fire based on how close is hitting to the target. So that's why I like to use the ready Fire aim philosophy. Plus, it's a cool video Who doesn't like that?
So as our problems became more complex, we needed a better methodology to address the solutions for those complex problems.
So right around 2001 very smart group of people that I, which I could claim I was involved in, but I wasn't released a agile manifesto. And this is the official agile manifesto, the birth of agile project management management.
And what it says is that we're uncovering better ways of developing software by doing it not by learning about it not training people, but by doing it and by helping others do it. And they determine that there were some common values in this cognitive framework that we call project management.
They valued individuals and interactions over processes and tools so you can take that busy, Oh, chart that I showed you early in the course, and you, for lack of better expression, chuck it in the trash.
Or maybe not. We'll talk about that later.
We value working software, right? If it's if it's good enough, that is good enough. I don't have to wait for perfect over all of the comprehensive documentation that normally exists in a traditional waterfall project. We valued customer collaboration
over contract negotiation. And if any of you work in the government
as part of the procurement of project management type services and tools, that should probably hit home because contract negotiation tends to take up the gross majority of your project management efforts and we will be value responding to change over following a plan.
Those are the key elements that created the agile manifesto. Now notice that they say
the items on the right have value. There's nothing inherently bad about them. What they've chosen is to embrace a mindset where they value the things on the left of the slide and bold mawr. So the
what we see when we start getting into the specifics of Agile is it's not a per script Ivo
way of doing project management, which is what waterfall tends to be where we tell you how to do it. It is a best practices and a mindset and a cognitive framework that allows us to develop and release
working software that is responding to all of these complex changes
in collaboration with the customer so they know what's going on and everybody works as a teen
and ultimately creates what's called a learning organization. And if some of these terms are unfamiliar to you again, I'd recommend you take my Enterprise Project Management course where we go into much more depth and those
So who were these individuals? Well, there you go, these air, the original signatories
of the agile manifesto and many people will say, Of course, not only did they change the world,
but they were rather ahead of our time. So if you remember me talking a little bit earlier about the project plus verification that I helped develop, it was just a year after this. So all of us quote unquote I t project management nerd types were really starting to see the value in agile
in iterated development, rapid application development. We needed ways to bring things to market
faster, to follow that ready fire aim concept
so that we weren't caught in these multi gear development cycles because in a any any organization, but specifically a for profit organization, you can't afford to dump money into something for three years and then not have it work the way that you want it toe work. So these gentlemen, ladies and gentlemen,
were the original signatories.
in many, many ways, they change the world. Keep in mind. This is 2000 and one.
The PM I released their agile addendum to their project management body of knowledge
2000. I believe it was 2017 and my have been 2016. But it took a long time for the traditional project management industry to really embrace. Agile. And now here we are. It's sort of the newest,
hottest topic on the block, but I hope that you'll notice it really isn't all that new. So in today's video, we discussed complicated versus complex problems and how they impacted project management. And we talked about the infamous Snowbird meeting in 2000 and one.
I want to thank you again for attending, and I will see you in the next video.
Up Next