►
From YouTube: Retrospective (Public Stream)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hey
welcome
to
the
get
loud
development
teams,
13
8
retrospective,
where
we're
going
to
be
talking
about
some
of
the
lessons
and
learnings
and
highs
and
lows
from
this
last
milestone
that
we
just
completed
in
terms
of
the
format
today
we're
going
to
spend
about
five
minutes
talking
about
previous
retrospective
improvement
tasks,
so
things
that
we
raised
last
time
want
to
check
back
in
in
then
we've
got
two
discussion.
A
Topics
picked
out
that
folks
voted
on
we're
going
to
spend
about
seven
minutes
on
each
of
those
and
then
talk
about
improvements
that
we
want
to
track
for
the
next
release,
so
diving
into
that.
Let's
get
into
the
previous
retrospective
improvement
pass.
I
think
craig
you
have
the
first
one.
A
I
think
maybe
craig
is
not
on
the
call,
so
maybe
we'll
jump
on
to
darva
if
she's
present.
B
John
john
hope,
I'm
here,
yeah
okay.
Well,
this
is
actually
from
a
couple
of
retrospectives
ago.
We
were
going
to
like
investigate
ways
to
get
engineers
involved
in
the
process
of
planning
new
features
earlier
in
the
product,
workflow
I.e
before
the
planning
breakdown
stage.
So
we've
taken
a
couple
actions
on
this.
The
first
one
is
the
you
might
have
heard
us
talk
about
this
in
retros
a
few
times.
B
We've
merged
this
up
to
the
overall
product
manager,
role
page,
which
is
we
call
it
like
product
shadowing,
which
is
48
hours
spent
between
an
engineer,
shadowing
a
product
manager,
and
we
try
to
split
that
up
so
that
they
get
a
chance
to
experience
everything
product
manager.
Does
you
know
customer
calls
as
well
as
planning,
and
things
like
that,
so
we've
merged
that
up.
So
it's
available
to
other
teams
and
then
also
like
this
milestone,
we're
trying
out
actually
not
building
a
feature,
but
instead
doing
a
spike.
B
The
outcome
of
the
spike
would
be
an
effective
plan
to
deliver
the
feature.
So
that's
like
one
broad
thing,
we're
doing
on
one
specific
thing:
we're
trying
out
this
milestone.
A
That's
really
neat
yeah
is
that
has
anybody
like
written
up
their
experiences
from
that
I'm
curious,
maybe
in
those
links.
If
people
wanted
to
learn
more
about
what
that's
like
to
be
in
that
shadow
program.
B
Yeah
so
part
of
the
process
of
being
on
the
program.
Is
that
your
retrospect
on
it
afterwards,
so
that
we
can
improve
it?
So
I
think
it's
in
the
issues
that
are
in
the
issues
list
that
I've
linked
there.
You
should
be
able
to
go
in
and
see
previous
experiences
like
charlie
did
the
first
one.
It
was
her
idea
to
actually
to
instigate
this
program
in
the
first
place
and
then
yeah
and
did
one
and
then
the
most
recent
one
I
think
is
alex
and
it
might
even
be
in
process
at
the
minute.
C
I
was
just
going
to
say
the
pm
shadow
program's
really
cool.
I
think
I'll
have
some
team
members
that
are
interested
in
this.
So
thank
you
for
putting
this
together.
D
Yeah
so
january
retrospective
was
a
little
light
in
feedback
in
various
areas,
so
we
did
a
little
bit
of
an
advertisement
where
we
asked
every
manager
to
pull
from
their
retrospectives.
At
least
I
said
one
comment
in
two
different
areas,
I
think,
is
how
I
said
there
are
two
of
the
four
areas
from
that
perspective
and
I'm
happy
to
report
that
it
looks
like
participation
is
definitely
upward.
D
Like
upwards
of
six
pages
of
content,
we
didn't
do
a
formal
like
make
sure
everybody's
doing
it,
but
this
looks
great
mike
here's
a
comment.
E
D
Cool
and
you
can
add
me
as
a
reviewer
and
then
we
can
make
sure
we
get
the
right
locations
in
place
and
move
forward
cool
cool
love,
the
collaboration
thanks
and
then
sam.
I
switched
up
the
orders,
and
so
we
had
a
couple
of
late
ads
or
not
late
ads,
but
participants
show
up
late,
so
craig
you're
up
next.
F
Yeah
thanks
for
pointing
out,
I
was
late.
It
was
in
the
wrong
meeting
yep
so
busy
calendar.
Last
month,
I
put
together
a
retro
issue
for
to
get
feedback
from
back
end
maintainers
on
what's
working
well,
where
some
areas
of
improvement
and
got
a
lot
of
really
good
conversation
going
and
using
my
favorite
new
tool,
the
discussion,
automation
tool,
which
is
linked
there.
So
anybody
can
add
to
their
issues
that
may
have
lots
of
threads
and
need
to
be
automatically
organized.
It's
great.
It
adds
a
summary.
F
F
The
deadline
for
feedback
was
just
a
few
days
ago,
so
I
I
have
a
follow
up
there
to
identify.
What's
next,
it
may
be
working
group
worthy
to
figure
out
how
if
we
should
push
towards
domain
maintainers
and
how
we
would
do
that,
we
do
have
documentation
to
encourage
it,
but
I
don't
think
we
have
like
a
uniform
step
forward
on
that
one
and
then
the
other
talked
about
topic
with
lots
of
different
small
themes
is
what
automation
we
can
add,
specifically
to
danger
and
roulette
so
great
conversations
going
on
there.
F
F
H
Great
craig,
since
we're
on
the
topic,
then
something
that
we
discussed
on
the
working
on
the
code
review
group
call
where
we're
looking
to
talk
food
approval
rules
with
code
owners
and
we
just
shipped
optional
code
owner
sections.
So
they
might
make
sense
to
consider
code
owners
as
well
to
apply
the
domain
expertise
to
certain
files
automatically.
So
look
into
that.
F
Yeah,
maybe
it
was
you,
someone
did
recommend
that
in
the
discussion
for
domain
maintainership
and
we
have
the
roulette
and
we
have
the
dashboard
to
show
you
know
who's
doing
what
and
incorporating
either
the
domain
expertise.
That's
part
of
team
yaml
or
the
code
owner's
file,
as
you
suggested,
as
part
of
that
to
direct
folks
to
domain
experts.
So,
okay,
absolutely
thank
you.
Thank
you.
It's
probably.
F
G
Right
I'll
take
the
next
one,
so
I
conducted
a
really
short
survey
for
the
team
to
see
what
the
engagement
was
like
in
these
retrospectives.
I
think
christopher's
idea
is
great
to
ask
the
managers
to
make
two
to
four
comments.
However,
the
ics
are
also
not
really
engaged.
So
if
you
can
click
on
this
issue
right
here
and
we
can
share
ideas
about
how
to
get
ics
more
engaged.
A
G
A
All
right
so
now
that
was
the
follow-up
items.
Now
we're
going
to
jump
into
some
discussion
topics.
There
were
three
topics
proposed
and
we
had
people
vote
in
a
common
thread
on
which
ones
they
want
to
discuss.
The
winners
were
number
two
and
three.
So
there
are
some
questions
there
about
focus
and
praise
before
we
dive
into
that,
though,
I
know,
mech
had
a
comment
on
the
first
topic,
which
wasn't
the
the
most
popular
one:
production,
reliability
and
incidents
mike.
E
Sure
I
know
this
wasn't
voted,
but
I
didn't
want
to
wait
for
the
next
retrospective
to
to
use
the
airtime,
but
I
I
think
we
need
to
keep
both
thoughts
on
improving
reliability
and
the
co-dependency
across
teams
and
even
across
stages
with
the
recent
incident,
and
we
do
have
a
corrective
action
to
direct
to
track
this.
We
don't
have
to
track
it
as
part
of
this.
This
retrospective,
the
code
change,
involves
a
security
release
and
teams
into
product
sections.
E
So
I
think
we're
we're
skiing
at
the
point
where
the
problem
starts,
to
involve
multiple
parties
and
starts
to
become
more
complex.
So
I
really
urge
folks
to
to
think
about
how
we
can
be
more
productive
with
cold
visibility
and
testing
in
this
area
and
collaborate
with
us
and
I'm
using
the
air
time
here
to
to
socialize
the
findings
here
and
the
the
corrective
actions.
D
Yes,
stan-
and
I
talked
about
this
particular
incident
yesterday
and
basically
to
describe
to
people
like
basically
we
have
token
rotations
that
go
on
and
because
we
have
a
source
like
canary
that's
running
and
a
production
that
we
effectively
don't
have
a
good
solution
right
now
to
rotate
the
tokens
which
feels
like
just
like
a
general
software
problem
now
stan,
and
I
talked
about
a
possible
solution
to
that.
I
would
encourage
everybody
to
kind
of
think
about.
I
wonder
if
we
should
just
have
every
team
kind
of
think
about.
D
Okay,
like
if
you
have
canary
running
and
production
running.
Are
we
confident
that
you
know
we
have
an
architecture
and
software
solutions
basically
effectively
solve
for
this
problem?
So
we
might
want
to
take
an
after
action
around
this
because
it
feels
like
we
want
to
touch
base
with
all
teams
on
this
particular
front.
So
it's
less
about
the
specific
incident
and
more
about
how
we're
developing
the
software
to
support
this
environment
would
be
my
take,
and
I
don't
know
that's.
E
Yes,
that
that's
to
the
the
momentum
of
that
thank
you
for
for
solidifying.
That.
A
I
try
to
capture
that
in
the
notes,
but
yeah
we
can
follow
up
on
that
all
right,
so
diving
into
the
next
topic
now
about
focus.
A
So
several
teams,
as
I
was
reading
through
all
the
notes
and
preparing
the
summary
video
brought
up
topics
around
the
idea
of
focus,
so
you
know
ways
to
create
more
focus
in
their
teams,
ways
to
maybe
facilitate
you
know
kind
of
knowing
what
to
focus
on,
and
so
you
know
I
thought
it
was
a
good
topic
to
open
up
to
everybody
if
there's
practices
or
things
that
you're
trying
that
are
working
or
not
working,
you
know
anybody
jump
right
in.
D
Yeah
just
noted
down
below
in
the
retro-
I
forget,
who
put
it
in
there,
but
somebody
put
in
the
friends
of
family
day
was
on
the
15th
of
this
month
and
because
of
that,
you
know,
costs
actually
folks
more
stress
because
they
were
trying
to
get
everything
done
by
the
14th.
One
of
the
things
that
we
had
to
do
for
the
fulfillment
team
on
eoa
is
effectively
move
friends
and
family
day,
because
it
was
during
a
critical
time
when
they
were
trying
to
meet
a
deadline.
D
What
I'll
do
is
take
also
an
action
on
this
to
basically
kind
of
review
that
or
any
other
feedback
people
want
to
provide
me
to
see
if
I
can
basically
get
policy
adjusted
to
make
sure
that
it's
maybe
not
between
the
15th
and
the
18th.
Just
from
that
perspective
as
a
consideration
so
minimally
I'll
do
that
for
friends
and
family
day.
But
if
other
folks
have
recommendations,
I'm
definitely
all
layers.
F
Come
up
next,
so
the
the
topic
of
focus
came
up
on
the
database
team
and
we
are
actually
experimenting
with
setting
aside
either
a
day
or
days
during
the
week
as
focused
topics.
So
we
call
them
out
during
our
team
weekly
meeting,
which
is
tuesday
and
call
out
who's
participating
and
how
they
can
participate
in
that,
so
that
we
have
a
theme
typically
on
wednesdays,
for
those
focused
topics
and
make
sure
that
there's
no
fires
we're
ignoring
while
doing
it.
F
F
C
I
think
I've
got
the
next
one.
My
comment
here
is
aside
from
trying
to
work
more
async
and
with
viewer
meetings,
which
I
think
we're
already
trying
to
do
across
all
of
our
teams.
What
I
found
really
helpful
is
really
emphasizing
the
priority
of
different
issues
and
the
roadmap
which
our
team's
working
on.
C
G
And
I've
seen
that
some
teams
that
have
individual
okrs
helps
those
team
members
focus
as.
G
I
Yeah
thanks
sorry,
I
was
typing
and
looking
for
a
link.
Maybe
some
of
the
teams
are
using
that
approach,
but
in
the
composition
analysis
we
have
a
dedicated
engineer
each
milestone
that
handles
every
external
request.
So
this
makes
sure
that
all
the
engineers
that
are
working
on
direction
items
get
stay
focused
on
their
priorities
and
any
customer
requests
incoming
bugs
to
triage,
etc,
are
handled
by
a
unique
person
that
only
has
side
tasks
or
stretch
items
assigned
to
them.
During
that
milestones,
this
also
helped
us
having
a
bit
more
predictability
in
our
commitments.
A
A
Next
topic
that
was
voted
on
is
about
praise,
and
I
just
noticed
that
you
know
maybe
compared
to
former
months-
and
this
is
great
there's
a
lot
of
praise
that
people
added
to
the
document
and
we've
also
just
done
the
employee
engagement
survey,
praise
and
recognitions.
Clearly
a
you
know,
topic
that
comes
up
in
that
context.
So
there's
some
questions
in
here.
People
have
thoughts
on
you
know
what
what's
the
most
effective
form
of
praise.
A
If
there's
things
you
know
in
the
past
have
been
meaningful,
particularly
meaningful
to
you
be
great,
to
share
those
and
help
us
understand
how
to
praise
even
more
andre.
You
want
to
kick
us
off.
H
Yes,
sam
thanks,
so
this
this
might
be
a
minor
detail,
but
it's
something
I've
I've
done
as
out
of
a
habit.
H
As
you
know,
karma
is
everything
on
the
internet
and
when
we
engage
with
customers
online,
whether
they're
making
a
complaint
or
a
suggestion.
I
always
find
it
particularly
on
twitter
to
when
somebody's
praising
a
feature
to
recognize
the
engineers
and
designers
who
worked
on
it
and
I've
seen
sometimes
conversations
evolving
through
that
through
requests
through
some
hey.
Did
you
think
about
this?
So
I
feel
like
it's
a
great
way
to
recognize
publicly
our
team
members
who
worked
on
on
the
features
that
have
high
visibility,
so
just
something
one
that
I.
A
Do
excellent
any
other
anyone
else
have
thoughts
on
praise
or
things
that
work
well,
don't
work
well,.
G
I
I
had
well
the
thanks
channel:
that's,
I
think
it
could
be
used
a
little
bit
more.
It's
there.
It's
not
used
often
so
when,
for
the
engineering
managers
out
there,
when
you're
having
discussions
in
your
one-on-ones,
maybe
reach
out
and
ask
the
team
members,
has
anyone
done
anything
great,
exhibit
a
value
and
if
they
have,
maybe
you
should.
You
know,
recognize
some
of
the
things
channel
things
like
that,
but
just
encouraging
people
to
use
a
little
bit.
A
A
I
guess
I
I
can
add
when
I
was
having
a
conversation
the
other
day
with
someone
who
was
telling
me
about
the
program,
a
program
at
another
company,
that's
similar
to
the
discretionary
bonus,
but
a
little
different
in
that.
A
The
way
it
was
set
up
was
that
everybody
kind
of
had
their
own
like
had
25
a
month
that
then
they
could
give
to
everybody
else
and
that
at
least
at
this
company
that
was
seen
as
something
that
had
a
big
impact
on
kind
of
team
cohesion,
even
at
points
where
maybe
there
were
other
challenges
in
the
company.
So
I
thought
that
was
interesting,
that
it
was
very
similar,
but
you
know
smaller
amounts,
maybe
more
frequent
bonuses
and
and
kind
of
a
different
take
on
that.
C
C
Oh
sorry,
I
was,
I
was
going
to
say
I
found
just
just
having
a
little
bit
of
like
an
attribution
type
of
mindset
when
talking
about
things.
So
whenever
you're
talking
about
hey,
we
built
out
this
feature
and
then
inserting
a
quick,
a
big
thank
you
to
so
and
so
for
helping
build
this
out.
I
I
like
to
echo
what
sam
suggested-
I
I
don't
know
what
are
the
implications
from
a
financial
perspective,
but
I
definitely
think
that
there
are
a
lot
of
situations
where
something
was
done
from
by
a
team
member
that
could
be
rewarded,
but
the
the
discretionary
bonus
is
just
too
high
as
a
bar
for
that
specific
action
like
currently,
it
needs
to
be
something
that
goes
very
beyond
the
usual
behavior,
so
having
something
with
a
lower
value,
but
that
can
be
used
multiple
times.
It
might
be
a
good
solution.
I
I
really
like
that
that.
A
Suggestion
so
trying
to
type
that
out
and
failing
pretty
bad
at
that
yeah
great
comment.
J
If
I
could
jump
in
one
one
thing
on
that,
I
just
wanted
to
remind
everyone
that
there
is
also
I
will
link
it
in
here,
but
there's
also
the
working
group
bonus
if
you
want
to.
If
a
team
does
something
really
great,
and
in
that
case
everyone
on
the
team
gets
100.
A
A
Do
teams
have
ways
that
they
found
effective
to
celebrate
victories.
One
thing
I
try
to
do
is
you
know
when
you
have
a
win?
You
you
know
accomplish
something:
it's
nice
to
celebrate
that
as
a
team
in
some
way
kind
of
mark
that,
and
it's
not
a
a
lot
of
times.
The
discretionary
bonus
doesn't
really
do
that
and
we've
done
things
like
that,
but
are
there?
Does
anyone
have
success
stories.
F
There
so
I
can
give
an
example
for
a
while
there
memory
group
would
do
end
of
milestone
happy
hour,
which
was
entertaining
and
sometimes
we
would
play
games.
We
found
a
few
games
that
we
play
online
among
us
is
one
of
the
entertaining
ones,
and
we
found
that
our
team
wasn't
big
enough
to
get
a
full
room
of
just
us
and
among
us,
so
we've
recently
expanded
that
to
other
teams
within
enablement.
We
have
a
in,
like
last
friday
of
every
month.
G
Milestone,
I
I
can't
get
in
the
dock
to
talk
to
type
right
now.
But
one
thing
I
was
thinking
about
doing-
and
this
again
is
for
the
ems-
is
looking
at
the
team
members
who
were
exceeding
in
my
group
and
just
evaluate
myself
and
see
if
I've
given
any
discretion.
If
I've
been
involved
with
any
discretionary
bonuses
for
for
people
who
have
been
exceeding
for
an
entire
year
and
kind
of
see,
if
I
have
a
discretionary
bonus,
blind
spot
and
and
maybe
kind
of
just
self-evaluate
and
and
make
some
tweaks
for
the
next
year,.
A
Well,
I
think
we're
about
at
time
for
this
topic.
I
don't
see
any
other
comments,
but
if
anybody
has
a
last
thought
I'll
pause
for
a
second.
A
Then
I
think
we'll
jump
into
the
improvements
for
next
release
track.
So
we've
got
a
couple
items
to
go
through
that.
I
think
we
plan
to
check
in
on
next
month
in
the
retrospective
andre.
I
think
you've
got
the
first
one.
H
H
So
there's
an
ongoing
discussion
on
that
issue
that
linked
there,
but
it
feels
like
we
need
to
have
action
on
making
some
documentation
updates
to
have
a
recommended
process
so
that
people
know
what
we
expect
consistently,
because
if
people
are
using
assignees
and
reviewers
or
they're
just
reviewers.
So
this
is
something
that
we
need
to
iron
out
to
avoid
some
friction
on
the
process.
D
Yeah
and
I'll
just
this
is
more
just
a
comment,
but
this
is
a
great
example
of,
and
it's
probably
easier
because
reviewer
is
such
a
visible
feature.
But
you
know
it's
a
great
example
of
us
dog
footing
something
and
then
we
can
use
the
retro
to
basically
get
that
feedback
loop
kind
of
working.
Obviously,
if
we
can
get
the
feedback
faster
than
that
before
the
retrospective,
that's
great
but
like
this
is
still
a
good
time
for
us
to
kind
of
cycle
through.
D
So
if
you
try
a
new
feature
in
the
product
and
you
see
challenges
with
it,
putting
it
in
the
retrospective
would
definitely
be
valuable,
because
not
only
does
that
get
the
communication
out
about
what
you're
challenging
to
the
team,
but
also
to
the
group
as
a
whole,
which
may
cause
other
people
to
potentially
try
it
out
and
see
if
it
how
it
works.
From
that
perspective
cool.
D
If
we
can
move
development
development
days
or
from
developing
friends
and
family
days
to
after
the
18th
or
if
I
can
get
some
kind
of
general
policy,
if
company-wide,
ideally
company-wide,
so
that
we
don't
have
to
have
our
special
case,
but
just
from
that
perspective,
good
news
is
that
the
next
friends
and
family
day
in
february
is
after
the
19th.
I
believe
so.
I
forget
the
exact
date.
H
D
Engineering,
we
think
it
would
be
better
for,
if,
like
yeah,
so
let's
say,
friends,
friends
and
family
day
is
set,
that
we
say
as
a
development
team
we're
actually
going
to
take
a
different
day,
because
that's
another
policy
that
we
could
do
right
is
is
hey.
We
just
view
this
as
too
critical
to
the
business,
so
therefore
we
will
adjust
accordingly.
C
Well,
so
last
year
we
had
a
really
strong
push
across
all
teams
to
implement
product
analytics
and
different
metrics
and
we're
able
to
get
product
performance
indicators
across
all
of
r
d.
C
What
we're
trying
to
do
right
now
is
start,
look
at
starting
to
re-look
at
our
tooling
and
put
a
heavy
emphasis
on
more
standardization
of
naming
conventions
and
implementation
methods.
So
I've
put
an
action
item
here
and
also
set
up
a
couple
of
okrs
where
we're
going
to
be
improving
our
tooling
we're
going
to
be
updating
the
existing
training
guides
and
then
also
providing
some
workshops
and
more
support
to
the
internal
teams.
D
Cool-
and
I
know
the
last
one
which
is
I'll,
be
looking
for
a
volunteer
but
follow-up
on
the
review.
Token
incident
you
know:
do
we
have
other
situations
in
the
product
where
we
can't
effectively
upgrade
certain.