►
Description
OpenShift Commons Transformation Fridays
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 Associates) will explain the problem with naive DevOps, and present a more sophisticated approach based on helping each other serve customer needs. Jeff Sussna will give examples from modern as well as legacy software systems.
A
All
right,
everybody
welcome
back
to
openshift
commons
and
today,
as
we
like
to
do
on
fridays,
we're
going
to
talk
about
transformational,
things,
organizational,
cultural,
very
devop-ish
things
as
well,
and
today
we
have
with
us
jeff
susna
from
cesna
associates,
but
you
may
know
him
as
the
author
of
designing
delivery,
rethinking
I.t
in
the
digital
service
economy,
which
came
out
in
2015.
A
B
A
Yes
and
it's
it's
a
great
combination
of
a
lot
of
things-
we've
been
talking
about
from
devops
to
systems,
thinking
to
new
things
like
promise
theory
and
that
so
last
week
we
did
a
great
talk
with
kevin
beard
around
raging
against
silos
and
jeff
stepped
up
and
said:
hey,
I
gotta
talk
for
you,
so
I'm
gonna,
let
jeff
introduce
himself
and
then
talk
for
as
long
as
you'd
like
because
it's
always
a
pleasure
and
then
we'll
have
a
conversation
with
some
of
the
members
from
the
global
transformation
office
who
are
here
with
us
today
and
take
questions
from
the
audience.
A
So
please
jeff,
take
it
away
and
show
us
what
you
do
with
silos
versus
raging
against
them.
C
Thanks
diane,
thanks
for
having
me
it's
great
to
be
here
so
yeah,
I'm
jeff,
sussna,
founder
and
ceo
of
susan
associates.
We
are
a
minneapolis-based
consulting
agency
and
we
are
very
much
hunkering
down
for
winter
here.
So
far,
it's
been
fairly
pleasant
and
we've
been
able
to
survive
the
pandemic
by
going
for
lots
of
walks,
but
the
weather
forecast
for
the
next
five
to
seven
days
is
that
it's
not
supposed
to
get
above
zero
fahrenheit,
so
it'll
be
very
much
walking
on
the
treadmill.
C
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.
C
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
remains
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.
C
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
expert
and
a
security
expert
on
every
team.
C
It
doesn't
scale
and
it
and
it
starts
to
bloat
your
two
pizza
teams-
and
I
was
thinking
about
this
and
suddenly
I
realized
something
which
is
that
sort
of
the
early
approaches
to
devops
made
an
assumption
that
they
didn't
tell
anyone
about,
and
that
assumption
was
that
there's
a
cloud
there
is
something
that
abstracts
away
enough
of
the
low-level
infrastructure
and
operations
details
that
it
actually
becomes
feasible
to
have
these
self-sufficient
teams
that
can
run
and
build
operations.
C
Excuse
me
applications
on
their
own
and
that's
incredibly
ironic,
because
the
public
cloud
is
the
biggest
silo
in
the
history
of
I.t.
You
don't
know
exactly
where
their
data
centers
are
you
don't
know
exactly
how
they
do
change
management
or
what
tools
they
use.
C
C
So,
instead
of
making
you
fill
out,
forms
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.
C
Public
clouds
don't
really
care
whether
they're
infrastructure
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.
C
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
and
elastic
load,
balancing
and
so
on
and
so
forth.
C
C
Let's
go
on
finish
the
project
go
on
with
our
lives,
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?
C
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
open
shift,
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.
C
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,
and
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.
C
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.
C
C
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?
C
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?
C
C
C
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.
C
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.
C
So
how
do
we
do
that?
Well,
the
answer
is
by
mutual
service
of
each
part
of
the
organization,
treating
other
parts
of
the
organizations
as
customers,
just
like
paying
customers,
and
this
has
the
effect
of
turning
silos
inside
out.
C
C
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.
C
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.
C
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?
C
C
The
problem
with
it
is
particularly
collaboration
is
kind
of
vague
and
it
sort
of
throws
us
back
to
where
we
started
at
the
beginning
of
well.
How
do
we
collaborate?
How
do
we
organize
to
do
this?
It's
this
old
water?
C
What
is
this
silo
breaking
thing,
so
we
haven't
really
made
any
progress
and
in
our
work
with
practical
sort
of
day,
two
devops
tuning
and
repair,
if
you
will,
we've
developed
our
our
own
acronym
at
suss
and
associates,
which
is
chart,
and
it's
really
about
a
set
of
principles
for
understanding
how
to
organize
yourself
and
how
to
interact
with
your
surroundings.
C
If
you're
going
to
be
a
mutual
service
provider,
how
do
you
actually
do
that?
So
the
first
principle
is
making
the
customer
your
compass,
which
means
aligning
your
team
with
your
customers
goals.
Going
back
to
this
idea
of
promises
and
centering
your
work
around
what
they
need,
not
what
you
build.
So
if
you're
aws,
what
they
need
is
high
available.
C
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
a
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.
C
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.
C
Then
it
makes
a
lot
of
sense
to
have
all
of
the
low
level
and
high
level
expertise
you
need
together
in
one
team,
so
that
you
have
networking
and
database
and
hardware
and
storage
and
application
software
all
working
together,
deploying
together
debugging
dealing
with
outages
together
again,
when
you
do
that
you,
you
start
to
melt
away
this
friction
and
delay
and
waste
that
tends
to
plague
functionally
organized
teams.
C
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?
C
Who
cares
you
know?
Maybe
we
are
on
our
way
towards
continuous
delivery
but
delivering?
Why
what's
the
actual
benefit,
and
does
everybody
understand.
A
C
Well,
on
the
one
hand,
that's
nice
to
know,
but
on
the
other
hand,
the
what
it's
more
interesting
to
talk
about,
what
promise
are
we
fulfilling
today?
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.
C
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.
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?
C
C
No,
your
sprint
goal
is
to
make
search
15
faster,
and
it's
funny
one
of
the
things
I
watch
a
lot
is
friction
between
agile
teams
and
devops
teams
and
executives
and
leadership
teams,
and
the
executives
are
always
saying
well,
this
great
you
did
15
stories,
but
so
what
what's
the
benefit
to
the
business,
and
you
should
be
able
to
say
everyone
should
understand
the
benefits
of
the
business
and
when
I
work
with
engineers-
and
I
ask
them,
what
are
you
promising
to
deliver?
C
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.
C
C
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.
C
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.
C
C
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.
C
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
10.,
in
which
case
you
know
that
you
have
to
adapt
your
plan.
C
C
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.
C
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.
How
are
we
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.
C
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?
C
So
what
you
want
to
do
is,
on
the
one
hand
you
want
to
maximize
your
own
visibility
into.
We
did
this
thing:
did
it
work?
Did
it
fulfill
the
promise?
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?
C
I
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.
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.
C
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.
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.
C
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.
Well,
maybe
we
should
go
to
these
weekly
meetings,
and
maybe
we
should
be
the
ones
reporting
on
these
graphs.
C
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?
C
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.
C
To
start
to
pass
the
puck,
where
your
customers
are
skating.
Sorry
about
that,
I'm
using
my
iphone
as
my
webcam,
and
I
thought
I
had
do
not
disturb
turned
on,
but
somebody
is
trying
to
make
a
spam
call
to
my
phone.
So
if
there
was
an
interruption
there
for
a
moment,
I
apologize
anyway
talk
about
responding
to
change
and
interruptions.
C
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?
C
A
B
A
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.
We
have
a
couple
of
other
folks
on
on
the
call
jabe
is
from
the
gto
office
and
I'm
just
going
to
unmute
them.
A
Well,
if
you
give
me
a
second
and
if
folks
have
questions
jabe
and
john
questions
for
jeff,
please
go
ahead,
but
I
think
one
of
the
things
that
I
really
loved
about
this
it
was
the
r
part
of
the
chart
was
responding
to
your
surroundings,
because
a
lot
of
what
we're
doing
at
from
the
openshift
community
stuff
and
the
things
we
do
at
red
hat
is
really
about
taking
in
all
of
this
feedback.
Massive
amounts
of
it
from
you
know
thousands
of
customers
and
trying
to
distill
it
into.
A
Where
is
the
innovation
going?
And
so
I
wonder
if
you
could
talk
a
little
bit
to
when
you
have
overwhelming
amounts
of
input
from
customers
distilling
some
of
that
down
how
you
would
coach
people
for
that.
C
Well,
one
piece
of
advice:
I
don't
remember
who
said
this
and
I
it's
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.
C
So
there's
a
there's
a
certain
amount
of
just
kind
of
filtering
signal
from
noise.
But
beyond
that
the
the
other
piece
of
advice
is.
This
is
where
I
get
to
give
my
pitch
for
involving
design.
C
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.
C
A
C
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?
How
does
one
push
off
against
theo
constantly
over
simplifying
and
to
putting
too
much
in
a
sprint?
A
And
since
this
is
planning
season
at
red
hat
boy,
can
I
commiserate
with
that
story?.
C
C
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.
C
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.
C
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?
C
A
A
Bit
to
the
the
mvp
stuff,
eric
that
that's
what's
ringing
in
my
head
right
now,
when
you
say
iterative
like
get
something
out
there
and
see
it.
Is
that
what
you're,
exposing
here
or.
C
Sort
of
so
the
reason
I'm
laughing
and
I'm
guessing
that
jabe
is
probably
defying
on
mute.
In
the
background
I
like
to
refer
to
mvp
as
the
worst
named
good
idea
ever.
C
Because
if
you,
if
you
read
the
lean
startup
book,
the
purpose
of
an
mvp
is
not
to
create
a
viable
product
right,
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.
C
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.
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.
C
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.
D
But
I
think
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,
clean
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
a
different
problem
to
me.
D
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.
D
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?
That
actually
means
that
you
have
created
an
impact
at
a
particular
scale,
a
particular
size.
That's
that
whole
argument
about
viability,
sustainability,
the
longevity,
the
holding
power
of
being
able
to
reproduce
the
power
and
the
the
value
that
is
viability
to
me.
Hey.
C
E
Are
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.
E
We
do
the
pd,
the
pd
to
pdpd
and
we
don't
follow
the
scientific.
You
know
a
lot
of
stuff
you
think
about
the
word.
I
always
trust
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.
D
And
I'll
just
I'll
throw
in
one
more
thing,
just
because
I
you
know
you
and
I
like
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
did
kind
of
design
production
operation
in
a
row,
these
three
things
in
a
row
in
a
straight
line.
D
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
10
years
before
cybernetics
became
a
thing.
E
D
That
we
describe
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.
D
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.
C
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
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.
C
C
Don't
assume
that
the
thing
that's
in
the
middle
of
your
backlog
should
still
be
in
the
middle
of
your
backlog,
and
you
know
to
the
to
the
point
I
made
earlier
about.
You
know,
get
a
customer
request
and
then
forget
it.
There
are
really
interesting
organizations
that
don't
work
from
backlogs.
C
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.
C
E
It
and
that's
the
key
right
you
break
out
in
the
prescription
and
you
break
out
into
the
fear
right
like
I
think
that,
so
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.
E
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.
D
D
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
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.
D
So
I
think,
actually,
a
lot
of
product
owners
who
kind
of
overstuff
the
sprints
are
focused
on
the
outcomes,
believe
I'm
sorry
focused
on
the
outputs
and
not
understanding,
actually
what
the
output
is
the
output
by
the
way
I
I
do
agree
that
it's
important
to
learn,
but
I
I
think
the
actual
activity
is
balancing
the
production
of
value
in
the
form
of
some
some
saleable
high
value,
good
and
learning,
and
it's
the
balance
of
those
two
things
that
goes
wonky
right
to
me.
D
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.
C
So
the
the
way
that
I
resolve
that
tension-
and
I
I
think
you're
absolutely
right-
and
this
is
this-
is
where
the
designers
tend
to
get
on
my
shoulders.
A
little
bit
is
one
of
the
best
ways
to
learn
is
from
people
using
your
software.
C
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.
C
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
value
small.
You
allow
yourself
to
do
that.
Yep.
D
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
design
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.
D
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
which
is
more
time,
designing,
more
detailed
design,
blah
blah
blah
and
that
that
can
cause
really
bad
problems
right.
D
But
there
is
this
weird
way
of
like
filtering
what
goes
into
what
should
be
designed
well
or
should
be
focused
on
eliminating
the
risk
in
design,
as
opposed
to
the
risk
in
use,
and
the
risk
in
you
in
design
is
if
we
know
that
this
thing
needs
to
support
the
traffic
for,
like
I,
don't
know,
20
000
users,
there's
probably
some
design
like
math,
that
we
could
do
to
make
sure
that
whatever
we
design
can
sustain
that,
I
usually
say
it's
like
you
know
it's
like
designing
a
bridge.
D
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?
D
Will
people
like
the
bridge
will
be
pretty
all
like
all
sorts
of
in-use
questions
yeah,
but
there's
also
like
just
straight
math
of
this
is
the
minimal
structure
that
will
be
required
to
ensure
that
a
15-ton
truck
won't
cause
the
bridge
to
collapse,
and
so
like
balancing
those
two
like
the
the
quantified
and
and
foreseeable
parts
of
architectures
and
design
engineering,
and
then
there's
the
okay
there's
some
stuff.
D
D
A
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.
A
If
you
want
to
have
the
last
word
in
here
and
then
yeah.
C
I'll
just
say
thanks
everyone,
it
was.
It
was
great
to
see
you
all
again
virtually
and
thanks
for
having
me
and
if
folks
want
to
talk
to
me
more,
you
can
find
me
at
sustadashassociates.com
or
I'm
on
twitter
and
linkedin
at
jeffsusna
and
susan
is
spelled
s-u-s-s-n-a.
A
That
that
book,
that's
it
on
the
background
there
and-
and
it's
a
great
read
as
well
so
designing
for
delivery
is
awesome.
So
thanks
again
jeff.
I
think
we're
gonna
definitely
have
to
do
another
follow-up
on
this,
because
I
I
feel
a
debate
coming
on
so
well
played.
Thank
you
all
all.