- Our next lesson is to support The Agile Manifesto.
It's been a while.
The Agile Manifesto was written in 2001,
you may know the history of that, you may not.
A bunch of people who were working really hard
to improve software development outcomes
got together and agreed on just a few simple things.
And they're so powerful, I think they unlocked
the intrinsic motivation of people doing that work.
And it says, we're uncovering better ways
of developing software by doing it and helping others do it.
Hey, I think we still are.
I think the Agile Manifesto says we have room to roan
and we have room to grown.
Through this work we've come to value
individuals and interactions over processes and tools.
People trump process every time.
Working software over comprehensive documentation.
It doesn't mean you don't need comprehensive documentation,
that might be a patent filing,
but the patent's not gonna be any good
if the device doesn't work.
So consequently, the value system
is heavily weighted on the left.
But over does not mean instead of, as we well know.
Customer collaboration over contract negotiation.
Be better to collaborate.
Responding to change over following a plan.
Also important to note,
that we don't wanna skip that last sentence.
While there is value in the items on the right,
we value the items on the left more.
So there is value in these things.
This does not mean instead of.
So we don't wanna take a insane fundamentalist view
and say, this is all we value.
We value this too, but the weight is over here.
When push comes to shove,
I'm gonna lean on people rather than process.
And if the process is broken, what will good people do?
They'll address the process.
That's the Manifesto, I think everybody's seen that.
I mean, probably a lot of people are tired
of talking about it and probably a lot of people
are tired of hearing about it.
But if it's just the front of the Manifesto,
the rest of the Manifesto are the 12 principles,
and they're far more interesting.
I'm not gonna read them to you because that would be
kind of boring for me to read you all 12.
But, I'm gonna look at them
from a slightly different perspective.
So, you can see them here.
First priority, changing requirements, frequent delivery,
working together throughout the project.
Build projects around motivated individuals.
Most efficient and effective method of conveying information
that's face to face,
Working software is the primary measure of progress.
Sustainable development, technical excellence,
simplicity, best architectures, requirements,
and designs emerge from self organizing teams.
At regular intervals,
the team reflects on how to become more effective.
Now, here's a question.
It's not 2001 anymore.
We're building incredibly large systems.
Does the Manifesto still work?
Is that maybe some old school thinking?
You know, 16, 18 years back we believed
that a small team could have these values.
Or, does it still apply?
It's not for me to say.
I'm gonna ask you that same question.
So in class, it's a little more interesting
cause we can do this as a group.
But, take a few minutes, no more than five or 10.
Review the principles behind the Manifesto.
Mark each works as is.
Requires rethinking for scale.
What conclusions do you reach?
I'm gonna give you a couple minutes to do that.
And then I'm gonna come back and tell you
what the classes tell me.
In building that device, satellite or medical device,
is working software or working system the primary
measure of progress?
Absolutely, you're gonna see that
in one lean ads or principles.
Do we need sustainable development?
Seems to me, even more so.
The bigger the system,
the more sustainable we need to do
cause we're truly in this for the long haul.
We're gonna build medical devices of that type
and address cancer, deliver chemotherapy,
or build an infusion pump, or ventilator, or whatever.
Indefinitely, we need that work to be sustainable.
Is continuous attention to technical excellence
and good design important?
As you scale, wouldn't you think even more so?
Because as you build these systems that are built upon
components of other systems,
it becomes even more critical.
And, the system itself becomes more critical.
Simplicity, the art of maximizing the amount
of work not done, is that essential?
The bigger the system, the more essential it is.
Not only are we finding that these resonate,
we need to amplify their criticality
as we scale up Lean Agile development.
Best architectures, requirements, and designs emerge
from self organizing teams.
Do we still believe that?
The system gets bigger, what's my team?
Is it just the team that did a component?
Or, is it team of teams that build the system?
The bigger the system is, the larger the team is.
So if that's the team that builds the system,
do I believe that the best architectures,
requirements, and designs for people building
a medical device come from self organizing teams?
I absolutely do.
But, I believe that's the team of teams.
And the right technical expertise on that team of teams
to come to the right conclusion.
So, do I believe that we need to reflect
at regular intervals?
Absolutely, built right into the model.
So, hopefully this is an exercise that helps you
go back to the Manifesto, fast forward,
put in the context of a really large system,
and saying, "Not only does it apply,
"it's even more critical in building really large systems
"than it is for the teams it was originally designed for."
So in this lesson, we've explored the House of Lean
as the foundation of a Lean Agile mindset.
We've reviewed how to apply and support
the values and principles of the Agile Manifesto
while building systems of scale.
And it think perhaps most importantly,
we've discovered that not only did it apply,
we need to amplify that belief system to deliver
larger systems in a lean and agile manner.