- Hi, and welcome to Agile Systems and Resilience,

changing everything since 1943.

So becoming resilient and anti-fragile,
it's really a way of life,
and to understand exactly what I mean,
first you need to understand what is fragility.
So, fragile things are things
that don't perform well under stress.
Now, unlike fragile things,
robust things are things
that actually handle stress really well,
and they don't deteriorate
in terms of their performance.
And normally, when we think about things
that are fragile and stressed,
we think about these two elements,
either you are fragile or you're robust.
But there is another part to the spectrum
that was identified by Nicholas Nassim Taleb
called anti-fragility,
and this was made really popular
in his book, "The Black Swan".
And anti-fragility says that there are things
which actually do better under stress, they improve,
and because of the fact that they improve under stress,
we can call those things truly resilient.
And that's what we want to go for
when it comes to our systems and our designs,
because of the fact that things will be stressed,
and we will experience change.
So Agile flips the script on fragility,
and it really does this compared to the antithesis of Agile,
which is the Predictive methods.
So I'm gonna walk from Predictive to Agile
and show you how this aligns with the fragility spectrum.
So to get started, let's talk
about things that are predictive.
Things that are predictive really rely
on there being no changes.
As a result, as stress increases,
performance really goes down.
It starts high, but then it goes down,
and these types of things
are the things that we call fragile,
and examples of fragile things are:
a political reputation,
because it only takes one gaff to ruin a career,
or one bad photograph;
or a cost efficient system.
Cost efficient systems are things that are so well tuned
that they literally can't change even a little bit,
or they begin to fail,
kind of like some of our supply chains during the pandemic.
Packed schedules are another thing that are truly fragile.
If you have a schedule where every meeting
is book-ended by another meeting,
if one slips, the rest could slip,
and then none of your meetings do well;
and then lastly, the iPhone SE screen.
The iPhone SE is replete over the internet,
as well as in the experience of those who had them,
that it essentially was constantly spidered and cracked
because of the fact that the screen
just could not handle even the smallest drop.
Now, first generation Lean techniques
help us to become robust.
They allow us to actually manage stress
in a normal curve fashion,
what looks like an S-curve as you see it here,
and this kind of S-curve actually is similar
to what we would experience
in terms of a worker's reputation.
At the very beginning, you're perfect,
but then you're no longer perfect, you're just normal.
In fact, you stay normal under enormous amounts of stress,
until eventually, if you continue
to make mistakes and mistakes,
people will give up on you,
but you're just like the rest of us if you're not perfect,
and frankly that's kind of what we've all experienced.
Examples of systems that perform like this
are systems that are redundant.
They have backup systems, so when something fails,
they can go and they can rely
on other parts of the system to work.
Examples of how to manage your time this way
is with a to-do list.
So if I have a list of things to do,
even if that list is not necessarily in any priority order,
as long as I just start at the top
and keep working my way down,
I'm going to get a lot of good work done.
So I would have to experience a lot of stress
and basically not get anything done
for me to feel unaccomplished.
And then, if you look at a car,
it actually follows this kind of performance
in terms of its value.
At the very beginning, once you drive it off the lot,
it's basically lost a big chunk of its value,
and then it's gonna continue to decrease
a little bit over time,
but it's gonna hold its value for a while,
and then, eventually, the wheels will fall off,
the transmission will need to be replaced, et cetera.
That's kind of what happens at the end.
So this is our normal curve for first-generation Lean.
Now, second generation Lean looked at the system
and said, you know what,
if we could reorganize the work that we do,
if we could prioritize, we could do better.
And so what they offer is essentially
what I have termed a buffered system,
and a buffered system basically says
that you're going to allow for the least important work
to be thrown out first
so that your most important work
is saved until the end in terms of your stress curve.
So essentially, performance goes well for a while,
and then eventually the stress overcomes the system.
And this is what we see in a hero's reputation.
So heroes' reputations are buffered because of the fact
that they can get away with anything, even murder,
and they can do it many times over,
until eventually, the world gives up on them
and says, no, you've done too many bad things,
we no longer can hold you as a celebrity.
Celebrities eventually do run out of good will.
Protected systems behave this way,
and I'm thinking about systems like a nuclear reactor,
where many, many, many, many fail-safes exist,
and essentially it will continue to perform,
and it can handle a lot of changes and stress.
It's designed to do that.
Prioritized to-do lists
actually perform really well like this,
so if you put your most important things
at the top of your list,
even if you only get to those things,
you're gonna have a good day.
And in terms of systems that we see in everyday life,
this is actually very similar to how a hospital works,
and in a hospital ICU service, they prioritize
which patients to take in first and to fast track,
and as a result, they can serve everyone
and meet their needs,
up until the point where their capacity is reached,
and that's when service really drops off,
which is why in the pandemic,
we're trying to flatten the curve.
Now, Agile flips the script and says that under stress,
we're gonna continue to improve performance,
and in fact, we like stress, because we learn,
and so this actually exhibits
what we call anti-fragile behavior.
And examples of this are like an artist's reputation,
where essentially, there is no such thing
as bad news or bad press.
Replicated systems look this way.
If you have many replicated, slightly variant options,
you can then pick which one performs the best
and that will work for you.
In terms of our time management,
experimentation actually has
this same kind of performance curve.
As we experiment we learn,
and as we learn, we now get better over time,
so instead of just having a list
of to-do's that are prioritized,
we should run some experiments
and get better at what we do.
And then a system that actually performs this way
is Roomba,
and what's really interesting is
that iRobot, the makers of Roomba,
actually were in the same lab as Jeff Sutherland
when he was working at MIT Labs
and preparing to become the founder of Scrum,
and he was actually informed by their systems
which were all about decentralized control.
But the point here is,
is that Roombas are little vacuums
that run into walls and figure out the map of your floor,
and then they can go and they can vacuum that floor
much more efficiently the next time and the next time.
They actually store the map of your floor,
and they can do it better each time, until parts break.
So that's examples of anti-fragility
and how we flip the script.
So our goal is to become agile,
so we wanna go for this.
I'm gonna explain a little bit more
about exactly what we mean.
So a really great place to start,
it's not really the beginning,
but it's a really good place to start,
is to talk about the Agile Manifesto.
Now the Agile Manifesto was developed
by agilists who were coming together in 2001,
and this is about seven years
after the Scrum paper was published
by Jeff Sutherland and Ken Schwaber.
At this point we had a number
of iterative methodologies in place,
like extreme programming
and dynamic system development methodology,
as well as Scrum,
and these leading practitioners sought each other out,
met in Snowbird in 2001,
and tried to come up with something
they could agree on as being a new code.
Now the thing is, is that these 17 practitioners
didn't really get along completely,
and they didn't always agree,
and then eventually, half of them left and went to go ski,
and the remainders just decided, you know what,
we should write something down.
So they got up, and they came up with this.
And essentially, they said, look, I think we all agree
that we value the items on the right,
but we really value the items on the left more.
And so the first thing that they talked about was
individuals and interactions over processes and tools.
And this is really important because of the fact
that people are the ones who get the work done,
not the processes and tools.
And processes and tools can't carry
anywhere near the amount of information
that you need to convey
on projects doing work,
so individuals and interactions
were more important than processes and tools.
However, you need processes and tools
in order to discipline yourself and to scale.
So that's how they valued those two things.
Then they said that working software,
and now, today, we say working systems,
is more important than comprehensive documentation.
However, working software over comprehensive documentation
doesn't mean that we don't document.
In fact you get better, more timely documentation
because of the way that Agile documents.
They document as things are developed,
or they do so with prototypes.
So as a result, you end up with better documentation,
not rush-at-the-end documentation
when no one can remember what they did,
or up-front documentation
which is OBE by the time it's delivered.
Then there's customer collaboration
over contract negotiation,
and again, contracts are important.
They're a great way of managing risk,
They're a great way of identifying responsibility.
However, what's important and what will be the going concern
is the value created
between the two parties working together,
so you wanna collaborate with your business partners,
be them the owners, or your customers, or whoever they are,
who are actually receiving the value,
you wanna collaborate.
And then lastly, responding to change over following a plan,
and again, plans are important.
There's more planning in Agile approaches
than there is inside of Predictive.
In fact, it happens every two to four weeks,
but responding to change
and being willing to change that plan
is essential to be agile.
So this is what they came together,
and this has basically launched a thousand ships
in terms of changing the world to become more agile
and to rethink what it means to work together
to get complex work done.
So speaking of complex systems,
let's talk about two projects performed by the Air Force,
both using Agile, but decades apart.
The first one is the P-80 Shooting Star.
The P-80 Shooting Star was actually a project done
by Lockheed Martin Skunk Works team
led by Kelly Johnson,
and in 1943, they actually prototyped
the first jet fighter ever, in just 143 days,
and they did it by having the team co-located,
working together, responding to change,
empowered to take and change the designs,
and by having great communication through co-location.
Now, Kelly Johnson's 14 principles of management
likely influenced some of the work
that's being done right now at Kessel Run,
which is an ongoing program inside the Air Force.
In fact, in 2016 their Jigsaw project,
which essentially replaced
hundreds of millions of dollars worth of software
within about two months,
today saves about $10 million per month in fuel savings
by efficiently routing and refueling
all of the planes that are being launched
by the Combined Air Force Operations Center
out of Abu Dhabi.
And now these two projects were done, like I said,
over 70 years apart, but they both use Agile,
and they both are achieving incredible return on investment
by leveraging the principles of Agile
that we just talked about.
Okay, let's do a quick comparison
of Agile and Traditional and Lean.
So let's start with our iron triangle,
scope, schedule, and budget.
These are all different types of costs,
and they all constrain the work that we do.
Note that the combination of scope, schedule, and budget
is not quality, it is total cost.
Schedule, budget, and scope are all forms of costs
to get something done, to achieve value.
Now, in terms of your goals,
Agile's goal is always speed,
because speed is gonna give you
the best return on investment.
When it comes to Traditional,
what we're going for is often predictability.
We wanna make sure
that we are gonna get what we asked for
on time and on budget.
And with Lean, our goal is almost always innovation
We want someone to solve our problem,
we want someone to figure out how to solve it for us.
And so when we look at the triple cost constraint,
oftentimes the way that we think about this
is we're gonna hold two constant, and change one.
So with Agile, we're gonna hold schedule and budget fixed,
so you have a certain amount of money
and you're gonna have a certain amount of time,
but then the question is,
what can you get done within that time?
And that's adjusting of scope, so it's time boxing.
With traditional,
you're gonna hold scope and schedule constant,
saying this is how much I wanna get done,
and this is when I want it,
and the question is how much it's gonna cost.
So I know what I want, I know when I want it,
give me the price.
With Lean, the question is, when can I get it?
How quickly can I get it?
When is the best time to deliver it?
And that's based upon scope and budget,
so you only have so much money,
but you have a scope that you must accomplish.
When is the best time to deliver that thing?
And that may be based upon WIP limits
or just-in-time delivery, that kind of thing.
When it comes to how you pick the vendor
that is going to be delivering for you,
with Agile, if someone's going to be changing your scope,
you want to source based on trust.
That's how you pick your provider.
In terms of Traditional, if you're looking...
if you know what you're gonna get,
and you know when you're gonna get it,
the only thing you care about
is that your provider be efficient,
so you source based on efficiency,
I'm looking for my lowest cost,
technically acceptable delivery.
And when it comes to Lean, the goal is always
to find someone with the expertise.
Because they're trying to solve a problem for you
and because you need that problem to be solved
within the budget that you have,
you want that person to have the greatest expertise,
and to give it to you at that price and get it done.
So now that you understand the high level difference
between Agile, Traditional and Lean,
let's talk a little bit about the sprint process.
There are really three parts.
The first part of the sprint process comes with planning.
So you have a product owner
who's been working on a backlog, essentially a list,
of features, stories, and bugs,
and at the very beginning of a sprint,
which is a two to four week period of time to get work done,
the development team will look at that list,
and they're gonna look at the top of that list
'cause it's gonna be prioritized,
and they're gonna pick what parts of that list
can group together into a shippable piece of product
or a shippable increment,
and if they can do that,
they're gonna go ahead and put together
what's called the sprint backlog.
So they focus on what's needed to achieve a sprint goal,
and they come up with a sprint backlog
to be accomplished in that two to four week sprint.
Then they move on to execution,
and here, during the execution,
there is a daily standup or a daily scrum
where the whole team gets together
and talks about the work that they're doing today
and what they're trying to accomplish,
and they help each other understand
what each other is doing
so they can move faster.
They also occasionally work with the product owner
in order to refine the backlog
so it's ready for the next sprint planning,
and they may show and get immediate feedback,
either from the product owner or from stakeholders,
and usually all of these different processes
are being managed by the Scrum Master.
The Scrum Master is essentially your facilitator-in-chief,
the person who is going to help get all the work done
by tracking and enabling meetings to go efficiently,
and to ensure the performance is being accomplished,
et cetera.
They are essentially the guide and the facilitator.
Once the sprint is completed, you're gonna have
what's called a potentially releasable increment.
That potentially releasable increment
is then going be demonstrated in the sprint review
to the product owner and any stakeholders
who are interested in the progress,
and that's gonna be an opportunity
to get real concrete feedback
on a working product, or maybe a prototype.
And then there's also gonna be the sprint retrospective,
and this is gonna be a chance for the team
to take a look at how well they did in the last sprint,
and then talk about what could they do better,
how could they improve as a team?
This is what really allows the team
to learn and go faster,
and they then start this process over again with planning
immediately after the retro.
And this is the reason why we say
Agile is an anti-fragile or resilient framework,
is because in Agile, you start off with planning,
and then you go to doing,
and then you check what you did,
and then you act to change how you plan and how you execute.
And so this plan, do, check, act, improvement cycle
means you can learn from every sprint
and get faster and faster.
So to sum up, we talked about the Agile Manifesto
and how we value individuals and interactions
over processes and tools,
working systems over comprehensive documentation,
customer collaboration over contract negotiation,
and, of course, responding to change over following a plan.
And that really is the centerpiece of Agile,
but the goal of Agile is speed.
It is a three-step process
in order to get that resilient learning framework
built into your program,
and in the end, that resilience
is what's going to lead
to really high performing teams,
is the fact that they can go faster by learning
and by having this communication.
That built-in continuous improvement
is going to make all the difference,
and through learning and through experimentation,
we're gonna become an anti-fragile team.
So, hopefully, this lesson has been clear to you,
and you've been able to get
a little bit of a refresher on Agile
if you didn't know it already,
or maybe you learned a thing or two about Agile
you didn't know.
In the next lesson, we're gonna go back
and talk about Traditional and Lean,
and we're gonna dive into the details there
about how Lean broke the iron triangle.
Look forward to seeing you there.
End of transcript. Skip to the start.