►
From YouTube: What is Continuous Improvement?
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Most
of
the
people
who
are
building
software
or
other
things
in
the
world
used
to
build
things
to
last,
so
better
quality
stronger
the
house
stronger.
The
software
system
is
better,
it
is
perceived
by
others.
Everything
is
optimized
to
last
for
ages
and
it's
this
photograph.
A
This
is
a
palace
that
exists
for
the
castle
that
exists
for
four
or
five
hundred
years,
and
we
know
many
different
churches,
though
kind
of
other
buildings,
that
they
are
just
amazing
and
they
were
built
to
stand
for
for
a
thousand
years
or
even
more
now.
This
is
how
we
want
to
do
their
houses,
and
also
this
is
how
we
want
to
build
our
software
systems.
A
We
build
them
once
and
then
refine
build
another
piece
of
it,
another
piece
of
it
and
until
it
becomes
really
actually
improvement,
never
never
stops,
but
the
general
idea
is
longer.
The
house
stands
is
better
and
the
way
you
would
build
a
house
in
this
world
is
is
like
this,
so
you
let's
say
you
have
an
idea.
You
have.
A
A
house
in
mind
you
want
to
build
your
own,
your
house,
your
building,
and
you
go
to
an
architect.
You
tell
the
story,
you
explain
what's
going
to
happen
in
5
10
20
years,
what
you
expect
to
happen
architect,
translated
into
specific
blueprint,
specific.
A
A
So
this
is
totally
fine.
If
you
knew
exactly
what
you
wanted
to
build,
what
kind
of
house
you
would
need
for
the
following
10
years,
because
normally
you
would
live
10
or
15
or
20
years
in
the
same
house,
but
unfortunately
the
world
is
not
as
predictable.
So
what
happens
is
basically
after
two
years
you
get
exactly
the
house,
you
dream,
you
dreamt
you
have
two
years
ago
and
you
have
to
live
in
it
for
10
years,
because
you
spend
all
your
budget
all
your
money
on
actually
building
this
house.
A
It
typically
took
a
bit
more
than
you
expected.
It
took
a
bit
longer
a
bit
higher
budget,
so
you
basically
left
with
no
money
and
that's
it,
and
if
the
house
is
not
perfect
fit
for
for
the
following
10
years
or
your
plan
plans
have
changed,
then
essentially
that's
what
it
is
and
you
still
have
to
live
in
it,
and
this
was
fine
in
the
world
that
wasn't
changing
too
quickly.
A
But
we
see
that
the
the
world
is.
The
speed
of
change
is
just
increasing
all
the
time
it's
exponential
in
the
past,
major
innovation
happened
once
in
generation
or
even
100
years.
Now
we
see
new
things
happening
every
week
every
month,
every
year,
all
the
time.
So
there
is
no-
and
it's
not
just
a
lot
of
innovations
recently,
but
also
the
speed
of
innovation
is
increasing.
A
You
can
see,
I
can
bring
dozens
and
dozens
of
charts
like
that,
showing
that
even
in
the
last
decade
or
two,
the
speed
is
increasing.
Here,
for
example,
you
see
the
density
of
unicorns
in
a
so
in
a
tech
world
and
also
within
cloud
native
ecosystem
itself.
The
maturity
of
the
cognitive
landscape
is
is
getting
bigger
every
month.
I
look
at
it.
There's
another
100
boxes
in
it.
A
That's
true,
but
you
can
also
think
about
it
as
as
an
opportunity
the
world
is
changing
and
the
world
is
giving
you
hundreds
and
thousands
of
new
options
to
choose
from
and
if
you
choose
right,
if
you
do
the
your
best
and
you
have
so
many
more
options
to
grow
in
different
ways
to
to
build
value
for
your
customers
in
better
ways.
So
it's
not
just
a
challenge
to
to
adopt
all
those
technologies,
but
it's
also
an
opportunity
to
grow
faster
and
better
and
build
value
in
better
ways.
A
So,
but
there
is
a
very
significant
challenge
in
adopting
new
technologies-
and
this
is
very
well
described
in
a
book
called
innovator's
dilemma
and
generally,
the
idea
is
that
the
blue
line-
this
is
the
old
technology
and
sort
of
it's
incrementally
improving
you're,
always
investing
in
a
bit
of
features
in
the
beginning.
It's
it's
the
value
growing.
Slowly
then,
you
get
most
of
the
value,
but
at
some
point
it
becomes
old
and
heavy
and
no
one
wants
to
use
it.
A
So
then
the
value
is
increasing
and
then
you
want
to
switch
over
to
a
new
technology.
But
then
you,
your
value
production,
is,
is
decreasing,
so
consider
like
airplanes
and
moving
from
propellers
to
jet
engines.
There
was
a
couple
of
decades
of
of
difficult
switch
and
also
today,
when
you,
when
you
consider
switching
from
vms,
to
containers
adopting
kubernetes
it's
difficult
in
the
beginning.
A
A
Now
you
need
to
switch
from
measles
to
kubernetes
in
less
than
three
years,
so
you
really
cannot
invest
two
years
or
even
a
year
or
even
half
a
year
in
adopting
new
technology.
You
need
to
optimize.
Instead
of
optimizing
for
a
long-term
longevity.
We
need
to
optimize
for
change,
for
speed
and
to
optimize
for
speed.
A
The
main
challenge
is
to
be
able
to
quickly
adapt
new
technologies
so
the.
Why
is
because
the
world
is
changing,
because
it's
just
too
fast
to
invest
too
much
in
switching
from
one
technology
to
another
or
stay
with
old
and
updated
technologies,
because
others
will
do
it
anyway.
So
if
not
you
then
somebody
else
will
will
do
it
and
then
how
can
we
do
it?.
A
What
we
want
to
change
to?
Basically,
the
idea
is
to
switch
from
build
to
last
and
to
build
to
change,
and
so,
instead
of
optimizing
for
long
term
and
quality
in
terms
of
how
long
the
same
system
will
will
work
and
we've
all
been
in
these
situations,
when
you
build
a
software
system
that
is
there
and
some
kabul
systems
that
are
still
40
or
50
years
later,
they're
still
surviving
and
bringing
value
to
mainstream
banks.
A
A
I
really
want
is
instead
of
building
these
castles,
and
you
can
imagine
a
software
system
that
is
like
a
castle
or
a
cathedral,
and
switching
to
this
kind
of
you
know
things
that
no
one
cares
about
just
quickly
patched
together.
They
still
could
be
very
high
quality,
but
the
whole
point
is
that
no
one
cares
what's
inside.
A
So,
basically,
instead
of
investing
a
lot
in
the
beginning
and
gradually
improving
those
things
are
just
got
it
and
started
new
right.
So
once
you're
done
with
this,
this
kind
of
construction
like
this
one.
This
is
the
food
holland
in
amsterdam,
this
kind
of
holes-
they
are
all
over
the
world
and
it's
an
old
trams
depot,
and
now
it's
a
full
food
hall
and
offices,
and
once
that
is
not
working
anymore,
they
will
just
remove
all
the
all
the
goes
inside
and
rebuild
everything
in
some
in
some
different
way.
A
A
Basically,
the
main
story
is
that
the
the
bigger
the
the
bigger
parts
to
the
slower
changing
parts
of
the
system-
they
are
those
who
dominate
the
speed
of
change.
What
I
mean
by
it
is
consider
a
house
right,
so
the
most
important
thing
is
foundation
that
defines
the
size
of
the
house,
but
also
the
inside
walls,
the
construction
of
the
of
the
building
itself.
So
if
you
have
a
supporting
go
in
between
it's
very
difficult
to
remove,
it
means
you
will
probably
not
do
it
so
the
most
important
parts
for
the
change
are
foundation.
A
The
structure
and
everything
inside
can
be
changed
over
time.
So
what
it
means
is
that
what
this
food
highland
example
it's
a
massive
hole,
it's
a
massive
hanger
that
has
no
walls.
That's
that's
why
you
can
feel
it
fit
in
anything.
You
like
you
can
remove
anything
that
you
have
in
there
and
you
build
it
again.
A
I
have
another
example
from
my
own
house
in
in
holland,
so
these
are
traditional
dutch
houses
with
like
a
rectangular
three
stories
building
the
problem
is
in
the
first
floor,
there
is
a
supporting
goal
and
we
wanted
to
build
a
an
aisle
in
in
the
kitchen,
but
there
is
no
space
for
that.
Unfortunately,
to
to
to
create
space,
we
need
to
remove
supporting
wool,
which
is
very
expensive.
A
What
it
means
is
that
basically
we
give
up
on
the
change
and
the
house
remains
the
same
and
more
than
that,
we
even
stop
investing
in
the
house,
because
we
know
that
one
day
we
will
need
to
move
to
another
place,
because
that's
what
we
want
right.
So
basically
the
moment
you
cannot
adapt
to
the
future
or
satisfy
your
needs
or
desires.
A
So
the
way
you
build
a
house
in
in
the
more
dynamic
world
is
different,
so
first
you
go
to
an
architect
and
instead
of
saying
this
is
what
I
expect
10
years
from
now.
You
say
I
don't
really
know,
but
I
have
some
guesses.
I
have
three
four
or
five
guesses.
Maybe
I
won't
have
so
many
kids.
Maybe
I
will
work
there.
Maybe
I
will
need
an
office.
Maybe
not.
Those
are
the
different
things
that
I
may
need.
A
The
architect
still
goes,
creates
different
scenarios
and
still
there
is
a
blueprint
of
a
real
house,
but
the
general
idea
is
to
build
strong
foundation
that
support
in
the
future.
Any
house.
You
will
want
right
any
direction.
Any
of
those
future
scenarios
that
you
you
might
could
imagine
could
be
built
on
top
of
that
foundation,
because
if
you
don't
have
the
foundation
to
support
future
houses,
then
it's
more
or
less
impossible
to
to
to
foundation
later.
A
Then
you
build
a
basic
house,
the
sort
of
mvp
of
the
house.
You
can
live
in
it,
but
it's
not
big.
It's
just
just
a
minimum.
You
really
need
it
need
for
moving
moving,
and
you
really
don't
want
to
spend
more
than
20
to
40
percent
of
your
budget
on
this,
because
what's
what
happens
after
that
is
continuous
addition,
continuous
improvement
of
that
health.
So,
basically
you
start
building
piece
by
piece.
You
can
imagine
also
a
software
system
built
the
same
way.
First,
you
build
a
very
strong
foundation
which
would
include
typically
a
gel.
A
I
will
talk
about
this
later,
but
typically
it's
agile
processes
and
strong
platform
and
things
from
continuous
integration
and
delivery
things
that
will
really
be
needed
in
the
future.
That
will
really
be
your
foundation
for
the
future
and
then
reason
every
small
house
on
top
of
that.
But
then
you
continuously
improve.
It
continuously
build
more
and
more
things.
You
never
stop.
Building
your
house
essentially,
the
benefit
is
that
you
always
live
in
a
house
that
you
want
in
that
specific
moment,
and
if
you
are
not
happy,
you
can
always
have
more.
A
And
a
very
important
element
here
is
also
the
maintenance
people
forget
about
maintenance.
When,
especially
these
days,
people
think
I
will
do
this
amazing
massive
building
that
is
beautiful
and
directly
into
the
photograph
directly
in
the
in
the
architecture
journal.
A
But
is
it
easy
to
maintain,
because
if
it's
difficult
to
maintain
it's
expensive
to
maintain,
then
there
are
all
the
incentives
to
reduce
the
investment
in
maintenance
later,
which
means
that
the
quality
of
the
system
will
degrade
much
faster
right.
So
what
happens
with
those
things
that,
let's
say
software
system
that
you
spend
two
or
three
years
building
and
then
there
are
no
way,
no
ways
to
improve
or
consistently
maintain
it.
That
is
just
so
sort
of
falls
apart
immediately
after
so
it's
very
important
to
include
ways
to
continuously
maintain
the
system.
A
So
the
how
is,
if
the
the,
why
is
we
want
to
to
adjust
to
the
new
fast-changing
world
the?
How
is
to
build
outside
of
outsized
foundation
and
strong
structure?
First,
build
the
mvp
on
top
of
that
and
then
allow
continuous
change.
The
whole
purpose
is
of
this.
Of
this
approach
is
to
say
everything,
we're
building
can
and
will
change
over
time,
and
we
need
to
be
prepared
for
that.
So
every
piece
of
construction,
every
piece
of
software
that
we're
introducing
in
the
system
is
not
permanent.
A
So
then
what
are
we
going
to
build
cloud
native?
Finally,
cloud
native?
Yes,
we
want
to
build
coordinative
systems,
because
this
is
exactly
the
set
of
technologies
and
practices
that
allow
us
this
fast
change
and
coordinative
yeah.
Most
people
say
that
cloud
native
is
mostly
technical
set
of
principles
like
containers,
microservices
and
dynamic
orchestration,
but
of
course
it
has
to
come
also
with
organizational
structure
with
the
right
culture
with
the
agile
processes
and
everything
else
that
will
actually
allow
you
to
get
the
maximum
out
of
those
technologies.
A
So
again,
if
we
want
a
fast
change,
we
want
to
allow
fast
change,
it's
not
just
about
adding
features
to
kubernetes
or
installing
parameters,
or
things
like
that.
It's
also
being
able
to
release
features
the
value
to
the
customer
quickly.
It
means
that
if
you
have
no
agile
processes,
so
you
have
no
no
culture
that
supports
this
kind
of
fast
change
and
looking
around
and
identifying
new
opportunities
and
going
after
them
immediately.
If
you
have
no
such
culture,
then
kubernetes
will
not
really
help
you
to
go
faster.
A
A
The
dynamic
strategy
is
as
versus
static
strategy
when
static
strategies,
when
you
say
waking
up
first
house,
you
say
10
years
from
now.
I
will
need
this.
That's
why
those
are
the
next
five
steps
that
I
need
to
take.
This
is
totally
fine
in
the
world
that
is
not
changing
too
frequently
right.
That's
why
you
can
define
your
strategy
and
go
for
five
years
and
build
the
product
and
after
five
years
it's
it's
still
relevant,
but
today
this
is
not
what
happens
so
what
you
need
to
do?
A
A
New
opportunities,
you
need
to
really
adjust
and
change,
and
it's
very
important
to
continuously
adjust
and
change,
and
that's
why
we
want
to
use
future
scenarios
just
as
planning.
So
when
you
plan
something
it's
based
on
predictions
right,
you
you
sort
of
make
a
guess
about
the
future,
and
you
are
always
wrong.
We
are
always
wrong,
especially
in
the
world
that
is
changing
fast.
A
Alternatively,
we
want
to
talk
about
different
scenarios
five
years
from
now.
Those
are
the.
This
is
the
range
of
scenarios.
I
can
imagine
that's
why
we
have
strategy,
which
means
we're
choosing
where
to
go,
but
we
are
ready
to
adjust.
Plan
is
not
adjustable
and-
and
you
have
no
needs
to
to
look
around-
this
is
an
essential
element
of
of
cloud
native-
is
dynamic
strategy
and
technologies.
A
The
next
thing
is
agile
processes.
I
there
is
not
much
to
say
a
girl
is
quite
well
understood
and
adopted
in
many
companies.
Unfortunately,
most
enterprises
don't
do
proper
agile.
They
do
sort
of
a
child,
a
childish
thing,
sort
of
waterfall
pretending
being
a
child,
not
really
delivering
all
the
time,
but
it
is
very
important
to
reduce
the
speed
of
the
the
time
it
takes
to
get
feedback
from
the
customer
and
also
in
traditional
scrum.
A
You
have
sprints
of
one
or
two
or
even
here
two
to
four
weeks,
but
these
days
you
don't
even
want
to
wait
for
that,
even
not
as
too
long.
You
want
to
deliver
things
constantly
every
day,
dozens
of
times
a
day
to
get
the
feedback
from
the
customer
and
reduce
dependencies
across
different
teams,
so
a
giant
cloud
native
world
is
is
becoming
even
way
more
important,
but
also
way
more
extreme.
There
is
no
waiting
for
anything
just
constantly
pumping
out
the
value
to
learn
from
customers.
A
What's
going
on,
releasing
the
value
is
the
best
way
and
looking
how
customers
respond
is
absolutely
the
best
way
to
learn.
What's
going
on
in
the
industry
in
the
world,
in
your
customer,
with
your
customer
base
and
based
on
how
to
improve
and
adjust
your
strategy
and
of
course
the
last
one
is
called
native
technology
and,
as
I
said,
I'm
not
going
to
go
too
deep
into
that.
A
I
mean
I
started
using
containers
since
docker
wasn't
even
called
docker
the
company,
and
since
then
it
became
obvious
that
things
like
containers,
microservices
and
kubernetes.
They
can
allow
you
to
go
bigger
and
faster.
A
So
at
the
end,
what
we're?
Building
we're,
building
called
native
cloud
native
means
dynamic
strategy,
agile
processes
and
called
native
technology,
and
the
last
part
is
so
how?
How
can
you
become
cloud
native-
and
this
part
is
mostly
based
on
the
book
coordinative
transformation?
By
the
way
this
book
is
now
available
for
free,
you
can
download
it
from
container
solutions
website
for
free,
so
they're
traders
they're,
always
traders,
so
those
cloud
native
systems
they
are
distributed
by
definition,
containers,
kubernetes
and
everything
else.
Microservices
they're
they're
not
cheap
right.
A
They
are
very
expensive
and
difficult,
mostly
because
they
require
much
more
coordination
and
they
have
they're
very
difficult
to
control.
So
the
change
to
cloud
native
is
not
obvious.
You
have
to
be
ready
to
pay
the
price
and
understand
the
value
in
being
able
to
respond
to
change
in
the
environment
and
the
way
we
typically
see
it
is
that
it's.
This
diagram
is
based
on
the
book
about
design
thinking
where
there
are
three
distinct
stages
of
any
project.
The
mystery.
A
When
you
don't
really
know,
what's
going
on
heuristic
when
you're
sort
of
getting
the
idea,
but
not
fully
yet,
and
an
algorithm
like
mcdonald's,
right
mcdonald's
in
the
beginning,
then
four
restaurants
and
then
current
setup.
When
you
have
a
book
how
to
run
a
mcdonald's
restaurant-
and
we
see
companies
go
through
this
before
they
start,
they
sort
of
stand
there
and
afraid
and
they're
looking
for
a
guide
and
who
can
help
them
to
take
the
journey
faster
in
the
mystery
stage.
A
A
And
this
is
basically
this.
This
dynamic
house
thing
this
is
exactly
what
you
want
to
achieve.
It's
essentially
create
very
strong
foundation,
build
an
mvp
house,
but
then
always
improve
it.
So
if
you
once
you
have
the
mvp
house,
it
means
that
you
have
the
skills
and
the
basics
and
the
structure
in
place.
From
that
point,
the
build
part
is
about
always
building
more
and
more
and
more
the
cloud
native
platform.
Never
the
development
of
coordinated
platform.
Never
stops.
A
You
add
more
pieces,
you
improve
pieces,
you
replace
them,
you
refactor
you,
it's
always
getting
on
and
onward.
You
always
keep
building
your
house,
but
as
important
is
the
the
maintenance,
the
run
pay
side.
So
once
you
have
a
system
in
production,
proactive
maintenance
and
continuous
improvement
on
the
infrastructure
level
is
as
important.
Otherwise
the
system
becomes
outdated
and
not
maintainable.
A
So
the
way
we
would
typically
do
it
is
start
from
a
stage.
We
call
sync
that's
where
we
understand
the
current
stage
to
understand
where
the
companies
is
currently
how
advanced
it
is.
Is
it
an
mystery
stage,
heuristic
stage
or
before
even
started
the
coordinative
transformation?
A
And
generally,
the
idea
is
to
really
map
all
the
future
scenarios.
What
the
company
wants
to
achieve,
what
what
are
the
goals
and
and
future
possibilities
and
move
into
design
stage,
where
you
acquire
the
knowledge
and
build
the
foundation,
that's
where
you
do
typically
public
or
private
cloud.
You
use
standard
standard
apis
to
make
sure
that
you
have
at
least
some
stability
in
the
future.
A
Definitely
introduce
agile
processes,
cicd
and
acquire
acquire
the
knowledge
all
those
and
more.
They
are
the
foundation
and
the
structure
that
will
help
you
to
grow
later
on,
and
then
there
is
endless
build
stage.
It's
basically,
it's
always
about
improving,
always
gradually
bringing
more
teams
and
more
introducing
more
features
and
just
always
investing
in
building
more
and
more
pieces
and
yeah.
It's
just
it's
just
endless
process
of
continuous
improvement
and
as
important.
A
You
have
to
have
a
very
strong
maintenance
structure,
so
the
things
need
to
run.
So
if
something
falls
apart,
of
course,
you
need
to
fix
it,
but
it
has
to
be
beyond
that.
You
have
to
push
the
quality
up
and
up
because
the
scale
of
the
systems
is
always
getting
bigger
and
there's
always
higher
demands
on
on
the
cloud
native
system.
A
A
If
your
cloud
native
transformation
is
successful,
you
will
never
again
be
afraid
of
change
and
again
you
can
download
this
book
and
on
that
website
listed
here
in
container
solutions,
and
thank
you
very
much
for
listening
and
if
you
have
any
questions
you
can
find
me
on
linkedin
or
booker
meeting
with
me
on
on
our
website.
Thank
you
very.