►
From YouTube: Keynote Panel - End User Council - Moderated by John Mark Walker, Yasemin Blanton & Art Butler
Description
Keynote Panel - End User Council - Moderated by John Mark Walker, Capital One; Yasemin Blanton, BMO Financial & Art Butler, Discover Financial Services
Watch continuous delivery practitioners and subject matter experts discuss lessons learned from years of technology modernization in highly regulated, large enterprises. Cloud, open source, and devops have combined to form the basis of technology modernization, but spoiler alert: it's not just about the technology. The platforms and tooling are maturing, but bringing about organizational change requires relationship-building and other under-utilized "soft skills".
For more information on the End User Council, including dates and time for future meetings, check out cd.foundation/end-user-council/
Looking for something specific?
0:00 Introduction
4:36 Why this panel?
5:04 How does open-source software affect decisions?
9:31 How has cloud-computing helped you and affected agility within the enterprise?
14:12 What strategies are useful to get people on board with new technologies?
19:00 What helps create the initial partnership to build on?
26:16 What's the right approach for growth in the early stages?
30:45 How do you define success?
35:00 When do you decide to scratch an idea and go back to the beginning?
39:40 Thank you
SUBSCRIBE CDF CHANNEL ►►https://tinyurl.com/y4e4434n
ABOUT US
The Continuous Delivery Foundation seeks to improve the world’s capacity to deliver software with security and speed. Learn more at https://cd.foundation/
A
Closing
out
today
we
have
the
end
user
panel,
moderated
by
john
mark
walker,
who
is
the
director
of
the
open
source
program
office
at
capital,
one
he
is
joined
by
jasmine,
blanton
and
art.
Butler
yasmin
is
head
of
delivery
technology
at
financial
group
and
art
butler
is
product
manager
at
discover
financial
services.
B
Greetings
good
morning,
good
afternoon,
this
is
john
mark
walker.
I
run
the
open
source
program
office
for
capital
one
and
I'm
here
with
a
panel
where
we'll
be
talking
about
the
end
user
council
in
the
continuous
delivery
foundation,
and
we
wanted
to
come
together
today
to
talk
about
how
does
continuous
delivery
effect
in
users
and
I've
assembled
a
fine
panel
of
distinguished
experts
who
can
talk
about
their
experiences
with
continuous
delivery?
B
B
The
fact
is,
we
all
have
to
deal
with
legacy
applications
and
and
how
we
how
we
manage
them
through
this
transformative
process.
So,
as
I
give
that
introduction,
let
let's
go
about.
Let's
go
around
the
horn
and
introduce
ourselves
and
talk
about
your
talk
about
who
you
are
your
experience
with
continuous
delivery
and
maybe
a
little
bit
about
you
know
your
job.
Currently,
why
don't?
We
start
with
jasmine
jasmine.
C
Hi
jm
and
hi
everyone,
I'm
yasmin
blanton,
I'm
the
head
of
u.s
personal
and
business
banking
technology
delivery.
At
bank
of
montreal,
I
have
20
years
of
technology
delivery
leadership,
experience
in
large
financial
institutions
to
really
create
digital
mobile
core
products
platforms,
mostly
using
distributed
systems.
Of
course,
I
do
you
know,
have
the
legacy
system
background
as
well.
C
Over
the
years,
I've
managed
source
code
management
and
build
management
teams,
admission,
critical
and
strategic,
large-scale
programs
platform
development,
as
well
as
the
agile
and
devops
center
of
excellence,
and
over
the
years
my
focus
has
always
been
on
the
sdlc
optimization,
so,
whether
it's
from
the
beginning
to
the
end,
the
middle
different
parts.
But
how
do
we
automate?
B
D
D
I've
been
working
with
several
different,
mainly
financial
institutions
and
insurance
companies.
You
know
more
financially
regulated
industries,
optimizing
their
software
development,
life
cycle
and
part
of
several
different,
several
digital
transformations,
so
I've
gained
quite
a
bit
of
continuous
delivery
experience
in
in
that
realm.
So
I'm
just
happy
to
be
here.
Also,
I'm
happy
to
be
a
part
of
this
panel.
B
Awesome,
thank
you
for
joining
us
and
you'll
notice.
The
theme
here
is
financial
institutions
and
highly
regulated
environments,
because
we
really
want
to
talk
about
what
are
the
obstacles
faced
by
modern
enterprises,
and
we
figured
no
one
knows
more
about
the
obstacles
and
how
to
improve
processes
and
work
within
the
confines
and
guardrails
of
highly
regulated
industries
like
like
the
three
of
us
or
people
like
the
three
of
us.
So
why
don't
we
start
off
with?
B
C
What
we've
seen
over
the
years
is
this
amazing,
thriving
ecosystem
of
tools,
processes,
services
and
it's
been
evolving
very
rapidly.
So
I
think
couple
characteristics
that
really
stand
out
from
an
open
source
perspective.
Is
it
evolves
so
rapidly
because
it's
been
it's
created
by
so
many
users
in
so
many
communities
that
it's
sort
of
hard
to
match
the
speed
of
the
open
source
kind
of
development
in
a
sense?
And
then
the
second
biggest
part
is
the
community
itself
so
similar
to
cd
foundation.
C
It's
great
to
find
the
people
that
are
trying
to
solve
the
similar
problems,
the
same
problems
across
the
different
companies
and
with
a
mission
to
you,
know,
automate
more
or
to
get
to
that
kind
of
accelerated
pace
and
really
connect
with
them
so
overarching,
I
think
the
the
ecosystem,
the
the
number
of
the
tools,
the
specialization,
the
rapid
development
through
a
community
makes
it
a
big
pillar
of
any
cicd
strategy.
In
my
mind,.
D
Yeah,
I
would
totally
agree
with
you
on
that
jasmine,
especially
like
the
harnessing
the
innovation
of
the
global
application
development
community
through
open
source
projects.
I
think
the
other
thing
is
you
get
when
you
build
your
cd
systems
or
platforms
based
on
open
source.
Essentially,
you
get,
I
think
it's
easier
to
get
adoption
with
inside
your
enterprise,
so
you
have
people
that
are
going
to
head
down
this
road.
We're
going
to.
B
Community,
so
it
reduces
barriers
to
entry.
Essentially,
so
sorry,
I'm
gonna
have
to
put
art
on
the
spot
here,
because
I
would
be
remiss
if
I
didn't
mention
that
it
is
his
birthday
today
and
this
is
being
recorded.
Is
september
20,
I'm
sorry,
I'm
not
going
to
mention
the
day
sometime
in
the
very
recent
past.
It
was
his
birthday
so.
B
Lot
perfect,
yeah
that'll
be
our
post-processing
project
so
but
but
yes
to
your
point
earlier
around
barriers
to
entry
and
adoption
those
are
you
know.
I've
been
in
involved
with
various
enterprise,
open
source
communities
for
20
years,
and
I've
watched
the
whole
thing
evolve
and
mature
over
time,
and
it's
been
quite
amazing
to
witness
you
know.
B
It's
it's
a
very
intermingled
relationship
between
those
three
trends
over
time.
So
I
guess
the
the
question
then
that
would
turn
over
to.
You
is
an
art
I
would.
I
would
be
curious,
like
how
have
you
seen
you
know
cloud
computing,
solving
helping
you
solve
your
problems
and
and
how
does
it
affect
the
the
agility
that
you're
able
to
bring
to
the
enterprise.
D
Yeah,
so
I
would
say
when
you
just
look
at
continuous
delivery
in
general,
when
you
start
down
that
transformational
path,
it's
extremely
disruptive,
so,
let's
say
you're
starting
to
get
some
momentum
from
an
application
development
standpoint
you're
getting
your
pipelines
built
out.
You
know
how
to
do
different
types
of
advanced
deployments.
You
know
canary
or
blue
green,
but
from
an
application
perspective,
there's
always
still
the
foundational
capabilities
that
don't
move
as
fast.
D
So
I'm
talking
about
the
infrastructure
side
of
things
or
like
some
of
your
middleware
side
of
things,
so
those
need
to
follow
pipelines
and
move
just
like
your
applications
as
code,
and
so
I
think
the
cloud
has
been
instrumental
in
allowing
us
to
do
that.
So
you
get
you
get
almost
like
a
merger
of
infrastructure
and
application
development
almost
into
a
single
pipeline
where
the
application
development
pipeline
is
easily
consuming
those
foundational
resources.
I
think
when
you
marry
that
with
containers
it
takes
it
to
another
level.
D
B
C
Or
is
it
like?
You
know,
I
think
the
only
solution
like
over
the
years
you
know
I
have
come
to
kind
of
see,
is
talking
to
people
talking
to
each
other
in
collaboration
is
probably
the
best
non-technical
solution
and
then
the
technical
solution
is
wherever
you
are,
whether
you're
at
legacy
app
wherever
you
are
in
the
organization.
C
You
can
automate
take
a
look.
You
know,
spend
some
time
and
automate
whatever
you
can,
even
if
you're
in
a
legacy
environment,
but
between
the
legacy
and
the
modern
applications.
I
think
we
always
see
this
tension
when
we
also
take
a
look
at
this
end-to-end
delivery,
which
is
something
we've
been
really
focusing
on.
I
think
in
the
over
the
last
few
years,
because
it's
not
only
application
development
that
can
go
faster
because
once
you
do
that
you're
like
what's
next
well,
it's
testing.
Okay,
you've,
automated
that!
What's
next,
it's
infrastructure,
it's
the
next
thing.
C
You
know
you
kind
of
go
down
and
when
you
reach
that
back
end,
like
legacy
environments,
I
think
you
collaboration
is
probably
the
best
non-technical
solution
and
one
of
the
things
again
that
kind
of
works
is
if
people
understand
the
big
picture.
If
people
really
understand
what
business
problem
we're
trying
to
solve.
Ultimately,
what
are
we
even
doing?
What
are
we
trying
to
get
to
the
customer
and
if
they
understand
yes,
business
is
trying
to
do
this?
C
We're
trying
to
get
to
the
customer
in
whatever
time
to
get
this
product
out
the
door
under
the
back
end
teams
or
legacy
teams,
understanding
this
big
picture
customer
facing
a
purpose
and
the
goals
really
works
well
and
then
they
kind
of
feel
the
ownership
and
accountability.
So
it's
not
only
like
the
cool
kids
and
the
the
other
people.
C
B
And
I
have
seen
that
exact
scenario
play
out
so
many
times
where
it's
the
cool
kids
versus
the
laggards
and
that
never
ends
well.
So
I'm
curious
like
how
do
you?
How
do
you
make
those
arguments
about
the
ultimate
business
value?
That's
delivered
because
you
you
have
to
navigate
this
series
of,
I
don't
call
them
land
mines,
but
but
but
you
have
to
navigate
the
internal
politics.
B
I
was
trying
to
avoid
the
word
politics,
but
there
it
is
yeah
there
there's
an
art
to
that
right
and
it's
it's
not
it's
not,
and
I'm
glad
you
alluded
to
the
non-technical
solutions.
You
know
I'm
curious
what
what
tactics
and
strategies
have
you
employed
previously
to
sort
of
win
the
day
and
get
people
on
board.
C
Yeah
and
I
think
for
the
there
are
multiple
conversations
to
be
had,
I
think,
with
the
technology
group.
A
lot
of
people,
of
course,
are
focused
on
you
know
the
technology,
the
automation,
the
speed
kind
of
solving
that
kind
of
technology
pipeline.
But
ultimately,
when
you're
having
this
conversation
with
a
business
group,
whether
it's
a
business
executive
or
a
product
group,
they
ultimately
care
about.
What
is
the
business
results?
C
D
C
B
D
I
think
I
can't
say
enough
about
early
on
creating
a
baseline.
First
of
all,
you
have
a
strategy
with
applications.
You
you
want
to
reach
your
end
goal
continuous
delivery
with
and
that's
on
the
technical
side.
But
as
part
of
that
strategy,
you
select
the
applications
that
are
kind
of
weighted
in
such
a
way.
They
might
not
be
the
most
critical
operationally
for
your
business,
but
they
do
carry
a
lot
of
weight.
D
If
you
show
some
business
value
with
them,
people
are
going
to
notice,
and
so,
when
you
choose
those
applications,
you
definitely
have
to
have
a
baseline
of
specific
metrics.
One
of
them
was
jasmine
was
just
talking
about.
You
know
how
often
you're
delivering
business
value
to
the
customer
other
ones
so
like
mean
time
and
delivery
mean
time
to
recovery.
D
Looking
at
the
number
of
incidents
you
have
and
most
you
know,
enterprises
you're
going
to
have
those
metrics
up
front,
but
you
need
to
take
notice
of
them
and
baseline
them
right
off
the
bat,
because
I
think
the
conversation
with
business
you
want
to
have
it
as
early
as
possible,
but
it's
hard
to
sell
them
early.
So
what
you
do
is
you
have
those
metrics
and
you
pay
attention
to
them
and,
as
you
start
to
evolve
and
adopt
a
continuous
delivery,
your
continuous
delivery
pipelines
and
get
better
at
it.
D
You
should
see
the
business
value
with
those
metrics,
those
minimal
metrics
there
you
don't
have
to
get
deep
down
into.
You
know
like
how
many
deals
am
I
doing,
and
how
long
is
my
testing
taking
and
those
type
of
things
and
how
much
code
coverage
those
are
great,
but
those
are
more
from
a
technical
standpoint
and
the
better
you
do,
those
those
top
level
metrics
should
get
better.
D
But
if
you
can
at
least
explain
those
top-level
metrics
to
the
business
and
show
that
business
value
early
on,
I
think
you'll
get
better
adoption
from
them
later
on,
because
it's
not
just
about
continuous
delivery
from
a
technical
standpoint.
It's
also
about
how
we
work,
and
so
when
we
looked
at
like
our
scaled
agile
frameworks,
they
have
to
actually
cross
over
to
where
we're
actually
taking
requirements
from
the
business
and
and
it
gets
there's
a
lot
of
tension
there.
D
Because
you're
saying
like
hey,
I
want
to
do
all
these
different
things
and
it
takes
it
takes
mips
to
do
those
things
as
far
as
like
test
driven
development
and
all
these
different
things,
and
they
all
they
want
to
do-
is
deliver
features.
But
in
the
end,
if
you,
if
you
can
show
the
value
with
those
top
level
metrics
that
help.
B
So
you
made
a
really
important
point
there,
which
is
baselining
starting
off
with
one
area
where
you
can
show
the
value
and
building
from
there,
and
I
guess
an
incremental
approach.
How
do
you
or
what
have
you
found
that
works
for
you
in
in
creating
that
initial
partnership
that
allows
you
to
to
build
that
gives
you
the
platform
on
which
to
build.
I
guess
the
other,
the
other
parts,
the
adoption
curve
that
come
later.
That's
a
great
question.
C
I
was
just
going
to
add:
it
really
gets
everybody
working
together
as
a
team,
a
cross-functional
team
and
you
kind
of
start
losing
a
little
bit
of
this
who's
business.
Who's,
tech,
like
who's
from
which
team
and
a
big
part
of
that
cross
collaboration,
is
obviously
again
understanding
the
purpose
and
the
goals,
but
also
really
business
understanding
what
they
need
to
do
from
a
product
perspective,
so
kind
of
tying
it
to
what
art
was
saying.
It's
not
only
enough
for
technology
to
go
fast.
C
If
product
group
needs
to
also
create
product
features
fast
and
do
market
research
fast
like
if
we're
accelerating
the
paste
in
one
part
of
product
delivery,
then
what
about
the
earlier
phases
and
that
business
and
product
groups
need
to
sort
of
match
that
speed
as
well?
So
it's
really
in
everybody's
best
interest
to
understand
what
we're
automating.
Why
are
we
automating?
Why
are
we
doing
this?
Like
acceleration,
so.
A
B
So
you're
approaching
a
group
of
people
and
and
and
I'm
by
the
way,
I'm
100
in
alignment
with
everything
both
of
you
have
said
so
far.
But
there
are
certainly
instances
where
you
know:
we've
talked
about
risk.
We've
talked
about
the
freedom
to
fail,
which
both
of
which
I
embrace
wholeheartedly
the
both
the
the
me
the
need
to
look
through.
Look
at
this
through
a
risk
management
lens,
but
also
how
do
we
give
how
we
get
that
create
that
psychological
safety
or
create
the
freedom
to
fail
for
our
teams?
B
And
sometimes
it
means
you
have
to
pick
the
the
right
partners,
the
ones
that
you
know
like
it's
business,
critical
and
but
it's
not
maybe
crucial
like
how
do
you
build
the
right
partnership
that,
with
the
the
right
elements
of
risk
that
that
allow
you
to
to
build
that
base?
Because
I'll
tell
you
when
I
showed
up
at
I
mean
I've
been
a
variety
of
companies
and
it.
B
It
was
ingrained
in
me
very
early
on
to
build
those
partnerships
with
the
risk
management
teams,
with
the
legal
and
audit
teams,
the
people
that
are
you're
going
to
need
to
get
their
approval
in
order
for
you
to
move
forward,
and
part
of
that
means
that
they're
going
to
evaluate
and
score
everything
that
you
do
so
since
we're
talking
about
highly
regulated
environments.
How
do
we
look
at
these
through
a
risk
management
lens
and
and
get
them
to
see
the
big
picture.
C
I
think
one
of
the
the
primary
like
the
first
things
is
really
to
use
the
initial
conversations
to
help
with
the
education
a
little
bit
because,
as
we
all
know,
there
are
there's
so
much
out.
You
know
out
there
in
terms
of
terminology,
there's
overlapping
terminology
between
devops
and
ci
and
cd
and
agile.
A
lot
of
different
things
are
in
the
same
space,
and
sometimes
what
happens
is
people
might
just
be
hearing
bits
and
pieces
of
information
and
they
might
think
like
again,
some
people
might
be
thinking.
C
Agile
is
like
it's
all
like
everybody
does,
whatever
they
want,
but
it's
actually
a
very
structured,
very
defined,
discover,
sort
of
a
process.
While
you
know
incorporating
change,
you
know
being
flexible,
so
I
would,
you
know,
say
definitely
be
prepared
to
have
first
of
all
multiples
of
conversations.
C
You
are
like
you
kind
of
cut
up
your
application
or
you
know,
divided
your
application
to
a
lot
of
maybe
different
small
parts
if
you're
doing
microservices
or
you're
approaching
it
differently,
you're
approaching
your
development
differently.
So
just
the
fact
that
you're
working
on
smaller
batches,
developing
testing
and
going
through
the
you
know,
cd
pipeline
and
putting
into
an
auto
you
know
automated
way
is
actually
great.
C
So
once
like
the
risk
team
hears
that
they're,
like
oh
okay,
like
that,
like
that,
actually
makes
a
lot
of
sense
in
terms
of
reducing
the
the
risk
and
then
you
say
well
we're
also
shifting
everything
left.
So
we're
not
going
to
have
these
like
big
bombs
anymore.
Like
explosions,
it's
just
going
to
be
little
things.
You
know
we
find
and
the
development
team
is
going
to
fix
it
right
away.
C
So
then
they're,
like
oh
wow,
like
that's,
actually
pretty
good,
like
you're,
going
to
fix
it
immediately
all
these
issues,
and
then
you
say
as
a
third
item
and
by
the
way
everything
is
automated,
so
we
have
every
audit
trail
we
can
trace.
We
can
look
at
the
logs.
We
can
see
what
failed
and
didn't
fail,
what
the
libraries
were
pulled
into
the
build.
So
once
you
have
this
almost
you
know
immediate
transparency
of
the
automated
pipeline
and
you
can
actually
trace
everything.
C
B
And
that's
a
that
is
a
fantastic
point
when,
because,
when
you
look
at
the
big
picture,
it
does
actually
reduce
the
risk
and
while
you
were
talking
it
brought
to
mind
pretty
much.
Every
agile
and
devops
101
talk
I've
ever
seen
where
you
talk
about
breaking
up
the
waterfall
into.
Like
the
you
know,
the.
B
D
B
Concurrent
processes
and
workloads
so
that
you're
anyway,
more
efficient
in
the
in
the
process.
Thank
you
for
for
going
into
that,
because
that
that
is
absolutely
essential
to
getting
these
things
done.
Art
you've
mentioned
adoption
a
lot
and
I
think
we've
talked
about
an
incremental
approach.
I
think
nobody
is
on
board
with
all
in
all
at
once
approach.
B
We
have
to
talk
about
how
we
increment
and
move
forward
and
make
progress,
but
I
guess
the
question
is
for
those
early
days,
and
you
mentioned
the
the
freedom
to
fail
and
that's
something
I
want
to
hone
in
on
again,
because,
especially
in
the
early
days
of
any
kind
of
major
effort
and
continuous
delivery
is
certainly
that
what's
the
right
approach
for
for
growth
in
the
early
stages,
you
know
do
you?
Are
you
gonna
like
come
and
lay
down
the
law
and
say
that
I
must
do
it
this
way
or
what's
that?
B
D
Yeah,
that's
a
good
question
jam
yeah.
I
think
I
kind
of
call
it
like
you
know
it's
a
balance
between
getting
people
to
adopt
your
continuous
delivery
initiative
and
innovate
with
it
versus
incurring
a
bunch
of
technical
debt
along
the
way.
So
I
think
you
don't
stop
anyone
from
going.
You
don't
stop
it.
You
know
it's
a
crawl
rock
walk
run,
so
you
have.
I
think
we
talked
about
the
legacy
applications
that
aren't
necessarily
built
to
do
this.
D
Let
them
go
too
because
they'll
get
some
benefit
from
automation,
then
you
have
those
strategic
applications
that
you
have
also.
But
I
I
say
you
don't
stop
anyone
from
going,
but
what
you
do
do
is
kind
of
identify
who
your
champions
are
real
early,
so
you
identify
those
champions
and
then
I'm
a
real
proponent
of
guilds.
Gills
that
have
a
very
specific
you
know
goal
in
mind,
so
it
may
be
coming
up
with
a
continuous
delivery
pipeline
to
deliver.
D
What
you're
trying
to
do
is
kind
of
centralize
that
innovation
and
get
people
collaborating
and
talking
together,
and
so
then,
what
happened
is
instead
of
having
them
all
going
out
doing
things
on
their
own
and
you
get
duplicates
of
all
these
things
doing
the
same
exact
thing
which
essentially
become
technical
debt.
They
become
products
of
their
own
in
their
own
little
micro
organizations
that
have
to
be
supported,
and
that's
not
what
we
want
right.
So
that's
almost
like
an
anti-pattern.
D
So
essentially,
if
you
get
them
to
actually
create
these
for
you
and
then
they
educate
the
rest
of
your
organization,
I
think
people
can
actually
run
faster
because
now
those
who
everyone's
not
going
to
be
innovative,
they
just
want
to
know
how
to
do
it
and
so
you've
built
these
pipelines.
They
can
consume
them
and
then,
if
you
back
that
up
with
a
real
strong
intersourcing
strategy
within
your
company,
where
once
those
pipelines
are
out
there,
everyone
can
contribute
to
them
going
forward.
B
Yeah,
let's
see
I'm
a
community
manager
by
trade,
and
you
are
speaking
my
language
right
now,
but
but
that
speaks
to
the
the
importance
of
developing
community
internally
and
how
that
can
play
a
role
in
you
know,
maybe
not
laying
down
the
law
but
getting
people
to
align
and
agree
on.
You
know
a
mutually
beneficial
approach
for
all
these
things.
Yeah.
C
But
it's
really
this
group
of
people
evolving
it
all
the
time
and
that
becomes
a
part
of
sort
of
like
everybody's
daytime
job.
In
a
sense,
it's
not
only
just
coding,
but
it's
really
everything
that
goes
into
that
overarching
product
development
and
maintenance
and
sustaining
that
and
then
evolving
it.
So
I
think
that
mindset
really
kind
of
plays
you
know
into
that,
and
you
can
do
that.
You
can
actually
do
wonders
with
across.
B
Continuous
improvement
is
the
name
of
the
game.
I
would
think
continuous
everything.
That's
a
that's
a
very
good
point
to
if
you,
if
you
look
at
like
what
your
end
goal
is,
and
you
look
at
the
what
the
end
state
that
you're
striving
towards
art.
What
is
how
do
you
define
success
here?
What
does
that
look
like
for
you.
D
So
I
think
you
define
success
right
up
front
when
we're
having
those
conversations
with
the
business.
So
I
think
essentially
you
you
set
a
target.
It's
a
lot
of
times
can
be
a
stretch
goal,
but
if
you're
ultimately
delivering
business
value
at
the
speed
that
you
want
to
deliver
it,
I
think
that's
when
you
achieve
what
you
want
to
achieve.
I
think
the
business
will
actually
let
you
know
when
you've
gotten
there,
you
may.
D
You
may
set
a
particular
goal,
but
I
think
ultimately,
it's
going
to
be
the
business
that
decides
whether
you've
achieved
it
or
not,
and
so,
like
we
said
it's
continuous
right,
so
you
may
set
a
goal
that
hey.
I
want
to
increase
my
delivery
of
features
from
once
a
month
to
once,
every
two
weeks
to
eventually
once
a
week
and
eventually
gets
to
once
a
day
or
multiple
times
a
day.
So
it's
it's.
D
C
So
I
think
when
the
business
goal
and
the
customer
value
is
so
clear
that
we
have
to
get
these
loans
out
to
the
people
in
this
amount
of
time
frame,
we
magically
do
it
and
of
course
it's
not
magic.
You
know
we
kind
of
use
all
these.
You
know
sort
of
principles,
practices
the
technical
aspects
intuitively
to
do
it
as
fast
as
possible,
because
we
don't
have
the
luxury
of
time
right.
I
mean
that's
the
main
reason
and
we
figure
it
out.
It's
all
hands
on
deck.
C
It's
everything
and
you
know
anything
and
everything
was
sort
of
like
preaching
almost
kind
of
happens
overnight,
and
then
the
question
becomes
okay.
How
do
you
sustain
that?
So?
Even
in
these,
like
large
financial
institutions
or
other
institutions
where
this
might
not
be
there,
like,
you
know
like
the
first
like
default
way
of
working,
how
do
you
make
it
the
default
way
of
working?
And
how
do
you
scale
it
out?
C
B
D
Ahead,
art,
oh
no,
I
think
that's
a
good
point
when
jasmine
was
talking
about
scaling
out
without
what
so
scaling
out
the
same
amount
of
resources.
Essentially,
so
we
get
better
and
we're
processing.
So
those
milestones
I
was
talking
about
earlier.
You
shouldn't
be
adding
a
bunch
of
additional
resources
to
hit
those
milestones.
You
should
be
able
to
hit
them.
You
know
easier
without
you
know,
adding
at
least
has
to
say
people
resources
for
the
most
part
and.
B
I
do
have
to
point
out
that
there
was
a
linux
foundation
survey.
I
think
it
was
last
year
in
the
show
they
always
do.
Surveys
around
you
know
open
source
usage
and
there's
a
very
tight
correlation
between
adoption
of
open
source
and
the
number
of
times
you
deploy,
which
speaks
to
the
small.
A
agility
of
these
teams
that
have
you
know,
gone
all
in
on
open
source.
So
I
just.
A
B
To
put
that
out
there,
since,
since
there
was
a
demonstrated
getting
back
to
the
the
first
point
we
were
talking
about,
which
was
the
role
that
open
source
plays
in
all
of
this
one
thing
that
so
so
far
we've
been
talking
about
the
the
happy
path,
the
good
things
we
all
do.
You
know
when
it
all
works
and
how
it's
all
you
know
goodness
and
you
know
mom
apple
pie
and
all
that
stuff.
But
I
I
want
to
hear
about
the
the
times
that
it
hasn't
worked.
How
do
you?
B
B
D
On
that
one
I
mean
like
so
you
you
got
some
of
the
issues.
We
talked
about
some
of
the
regulatory
issues
we
talked
about
earlier,
dealing
with
risk
dealing
with
change
management.
Things
like
that,
I
think
not
getting
them
in
the
conversation
early
enough.
So
we
got
you
got
organizational
challenges
up
front
right
a
lot
of
times.
Your
engineering
ends
up
a
result
of
how
your
enterprise
is
actually
organized,
and
so
those
are
those
silos
we're
trying
to
automate
across.
D
You
have
basically,
these
manual
gates
in
place
and
you're,
trying
to
you're
trying
to
break
down
those
barriers.
With
your
cd
solution
we've
come
into.
You
know.
We
want
to
automatically
open
up
a
change
management
ticket
because
we
didn't
get
our
I've
been
in
organizations
where
we
didn't
get
change
management
involved
in
that
conversation
early
enough
as
a
partner.
D
Jasmine
talked
about
the
education,
but
on
top
of
that
I
would
say
education
and
making
sure
that
they're
a
partner,
it's
not
an
adversarial,
a
relationship
between
your
risk
management
areas
and
your
change
in
incident
management
areas,
so
educate
and
get
them
in
as
a
partnership.
Early
on
now
to
help
you
get
past
some
of
those
those
barriers
or
silo
barriers
that
you
you
you
hit
early
on
and
yeah.
So
I
think
I
think
that's
that's
one
example
there's
quite
a
few.
I
can
keep
going.
B
Yeah,
I
know
I
think
I
mean
I
can
certainly
speak
from
experience
and
say
go
back
to
that
time
or
a
few
times
where
I
did
not
pull
in
the
right
people
and
suddenly
these
technology
arguments
that
I
thought
were
perfectly
made,
so
they
just
get
swatted
down
by
people,
because
I
didn't
do
my
job
early
enough.
As
to
your
point.
Yes,
it
looked
like
you
were
kind
of
at
the
bit
to
really
break
in
there
and
talk
about.
C
Yeah,
I
was
going
to
say
it
is
a
part
of
that,
like
over
communication
like
overarching
like
change
strategy,
but
it's
creating
that
scaffolding
right
as
you're
deploying
anything
new
giving
that
awareness
to
people
that
this
is
new
and
this
hasn't
been
done
before
so,
especially
with
crcd.
A
lot
of
things
are
again
like
technical
they're,
a
part
of
the
development
you
know
kind
of
work
or
the
team's
work.
It
may
not
be
as
visible
to
leaders
or
other
partners.
C
What
exactly
is
going
on
so
really
over
communicating,
I
would
say,
like
we're,
changing,
maybe
the
deployments
you
know
from
this
to
this,
and
it's
going
to
we're
going
to
use
this
tool
and
we're
going
to
give
it
a
try
on
this
date
and
by
the
way
it
may
not
succeed,
it
might
fail.
The
deployment
might
fail,
and
again
maybe
to
your
point-
you
don't
try
it
with
your
mission,
critical
app.
But
oh
I
mean
everything
is
important
nowadays.
C
So
you
also
can't
just
say
you
know
it
just
failed
and
walk
away,
but
creating
that
scaffolding
is.
Maybe
you
have
additional
monitoring
that
night
when
you're
doing
the
deployment.
When
something
happens,
you
create
this
plan
b.
You
know,
plan
a
plan
b
plan
c,
so
you're
a
little
bit
more
careful
and
over
communicating.
And
then,
if
it's
successful
you
celebrate
and
you
move
on
to
the
next
thing,
what
I
kind
of
look
at
it
is
like.
B
I
think
it's
very
sage
advice,
so
I
I
want
to
bring
this
to
a
close,
and
I
just
want
to
reiterate
what
a
fun
panel
this
has
been
if
you're
out
there
listening,
and
you
think
this
sounds
like
a
good
time.
Consider
joining
our
end
user
council
we'll
be
meeting
probably
once
a
month
we'll
send
out
some
connection
details
that
you
can
also
participate,
but
it's
basically
what
you've
seen
here.
B
People
talking
about
best
practices
or
anti-patterns
or
things
that
have
worked
or
haven't
worked,
but
it's
something
that
is
a
major
initiative
for
the
continuous
delivery
foundation
this
year.
So
we
look
forward
to
your
participation.
I
want
to
thank
art
and
yasmin
for
participating,
and
this
has
been
an
exceedingly,
hopefully
helpful
panel
and
certainly
a
lot
of
fun
to
do.
Thank
you
so
much.
Thank
you.
Thank.