The Agile Manifesto
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:00
>> Hello, and welcome to Lesson 2.3, The Agile Manifesto.
00:00
I'm your instructor Kane,
00:00
and in this lesson,
00:00
we're going to cover the difference between
00:00
complicated and complex problems and
00:00
discuss the infamous Snowbird Meeting in 2001,
00:00
and probably the last year that I had hair.
00:00
Complicated problems are those problems
00:00
that are by definition complicated,
00:00
but they can be modeled and eventually solved.
00:00
If I use an example of making a pot of
00:00
coffee in my enterprise project management course.
00:00
It's the idea that if you
00:00
develop a certain number of steps
00:00
and you have enough if then
00:00
statements or loop statements,
00:00
then you can model
00:00
this problem or the solution to this problem
00:00
via your standard Visio flowchart
00:00
or something along those lines.
00:00
The idea is that while it
00:00
might be complicated and might take
00:00
you quite a number of steps to solve, it is solvable.
00:00
You can build a what's called a deterministic
00:00
model that shows the solution for that problem,
00:00
and that was very common in the 1990s.
00:00
Once we entered the new millennium,
00:00
we started to see the problems that we thought were
00:00
complicated were actually more complex,
00:00
and complex problems are those problems
00:00
where they're really an infinite number of variables
00:00
and infinite number of inputs and outputs
00:00
and things just become so
00:00
difficult to model that you
00:00
can't really build a good deterministic model for them.
00:00
If you think about trying to
00:00
predict the direction of
00:00
a flock of birds or a school of fish,
00:00
that's an example of a complex problem.
00:00
There's just so many variables going on.
00:00
The fish know what's going on,
00:00
you're never going to build a model
00:00
to determine whether the fish are
00:00
turning left or right at any given moment.
00:00
When we got into this web-based world and we
00:00
moved into this rapid application
00:00
development spiral method and so on,
00:00
our problems became ever more complex.
00:00
The problems that we were trying to solve with technology
00:00
required a change in our project management philosophies.
00:00
We talked about the 80/20 split.
00:00
In the last video,
00:00
we spent 20 percent of our time
00:00
building a solution and money,
00:00
[NOISE] and the other 80 percent
00:00
of our time and money maintaining,
00:00
enhancing, and refining the solution.
00:00
Really what we needed was a methodology that
00:00
could cover this complex world at a 100 percent level.
00:00
While we were planning and
00:00
executing and learning and shifting and changing,
00:00
we were addressing all of
00:00
these complex variables as they arose.
00:00
You remember from my previous video,
00:00
we talked about the idea of ready, aim,
00:00
fire with the traditional waterfall single shot gun,
00:00
and the ready fire aim concept.
00:00
Now the reason why that's a good analogy is,
00:00
first of all, I like guns.
00:00
But second of all, if
00:00
you think about the difference
00:00
between being on the ground,
00:00
let's say laying down on the ground with
00:00
a rifle and you're
00:00
aiming and everything steady and static,
00:00
and then you aim on the target.
00:00
You know where you're at, you know where the target is,
00:00
everything is a known variable,
00:00
you can solve for all the normal variables
00:00
that exist like breathing and so on.
00:00
You can take your shot,
00:00
and odds are pretty good if you know what you're doing,
00:00
that you're going to hit the target.
00:00
Maybe not the first try,
00:00
but probably the second or the third.
00:00
That is a complicated problem,
00:00
there's a limited number of
00:00
variables that you have to solve.
00:00
Compare that to firing a gun from a moving helicopter
00:00
at a target that's on the ground that may also be moving.
00:00
You're moving at 100 plus miles an hour,
00:00
you're changing altitude, you're banking,
00:00
you're shifting, and all these things.
00:00
Now all of a sudden this problem has
00:00
so many variables that
00:00
the human brain is not capable of solving them.
00:00
I'm going to show you a real brief video
00:00
because honestly it's a cool video,
00:00
and who doesn't like cool videos.
00:00
But this is what the military developed to
00:00
address that complex problem.
00:00
This is a mini-gun that's firing out of a helicopter.
00:00
Now you notice all the red lines here.
00:00
Those red lines are referencing what are called tracer
00:00
rounds and they glow
00:00
versus regular bullets that you can't see.
00:00
Notice what the helicopter gunnar is doing.
00:00
As he's moving,
00:00
that a lot of bullets,
00:00
but as he's moving toward the target,
00:00
he's ready firing and then
00:00
adjusting his fire based
00:00
on how close he's hitting to the target.
00:00
That's why I like to use the ready fire aim philosophy,
00:00
plus it's a cool video and who doesn't like that.
00:00
As our problem became more complex,
00:00
we needed a better methodology to
00:00
address the solutions for those complex problems.
00:00
Right around 2001, a very
00:00
smart group of people that I
00:00
wish I could claim I was involved in, but I wasn't,
00:00
released a Agile Manifesto,
00:00
and this is the official Agile Manifesto,
00:00
the birth of agile project management.
00:00
What it says is that we are uncovering better ways of
00:00
developing software by doing it.
00:00
Not by learning about it, not training people,
00:00
but by doing it, and by helping others do it.
00:00
They determined that there were some common values
00:00
in this cognitive framework
00:00
that we call project management.
00:00
They valued individuals and
00:00
interactions over processes and tools,
00:00
so you can take that Visio chart
00:00
that I showed you early in the course,
00:00
and for lack of better expression,
00:00
chuck it in the trash,
00:00
or maybe not, we'll talk about that later.
00:00
We value working software.
00:00
If it's good enough, then it's good enough,
00:00
I don't have to wait for perfect over all of
00:00
the comprehensive documentation that normally
00:00
exists in a traditional waterfall project.
00:00
We valued customer collaboration
00:00
over contract negotiation,
00:00
and if any of you work in the government as part of
00:00
the procurement of
00:00
project management type services and tools,
00:00
that should probably hit home because
00:00
contract negotiation tends to
00:00
take up the gross majority
00:00
of your project management efforts.
00:00
We value responding to change over following a plan.
00:00
Those are the key elements that
00:00
created The Agile Manifesto.
00:00
Now notice that they say,
00:00
the items on the right have value.
00:00
There's nothing inherently bad about them.
00:00
What they've chosen is to embrace a mindset where they
00:00
value the things on the left of this slide in bold more.
00:00
What we see when we start getting
00:00
into the specifics of agile is it's
00:00
not a per scriptive way of doing project management,
00:00
which is what waterfall tends to
00:00
be where we tell you how to do it.
00:00
It is a best practices,
00:00
and a mindset,
00:00
and a cognitive framework that allows us to
00:00
develop and release working software
00:00
that is responding to all of these complex changes in
00:00
collaboration with the customer so they know what's going
00:00
on and everybody works as a team,
00:00
and ultimately creates what's
00:00
called a learning organization.
00:00
If some of these terms are unfamiliar to you, again,
00:00
I'd recommend you take
00:00
my enterprise project management course where
00:00
we go into much more depth in those.
00:00
Who were these individuals? Well, there you go.
00:00
These are the original signatories
00:00
of the Agile Manifesto.
00:00
Many people will say, of course,
00:00
not only did they change the world,
00:00
but they were rather ahead of our time.
00:00
If you remember me talking a little bit earlier
00:00
about the project plus
00:00
certification that I helped develop,
00:00
it was just a year after this.
00:00
All of us "IT
00:00
project management nerd types" were really starting to
00:00
see the value in Agile in
00:00
iterative development, rapid application development.
00:00
We needed ways to bring things to market
00:00
faster to follow that ready, fire,
00:00
aim concept so that
00:00
we weren't caught in
00:00
these multi-year development cycles,
00:00
because in any organization,
00:00
but specifically a for-profit organization,
00:00
you can't afford to dumb money into something for
00:00
three years and then not
00:00
have it work the way that you want it to work.
00:00
These ladies and gentlemen,
00:00
were the original signatories,
00:00
and in many, many ways,
00:00
they changed the world.
00:00
Now keep in mind, this is 2001.
00:00
The PMI released their Agile addendum
00:00
to their Project Management Body of Knowledge.
00:00
I believe it was 2017,
00:00
it might have been 2016.
00:00
But it took a long time for
00:00
the traditional project management industry
00:00
to really embrace Agile.
00:00
Now here we are,
00:00
it's the newest, hottest topic on the block.
00:00
But I hope that you'll notice,
00:00
it really isn't all that new.
00:00
In today's video, we discussed complicated versus
00:00
complex problems and how
00:00
they impacted project management,
00:00
and we talked about the infamous Snowbird Meeting
00:00
in 2001.
00:00
I want to thank you again for attending
00:00
and I will see you in the next video.
Up Next
Similar Content
