►
Description
“Agile transformation is a cultural challenge.” We’ve all heard it, and we usually agree, but do we really understand what it means? Do we even know what we’re after? And how can we move from Agile-ish project management to a full, enterprise program that delivers higher-quality software faster without sacrificing visibility or predictability?
In 2019, Gitlab surveyed over 4000 software professionals about their Agile and DevOps journeys and implementations, and the results offer candid insight into challenges, failures, and wins. We’ll walk through the results and help you build your own journey on what we’ve learned.
In this webcast, we:
- Define the meaning and benefits of Agile transformation
- Examine cultural challenges that won’t go away and problems tools haven’t fixed
- Preview GitLab’s roadmap to support Agile planning and transformation
A
All
right,
hello
and
welcome
everyone.
Thank
you
for
joining
us
today.
We're
very
excited
to
have
everyone
here
in
this
webcast
we're
going
to
be
covering
a
hot
topic
on
agile
transformation.
We
will
be
talking
about
the
good,
the
bad,
the
ugly
and
a
plan
to
make
it
all
work.
My
name
is
Zack
I'm
on
the
marketing
programs
team
here
at
get
lab
and
I'm
joining
you
today
from
Raleigh
North
Carolina.
We
love
to
hear
where
everyone
is
tuning
in
from
so.
A
Please
use
the
chat
tool
at
the
bottom
of
your
screen
to
let
us
know
where
you
are
all
joining
from
before
we
get
started.
I
want
to
cover
just
a
couple.
Quick
housekeeping
items
first
feel
free
to
ask
questions
throughout
the
presentation.
You
can
use
the
Q&A
function
at
the
bottom
of
your
screen.
To
ask
those
questions.
We
will
have
some
dedicated
time
for
questions
at
the
end
of
the
webcast,
but
you
can
go
ahead
and
submit
those
throughout
the
presentation
and
we
will
get
to
as
many
as
we
can
by
the
end.
A
Also,
if
you're
experienced
excuse
me
also,
if
you're
experiencing
any
technical
difficulties,
please
use
the
chat
tool
and
I
will
help
you
with
any
difficulties
that
you
might
be
experiencing.
Our
presenter
today
is
Cormac
Foster,
get
labs
senior
product,
marketer
specializing
in
agile
transformation.
We're
gonna
launch
just
a
couple
of
polls
to
kick
off
the
webcast
today
to
learn
a
little
bit
more
about
everyone
that
way.
Cormac
can
tailor
his
presentation
accordingly.
A
A
A
A
B
Thank
you
and
yeah.
Those
numbers
actually
look
pretty
similar
to
some
of
the
numbers
we're
going
to
see
in
in
coming
slides,
so
yeah.
Thank
you
again.
All
of
you
for
joining
my
name
is
Cormac
Foster,
as
you
heard,
and
I
cover
a
j'l
transformation
and
the
tooling
that
supports
that
here
at
gate
lab
today.
B
We're
going
to
start
by
talking
about
what
agile
transformation
means,
because
I
know
that's
kind
of
a
loaded
term
we're
going
to
go
over
the
some
of
the
results,
the
relevant
results
from
a
survey
we
did
last
year
with
four
thousand
respondents.
Our
global
developer
report
will
be
a
link
to
download
that
at
the
end
of
the
session
here,
then
we're
going
to
talk
about
agile
as
a
cultural
transformation,
because
a
lot
of
talk
goes
into
agile
culture,
but
in
many
cases
it's
kind
of
a
punchline.
You
know
like
why
isn't
this
working?
B
B
We'll
talk
about
how
we
do
it
at
git
lab,
not
that
we
necessarily
do
it
the
best
possible
way,
but
it's
it's
a
very
different
approach
from
what
I've
seen
at
other
companies
where
I've
worked
well,
then
we'll
talk
a
little
bit
about
what
we
see
as
the
kind
of
near-term
future
for
agile
in
the
enterprise
and
then
we'll
talk
briefly
about
our
roadmap.
Although,
as
you'll
see
our
roadmap
at
gitlab
is
online
and
you
can
participate
in
it,
so
I
won't
take
too
long
talking
about
the
product
and
then
we'll
have
a
Q&A.
B
So
before
we
get
into
the
data,
just
a
level
set
agile
and
transformation
on
their
own
are
pretty
loaded
terms
and
I
want
to
be
sure,
we're
speaking
the
same
language.
So
let's
talk
about
what
agile
transformation,
at
least
for
the
purposes
of
this
webinar.
Is
it
isn't?
First,
if
we're
talking
about
agile
with
a
capital
A,
some
people
say
well,
is
agile
a
thing
or
is
it
just
kind
of
a
loose
concept
of
you
know
AI
ideas,
and
it
really
is
a
thing.
There's
an
agile
manifesto.
B
If
you
haven't
read
it
I
suggest
that
you
do
there's
a
link
there.
You
can
read
it
in
about
30
seconds.
There
are
four
agile
values
and
twelve
principles.
The
agile
values
are
over
there
on
the
right.
I
didn't
have
space
for
the
twelve
principles,
but
again
you
can
scan
them
very,
very
fast.
The
values
are
aspirational
and
cultural,
which
is
as
we'll
talk
about
in
a
second,
is
very
important.
B
There
are
things
like
working
software
is
the
primary
measure
of
progress
or
business
people
and
developers
should
work
together
daily
throughout
the
project,
so
they're
easy
to
grasp
concepts
that
are,
in
many
cases
very
hard
to
implement
because
they
require
cultural
buy-in
across
across
the
company
and
we'll
get
into
that
bullet.
2
is
actually
pulled
from
one
of
those
values.
There
are
a
lot
of
different
agile
methodologies,
but
the
goal
of
any
agile
implementation
and
the
kind
of
transformation
is
delivering
the
greatest
amount
of
value.
B
Now
sometimes
you
have
to
think
about
what
value
means
in
a
different
way,
but
ultimately
it's
about
delivering
value
to
your
end,
customers,
whoever
those
might
happen
to
be
as
quickly
as
possible,
getting
it
in
people's
hands,
so
they
can
use
it
so
that
you
can
iterate.
On
top
of
that,
the
next
bullet
it
is
not
dependent
on
any
particular
methodology
or
framework.
So
I
am
a
certified
scrum
master,
as
are
probably
many
of
the
people
on
this
call.
I
can
help
your
organization
implement
scrum.
B
Does
that
mean
that
I
can
pick
the
best
methodology
for
you,
or
does
it
mean
that
I
am
the
person
who
is
best
qualified
to
tell
you
how
to
rely
on
your
business
to
become
a
more
agile
business?
Absolutely
not
so.
A
lot
of
people
are
very,
very
aligned
with
you
know
their
favorite
framework
or
their
favorite
methodology,
and
it
becomes
almost.
B
They
become
teams,
you
know
they're,
like
I'm,
the
safe
person
or
I'm
the
scrum
person
and
really
like
those
are
all
implementations
of
agile,
but
they
are
not
the.
They
are
not
agile
themselves,
and
it's
also
not
a
tool
chain
as
much
as
I
would
love
to
be
a
vendor.
Who
sells
you
a
tool
chain
that
will
make
you
an
agile
company.
You
know
I
we're,
not
tools
can
help,
but
we're
talking
about
processes
here.
B
We're
talking
about
culture,
we're
talking
about
things
that
tools
can
help
automate,
but
tools
are
not
the
answer
and
then
they
usually
start
small.
In
many
cases
in
agile
transformation
is
driven
by
a
single
developer
in
some
cases
or
a
single
team
working
on
a
single
project,
and
it
builds
out
from
there.
We
see
that
a
lot
and
we'll
talk
about
ways
that
you
can
make
that
happen
and
it's
an
ongoing
journey.
B
You
know
you're,
probably
never
going
to
get
to
the
point
where
you
say
we're
a
perfectly
agile
company,
we're
done,
let's
move
on
and
in
the
spirit
of
moving
on,
let's
get
into
the
numbers.
So
no
one
builds
software
or
any
kind
of
products
in
a
vacuum.
So
if
you're
building
an
airplane,
you
have
a
supply
chain.
If
you're
building
software
you
have
the
software
development
life
cycle,
the
SDLC,
it's
the
same
principle
and
the
same
kinds
of
things
can
go
wrong.
B
If
you
miss
a
handoff
in
one
area,
everything
else
comes
crashing
to
a
halt
and
your
product
is
late
or
your
product
is
wrong.
You're,
bringing
no
value
to
the
market
to
justify
all
the
work
that
you've
done.
So
with
this
question,
we
asked
respondents
to
list
all
of
the
places
in
their
sdlc
their
supply
chain
where
things
get
stalled,
and
some
of
the
answers
were
things
that
you
expect.
These
are
the
top
five
answers.
There
were
a
number
of
other
answers
that
are
detailed
in
the
in
the
report.
B
B
So
we
expected
that-
and
there
are
a
lot
of
things
you
can
do
to
integrate
quality
into
your
process.
What
was
most
interesting
to
me
was
that
planning
product
and
project
planning
was
the
number
two
roadblock
I've
spoken
with
a
number
of
people
who
have
actually
identified.
This
is
a
problem
and
it
always
comes
back
to
visibility
so
either
in
most
cases
they
don't
have
kind
of
a
low,
latency
or
real-time
understanding
of
what
the
customer
needs
or
what
the
customer
is
doing.
B
So
they
don't
know
how
to
plan
a
product
and
plan
on
the
next
version
of
a
product
when
they
don't
know
what's
happening.
So
if
you
are
only
figuring
out
what
customers
think
about
your
product,
when
you
do
quarterly
surveys,
and
then
you
take
another
quarter
to
plan
you're
six
months
behind
and
in
the
meantime,
you've
either
been
doing
nothing,
you've
been
building
software
and
it
doesn't
meet
those
needs.
The
other
thing
they
don't
have
visibility
into
is
what
the
development
team
is
doing,
and
this
is
a
big
thing.
B
A
lot
of
agile
methodologies
spend
time
really
focused
on
the
definition
of
done.
You
know,
how
can
we
get
software
into
people's
hands?
That
does
what
they
need
it
to
do
and
meets
all
the
criteria
we
have
for
for
acceptance,
it's
if
you're
used
to
done
being.
You
know
these
20
features
need
to
be
done
by
March
and-
and
you
know,
the
development
team
is
working
toward
different
goals
or
in
different
ways.
That
can
be
a
disconnect
but
I.
B
Think
generally,
if
you
don't
understand
what
developers
are
doing
that
and
you
have
no
idea
how
long
it's
actually
going
to
take
to
reach
any
definition
have
done
so.
That's
that's.
A
big
problem,
so
to
me,
with
these
numbers
show,
is
that
even
in
companies
that
have
begun
rolling
out
various
agile
practices,
they
haven't
reached
all
the
way
through
the
organization
as
a
whole.
So
you
may
be
agile
in
one
part
of
the
company,
but
not
in
another
end,
and
if
that's
the
case,
then
you
probably
don't
have
that
end-to-end
visibility.
B
Okay,
I
feel
a
little
bad
about
this
slide,
but
only
a
little
bit
because
I'm
still
friends
with
the
person
who
said
it
many
years
ago,
I
was
working
on
a
project
building
a
CRM
system
for
a
company
any
more
than
that,
but
we
had
a
customer.
They
wanted
to
CRM
app
and
one
of
the
business
stakeholders
asked
if
we
were
going
to
write
it
an
agile,
and
he
said
because
that's
the
language
you
use
when
you
change
your
mind
and
it's
funny.
B
He
and
I
just
joked
about
it
about
a
month
ago
and
he's
now,
mr.
agile,
which
is
which
is
also
funny
but
yeah.
He
didn't
really
understand
what
agile
was,
but
he
had
this
innate
understanding
that
something
was
wrong
with
the
way
that
his
company
was
doing
business
and
the
way
that
they
were
building
products,
and
he
wanted
to
change
that.
So
he
started
doing
research.
B
So
to
his
to
his
point.
Let's
talk
about
requirements,
so
we
asked
again
over
4000
developers
how
frequently
requirements
change
after
work
has
begun,
and
it's
pretty
overwhelming
responses
requirements
change
all
the
time
more
than
and
I
think
55%
of
respondents
said
they
change
all
the
time
or
most
of
the
time,
and
that
means
that
change
is
the
normal
state
of
development.
It's
what
we
should
expect
when
we
go
into
something
we
don't
know
what
we're
getting
into
if
we're
going
to
be
doing
something
complicated
or
interesting
or
new.
B
But
despite
that,
most
companies
have
refused
to
change
the
way
they
kind
of
estimate,
projects
and
plan
projects
and
they've
very
short
memories.
So
you
know
they
walk
into
a
project
and
they
say:
ok
we're
going
to
kind
of
speck
this
out
and
then
maybe
in
a
kind
of
waterfall
fashion,
or
even
if
it's
even
if
it's
agile,
we
have
a
list
of
user
stories.
B
These
are
the
things
that
needs
to
do,
and
these
are
the
things
it's
going
to
need
to
do,
and
you
know
six
sprints
when
we're
probably
going
to
be
mostly
done
and
that's
not
always
the
case.
In
fact
it's
rarely
the
case.
So
there
is
again
a
disconnected
people
who
may
be
working
in
agile
fashion.
They
may
be
working
iteratively
when
they're
actually
like
doing
their
work,
but
the
planning
doesn't
necessarily
reflect
the
reality
that
things
are
going
to
change.
B
B
I
am
perfectly
aware,
are
not
a
one-to-one
match
in
part,
because
DevOps
is
largely
focused
on
the
creation
of
software
and
an
agile
transformation
can
be
business
wide
and
compass
more
than
that,
but
still
DevOps
is
kind
of
where
processes
and
technology
and
people
all
come
together,
and
software
development
is
usually
at
the
center
of
an
agile
transformation
or
it's
the
end
goal.
So
it's
a
pretty
good
proxy
to
evaluate
where
an
organization
might
be
on
their
agile
journey.
B
If
they
didn't
know
they
could
get
more,
they
would
just
say
that
yeah
things
are
going
well
they're,
ten
percent
better
than
they
used
to
be,
but
they
know
they
can
get
more
out
of
this
I
know
they
can
become
more
efficient.
They
know
they
can
communicate
better
with
other
people
in
the
company
and
they
know
that
other
people
in
the
company
can
use
what
they're
doing
to
build
a
system
that
better
supports
agile
operations.
B
So
by
mentioning
visibility.
A
lot,
if
you
don't
know
what
other
people
in
the
company
are
doing,
there's
a
huge
likelihood
that
you're
doing
the
wrong
thing
or
that
you're
doing
the
same
thing,
and
both
of
those
are
bad
for
different
reasons.
But
it
happens
a
lot
and
you're
not
going
to
know
and
be
able
to
correct
until
you
have
a
check
point
at
some
point
in
the
future
and
the
farther
away
from
that
from
you
that
that
complication
is
the
longer
it's
going
to
take
to
see
it.
B
So,
if
I'm
planning
projects
on
one
side-
and
there
are
a
bunch
of
people
developing
that
project-
you
know
the
building
requirements
or
developing
a
project
and
there's
a
problem
with
security.
All
the
way
at
the
end
and
I
have
to
wait
until
there's
a
security
problem
and
someone
tells
the
developer
and
they
start
sorting
that
out
and
ultimately,
it
gets
back
to
me
when
I
ask
where
something
is
I
might
need
to
completely
change
what
I'm
doing
that's
a
problem.
If
I
have
to
wait
that
long
for
it
to
happen.
B
If
you
have
a
system
where
all
of
this
information
is
flowing
back
and
forth,
that
data
is
going
to
be
accessible,
but
it's
not
just
that
the
data
is
there,
it's
that
you
can
use
the
data,
that's
there
to
be
more
it
or
to
be
more
agile
and
be
more
responsive
outside
of
software
development.
Just
from
a
business
perspective,
you
can
make
better
decisions
about
when
things
are
going
to
be
done,
you
can
about
the
cost
of
making
changes.
B
You
can
make
data-driven
decisions
about
things
that
you
can
actually
calculate
an
ROI
and
then
we
we
looked
at
innovation
and
innovation,
I
think
there's
a
macro
story
and
there's
a
kind
of
micro
story,
a
tactical
story
and
more
of
a
strategic
one.
When
you
have
smoothly
running
processes-
and
you
have
that
horizontal
visibility
throughout
the
product
lifecycle,
you
can
start
to
innovate,
you
can
free
yourself
up,
lift
yourself
out
of
the
trenches
and
start
to
make
better
decisions.
B
If
I
were
the
product
owner
and
start
immediately
on
new
features-
and
that's
that's
big,
that
is
innovation.
That
is
going
to
make
a
business
difference
in
the
market
and
it
allows
me
to
move
fast,
but
it
works
on
a
smaller
scale
too.
So,
let's
say
I'm
a
developer
if
I
commit
code
right
away
and
I
got
up
to
get
some
coffee
and
by
the
time
I
come
back
with
my
coffee.
I
realize
that
there's
a
problem
with
that
code,
I
realized,
there's
a
performance
impact
or
a
security
impact
and
something's
wrong.
B
I
can
go
back
and
fix
that
problem
right
away
before
I
build
new
code
on
top
of
bad
code.
Now
that
doesn't
seem
very
innovative,
but
again
we're
talking
a
much
smaller
scale.
Maybe
I
have
to
take
an
entirely
new
approach.
Maybe
I
didn't
write
bad
code,
but
the
whole
approach
I
was
taking
was
just
not
going
to
work.
B
B
So
I
know:
I've
talked
a
lot
about
visibility.
I'm,
probably
gonna
beat
it
to
death,
but
I
think
this
is
important.
I
included
this
slide
because
I
think
it
points
out
something
that
is
often
forgotten.
The
agile
process
needs
to
embrace
everyone
involved
with
your
product,
including
users,
not
just
folks,
planning
it
and
developing
it
and
testing
it
and
making
sure
it's
secure
and
auditing
and
all
that's
super
important.
But
if
no
one
uses
your
product
or
the
people
who
use
it,
don't
get
the
value
they
should.
Then
it's
useless.
B
You
might
as
well
you've
just
burned
money
and
there's
there's
no
point
so
again.
If
you
have
to
wait
a
quarter
to
figure
out
that
there's
a
problem
and
then
another
quarter
to
fix
it.
You're,
probably
going
out
of
business
I
mean
that
can
work
and
and
sometimes
it
can
even
be
profitable
for
a
while
until
your
competition
catches
you,
but
it's
boring
for
your
developers
and
you're
going
to
irritate
your
users.
B
B
The
good
news
is
that
60%
of
businesses
are
routinely
collecting
information,
there's
a
wide
range
of
information
there
they're
collecting
some
of
that
is
kind
of
real-time
or
batch
telemetry
from
from
the
application
where
you
can
actually
see
what
people
are
doing,
what
features
they're
using
some
performance
metrics
and
in
some
cases
it's
you
know,
surveys
that
they're
doing
or
they're
collecting
reviews
and
ratings
from
app
stores
or
places
like
that.
Now
there
are
different
use
cases
for
all
of
those.
B
Ideally,
you
should
be
doing
multiple
kinds
of
polling
from
your
users,
but
something
is
better
than
nothing
now.
The
bad
news
is
that
40%
of
folks
are
doing
nothing
they're,
basically
winging
it
and
all
the
effort
that's
going
into
this.
This
system
is,
is
being
kind
of
left
up
to
the
toss
of
the
dice
at
the
end.
B
So
again,
like
you
can
be
super
agile
all
the
way
to
this,
but
if
your
user
feedback
isn't
incorporated
into
your
process,
it's
it's
very
risky
and
then
there's
some
semi
good
news,
which
is
a
good
chunk
like
half
of
the
people
who
aren't
collecting
feedback
right
now
would
like
to
they
know
they
would
like
to
and
that's
something
that
tools
actually
can
help
they
can.
There
are
many
tools
out
there
from
get
lab
and
others
they
can
collect
a
wide
variety
of
information.
B
And
this
is
going
to
be
the
last
data
point
before
we
start
talking
about
culture.
I
do
want
to
talk
to
tucked
a
bit
about
it,
but
security
like
other
forms
of
testing
security
is
one
of
those
things
that
traditionally
has
been
left
to
the
end.
It's
been
fern
over
the
wall
in
many
cases
after
the
traditional
internal
QA
process
is
finished,
so
you
develop
you
throw
it
over
the
wall,
the
QA
it
passes
or
it
doesn't
when
it
finally
passes
for
that
over
the
wall,
the
security
they
look
at
that
it
passes
her.
B
It
doesn't
if
it
doesn't,
it
goes
all
the
way
back
to
development
development,
fixes
it
and
so
on,
and
so
forth,
incredibly
inefficient
and
like
other
kinds
of
bugs
and
flaws.
If
there
is
a
security
issue,
it
really
helps
to
catch
it
early.
You
know
it
could
be
something
really
simple,
maybe
you're,
building,
maybe
of
a
dependency
on
an
open
source
library
that
is
not
secure.
Well,
that's
an
easy
fix,
but
once
you're
really
far
down
the
line
that
becomes
a
more
difficult
fix
once
you've
you've
done
a
lot
of
things.
B
You've
built
a
lot
of
things
on
top
of
that,
in
some
cases,
some
of
that
kind
of
heard
over
the
wall
may
be
unavoidable
if
you
have
to
pass
external
audits
or
you're
delivering
software
into
someone
else's
kind
of
assembly
line,
but
even
then
there's
still
an
awful
lot
of
opportunity
to
shift
the
security
testing
to
the
left
closer
to
development,
even
if
you're
audited,
you
know
you
you
want.
If
you
can
show
the
auditor
that
you
have
100%
test
coverage
that
you
have
logs
of
everything
that
you've
done.
B
It's
going
to
be
a
lot
easier
to
go
through
that
process.
It's
going
to
be
much
easier
to
bake
in
changes
that
they
recommend
to
your
process
and
you'll
even
be
able
to
do
things
like
automatically
run
tests
retro
actively
on
older,
builds
of
your
software
so
back
to
the
graphic.
What
we're
seeing
here
is
a
strong
correlation
between
overall
DevOps
maturity
and
satisfaction
with
security
processes,
which
makes
sense
if
you
have
the
ability
to
automate
everything
else
you're
doing.
B
If
you
have
that
visibility,
you
can
automate
in
security
tests
and
security
scans
as
you
go,
but
we're
seeing
that
security
satisfaction
lags
a
bit
and
that
also
matches
up
with
what
we've
seen
with
our
own
customers
and
people.
We've
talked
to
you
at
trade
shows
and
other
places
in
the
market.
We
typically
see
that
DevOps
and
kind
of
agile
generally
starts
in
one
area
with
a
very
specific
part
of
the
tool
chain.
B
Okay,
so
now
for
the
the
case
study
before
we
look
at
what
the
future
holds,
I
want
to
talk
a
bit
about
culture,
so
we
hear
about
agile
culture.
A
lot
consultants
often
blame
culture
for
agile
adoption
problems,
like
always,
there's
nothing
wrong
with
our
tools.
It's
that
your
culture
isn't
there
to
support
it.
In
many
cases,
that's
actually
true.
B
Consultants
have
a
have
a
responsibility
to
help
with
culture
as
well.
It's
a
squishy
term.
People
use
it
really
lazily,
but
it's
absolutely
essential
to
agility.
If
you
don't
have
an
agile
mindset
and
you
don't
build
cultural
support
for
it
in
your
company,
all
the
automation
in
the
world
isn't
going
to
save
anything,
because
people
aren't
going
to
use
your
tools
they'll
be
confused
by
them,
they'll
be
threatened
by
them.
So
as
an
example
of
an
interesting
way
to
to
build
an
agile
culture.
B
B
I
haven't
been
here
that
long,
but
I've
been
incredibly
impressed
and
in
some
cases,
made
uncomfortable
at
first
by
the
degree
to
which
it
it
is
and
kind
of
lives,
agile,
values,
it's
been
kind
of
a
shock,
because
change
is
hard
sometimes,
but
the
benefits
have
been
fantastic.
So
our
mission
here
at
get
love
is
everyone
contribute
can
contribute,
that's
a
goal
and
a
challenge
for
the
product,
but
it's
also
how
we
design
the
company.
We
have
a
number
of
cultural
values
which
I
encourage
you
to
all
read
on
our
site.
B
B
Some
of
those
values
seem
a
little
touchy-feely,
particularly
to
people
who
are
primarily
concerned
with
code,
but
they're
really
not
we're
working
with
people
not
with
robots,
and
we
are
encouraging
a
collision
of
different
perspectives,
people
with
different
backgrounds,
people
in
different
roles,
to
generate
creative
solutions,
because
that's
really
the
point
of
this
is
you
know
if
you're
not
generating
creative
solutions
to
new
problems,
then
you're
not
really
innovating,
and
if
you
want
to
work
together
effectively,
you
need
to
take
the
human
beings
into
account.
So
you
need
to
build
teams
with
trust.
B
So
a
lot
of
our
values,
kind
of
focus
around
that
where
that
I
hate
the
term
but
where
the
rubber
meets
the
road
there,
where
it
actually
kind
of
instantiates
as
something
that
gets
things
done,
is
what
we
call
the
MVC.
So
the
MVC,
the
Minimum
Viable
Change,
is
this:
it's
very
similar
to
the
MVP,
the
Minimum
Viable
Product.
But
it's
not
applied
just
to
products.
In
our
case,
you
know
whatever
we're
doing
in
the
company,
whether
we're
enhancing
a
feature
or
editing
a
webpage,
we
are
encouraged.
B
Look
for
the
smallest
increment
have
changed
the
vaudeville.
You
and
then
just
do
it.
Do
it
right
away,
you
don't
have
to
make
it
pretty.
If
someone
says
we
need
a
new
page
talking
about
how
gitlab
helps
with
agile
transformation,
I
will
go
out
there
and
create
a
page.
It
says:
github
helps
with
agile
transformation.
Give
it
my
best
shot.
B
Put
it
up
today
and
don't
let
it
sit
in
committee
for
two
weeks.
Just
put
that
page
up
today
and
immediately
other
folks
in
the
company
will
contribute
to
that,
though,
tell
me
something:
that's
a
bad
idea,
a
good
idea,
hey,
why
don't
you
say
this
instead,
but
they'll
actually
contribute
their
suggestions
and
the
public
will
do
the
same,
and
we
iterate
on
that
as
a
company
constantly,
but
it's
better
to
get
value
out
today,
again,
very
agile,
you
want
to
add
an
increment
of
value
anytime.
B
You
do
something,
but
if
you
can
add
an
increment
of
value,
just
do
it
as
quickly
as
you
can
and
that's
a
big
change
for
me.
I've
worked
at
places
where
it
really
is
about
getting
something
shiny
and
perfect
before
the
world
sees
it
and
get
lab.
Is
is
absolutely
not
that
way
now
that
can
get
messy?
We
have
eleven
hundred
plus
employees
right
now
and
then
we
have,
you
know
millions
of
millions
of
users
out
there
who
can
also
contribute,
so
it
could
get
very
messy
if
everyone
were
just.
B
We
don't
want
this
to
turn
into
you
know
Wikipedia,
so
we
have
dris
directly
responsible
individuals
that
one
we
didn't
create,
but
it's
a
it's
a
great
concept
to
provide
guardrails
around
this.
It's
one
person
who
is
in
charge
of
this.
So
if
I
make
a
suggestion,
the
DRI
can
look
at
that
suggestion.
They
can
accept
it,
they
can
reject
it
and
then
we
move
on
and
we
also
have
a
culture
that
encourages
people
to
basically
have
short
toes
people's
toes,
don't
get
stepped
on.
B
You
know,
let's
assume
people
have
good
intentions
and
that
they're
proposing
changes
for
a
good
reason.
But
likewise,
if
someone
does
not
accept
your
suggestion,
it's
nothing
personal
they're,
the
DRI
for
that
they
probably
have
a
very
good
reason
for
it
and
then,
as
a
company,
we
understand
that
it's
still
a
work
in
progress
like
everything,
including
our
processes,
are
changing.
B
Maybe
we
could
work
on
those
talked
about
how
to
do
that
and
so
I
kept
a
list.
A
big
google
doclist
and
I
presented
it
to
my
boss-
and
I
said
I
said,
hey
you
know
what
maybe
we
should
get
some
people
together
and
talk
about
this
and
he
said
well,
why
don't
you
just
go
into
our
handbook
or
we
talked
about
what
the
process
is
for
this
and
change
it,
and
that
had
never
occurred
to
me.
But
that's
how
we
do
business
here
and
again
it's
a
work
in
progress,
but
it's
it's.
B
It's
worked
out
well
for
us
and
we
have
built
support
in
the
system
to
do
that.
So
one
thing
that
you'll
see
if
you
go
to
any
page
on
get
lab
comm
at
the
bottom
of
the
page.
There's
an
edit
this
page
button,
you
personally,
you
don't
need
to
be
an
employee.
You
can
click
on
that.
You
can
suggest
and
edit
to
a
page
and
our
DRI
for
that
page,
we'll
take
a
look
at
that
and
take
that
into
account
and
we'll
either.
B
Okay,
so
where
are
we
in
four
years?
Four
years
is
kind
of
arbitrary,
but
it's
far
enough
out
that
I
think
some
things
will
change,
but
close
enough,
so
that
you
know
we.
We
have
a
reasonable
idea
of
where
they
might
be
going
based
on
conversations
we've
had
with
our
users
and
others
I
think
we're
finally
going
to
see
widespread
adoption
of
agile
at
the
highest
level
and
we'll
see
that
move
that
we've
all
been
waiting
for
from
outputs.
B
Where
you
say
I
did
all
of
these
things
to
outcomes
where
you
say:
here's
what
we
built,
here's
the
value
we
added
and
the
reason
for
that
is
going
to
be
measurability.
The
enterprise
doesn't
love
waterfall,
they
know
the
estimates
are
made
up.
I
know
how
many
planning
meetings
have
been
in
where
somebody
said.
Okay,
the
last
time
we
said
we
were
65%
done.
Can
we
say
we're
75%
done
now?
You
know
that
everyone
knows
that's
how
it
works.
B
B
So
again,
I'll
go
through
this
roadmap
stuff
really
quickly,
but
because
you
can
check
this
out
on
the
site
in
much
more
detail
on
about
get
lab
comm.
We
have
our
vision
and
a
roadmap,
and
we
have
some
videos
and
really
considered
documentation
from
our
product
team
going
into
decision-making
behind
all
of
our
current
bets
and
prioritizations
and
again
it's
something
you
can
contribute
to
the
discussion
of.
B
We
invite
that
from
the
public,
because
we
you
know
if
you
can
help
us
make
a
better
product
before
we
go
and
make
the
wrong
product
we'd
love
for
that
to
happen.
But
we
have
three
big
goals
for
our
planning
and
management
tools
that
relate
to
the
topic
today.
So
first
we
want
more
people
in
the
enterprise
using
them.
That
means
doing
things
like
building
out
dashboards
that
provide
valuable
information
to
people
who
aren't
developers.
That
means
allowing
stakeholders
to
not
just
review
code
but
also
other
kinds
of
assets.
B
They
might
not
need
to
know
the
intricacies
of
what's
going
on
with
a
certain
commit,
but
they
do
need
to
know
on
a
kind
of
macro
level
where,
in
that
kind
of
tool
chain
something
you
know,
what's
the
progress
of
something,
what's
the
cost
of
something
getting
it
from
here
to
there?
What's
the
cost
of
getting
a
change
from
here
to
there
and
then
how?
What
does
that
change
generating
for
value
at
the
end
of
the
chain?
B
So
they
can
start
to
make
decisions
that
will
impact
the
kinds
of
things
that
software
development
is
working
on
and
those
two
can
work
together
and
then,
finally,
we
want
to
be
sure
to
continue
to
meet
all
the
enterprise
requirements
that
that
our
customers
have.
So
we
don't
put
barriers
between
business
and
agility,
so
continue
performance
improvements,
always
integration
with
identity
providers
and
other
kinds
of
directories
improved
auditing.
That
sort
of
thing,
but
again
please
go
to
the
website.
B
You'll
see
a
much
more
nuanced
discussion
of
everything,
that's
going
on
and
a
lot
more
detail
across
the
entire
product
and
then,
finally,
if
you
haven't
read
it
yet,
the
developer
survey
is
available
on
about
gitlab
com.
I
will
leave
this
link
up
during
the
Q&A.
So
thank
you
very
much
for
that,
and
now
we
can
move
to
the
Q&A.
A
Awesome,
thank
you,
Cormac
everyone.
That's
still
in
the
call.
Please
go
ahead
and
start
submitting
your
questions
into
the
Q&A
section.
We've
got
a
couple
questions
already
that
will
go
ahead
and
jump
into
the
first
question
that
I
have
is.
How
would
you
I'm
sorry
first
question
I
get
that
agile
is
more
productive,
it's
more
productive,
and
so
does
my
team.
How
do
I
convince
management
who
are
not
developers
that
this
is
a
better
way
for
us
to
work?
A
B
Question
and
it's
a
common
situation,
so
we
see
that
a
lot.
We
see
a
lot
of
just
with
gitlab
the
the
tool
with
our
product.
We
see
a
lot
of
developers
adopt
it,
for
you
know,
CI
on
a
project
and
source
code
management
for
project,
and
they
start
working
with
it
and
they
see
great
results
and
then
they
they
are
limited
because
they've
only
used
it
on
a
single
project
and
they
want
to
broaden
their
adoption.
B
I
think
that
the
challenge
is
again
cultural
you're,
going
to
need
to
show
people
who
aren't
familiar
with
agile
methodologies,
the
benefits
that
they
can
get
from
shifting
their
mindset
toward
a
continuous
stream
of
value
from
a
list
of
features
so
kind
of
start
with
what
you
can
and
work
your
way
up.
The
chain
with
things
like
I,
don't
know
a
dashboard.
So
if
you
know
you're
used
to
things
like
burndown
charts
and
all
that
those
kinds
of
progress,
metrics
are
things
that
probably
your
management
outside
of
outside
of
IT
is
not
used
to.
B
So
if
you
can
get
them
engaged
with
a
real-time
stream
of
data
in
a
way
that
they
aren't,
that
would
be
helpful.
I
think
the
other
thing
everyone
knows:
change
management's
a
problem.
So
if
you
can
show
ways
that
requirements
changed
and
you
were
able
to
adapt
that
you
didn't
spend
as
much
time
building
the
wrong
software
and
you
did,
you
were
able
to
shift
gears,
and
you
know
at
the
end
of
the
at
the
end
of
a
sprint,
deliver
something
that
you
know
would
have
taken
six
months.
B
You
know,
even
if
you
didn't
deliver
50
features
you
delivered
three
or
four,
but
those
were
the
right
features.
I
think
showing
that
you
can
pivot
it
quickly
and
again,
it's
gonna
take
some
time,
but
that
I
think
will
help
win
people
over
and
they
might
say,
okay
for
our
next
product,
we're
going
to
start
from
scratch
and
we're
gonna
give
this
a
shot.
You
know
I,
don't
think
you're
necessarily
retro
actively
gonna
change
everything
you
do
about
every
product
line,
but
that's
a
good
place
to
start.
A
B
Okay,
well,
don't
rip
out
and
replace
your
existing
tools.
I
mean
if
you,
if
you
can
do
that,
and
you
want
to
do
that,
and
it
makes
sense
for
you
to
do
that.
Great
I
know
some
folks
in
sales
would
love
to
talk
to
you,
but
I
think
that
any
tool
worth
worth
its
salt
any
any
vendor
of
any
tool
worth
their
salt
is
going
to
understand
that
you
know
we're
talking
about
processes
here,
we're
talking
about
the
way
your
company
does
business
and
you're
not
going
to
change
that
overnight.
B
A
B
That
you
need
to
look
at
what
problems
you're
trying
to
solve
and
what
business
you're
in.
So
if
you
are
trying
to
solve,
if
you
don't
know
the
answers,
if
you
don't
know
the
how
and
you
need
to
be
really
creative,
that's
a
good
sign
that
agile
might
work.
There
are
some
other
things.
You
should
look
at
like
how
many
people
can
be
involved
in
parallel
in
this.
B
You
know
how
you
know
what
role
automation
could
play
in
helping
that
be
more
efficient,
I
I,
think
if
you
are
doing
the
same
thing,
the
same
time
every
single
time
and
your
business
is
really
about
efficiencies
margins,
efficiencies
of
scale
for
known
problems
that
have
already
been
solved.
Let's
say
you
have
an
assembly
line
in
your
building,
bicycle
frames
or
cars,
or
something
like
that
they're,
probably
methodologies
that
are
better
suited
to
optimizing
that
part
of
the
value
chain.
But
even
then
you
know
you
and
wherever
hardware
is
involved,
it
becomes.
B
You
know
it
lengthens
the
cycle
times,
but
even
then
there
are
you
know,
innovations
with
technology,
a
lot
of
computer
modeling,
a
lot
of
3d
printing
things
like
that
have
have
have
compressed
that
cycle
time
for
hardware,
so
agile
in
some
cases
can
make
sense.
If
you
look
at
say
the
prototyping.
So
if
your
Ford
Motors,
maybe
you
don't
need
an
agile
methodology
for
assembling
engines
on
the
assembly
line,
but
the
prototyping
department
absolutely
could
could
take
advantage
of
that.
B
A
Awesome
looks
like
we
have
one
or
two
more
questions.
We
use
ServiceNow,
where
we
have
to
create
change,
requests
for
every
release.
The
UI
authorizations,
along
with
change
boards,
is
so
inefficient.
How
do
you
go
from
one
release
a
week
or
month
to
potentially
multiple
a
day?
What's
the
shift
and
change
management,
we
need
to
do
ooh.
B
Again,
I
would,
in
the
spirit
of
agile
I,
would
stay
start
to
start
small
start
with
a
okay,
I.
First
of
all,
I
will
say
again,
you
know,
scrum
master
means
I
can
help
you
with
you
know
implementing
scrum
for
your
project
yeah.
It
doesn't
mean
that
I
work
for
Mackenzie
the
other,
so
there
are
people
who
who
do
this
for
a
living.
You
know
who,
who
you
know,
can
probably
answer
this
with
more
authority,
but
I'll
give
it
a
shot.
B
I
would
say,
start
small
and
try
to
find
ways
where
you
could
kind
of
prototype
something
do
a
little
skunk
works
project
that
maybe
falls
outside
of
that.
You
know,
get
your
insert
buzzword
here,
your
Tiger
team
of
people
together
from
cross-functional
team
and
say
you
know:
how
can
we
make
this
different?
B
Let's
start
with
a
very
small,
discreet
feature
and
try
to
work
outside
that
box
that
you've
created
because
I
think
you
know
if
you
you've
got
this
massive
change
management
procedure
that
already
exists
and
there's
a
lot
of
inertia
there
and
getting
everyone
to
change
their
mind
and
kind
of
fur.
That
out,
is
you
know
it's?
B
It's
like
the
tool
question
from
earlier:
you're,
not
gonna,
get
everyone
to
just
throw
out
something
that
they've
been
working
with
overnight,
for
a
bet
that
it's
something
like
this
would
work
so
I
would
say:
I
would
say,
start
small
and
really
focus
on
that
value.
Focus
on
the
ability
like
as
to
the
other
question,
the
ability
to
to
show
change
in
a
meaningful
way
and
to
show
that
you
can
again
sorry
for
the
buzz
word
pivot
more
quickly
and
address
changing
responses.
B
And
then
you
know,
if
that's
successful,
say
look,
you
know
we
had
a
business
need,
and
two
months
later
we
had
software
that
actually
adapted.
Where
is
our
old
change
management
procedure
which
you,
because
you
already
know
how
that
works?
So
you
can.
If
you
look
at
what
you've
done,
you
can
then
map
back
to
what
it
would
have
taken
to
get
that
done
beforehand
and
and
try
to
show
that
Delta
but
yeah
I.
A
All
right
awesome,
it
looks
like
we
have
one
more
question
and
then
we
will
close
up.
This
question
comes
from
Martin
I'm,
part
of
a
start-up
that
deals
with
big
companies,
so
we
want
to
be
agile,
but
by
contracting
these
big
companies,
but
by
contract.
These
big
companies
set
us
a
date
of
delivery
with
specific
required
features.
How
do
we
consulate
these
two
conflicting
visions?
A
B
That's
such
a
good
one.
I
asked
that
very
same
question
when
I
was
actually
taking
my
my
scrum
class
I
said
well
yeah.
This
is
all
great,
but
what,
if
you
are
part
of
someone
else's
delivery
stream-
and
you
are
you-
know-
you're
bidding
on
contracts,
you're
bidding
on
a
government
contract
or
the
government
says
we
need
this
done
by
this
date.
There
is
always
going
to
be.
You
know
the
the
answer.
B
The
the
unsatisfactory
answer
I
was
given,
was
well
just
don't
just
don't
bid
on
those
contracts
and
and
tell
someone
you're
going
to
deliver
a
consistent
stream
of
value
and
they
need
to
change
their
thinking,
and
that
would
be
great
if
you
could
do
that.
Like
you
know
what
why
don't
you
just
you
know
instead
of
telling
you
we'll
be
done
with
this
in
two
years,
just
by
two
years
worth
of
our
awesomeness,
and
we
will
deliver
consistent
value
and
we
promise
it's
gonna
be
better
down
the
road.
B
Now
you
can
get
to
that
point
after
you've
done
work
with
someone
again
and
again
and
I
again.
There
are
people
process,
consultants
who
actually
have
systems
for
mapping
this
out,
and
there
are
some
you
know,
frameworks
for
there's
some
enterprise,
agile
frameworks,
that
kind
of
bridge
the
gap
between
like
the
waterfall
world
and
the
like
cowboy
cowboy.
B
You
know,
let's
just
get
this
done
kind
of
agile
thing,
I
think
it's
tough
I!
Think
that
you
know.
Ultimately,
your
numbers
aren't
when
you
do
your
estimation.
If
you
look
at
what
needs
to
be
done-
and
let's
just
say,
you
assign
story
points
to
things,
and
you
say:
oh
okay,
we
know
this
is
our
developers
can
typically
get
this
much
work
done
in
a
specific
in
a
sprint,
so
we
estimate
it
will
take
this
many
teams,
this
many
Sprint's
to
get
sort
of
thing
done.
B
If
you
have
an
agile
development
organization
with
some
history
on
other
projects,
I
think
at
least
you'll
have
a
more
realistic
view
of
what
you
can
produce
you're
just
going
to
have
to
do
the
extra
work
to
map
the
two
of
those
together
internally.
For
your
estimates,
sorry
I
don't
have
a
better
answer
for
that.
I
love!
If
you,
if
you
do
come
across
a
really
great
answer
for
that,
I
would
absolutely
love
for
you
to
share
that
in
the
future.
That'd
be
great.
A
Awesome
looks
like
we
are
out
of
questions
so
Cormac
I
want
to
thank
you
for
the
informative
session
today
and
thanks
everyone
for
joining
us.
We
will
be
sending
out
the
recording
for
the
webcast
in
the
next
few
days.
So
look
out
for
that
in
your
inbox
and
thank
you
all
again
have
a
great
day.
Thank
you.