►
From YouTube: Enterprise DevOps: From Silos to Services - Jeff Sussna (Sussna Associates) OpenShift Commons
Description
Enterprise DevOps: From Silos to Services
Guest Speaker: Jeff Sussna (Sussna Associates)
Hosted by Diane Mueller (Red Hat)
OpenShift Commons Briefing
https://commons.openshift.org/events.html
#TransformationFriday
DevOps tells us we should break down silos between departments. Putting that admonishment into practice remains somewhat of a mystery. In large organizations it’s not feasible to make everyone part of a single team. It’s also not feasible to embed every kind of expertise into each team.
The solution lies in transforming silos instead of trying to get rid of them. In this briefing, Jeff Sussna (Sussna Associatates) explains the problem with naive DevOps, and presents a more sophisticated approach based on helping each other serve customer needs. Jeff Sussna gives examples from modern as well as legacy software systems.
https://www.sussna-associates.com/
B
B
Anyway,
our
clients
are
cloud
software
teams
and
executives
that
are
struggling
to
meet
the
demand
for
software
delivery.
That
is
not
just
continuous,
but
also
customer
centered,
and
they
typically
engage
us
when
they
are
doing
some
form
of
agile
and
or
devops
and
not
getting
the
results
they
expect
or
hope
for,
and
they
say
things
to
us
like.
Well,
we
did
the
scrum
training.
We
do
stand-ups,
we
do
retros.
B
We
have
an
sre
team,
we're
running
kubernetes.
What
are
we
doing
wrong
and
what
we
find
often
particularly
in
the
area
of
devops,
is
there's
a
great
deal
of
confusion
about
this
idea
of
breaking
down
silos.
You
know
it's
right
at
the
heart
of
devops,
it's
right
in
the
word,
but
unfortunately
the
the
details,
the
practicalities
of
how
you
do.
It
still
remain
something
of
a
mystery,
and
the
reality
is
that
in
any
kind
of
complex
organization
which,
to
be
honest,
is
anything
more
than
about
30
people
in
engineering.
B
A
literal
approach
doesn't
really
work.
On
the
one
hand,
you
can't
just
put
everyone
on
one
team,
you
know
otherwise
you
end
up
with
50
or
100
or
500
people
in
a
stand
up
every
day
and
on
the
other
hand,
if
you
look
at
one
of
the
devops
ideas
of
these
cross-functional
self-sufficient
teams,
where
you
have
everything
you
need
in
order
to
build
and
run
an
application
that
doesn't
scale
either.
You
know
the
idea
of
having
a
network
expert
in
a
database
spurt
and
a
security
expert
on
every
team.
B
B
B
So,
instead
of
making
you
fill
out
forums
and
ask
permission
in
order
to
get
access
to
scarce
resources
like
servers
or
vms,
the
public
cloud
approach
is
well.
You
want
servers,
let's
figure
out
how
to
give
you
as
many
as
you
want
for
as
long
or
short
of
time
as
you
want
as
fast
as
you
can
ask
them
ask
for
them.
B
Secondly-
and
this
is
a
really
important
point-
is
they're
focused
more
on
helping
you
than
on
what
it
is
they
do?
Public
clouds
don't
really
care
whether
their
infrastructures
as
a
service
or
platform
as
a
service
or
software
as
a
service.
Their
approach
is
helping.
You
solve
your
problems
with
whatever
expertise
they
have,
they
can
contribute,
and
that
leads
to
them
not
just
being
helpful
but
being
continuously
more
helpful.
B
So
I
remember
the
first
consulting
project
I
ever
did
about
10
years
ago,
or
so
where
I
was
helping.
A
small
company
migrate,
a
fairly
straightforward
lamp
application
from
a
bunch
of
failing
hardware
and
a
colo
onto
aws,
and
it
was
a
pretty
straightforward,
lift
and
shift
kind
of
thing.
We
wanted
to
take
advantage
of
some
of
the
basic
public
cloud
capabilities
like
multiple
availability
zones,
an
elastic
load,
balancing
and
so
on
and
so
forth.
B
B
The
project
go
on
with
our
lies,
so
we
did,
and
literally
about
three
weeks
after
we
finished
the
project,
aws
announced
a
new
service
which
was
elasticash,
in
other
words,
on-demand
high
availability,
memcache,
and
I
remember
seeing
this
and
thinking
well,
they
must
have
been
reading
our
emails,
but
whether
they
were
or
not,
what
they
were
definitely
doing
was
watching
their
customers
struggle
with
things
on
top
of
their
platform
and
figuring
out.
How
can
we
use
our
expertise
to
make
that
struggle
simpler?
B
So
we
can.
We
can
see
an
example
of
how
this
idea
of
focusing
on
helping
and
not
just
doing
is
important
a
lot
of
organizations
I
work
with.
We
help
them
with
some
sort
of
platform,
team,
they're
operating
something
like
openshift,
and
they
think
that
their
job
is
to
tip
up
and
run
an
open
shift
farm,
but
what
they
figure
out
fairly
quickly
is
in
order
to
recoup
that
investment.
B
It
also
means
that,
in
addition
to
the
platform,
application
teams
need
to
be
able
to
consume
it
and
they
need
things
that
they
may
not
have
they
probably
don't,
because
they
haven't
had
an
environment
to
do
them
in
before.
You
know
they
need
to
understand
and
have
expertise
in
ci
and
cd.
They
need
a
modular
architecture
that
fits
in
containers
and
kubernetes
and
microservices,
which
they
probably
don't
have.
B
I
had
an
epiphany
one
day
when
I
was
reading
a
marketing
website
from
an
early
software
as
a
service
company.
It
might
even
have
been
salesforce
and
right
on
their
home
page.
They
were
talking
about
things
like
multiple
data,
centers
and
off-site
backup
and
advanced
security
practices,
and
I
realized
that
they
were
spending
marketing
dollars,
talking
about
it
operations
and
then
they
said
something
really
interesting,
which
was
we
update
the
software,
so
you
don't
have
to,
and
the
epiphany
was.
B
B
But
when
software
moves
into
the
cloud,
the
conversation
is
completely
different.
It
becomes
well.
Why
is
it
taking
so
long
to
give
us
this
feature?
Where
is
this
bug
fix?
Why
haven't
you
made
stability
better
yet,
and
what
happens
is
that
customers
begin
to
demand
not
just
value
but
continuously
increasing
value?
B
On
the
one
hand,
they
become
very
impatient
with
delay
and
taking
too
long
to
deliver.
Improvements
can
actually
lose
your
customers,
but
at
the
same
time,
what
they're
asking
for
is
not
just
random
change,
not
just
this
spray
of
features,
but
evolution
of
continuous
improvement
in
value
and
what
value
means
in
the
cloud
is,
first
of
all,
usefulness
that
your
software
helps
them
get
something
done,
but,
secondly,
usability
in
the
largest
sense.
Can
I
adopt
it?
Can
I
migrate
to
it?
Can
I
get
help
with
it?
B
Imagine
that
what
you
want
to
do
is
you
want
to
buy
supplies
to
renovate
your
bathroom
there's
a
whole
bunch
of
things
that
have
to
happen
that
that
are
involved
a
website,
a
store,
multiple
departments
in
the
store.
You
know,
you're
going
to
need,
lumber
and
you're
going
to
need
plumbing
and
you're
going
to
need
electrical
and
you're
going
to
need
to
check
out
and
deal
with
the
checkout
team
and
the
cashiers
and
all
of
the
back
end
systems
that
support
all
of
that.
B
So
that's
something
that
you're
not
going
to
fit
into
a
single
small,
agile
team,
and
one
of
the
questions
we
have
to
address
is
agilent.
Devops
are
very
much
about
decomposing
things
into
smaller
and
smaller
pieces,
whether
it
be
user
stories
or
deployments
or
microservices
or
microservice
teams,
but
we
still
have
to
figure
out
how
to
put
them
back
together,
because
customers
buy
services,
they
don't
buy
microservices,
and
what
this
tells
us
is
that
these
customer
facing
product
teams
need
customer-centered
delivery.
B
B
You
know
the
problem
with
silos,
isn't
that
things
are
separate,
it's
that
they're
sealed
off
from
each
other.
So
what
we
have
to
do
is
figure
out
how
to
kind
of
flip
them
inside
out
and
connect
them
in
to
each
other
in
some
way
that
delivers
coherent
service
but
also
maintains
agility
and
autonomy,
and
we
can
do
that
by
asking
three
deceptively
simple
questions.
B
B
So
let's
look
at
some
simple
examples
of
what
it
means
to
think
in
terms
of
making
promises
to
each
other.
If
you're
in
support,
you
make
a
promise
to
end
users
which
you
will,
which
is
that
you
will
help
them
solve
problems
with
using
the
application
and
more
and
more
support
organizations
are
thinking
about
their
promises.
B
Not
just
in
terms
of
how
many
tickets
can
we
close.
But
how
often
can
we
help
the
customer
solve
their
problem
on
the
first
phone
call,
but
you
also
make
promises
to
application
teams,
which
is
that
you
will
amplify
the
customer's
voice,
one
of
the
best
ways
to
understand
how
your
system
is
working
and
how
people
are
using
it
and
how
it
isn't
working
is
from
support
if
you're
in
networking.
B
What
are
you
promising?
Well,
what
you're
promising
is
high
performance,
secure
and
compliant
data
flow
so
that
I
can
connect
my
application
to
my
database
and
get
you
know
high
throughput
low
latency,
but
also
be
sure
that
I'm
not
violating
pci
or
hipaa
requirements
if
you're
on
the
applica
on
the
platform
team.
What
promises
are
you
making
well
you're,
promising
to
minimize
the
friction
associated
with
delivering
code
to
production
and
you're,
also
promising
to
maximize
the
ability
of
application
teams
to
observe
the
behavior
of
their
applications?
B
B
B
B
So
imagine
as
an
example,
a
data
warehousing
team
inside
of
an
enterprise
that
is
siloed
along
functional
lines.
So
you
have
a
business
analysis
team.
You
have
the
development
team,
you
have
a
test
team,
you
have
a
documentation
team,
you
have
an
operations
team
and
there
are
handoffs
and
delays
and
misunderstandings
and
bugs
every
step
of
the
way.
B
B
One
way
to
think
about
all
of
this
is
that
it's
kind
of
everything
is
a
product,
so
you
take
all
of
the
pieces
of
the
puzzle.
The
business
analysis,
the
development,
the
test,
the
documentation,
the
ops
and
you
put
that
in
one
cross-functional
team
around
that
product
area,
and
you
have
them
all
in
stand-ups,
together
every
day.
B
They
tend
to
be
large,
complicated,
very
old,
architectures
proprietary
databases
very
specialized
hardware
requirements.
It's
not
the
kind
of
thing
that
you
can
easily
port
to
docker
containers,
and
this
is
an
area
where
it
makes
a
lot
of
sense.
You
have
sufficient
complexity
and
sufficient
specialized
needs.
B
The
second
principle
is
to
see
the
horizon,
which
means
focusing
your
work
on
fulfilling
your
promises,
so
that
what
you're
dealing
delivering
is
value
not
just
work.
I
see
a
lot
of
agile
teams
that
have
this
kind
of
heads
down
tunnel
vision
approach.
Is
I'm
working
on
this
user
story,
I'm
working
on
this
user
story
and
there
isn't
any
any
understanding
of
well.
What
are
we
actually
delivering?
B
B
What
value
are
we
delivering
to
our
customers
today
or
not
delivering
that
we
have
to
adapt
to
in
retros
I
like
to
talk
about
something
I
call
the
not
enough
muffins
effect
where
you
have
a
team
and
there's
a
tradition
that
somebody
brings
in
muffins
for
the
whole
team
every
monday
morning
and
there's
a
problem
that
there
are
never
enough
muffins.
So
you
have
your
retro
and
you
talk
about
what
didn't
go
well
and
somebody
says:
well,
we
still
don't
have
enough
muffins.
B
You
should
bring
in
twice
as
many
as
you
think,
you'll
need
now.
On
the
one
hand,
that's
a
good
problem
to
solve
right,
it's
good
for
everybody
to
get
muffins
on
monday
morning,
but
it
doesn't
really
have
anything
to
do
with
how
effectively
your
agile
process
is
working,
and
it's
more
interesting
and
more
useful
to
ask
questions
about
how
well
did
we
deliver
on
our
promises?
B
B
They
say:
well,
I'm
promising
to
deliver
this
kubernetes
port
and
one
of
the
things
I'll
say
sometimes
is
well.
If
the
ceo
walked
over
to
your
desk
and
said,
why
am
I
paying
you
to
do
this
work?
Typically,
there's
a
really
good
answer.
Well,
it's
going
to
make
it
much
easier
for
engineers
to
test
their
changes
quickly
and
easily
against
the
whole
application.
B
B
I
often
joke
that.
I
should
offer
a
fixed
fee,
consulting
service
where
all
I
do
is.
I
walk
around
your
organization
and
I
say
one
sentence
over
and
over
and
over
again,
which
is
make
your
work
smaller,
make
your
work
smaller,
make
your
work
smaller.
It's
amazing
how
flow
and
quality
start
to
improve.
B
Simply
when
you
start
thinking
in
terms
of
what's
the
smallest
next
piece
of
value
I
can
deliver,
and
it's
ironic
because
engineers
deal
in
decomposing
problems.
That's
what
that's!
What
code
is
right?
You
want
to
accomplish
something
you
have
to
break
it
down
into
its
algorithmic
steps,
but
they
seem
to
have
a
really
hard
time.
B
B
My
task
is
we're
changing
backup
software,
so
I
have
to
decommission
the
old
software
and
install
the
new
software
on
200
servers.
I
can't
break
that
down,
and
I
said
okay,
what
are
you
doing
today
and
he
said
well,
I'm
doing
the
first
10
servers
boom.
There
you
go
and
why
is
that
valuable?
Because
either
he
comes
back
at
the
end
of
the
day
and
says
I
did
the
first
10
servers
and
you
know
everything
is
on
track
and
everything
is
going
well
or
he
says.
Well,
I
only
got
five
servers
done.
B
I
got
stuck
with
this
problem
and
someone
else
on
the
team
says:
oh,
I
know
how
to
fix
that
I'll
help
you
after
the
stand
up
and
we'll
get
back
on
track,
or
he
says
well,
I
only
got
five
servers
done.
It
turns
out
that
this
is
harder
and
slower
than
I
thought.
We're
only
going
to
be
able
to
do
five
servers
a
day,
not
ten,
in
which
case
you
know
that
you
have
to
adapt
your
plan.
B
B
It
means
doing
lean,
optimization
of
always
looking
for
ways
to
bring
excess
work
in
progress
and
handoffs
and
toil
out
of
it
again.
If
you
go
back
to
that
data
warehousing
example,
it
was
as
simple
as
getting
the
right
people
in
a
room
together
every
day
that
waste
started
to
disappear
and
one
of
the
challenges
I
see
that
particularly
operational
groups
struggle
with
one
of
the
things
about
lean.
Optimization
is
shifting
unplanned
to
planned
work
and
they
say
well,
we
can.
B
We
can
never
get
out
from
under
our
unplanned
work,
we're
always
having
these
things
come
in,
that's
the
nature
of
being
in
operations.
However,
we
become.
How
are
we
supposed
to
become
more
agile
or
more
strategic
or
more
proactive
when
we're
constantly
being
bombarded
with
things
and
what
I
teach
them
is.
It
is
a
way
of
slowly
digging
their
way
out.
B
How
can
you
spend
20
minutes
today?
That
will
give
you
40
minutes
back
of
free
time
and
then
next
week
you
can
invest
that
40
minutes
to
get
yourself
80
minutes
back
and
you
sort
of
slowly
dig
out
from
under
the
dirt
a
database
group
as
an
example
which
was
they
were
trying
to
automate
database
provisioning.
B
One
of
the
misunderstandings
we
have
with
agilent
devops
and
things
like
continuous
delivery
is
that
the
purpose
is
to
deliver
things
right.
Working
code
is
the
measure
of
progress,
but
really
in
an
adaptive
organization.
That's
continuously
evolving.
The
most
important
thing
is
not
what
you're
delivering
now,
it's
figuring
out
where
you
want
to
go
next
and
part
of
the
point
of
continuous
delivery.
Is
it
allows
you
to
make
that
decision
more
frequently
and
more
continuously?
B
B
Did
it
help
us
deliver
the
value
that
we
wanted
to
deliver
or
not
and
based
on
how
people
are
using
it
and
based
on
its
effect?
Where
do
we
want
to
go
next,
but
the
more
interesting
bit
is
when
you
start
enhancing
visibility,
for
others
worked
with
a
team
where
I
asked
the
product
owners
to
start
going
to
the
weekly
operations
meetings
and
they
stopped
going
because
they
were
bored
out
of
their
minds,
and
the
reason
was
that
the
operations
meetings
were
talking
about.
B
Well,
this
server
crashed,
and
this
is
why
it
crashed
and
the
po
said
to
me.
This
is
really
irrelevant
to
us,
and
then
I
sat
down
with
them
and
I
showed
them
a
splunk
graph.
They
had
these
nice
dashboards
on
monitors
up
on
the
walls
around
the
building
that
showed
splunk
graphs,
and
I
said
you
see
this
graph.
What
it
means
is
that,
this
morning,
from
10
to
11
on
average,
it
took
15
seconds
to
load
the
login
page
and
the
pos
went
ooh,
that's
really
bad
and
this
other
graph.
B
This
shows
that
between
9
and
10
this
morning,
10
of
the
page
responses
were
500
errors
and
they
went
ooh.
That's
really
bad,
and
this
was
suddenly.
They
understood
something
technical
in
terms
of
its
impact
on
the
business
and
the
customer.
Experience
and
the
the
manager
of
the
po
group
said
something
to
me
in
response.
That
was
one
of
those
moments
where
you
go.
Okay,
I've
actually
added
some
value
here.
I
can
feel
good
about
myself,
she
said.
B
Well,
maybe
we
should
go
to
these
weekly
meetings
and
maybe
we
should
be
the
ones
reporting
on
these
graphs.
So,
where
you
really
start
providing
mutual
service
inside
an
organization
is
when
you
start
giving
other
teams
visibility
into
what
you're
doing
that
allows
them
to
do
what
they
need
to
do
better.
B
Now,
one
of
the
funny
things
about
feedback
is
it's
really
hard
and
I
think
the
these
sort
of
agile
feature
factories
and
continuous
delivery
factories
tend
to
get
us
into
a
trap
where
we're
so
focused
on
delivering
the
next
thing
that
we
forget
to
actually
ask
ourselves.
Well,
how
did
that
thing
work?
B
We've
made
them
all
feedback
driven.
I
said,
okay,
well
indulge
me,
let's
go
ahead
and
do
the
exercise.
It
may
be
very
brief
and
then
we
can
go
on
with
the
rest
of
the
day
and
I'd
broken
them
into
four
teams
and
at
the
end
of
the
exercise,
three
of
the
four
teams
independently
came
to
the
same
conclusion
which
they
very
sheepishly
reported
to
me.
They
realized
that
they
were
really
good
at
collecting
feedback,
and
then
they
didn't
do
anything
with
it.
B
B
So
what
this
allows
you
to
do
is
to
start
to
flip
the
equation,
many
organizations
they
do
agile
and
they
do
devops
and
they
feel
kind
of
overwhelmed
because
suddenly
they
they
feel
like
they
don't
have
any
excuse
to
not
do
exactly
what
the
customer
demanded
exactly
when
they
demanded
it
pressure
from
executives
and
pressure
from
sales
and
pressure
from
product.
But
what
this
is
about
is
starting
to
get
out
in
front
and
starting
to
continuously
understand
what
is
it
that
your
customers
need?
B
A
Well,
thank
you
very
much
for
that
jeff
it
always.
Your
talks
are
what
I
would
call
incredibly
pragmatic
and
practical
you,
you
take
things
and
you
distill
it
down
into
really
nice
chunks.
I
was
joking
offline
that
you
kind
of
in
some
ways.
You're
like
the
tim
ferriss
of
devops.
You
turn
things
into
chunks
that
we
can
actually
do
and
make
happen.
So
really
thank
you
for
that.
I
hadn't
seen
the
chart
acronym
explained
and
that
was
very
very
helpful.
A
B
Well,
one
piece
of
advice:
I
don't
remember
who
said
this
and
I
was
one
of
those
things
where
I
wish.
I
had
booked
market
bookmarked
it
at
the
time,
but
there
was
a
company
software
company
that
published
an
article
where
they
said
that
when
your
customers
ask
for
something
you
should
forget
it
and
and
what
and
then,
when
you
read
the
article,
what
they
really
mean
is
you
should
write
it
down
and
then
just
leave
it,
because
if
it's
actually
important
and
valuable
they'll
ask
for
it
again.
B
B
One
of
the
things
I
like
about
the
promise
based
approach
is
it's:
it's
truly
customer
centered
and
it
gets
you
thinking
about
what
are
your
users
trying
to
accomplish
and
understanding
that
and
coming
up
with
solutions
to?
That
is
really
what
design
and
design
research
are
all
about,
and
when
you
do
that,
when
you
set,
you
know
aws
just
didn't.
I
I'm
assuming
didn't
just
sit
back
and
wait
for
somebody
to
call
up
and
say:
hey
we're
struggling
with
memcache.
B
A
B
Is
I
like
to
use
a
phrase
which
is
overwhelming
your
customers,
with
goodness,
which
is,
when
you
start
to
use
continuous
delivery,
not
just
to
satisfy
the
demand,
but
almost
to
create
the
demand
and
again?
This
is
where
research
is
really
important,
because
research
gives
you
insight
before
the
customer
asks
right.
What
is
the
customer
likely
to
ask
for
next
week
next
month
next
year
and
how
can
we
give
it
to
them
before
they
have
time
to
complain?
Because
we
don't
have
it
and
that's
the
holy
grail.
A
Yep,
absolutely
yeah,
so
there's
one
quick
question
that
came
in
from
the
audience
and
it's
about
the
smaller
work
make
smaller
work
comment
that
you
have
the
mantra
which
I
think
is.
I
think
that's
what
triggered
the
tim
ferriss
idea,
and
I
was
like
yeah
I've
heard
this
before
so
he's
asking:
does
it
always
require
a
consultant
to
make
smaller
work?
B
B
You
know,
agile
was
actually.
It
was
a
very
pragmatic
solution
to
a
really
serious
problem,
which
was
you
had
these
it
projects
that
were
going
on
for
five
or
ten
years
and
costing
tens
of
millions
of
dollars
and
when
they
were
delivered,
they
didn't
work
and
they
didn't
actually
meet
the
need,
and
so
agile
was
a
response
to
that
of.
Well.
B
How
can
I
break
it
down
into
smaller
pieces,
but
we
live
in
a
new
world
where
you
can't
know
for
sure
that
you
even
want
to
build
the
big
thing
today.
You
think
you
want
to
build
the
big
thing
and
when
you
look
at
things
like
lean
ux,
what
they're
really
about
is,
let's
make
sure
that
we
want
to
keep
building
the
big
thing
and
the
best
way
to
do
that
is
to
build
a
little
thing.
B
So,
instead
of
saying
we're
going
to
build
this
new-
and
I
like
to
use
slack
as
an
example
because
everybody
knows
slack
instead
of
saying
well,
we
want
to
build
this
new
feature
in
slack
to
do
it
in
terms
of
well.
We
want
to
make
this
capability
better
and
what's
the
next
small
thing
we
can
do,
that
makes
it
a
little
better
and
then
how
can
we
use
that
as
feedback
to
go
well?
Where
do
we
go
next?
B
A
C
B
A
B
It's
to
create
the
simplest
possible
test
of
whether
what
you
think
you
should
do
next
is
viable
or
not,
and
actually
the
the
sort
of
poster
child
for
mvp
from
that
book
is
the
story
of
dropbox.
When
they
were
first
getting
started,
they
didn't
even
know
if
they
could
get
money
to
start
a
company,
so
the
first
thing
they
did
was
they
created
a
video
that
showed
how
their
interface
might
look.
They
made
no
attempt
to
make
it
realistic.
The
only
point
was
to
explain
how
is
this
different,
so
there
was
no
code.
B
You
know
there
was
none
of
this
well,
we'll
we'll
write
a
front
end
and
collect
people's
money.
Before
we
build
the
back
end,
they
didn't
write
anything.
It
was
simply.
How
can
we
ask
the
question
of?
Is
this
viable
from
a
funding
perspective,
so
there's
huge
amount
of
confusion
in
my
opinion
about
what
mvps
are
and
there's
a
difference
between
what
we
would
call
an
mvp
and
actually
delivering
a
viable
piece
of
value,
delivering
a
a
piece
of
value
it
has
to
work.
C
But
I
think
I
I
think
that's
actually
the
what
you
just
said
is
actually
the
confusion,
a
lot
of
people
because
of
the
nature
of
the
book,
lean
startup
and
the
context
that
it's
in
where
you
are
in
in
an
entrepreneurial
situation.
People
hear
viable
as
just
find
the
valuable
thing,
but
I
think
in
fact
viability
has
much
more
to
do
with
things
like
operational
burden.
The
ability
to
upgrade
all
those
things
are
whether
or
not
finding
something
valuable
and
something
something
viable
is
is
a
different
problem
to
me.
C
So,
like
you
know
the
in
in,
like
kind
of
contemporary
language,
a
lot
of
people
are
throwing
around
right
now,
like
there's
outputs
of
a
system
and
then
there's
outcomes
right.
So
you're,
like
you
part
of
the
conversation
of
value,
is
saying
the
outputs
aren't
valuable.
The
outcome
is
valuable.
That's
the
first
shift.
The
second
shift
is
to
say:
is
it
impactful
and
impact
often
means
hey
you
could
you
could
create
those
outputs
and
create
those
outcomes
once,
but
can
you
create
them
over
and
over
and
over
again
in
a
sustained
way?
C
B
D
You
good,
you
know,
I
think
this
to
me,
there's
nothing
wrong
with
dv
in
mvp.
In
fact,
you
know
I
eric
reese
told
me
in
a
conversation
once
that
he
would
basically
fire
somebody
if
they
didn't
start
out
with
like
a
simple
heroku
app
right,
like
you
know,
and
and
and
so
it
isn't,
that
it
is,
it
is
viable.
The
problem
is
we
don't
do
the
classic?
You
know
you
know
me,
I'm
going
to
bring
deming
into
the
story,
but
we
don't
do
the
pdca.
D
We
do
the
pd,
the
pd,
the
pd
pd,
and
we
don't
follow
the
scientific.
You
know
you
know
a
lot
of
stuff.
You
think
about
the
word.
I
always
struggle
to
pronounce
epistemology
right,
like
we
don't
sort
of
apply
that
process
so
that
the
problem
is
these
large
organizations
now
who've
seeded.
This
idea
of
lean
startup
they're
just
got
train
wrecks
of
mvps
all
over
the
place
because
they're
on
these
sort
of
tight
budgets
and
get
it
up
as
quick
as
possible.
C
And
I
think
one
I'll
just
I'll
throw
in
one
more
thing,
just
because
I
you
know
you
and
I
love
talking
about
deming,
so
much
right.
One
of
the
things
about
deming's
loop
is
that
it's
an
extension
of
the
schwartz
cycle,
which
short
came
up
with
right
and
short,
basically
had
this
observation.
He
said
like
we
keep
on
doing
this
thing.
We
do
kind
of
design
production
operation
in
a
row,
these
three
things
in
a
row
in
a
straight
line.
C
What
if
we
make
it
into
a
circle
right
like
what,
if
we
actually
hook
the
system
back
together
again
and
that's
interesting
and
and
then
you
know
short,
becomes
deming
cycle
where
he
adds
like
a
moment
of
reflection
and
things
like
that.
All
also
very
interesting.
The
most
interesting
thing
since
we
have
jeff
on
the
phone
here
is
that
stuart
came
up
with
the
short
cycle.
D
C
That
that
we
described
in
cybernetics
I'm
not
arguing
that
it
comes
from
short,
but
the
language
that
we
apply
and
overlay
on
top
of
schwart
and
deming
the
cybernetic
language.
Sometimes,
I
think,
hides
some
of
the
original
thinking
around
why
it
was
recycled,
why
it
was
a
scientific
cycle,
what
we
were
trying
to
get
done
with
it,
and
I
think
it's
really
interesting
and
the
only
last
thing
I'll
say
about
it-
is
that
I
also
think
it's
fascinating.
C
That
short
came
up
with
the
cycle
inside
of
a
telephone
factory,
which
was
one
of
the
first
high
production
factories
that
created
a
networked
device,
so
that
quality
had
something
to
do
with
the
way
in
which
these
devices
were
deployed
into
a
network,
and
that's
why
quality
and
that
loop
becomes
such
an
important
part
of
what
they're
trying
to
do
at
the
hawthorne
factory
anyway.
That's
me
randomly
ranting
about
other
things.
B
So
good
to
bring
this
to
bring
this
back
a
little
bit
down
to
earth.
I
think
what
we're
all
violently
agreeing
about
here
is
that
the
the
ultimate
purpose
of
agilent
devops
is
not
to
do.
You
know,
deliver
more
stuff
faster,
it's
to
learn
more
continuously
and
be
the
way
that
you
stay
quote
unquote
ahead
of
your
customer
in
a
highly
dynamic
environment
is
by
constantly
learning,
and
if
you
don't
have
that
loop
back
of
we
did
a
thing.
B
B
B
They
just
say
I
mean
I've
seen
teams
where
they
do
mob
programming.
The
entire
team
builds
one
useful,
usable
and
dependable
thing
and
they
release
it
and
they
say:
okay,
what
should
we
build
next
and
they
don't
really
care
where
a
thing
was
on
the
backlog,
they're
just
saying:
okay,
based
on
what
we
did
last.
B
D
And
that's
the
key
right
you
break
out
in
the
prescription
and
you
break
out
of
the
fear
right
like.
I
think
that
sort
of
the
the
reason
I
love,
pdca
or
or
just
scientific
thinking
in
general
is
everything's
an
experiment.
So
you
sort
of
you
just
get
rid
of
the
whole
concept
of
fear
of
doing
something
you
know.
D
Should
we
do
this
or
do
you
have
enough
experience
to
do
this
or
you
know
you
know
shut
up,
because
you
haven't
been
here
that
long
or
shut
up
because
you're,
you
know
no,
no,
I'm
just
going
to
experiment
and,
like
the
truth,
will
bear
out
right
and,
and
so
both
that
sort
of
decimates
the
whole
sort
of
feel
fear
of
failure,
and
then
it
also
allows
to
sort
of
bust
prescription
like
we
did
it
last
time.
We've
always
done
it.
This
way,
right.
C
C
I
I
have.
I
have
an
idea:
what
do
you
have
a
thought
on
that?
Jeff
I'll?
Let
you
go
first,
so
my
my
my
thought
connecting
these
two
things
together
is
that
if
you
start
sprints
with
the
idea
that
you're
going
to
learn
something
at
the
end
of
the
sprint
or
during
the
sprint,
you
would
always
build
build
capacity
in
for
processing
and
understanding
what
that
learning
was
and
the
implications
of
it.
C
If
you
over
focus
just
on
learning
you,
you
get
also
bad
effects
right,
learning's,
expensive
and
you
can't
sell
learning
directly
unless
you're
a
consultancy
and
most
people
aren't
so
it's
a
balance
between
the
two.
Like
you
need
to
learn
a
little
bit.
You
need
to
produce
a
little
bit.
You
need
to
go
back
and
forth.
You
need
to
know
when
to
tic
tac
between
those
two
different
forms
of
value,
information
and
value-added
goods.
Right,
I
don't
know.
B
B
You
can't
learn
everything
you
know.
I
need
my
t-shirt.
That
says
I
don't
always
test
my
code,
but
when
I
do
I
test
it
in
production
right
is
there
certain
things
you
can
only
learn
in
the
real
world
and
if
you
use
the
real
world,
if
you
use
your
customers
as
a
place
to
learn
from
lousy
software,
you
won't
have
any
customers
anymore.
B
So-
and
this
is
where
I
come
back
to
iterative
versus
incremental-
is
what
you're
continuously
delivering
has
to
be
software,
that
they
can
use
and
software
that
you
can
support
and
by
making
it
small
and
making
not
just
the
increments
of
work,
but
the
increments
of
values.
Small.
You
allow
yourself
to
do
that.
Yep.
C
I
think
that
you
know
the
thing
I'd
add
there
really
quickly,
because
I
I
agree
kind
of
like
testing
use
and
stuff
like
that,
is
that
I
actually
like
when
I
think
about
architecture
when
I
think
about
designing
software
or
designing
systems.
I
actually
think
there's
two
types
of
risk
and
two
moments
of
risk.
There's
is
the
risk
that
we
designed
it
incorrectly
and
then
there
is
the
risk
that's
exposed
by
in
use.
C
Is
it
being
used
incorrectly
or
did
it
not
do
what
we
wanted
it
to
do,
and
there's
actually
two
different
ways
to
recover
from
that,
and
I
think
a
lot
of
people
get
obsessed
with
the
we
designed
it
wrong
theory
of
risk
like
we
didn't
design
it
completely
and
there's
a
loop
there.
That
says
like
we
should
spend
more
time,
designing
more
detailed
design,
blah
blah
blah
and
that
that
can
cause
really
bad
problems
right.
C
It's
like
designing
a
bridge,
if
you,
if
someone
says
I
need
a
bridge
and
there's
going
to
be
15
ton
trucks
driving
across
it.
There
are
social
criteria
that
we
can
talk
about
things
that,
like
will
the
bridge
be
used
to
drive
the
right
types
of
things?
Will
it
improve
the
connection
between
the
two
towns?
C
A
Thank
you
thank
you
for
that,
so
we
do
have
to
close
at
the
end
of
the
hour
just
to
respect
jeff's
time,
and
I
you
know,
I
I
also
wanted
to
say
to
jeff.
Thank
you
very
much
for
coming,
because
I
think
the
chart
and
I
love
the
reference
to
pass
the
puck
to
where
your
customers
are
skating.
I
think
you're
helping
us
see
where,
where
to
look
and
and
how
to
look-
and
I
think
that
was
very,
very,
very
helpful
for
today
so
jeff.