►
Description
Join Deborah Chaskin, Scrum Master and Agile Consultant, as she explores how agile practices may need to adapt to embrace microservice development. Deborah covers the agile mind set and how we need to shift our thinking as we shift our development methods. Aired on January 12, 2021.
A
All
right,
I
think
it's
1201
I'll
go
ahead
and
get
started
while
people
are
signing
in.
Thank
you,
everybody.
This
is
the
january
12th
2021,
first
cdf
meetup
of
2021.
A
We
have
a
very
interesting
speaker
today,
deborah
I
met
deborah
through
a
linkedin
chat.
I
know
some
of
you.
I've
met
through
linkedin
chats
because
I'm
not
shy
about
asking
for
a
coffee
chat
and
talking
about
where
you
are
in
microservices
and
what
you're
doing
and
I'm
not
a
scrum
master,
and
I
really
I
I
understand
agile
practices,
but
I've
never
really
studied
it
and
we
started
getting
in
a
conversation
with
deborah
about
what
she
called
the
agile
mindset
and
how
that
relates
to
microservices,
and
I
had
such
a
good
time
talking
to
her.
A
We
laughed
we
had
fun.
I
thought
she'd
be
a
great
intro
for
2021
and
and
kicking
off
our
our
talks
for
this
year.
Everybody
should
know
deborah
is
doing
this
on
her
birthday,
so
happy
birthday
to
you
deborah.
A
A
So
next
month
we
are
going
to
learn
about.
Captain
kept
in,
as
everybody
may
know,
is
a
event-based
cd
cd
tool.
It
has
a
very
interesting
control
plane
and
it's
a
very
different
approach
to
the
cd
pipeline,
which
I'm
very
I'm
looking
forward
to
to
seeing
it
andreas.
I
think
his
last
name
was
grabner.
Maybe
I
should
be
looking
at
this
from
dynatrace
who
is
there?
I
would
call
him
one
of
their
evangelists
and
he
knows
kept
in
very
well
he's
been
involved
in
that
project.
A
A
So
on
that
I
want
to
let
everybody
know
if
you're
on,
I
have
allowed
you
to
talk,
so
you
can
keep
yourself
muted.
That
would
be
great,
but
if
you
have
a
question
for
deborah
along
the
way
she
has,
you
know
opened
it
up,
so
that
you
can
just
you
know
just
say:
hey
deborah,
wait!
A
second,
I'm
not
clear
on
this
and
you'll
find
that
she
will
be
very
willing
to
answer
your
questions
and
probably
dive
into
an
aspect
you
weren't
thinking
about.
A
B
B
I
just
started
a
contract
with
verizon
as
a
product
owner
and
some
project
management
pieces,
and
I
I'm
also
considering
myself
an
artist
and
there's
we're
all
multi-dimensional
and
I'm
so
happy
that
I
met
tracy
because
she's
helped
me
and
I'm
here,
giving
a
presentation
fearlessly,
giving
a
presentation
on
microservices
and
the
agile
mindset
and
as
I
was
coming
up
with
this
talk,
I
came
up
with
a
saying,
and
so
I'm
so
glad
I
wrote
this
talk
because
I
got
a
new
saying
for
myself
and
it
says
sometimes
your
willingness
to
change
your
mindset
can
be
the
source
of
your
joy
and
take
that
with
microservices
and
take
that
in
your
life.
B
So
I
I
love
looking
at
dictionaries
for
definitions
because
you
kind
of
have
to
get
at
the
root
of
something
to
understand
it.
So
what
is
the
agile
mindset?
Well,
it's
two
words:
agile
and
mindset
now
mindset.
The
second
one
is
is
an
attitude
and,
as
we
know,
the
attitude
we
bring
into
our
lives
is
the
attitude
that's
going
to
reflect
other
people's
impressions
of
us.
It's
going
to
reflect
our
output,
no
matter
what
we're
doing
agile.
Well,
it
started
out
that
agile.
B
The
original
definition
is
the
ability
to
move
quick
and
easily,
but
then
these
guys
got
together
and
they
talked
about
project
management
and
they
tried
to
moder
model
it
after
agile.
So
I,
like
images,
so
I
think
of
agile
as
certain
animals
or
agile
and
other
animals
aren't
agile,
so
for,
for
example,
a
cougar
is
very
agile
because
it
can
run
quick.
Okay,
a
beaver
is
very
agile,
because
a
beaver
doesn't
work
with
large
pieces,
a
beaver
likes
to
break
down
pieces
into
smaller
pieces
like
user
stories,
instead
of
a
large
bunch
of
requirements.
B
Bees
are
definitely
agile
because
they
swarm
together.
You've
got
a
problem.
Your
code's,
not
working.
Okay,
we're
in
this
together,
everybody
get
on
the
meeting.
I
don't
want
to
send
a
formal
invite
just
be
here
and
I'll,
give
you
a
demo
and
you
point
out,
what's
wrong,
we're
all
gonna
put
our
brains
together
and
not
judge
each
other,
we're
swarming
we're
swarming
like
bees.
Okay,
dragonflies
are
agile
because
they
can
fly
in
different
directions.
Right
left
backwards
forwards,
and
we
have
to
do
that
so
many
times
we
have
to
undo
what
we
did.
B
We
have
to
admit
that
we're
showing
a
half-fake
demo
and
it's
not
smoking
mirrors
it's
that
I'm
just
building
it
and
and
the
queries
don't
work
because
we
haven't
put
the
date
in
and
pieces
like
that.
So
you
know
always
go
back
to
the
animals
now
who
isn't
agile
in
the
animal
world-
and
I
like
this-
but
you
kind
of
kind
of
use
comedy
to
get
over
the
frustrations
that
you're
in
a
situation
that
people
are
there
that
don't
tend
to
be
agile.
B
So
that's
that's
this
view
graph.
You
guys
you're
not
interrupting
me.
If
you
want
to
say
something,
but
I
will
have
an
exercise
for
you.
So
the
agile
mindset,
okay,
the
agile
mind,
there's
this
guy
named
tik,
nahan
he's
a
buddhist
monk,
but
I
I
learned
a
lot
from
him.
I
did
a
silent
meditation
retreat
with
him
and
the
whole
idea
is
the
ceremonies
when
you
go
to
the
agile
ceremonies.
B
B
So
here
we
are,
and
we
realize
we
have
such
something
so
powerful
with
all
these.
Like
super
intelligent
people
who
can
code
and
create
these
microservice
stand-alone
services
that
can
be
used
across
multiple
organizations
and
can
automate
so
much
that
now,
how
do
we
integrate
it
into
something
that
not
even
the
ceremonies
totally
tell
you
what
your
role
is,
because
you
might
not
even
have
a
role
on
the
scrum
team?
B
B
So
an
agile
mindset
is
more
a
state
of
being
than
a
state
of
doing,
and
it's
going
to
work
best
if
everybody
buys
into
the
mindset
so
like
tiknahan
says
just
smile
and
you'll
be
happy
just
try
it
just
try
it
like,
like
your
green
eggs
and
ham
or
whatever.
So
so.
The
whole
idea
is
that
I'm
not
going
to
go
on
this
slides
too
quickly,
but
the
agile
manifesto.
B
It's
actually
coming
up
on
its
20th
anniversary
february,
11th,
to
13th,
where
17
software
developers
met
at
a
re
resort
and
they
went
skiing
in
colorado
and
they
tried
to
come
up
with
some
lightweight
development
practices,
and
that
was
good
and
they
came
up
with
some
very
good
ideas,
but
no
operations
were
present
there
and
in
fact
there
were
no
women
there.
So
I
think
that
us
women
should
go
and
help
them
edit.
The
manifesto
now,
but
that's
just
my
opinion,
so
so
you
could
read
about
this.
B
I
can
you
you're
welcome
to
share
these
slides
with
them.
If
they'd,
like
anybody,
have
anything
to
say
yet.
C
This
is,
this
is
steve.
Do
you
think
the
manifesto
still
holds
true
from
when
it
was
written
20
years
ago.
B
B
So
I
would
say
that
some
of
it,
you
take
everything
with
a
grain
of
salt,
but
if
somebody
is
writing
that
and
there's
been
trying
it
over
the
past
20
years,
some
of
it's
working,
some
of
it's
not
and
it's
up
to
us
not
to
be
rigid,
but
to
take
the
good
parts
and
not
like
throw
the
baby
out
with
the
bathwater.
That's
how
I
see
it
does
that
make
sense.
B
My
pleasure
now
agile
values,
they
have
a
list
of
the
agile
values
and
the
whole
idea
is
that
if
the
team
can
kind
of
arrive
at
the
same
values,
they
can
have
a
shared
mindset
and
teams
are
much
more
powerful
when
they
have
shared
mindsets.
B
So
before
basic
characteristics
to
the
shared
mindset
are
individuals
and
interactions
are
more
important
than
processes
and
tools.
Now
that
doesn't
mean
we
throw
up
processes
and
tools
in
the
diagram.
In
the
garbage
I
mean
I
need
uml
diagrams
when
I'm
seeing
what
somebody
wants
to
build,
or
I
won't
understand
the
big
picture,
but
the
individuals
and
the
interactions
are
what
really
help
like.
For
example,
I
started
a
new
job
and
I
am
not
learning
the
system
as
quick
as
I
would
like
to,
and
I
could
look
at
the
processes
and
the
tools.
B
Second
value
is
that
working
software
over
comprehensive
documentation
and
I
believe,
that's
true.
I
believe
that
you
need
some
documentation,
but
you
can
use
visuals
or
if
you
feel
that
you
needed
more
documentation,
you
could.
You
could
create
like
test
scenarios
and
show
that
they
work
in
a
demo.
But
working
software
is
the
ultimate
goal,
so
that
doesn't
mean
have
no
documentation.
It
just
means
don't
be
anal
about
it.
Customer
collaboration
over
contract
negotiation
now,
I
think,
that's
very,
very
valuable.
In
fact,
I
apply
those
values
to
my
waterfall
projects.
B
I
was
working
with
the
department
of
transportation
to
move
their
traffic
lights
over
to
a
t's
network,
and
it
was
so
important
that
I
got
along
well
with
the
department
of
transportation
and
everybody
else
in
queens
in
new
york
city,
because
I
had
to
collaborate
and
things
would
change.
So
nobody
would
pick
at
the
contract.
B
But
you
know
they're
struggling
too
on
their
side
of
the
end
so
that
that's
part
of
it
and
then
the
next
one
is
responding
to
change
over
following
a
plan
and-
and
that's
so
true
when
it
comes
to
microservices,
because
you
have
so
many
items
changing
and
you're
you,
you
change
your
microservice
you're,
changing
multiple
customers,
not
just
one,
so
any
questions
on
the
values
here:
okay,
I'm
not
going
to
go
through
all
the
principles,
but
these
are
the
principles.
Okay,
in
the
interested
time,
I'm
going
to
skip
it.
B
But
if
somebody
wants
to
ask
me
a
question
they're
more
than
welcome
to
email
me.
A
Debra
this
is
tracy.
I
would
the
question
I
would
ask
is
in
those
12
principles:
are
there
any
that
you
think
are
less
important
now
with
microservices
or
are
there
some
that
are
more
important?
Now.
B
That's
a
very
good
point.
I
think
the
first
one
is
very
important
customer
satisfaction
by
early
and
continuous
deliverable
of
valuable
software,
because
that's
basically
telling
you
that
you've
got
to
make
sure
that
the
majority
of
your
customers
are
going
to
be
positively
impacted
by
your
changes.
B
So
that's
why
it's
important
to
have
the
relationships
with
them.
Also
because
if
you
make
one
change
and
you
take
a
major
client
and
tick
them
off,
you're
not
going
to
be
happy,
so
I
think
that's
a
big
one.
Let
me
go
through
each
one
of
them.
The
next
one's
welcome
changing
requirements
even
late
in
development.
That
is,
that
is
something
that
is
really
important
to
have
to
do
before
you
roll
something
out
to
deployment,
but
sometimes
you
need
to
kind
of
in
my
opinion.
B
Sometimes
you
have
to
delay
it
because
it
could
have
negative
impacts
on
other
clients.
So
this
is
like
something:
that's
you
got
to
negotiate
and
you
still,
in
my
opinion,
you
try
to
minimize
this
scenario
by
doing
something
upfront
just
because
of
all
your
dependencies,
so
you
want
to
keep
a
track
and
documentation
of
who,
what
all
your
micro
services
have
in
terms
of
their
dependencies.
B
B
We
can
motivate
people
with
our
attitudes,
but
we
like,
if
somebody's
like,
just
like
a
worker
bee
like
I
am.
I
can
motivate
people
because
I'm
fun
to
be
with
and
this
and
that,
but
I
really
don't.
I
can't
change
them,
but
senior
management
should
focus
on
this.
No
matter
what
project
they're
working
on
face-to-face
conversation,
we
all
know
we
can't
do
that
with
covid.
Unfortunately,
so
zoom
is
here,
so
we
we
do.
The
best
we
can
working
software
is
the
primary
measure
of
progress.
I
don't
know.
A
B
Okay,
that's
good!
She
knows
this
stuff,
I'm
not
an
expert
in
microservices
in
any
way
sustainable
development
able
to
maintain
a
constant
pace
that
that's
basically
the
idea
that
you
don't
want
to
burn
out.
B
B
B
I
want
to
solve
world
hunger,
blah
blah
blah,
so
I
think
it's
always
important
to
know
your
minimum
viable
product
and
when
you
deal
with
micro
service
uses,
you
need
to
know
your
minimal
viable
product,
and
that
is
what
the
bare
minimum
is
that
you
have
to
deliver
before
you
start
putting
cherries
on
the
pie,
best
architectures
requirements
and
designs
emerge
from
self-organizing
teams.
B
I
think
that
that
is
important.
I
don't
know
how
important
it
is
in
microservices,
because
the
teams
might
not
always
know
what
the
management
is
committing
to
for
other
microservices.
So
you
might
need
to
depend
on
management
to
some
extent
and
depend
on
whatever
dependencies
you
already
have
documented
regularly.
The
team
reflects
on
how
to
be
more
effective
and
adjusts
accordingly,
that's
true
for
whatever
you
do
in
life
all
right.
This
is
the
exercise.
We
can
do
it.
If
you
want.
You
can
get
out
a
piece
of
paper.
B
You
could
just
tell
me
what's
coming
in
your
mind,
and
I
want
you
to
describe
the
thoughts
you
have
that
enable
you
to
maintain
an
agile
mindset
and
then
the
thoughts
that
might
discourage
you.
B
B
I
know
that
because
I
have
an
app
that
I
paid
for,
but
now
they
took
it
off
of
the
database
and
my
phone,
and
it
helps
me
change
my
thoughts
when
I
have
the
thoughts
that
don't
serve
me
and
it's
not
going
to
serve
the
team.
If
there's
some,
if
anybody's
discouraged-
and
it
doesn't
disturb
yourself-
it
doesn't
serve
you
either.
So
here
are
examples
I'll
show
you
what
other
people
had,
and
you
could
do
this
on
your
own
time,
a
discouraging
thought
might
be.
B
B
So
then
it's
a
matter
of
reminding
yourself
that
agile
also
involves
planning,
because
you
know
like
we're
literal
people
I
mean
none
of
us
would
be
in
this
industry.
If
we're
not
literal,
I
mean
I'm
more
in
a
big
picture
level,
but
I'm
literal
too
just
trust
me.
So
I
you
know
like
it.
When
we
looked
at
the
analogies
and
we
they're
not
all
or
nothing
thinking
so
agile
involves
planning
too
for
repetitive
work.
We
can
use
more
of
a
waterfall
approach,
all
right
I'll.
B
Just
do
the
last
two
people
deliberately
inflate
their
team's
velocity
to
look
good
and
that's
true.
A
lot
of
managers
do
that
they
want
to
they
want
to
like
take
agile
and
they
want
to
take
the
practices
and
try
to
use
it
to
get
more
out
of
somebody
where
they're
burning
them
out
and
the
supporting
thought
is
not
everyone
inflates,
their
team
velocity
protect.
Perhaps
others
may
not
understand
the
quickest
way
to
deliver.
We
cannot
change
other
people
except
by
changing
our
own
mindset.
Actually,
I
should
put
this
in
my
refrigerator
next
discouraging
thought.
B
We
can
never
trust
code
that
comes
out
of
operations,
supporting
thought
because
that's
all
or
nothing
thinking
also
a
supporting
thought
is:
how
can
we
build
our
trust
of
code
for
integration,
and
this
might
be
a
good
topic
to
discuss
at
the
next
retrospective,
because
people
have
retrospectives
it's
part
of
the
agile
practices
and
they
examine
what
they
do
and
what
they
might
change
and
what
they
might
want
to
do
better.
C
B
Yeah,
actually,
when
I
ran
that
app,
which
I
missed
brightly,
I
wish
someone
would
write
another
one
for
me,
but
what
it,
what
that's
one
of
it?
It's
all
or
nothing
thinking.
But
if
you
read
about
cognitive
therapy,
there's
a
lot
of
dysfunctional
thinking.
There's
like,
like
my
son,
told
me
yesterday
that
I
I
don't
know
he
was
in
taiwan
and
a
bus
ran
over
his
phone.
His
smartphone
that
I
bought
for
him.
B
B
B
Why
agile
for
microservices?
And
what
I
have
here
is
microservices
requires
production
of
small
modules
that
provide
valuable
services.
So
remember
we
said
it
was
small.
Well,
that's
good,
because
agile
is
like
small
modules.
B
Microservices
are
highly
innovative.
Agile
practices
encourage
innovation,
so
you
guys
have
a
lot
of
talent.
You
can
be
at
the
cutting
edge
of
technology
and
agile
practices
are
much
better
for
people
in
the
cutting
edge
of
technology,
because
you
don't
want
to
be
on
something
where
you
have
an
idea
and
you
can't
code
it
for
another
six
seven
months,
microservices
are
good
at
adapting
quickly
to
ever.
Changing
needs
and
they're
reusable
legacy
systems
need
to
be
quickly
automated
with
microservices.
B
So
I
and
I've
seen
that
that
you
could.
You
could
take
something
like
a
dead
system
and
you
can
use
some
of
the
micro
services
that
you
wrote
and
have
it
do
ordering
or
ticketing
or
incident.
You
know
incident
management
or
it
could
do
whatever.
I
wish.
I
could
do
my
dishes,
even
though
I'm
supposed
to
do
them
mindfully,
but
you
you
could
do
that
agile
works
well
with
quick
deliveries,
and
you
know
the
way
in
this
world.
B
Everybody
wants
something
tomorrow:
agile
supports
collaboration
and
cross-functional
teams
and
in
microservices,
since
what
you
use
do
is
used
by
so
many
people.
You
need
something
where
you're
not
just
collaborating
with
one
customer
you're
collaborating
with
tons
and
tons
of
customers.
So
so
you
need
these
techniques
so
that
you
can
like
win
in
the
game
of
microservices.
B
B
C
On
the
collaboration,
what
what
have
you
seen
that's
been
coming
out
that
makes
it
the
the
easiest
way
to
collaborate.
You
know,
because.
C
B
It
depends
on
what
you
could
now
you
want
to
address.
The
second
part
of
the
first
part,
the
the
first
part
that
what
makes
it
easy
to
collaborate
for
like
the
development
team
would
be
like
the
daily
calls,
because
you
want
to
find
out
what
your
obstacles
are
and
what
obstacles
you
might
want
to
remove.
Now
you
said
that,
how
do
you
communicate
on
a
larger
basis?
There's
a
tech
there's
a
technique
called
scaled
agile
framework.
B
The
acronym
is
safe
and
it
actually
is
used
to
communicate
when
your
project
has
impacts
on
other
projects
in
the
same
release,
and
they
have
this
whole
idea
of
the
release.
Train
engineer,
which
is
like
this:
it's
like
a
level
above
a
scrum
master
like
release,
train
engineers
to
a
scrum
master.
What
a
program
manager
might
be
to
a
project
manager
and
what
what
you
need
to
do
is
the
developers
might
not
have
to
worry
about
all
the
main
details.
Let
the
release
train
engineer
worry
about
it.
B
That
shows
what
is
impacting
you,
but
that's
how
you
and
then
the
scaled
agile
framework
is
how
I
think
might
help
micro
services,
but
microservices
would
have
to
engage
operations
in
that
and
they
would
have
to
possibly
be
involved
with
an
agile
project
management
office
because
they
do
have
project
management
offices
for
agile,
where
you
would
communicate
that
you've
got
this
microservice
and
that's
a
good
way
for
you
to
market
what
your
deliverables
are.
Also
because,
if
you
have
a
microservice
that
you
developed,
you
don't
have
to
spend
all
your
time.
B
If
you
know
like,
I
can't
write
a
lot
of
code,
so
you
can't
you,
don't
have
to
spend
all
your
time
having
to
be
the
person
who
does
it,
but
you
need
to
have
a
contact
that
you
can
go
to
in
the
organization
and
make
them
aware
of
what
you
created
and
then
you
have
a
better
chance
of.
If
you
have
a
performance
review.
Writing
that
you
were
you
delivered
something
that
helped
many
organizations.
B
C
B
Oh
okay,
I
made
this
thing
up
so
hopefully
it'll
work.
This
is
this
is
an
example
of
it
in
the
business,
creating
a
platform
using
microservices
to
support
all
key
processes
across
of
a
company
okay,
so
this
platform
will
enable
reuse,
collaboration
and
a
sense
of
trust
for
the
code
created.
So
this
might
be
like
almost
like
an
architecture
drawing
for
scaled
agile
framework.
B
I
I
just
grabbed
what
I
call
itel
functions,
which
are
like
in
a
system
from
a
business
perspective.
You've
got
billing.
You've
got
ordering.
You
got
ticketing,
you
could
have
a
common
database.
You
have
reporting
over
here,
and
this
organization
might
be
feeding
these
little
critters
each
one
of
these
little
critters
might
be
drilled
down
into
smaller
microservices,
and
this
guy
might
have
a
need
for
the
micro
services
that
he's
using
to
make
some
changes
to
their
billing.
B
B
Keeping
everything
just
for
me
myself
and
I,
but
microservices
and
agile,
are
all
about
sharing.
Agile,
really
is
all
about
sharing
when
it's
done
right,
it
really
is,
and
I'm
sure
microservices
is
also
so
that's
the
beauty
of
it.
So
remember
that
thought
when
you
get
driven
crazy
by
agile
and
microservices,
when
there
was
an
endless
supply,
the
need
for
silos
goes
away,
and
this
is
something
that
tracy
taught
me
because
I
don't
know
much
about
microservices,
but
we're
going
to
stay
tuned
to
learn
how
microservices
produce
an
infinite
supply.
B
The
challenges
are
in
the
integration
and
breaking
down
the
silos.
Oh
the
toy
analogy.
We
came
up
with
this.
If
you
got
more
questions,
she
could
elaborate
it
more
for
micro
services,
but
I
was
telling
her
when
I
f
when
I
first
met
tracy
that
you
know
like.
In
the
old
days
children
fought
over
playing
with
particular
toys
and
colors.
Like
I
want
the
red
block,
I
want
the
blue
block.
I
my
brother,
wouldn't
let
me
touch
his
gio
joe
doll.
I
I
didn't
like
the
barbie
doll,
but
he
wouldn't.
B
Let
me
touch
his
gi,
joe
though,
and
in
the
old
days
organizations
fought
over
stuff
like
oh,
I
want
that
funding.
No,
I
want
that
computer.
I
want
that
docking
station
microservices
makes
it
possible
to
reuse
code
across
many
systems
and
services.
B
B
When
we
learn
to
embrace
an
agile
mindset,
we
all
become
richer,
and
if
it
I
mean,
if
our
country
could
think
like
this
imagine
what
a
world
this
would
be
see
this.
This
beautiful
little
girl
there-
and
this
is
the
fisher
price
kitchen
set.
I
love
the
fish
surprise
kitchen
set
because
my
first
son,
it
was
his
favorite
toy
and
he
would
let
me
play
with
everything
and,
except
for
the
strawberry,
pink
one
topping
of
the
cupcake,
but
with
microservices.
B
A
Well,
deborah,
thank
you
that
was
quite
entertaining.
It
makes
me
think
about
a
lot
of
things.
Thank
you
and
it's
pretty
cool
that
you
got
to
go.
Do
a
meditation
with
teach,
not
han
that's
pretty
cool.
B
He
was
amazing,
he
was
sitting
at
yeah
yeah.
He,
the
kids,
were
up
on
the
podium
with
him
and
all
of
a
sudden
my
son
was
confused.
He
was
young
at
the
time
like
he
was
like
preschool.
He
didn't
know
how
to
act,
so
he
he
wound
up,
because
the
monks
were
singing,
so
he
stood
up
and
he
started
imitating
the
monks
singing,
but
it
looked
like
he
was
mocking
them.
B
So
chick
nahan
sat
next
to
him
and
he
put
his
hands
between
the
held
his
hands
like
this,
and
after
that
everybody
broke
their
silence
and
started
laughing.
A
Well,
I
I've
never
thought
about.
You
know
putting
you
know
kind
of
buddhist
concepts
into
a
discussion
around
agile.
So
thank
you
for
making
those
that
connection.
For
me.
Oh
thank
thank
you.
I
I
don't
know
it
helps
me
so
there
there
it
there's
some
who
would
like
to
get
your
book
list
for
your
cognitive,
cognitive,
behavior.
A
Sorry,
if
anybody
wants
that,
just
give
me
your
email,
send
me
your
push
your
email
through
the
chat.
You
don't
want
to
share
email
to
everybody.
I
understand
so
just
send
it
directly
to
me
and
I
will
send
the
list
to
debra
and
then
she
can
forward
that
book
list
to
the
folks
that
would
like
it.
B
A
Everybody
who's
on
the
call
is
able
to
talk.
So
if
you
want
to
ask
her
a
question
or
chat
at
all,
just
just
unmute
yourself
and
ask
away.
C
This
is
steve
again,
do
you
think
organizations
are
starting
to
break
down
the
silos?
Are
they
still
pretty
stuck
in
that
that
mindset
of
this
is
mine?
You
can't
have
it.
B
C
Yeah,
because
I
know
I
remember
we
used,
we
used
to
go
through,
centralized
decentralized
forever,
it
would
become
cyclical
and
then
I've
seen
where
he
has
products
were
siloed
and
then
they
get
unsiloed
into
business
units
and
then
they
get
siloed
back.
So
I
was
curious
where,
where
we
were
in
this
time
of
in
the
process.
B
It
depends
on
the
company,
a
company,
because
I've
consulted
to
a
bunch
of
companies
like
zebra,
which
was
part
of
motorola.
They
spun
off,
and
they
would
not
be
like
that
they
would
share
with
each
other.
Honeywell
has
a
lot
of
good
values
and
they
can
do
agile,
even
though
they
did
waterfall
in
my
project,
they
brought
the
agile
values
to
waterfall.
A
A
Most
people
have
implemented
agile.
So
as
we
move
away
from
monolithic
and
into
microservices,
I
think
we're
going
to
have
some
basic
challenges
just
even
well.
I
think
it's
going
to
force
people
to
take
that
my
that
my
that
agile
mindset,
for
example,
even
architecting,
a
microservice
solution,
it's
going
to
require
you
get
people
in
the
room
to
talk
to
each
other,
to
collaborate
and
to
not
hold
their
toys
so
close
to
their
chest.
So
to
speak.
That's
nice.
B
C
So
you'll
get
you'll
get
evaluated
on
how
well
you
share
with
others.
Yep.
A
B
A
Like
microservices
is
a
good
way
to
do
that,
as
well
kind
of
like
you
know,
github
yeah,
well,
okay,
deborah!
Thank
you
so
very
much.
If
there's
this,
if
anybody
has
any
other
questions
for
deborah,
please
ask
them
now.
Otherwise
we
will
sign
up
and
we
will
see
everybody
in
february
and
learn
about
kept
in
and
control
planes
and
event-driven.
Continuous
delivery.
Captain
is
part
of
the
cloud
native
computing
foundation.
The
cncf,
which
is
a
sister
organization
to
the
cd
foundation,
we're
both
under
the
linux
foundation,
so
they're
family
awesome.