►
From YouTube: Concurrent DevOps and VSM
A
So
I've
been
thinking
a
lot
about
VSM
about
stream
management
and
good,
lab
and
I.
Think
there's
a
couple
things
I
wanted
to
explore.
One
of
them
is
this
concept
of
concurrent
DevOps
versus
a
linear
concept
of
DevOps,
which
I
think
there's
some
tension
inside
get
lab
and
how
we
implement
things
I
think
about
things.
A
I
think
it
applies
to
VSM,
so
I
wanted
to
talk
about
in
this
video
and
and
introduce
maybe
a
new
way
to
do,
vs
and
that
we
have
been
designed
currently
so
with
concurrent
DevOps
or
maybe
truths
start
with
traditional
waterfall
style,
project
management
and
software
delivery.
It's
very
linear,
there's
stages,
and
it's
it's
not.
A
It
doesn't
promote
a
lot
of
collaboration
and
we
know
all
the
problems
of
that
and
then
some
of
the
you
know
the
iterations
there
is
that
you
know
10
years
ago
or
20
years
ago,
whatever
there
was
agile
as
a
evolution
beyond
waterfall
and
then
beyond
edge
on
the
others.
Agile
devops
are
applying
the
concepts
of
agile
beyond
software
development,
but
really
software
delivery
like
involving
ops,
so
it
really
DevOps.
A
So
so
that's
clear,
and
so
one
one
salient
point
with
agile
devops
is
the
concept
that
it's
not
really
about
stages
right:
it's
not
really
about
waterfall
to
individual
stages.
Yes,
there
are
stages
in
the
sense
that
people
often
use
stages,
but
but
in
reality
people
increasingly
so
are
not
really
saying
that
its
development
time
now
I'm
only
going
to
do
development
and
do
nothing
else.
There's
this.
You
know
constable
of
shift
laughters.
You
know
security,
that's
supposed
to
be
security,
stakeholders
that
should
be
involved
earlier
same
with
quality
and
so
on
and
so
forth.
A
So
it's
all
about
events,
things
happening
in
events
and
transactions
as
opposed
to
individual
stages
and
so
I
think
that's
how
the
concept
of
concurrent
DevOps
as
we
product-market
it,
and
get
that,
for
example,
I'm.
Pretty
sure
we
have
a
concurrent
DevOps
page
to
explain
that
that
makes
sense,
and
so
for
gitlab
we
can
do
concurrent
DevOps,
because
everybody
can
participate
in
an
issue
and
people
can
comment,
emerge,
requests
and
so
the
UI
the
features
promote
concurrent
DevOps
in
the
sense
that
there's
nothing
blocking
people
from
participating.
A
So
I
want
to
start
off
the
bat
saying
that
there's
a
concert
of
concurrent
DevOps
versus
linear
software
delivery.
How
this
applies
to
the
sm
is
that
the
SM
as
a
concept
really
evolves
from
the
linear,
waterfall
style,
more
so
than
the
agile
concept
and
so
with
with
VSM.
It's
all
about.
You
know
reducing
waste
characterizing,
your
stages
and
coming
from
you
know
lean
manufacturing
where,
in
that
scenario,
you've
modeled
your
process
in
two
distinct,
mutually
exclusive
stages,
and
you
need
to
get
through
those
stages
one
by
one
and
then
from
there.
A
You
look
at
each
individual
stage
and
say
where
can
I
improve?
Where
is
their
waste
in
between
each
individual
stage,
so
that
duck
is
great
in
manufacturing.
I
can
presume
I'm
not
expert
in
manufacturing,
but
it
doesn't
really
make
sense
in
software
because
of
what
we
just
said
with
concurrency,
and
so
why
I
don't
think
the
SM
should
I
mean
and
looking
what
analysts
say:
they're
modeling
BSM
after
that
lean
manufacturing
type
of
concept,
I
think
we
as
Gilad
can
do
better
so
that
that's
where
it's
exciting
so
VSM
breaking
it
down.
A
There's
two
pieces,
so
one
piece
I'm
not
proposing
that
we
change
one
piece
I
am
proposing.
We
change.
The
first
piece
is
the
outside
the
box
that
the
black
box
concept
of
you
just
want
to
compress
the
cycle
time
so
cycle
time.
The
time
from
the
purpose
of
this
conversation
is
more
or
less
the
same
and
and
time
of
software
delivery.
Lead
time
could
include
the
time
that
you
have
to
wait.
For
you
know
the
customer
or
internal
stakeholder
requests
a
feature
and
then
from
there
to
actually
software
delivered.
A
That's
the
entire
thing
is
lead
time.
It's
the
cycle.
Time
is
a
subset
of
that.
So
why
that's
relevant
or
that
black
box
is
relevant
in
this
discussion-
is
that
that
is
not
going
to
change,
because
there's
a
direct
correlation
between
software
delivery.
Compressing
that
time
to
better
business
outcomes,
because
you
know
the
past
20
30
years
of
software,
innovation
has
demonstrated
to
us.
A
That's
how
you
would
a
business
just
quick
small
compressed
cycle
times,
allowing
customers
to
rely,
realize
their
business
value
earlier
and
more
often
and
frequently,
and
so
you
can
get
feedback,
the
flywheel
spins
so
on
and
so
forth.
So
that
is
not
going
to
change.
What
will
change
are
what
I'm
proposing
in
this
video
is
inside
the
black
box
inside
the
black
box.
What
it
should
do
is
help
change
outside
the
black
box
or
put
it
another
way.
A
If
the
black
box
itself
is
compressed,
and
so
what
I
argue
is
that
we
have
to
design
the
inside
of
the
black
box
in
a
way
that
actually
helps
users
compress
cycle
time,
it
should
help
that,
and
so
what
I'm
saying
is
that
traditional
or
non-traditional
up
till
now,
what
we
have
modeled
DSMB
said:
okay,
let's
model
the
black
box
and
the
way
we
model
the
black
boxes.
We
just
chop
it
up
into
linear
stages,
and
we
just
said
that:
that's
not
the
future
of
DevOps
chopping
into
linear
stages
is
not
how
we
work
now.
A
That's
not
how
we
work
in
the
future.
Get
lab,
doesn't
even
work
like
that,
because
we
barely
have
in
depth
and
in
review,
but
everybody
works
in
in
transaction
and
events
in
a
current
current
fashion.
So
what
I
argue
is
that
what
BSM,
instead
of
designing
features
in
the
black
box
to
show
individual
stages
and
tie
it
closely
to.
A
Workflow
stages:
let's
not
do
that:
let's
not
tie
workflow
stages
with
the
inside
of
the
black
box
of
VSM,
where
four
stages
I
think
is
still
important,
but
I
actually
think
we're
act,
that
the
industry
will
move
away
from
that
agile,
workflow
board.
I
think
it
will
be
more
toward
a
Kanban
style
where
you
just
pick
what's
most
important
and
you
work
on
it.
Next,
the
inter
concurrent
DevOps
fashion,
so
specifically
I,
don't
think
the
SM.
A
A
Inside
their
VSM
framework,
so
so
I'll
give
you
some
specific
examples
to
say
that
right
now,
when
you
have
developers
checking
a
code
making
commits
those
are
events
when
you
have
business
stakeholders
commenting
on
issues
throughout
the
cycle
of
an
issue
being
turned
into
a
murder
question
being
developed
and
shipped.
Those
are
all
events,
because
the
product
stakeholder,
the
business
older
owner,
is
participating.
Those
are
events,
security,
stakeholder,
reviewing
it
early
on
reviewing
it
later
same
with
quality
so
on,
and
so
whether
these
are
human
events,
computer
events.
These
are
all
point
in
time.
A
Events
that
get
lab
can
log
and
surface
to
a
user,
and
then
the
feature
would
be
built
or
interesting
features
would
be.
For
example,
you
go
to
review
your
VSM
cycle
time
and
you
know
in
the
past
month
it's
you
know
increased
by
50%
and
that's
terrible,
and
you
want
to
find
out
why
and
then.
So
you
look
at
your
statistics
of
those
events
and
you
see,
oh
because
you
know
we
introduced
this
new
security
process
and
we
had
security
stakeholders
review
the
code
late
in
the
game.
A
A
They
tweak
it
so
security
stakeholders
are
involved
early
on
and
then
rightfully
so
the
development
times
reduced
because
there's
less
rework
and
then
you
see
a
drop
in
cycle
time,
which
is
the
desired,
are
welcome.
So
that's
the
approach
I
want
to
take
with
VSM
to
avoid,
instead
of
modeling
individual
stages
that
are
mutually
exclusive
in
time,
which
doesn't
even
make
sense,
let's
focus
on
events
instead
and
see
what
we
can
explore.
A
I
just
had
this
great
idea:
I
wanted
to
log
in
on
the
video
I'm
gonna
document,
some
ideas,
and
maybe
some
visuals
to
really
hammer
home
the
idea,
but
I
wanted
to
record
this
video
and
get
it
out
there
and
get
everybody's
feedback
as
soon
as
possible.
So
please
comment
on
the
issue
in
which
this
video
will
be
attached
to.
Thank
you.