►
From YouTube: GitLab 10.0 Release Retrospective
Description
Welcome to our retrospective of GitLab 10.0!
Follow along in our kickoff doc! https://docs.google.com/document/d/1ElPkZ90A8ey_iOkTvUs_ByMlwKK6NAB2VOK5835wYK0/edit?usp=sharing
A
A
B
Apologize
for
that
I
was
just
jumping
around
with
setup
here,
so
I
wanted
to
share
that.
We
did
a
really
good
job
with
the
issue
boards,
so
there
was
a
lot
of
coordination
required
in
shipping
group
issue
boards.
Of
course
it
was
a
really
big
feature
for
our
premium
customers
and
in
particular
there
was
a
lot
of
edge
cases
on
how
to
bring
the
boards
to
groups
with
all
the
labels
and
milestones.
B
C
Yes,
so
basically
I
wanted
to
mention
about
Auto
Devils,
because
this
was
basically
the
trend
amongst
effort
from
everyone
involved.
It
was
probably
one
of
the
bigger
tasks
that
we
managed
to
do
in
so
short
time.
It
involves
a
lot
of
people,
a
lot
of
different
stories
to
cover
keeping
in
mind
that
we
have
to
have
proper
uux
that
we
have
to
make
it
actually
work.
We
want
to
actually
also
make
it
possible
to
use
some
github.com.
So
thank
you,
everyone
for
doing
that
for
making
this
happen.
D
Okay,
thank
you.
Now,
it's
better
yeah
getting
back
to
the
out
to
the
DevOps.
It
was
great
Busta.
We
were
also
able
to
ship
other
things,
since
we
don't
want
just
to
focus
on
one
thing
at
all.
So,
even
if
we
were
on
low
capacity
on
low
time,
we
were
able
to
ship
protected
runners
and
variables
for
pipelines,
schedules
that
are
very
awesome,
and
that
reflects
the
fact
that
the
team
can
work
together
on
different
things
at
the
same
time.
D
E
E
So
we
got
a
huge
conflict,
probably
on
the
sixth
and
then
that
got
pushed
into
the
seventh
of
the
eighth
and
then
that
was
Friday,
and
then
we
didn't
actually
get
that
merged
until
Monday
the
11th,
at
which
point
we
could
actually
resolve
the
same
complex
in
stable
branches
which
had
been
created.
That's
mostly
due
to
conflicts,
differences
between
c8
uni,
which
we
are
actively
still
working
on,
reducing
it's
an
ongoing
process.
I,
don't
know
if.
E
C
So
basically,
we
had
a
bunch
of
links
everywhere
that
were
still
pointing
to
github,
see
mot
runner
to
either
issues
or
my
request,
and
basically
these
things
started
having
4:04,
which
kind
of
make
it
work
harder
for
us
or
our
customers
and
for
the
community
to
basically
linked
to
the
valid
place
like
the
solution.
For
that
is
that
we
decided
that
we
are
gonna.
C
We
move
get
up
same
with
your
honor
project
competing
and
bring
back
the
redirect,
because
we
kind
of
confirm
that
the
container
registry
problem
that
we
in
the
beginning
thought
that
it
will
be
issue.
It's
not
really
issue
because
it's
the
container
registry
is
only
used
by
us,
but
like
the
matter
out
of
it
that
it
didn't
went
very
well
because
you
just
create
some
extra
todo
for
everyone
Victor.
C
B
The
lock
issue
issue
was
not
shipped
I
was
originally
scoped
for
10
0,
and
currently
it
is
planned
to
be
shipped
in
10
1,
but
unfortunately
it
is
it's
not
merged
into
master.
So
that's
why
I
said
that
it
will
take
at
least
two
releases
to
complete
the
the
issue
and
merge
requests
are
length
there
and
I
mentioned
what
we
can
improve
in
the
another
section,
but
essentially
seems
that
there
was
love.
A
coordination
required
this
issue
that
we
could
have
done
a
better
job
in
accounting
for.
F
Neck
here
up
yes,
so
we
wanted
to
get
an
initial
graph,
QL
API
endpoints
into
temple
into
and
use
it
for
the
merge
request.
Widget
after
you
were
developing
this.
It
came
to
light
that
there
were
a
number
of
outstanding
licensing
and
patenting
issues
to
do
with
rack,
UL
the
software
and
per
spec
itself.
F
So
in
the
end
we
decided
not
to
go
ahead
and
it's
basically
on
ISIL
until
we
can
resolve
these
issues,
I
understand
it's
being
taken
up,
internals
in
a
Facebook
and
it's
affecting
over
project
as
well,
not
just
us,
so
it's
unfortunate
I
didn't
go
in,
but
probably
the
right
decision,
given
the
uncertainty
exists
at
the
moment.
Camille
you
next.
C
We
started
working
on
out
of
there
was
quite
light
and
because
this
was
basically
so
to
after
a
lot
of
people
vacations
and
we
kind
of
heat
that
there
was
a
lot
of
back-and-forth
between
different
people,
a
lot
of
changing
and
evolving
requirements.
During
the
time
when
we
focus
on
engineering,
but
also
we
were
kind
of
developing
the
product
side,
a
new
excite.
We
we
we
kind
of
we're
aware
that
it
will
be
hard
to
make
this
in
time.
C
When
we
between
this
time,
we
actually
made
something
like
six
metric
was
with
this
very
small
bug
and
regressions.
They
were
not
very
big,
but
it
kind
of
was
not
very
comfortable
doing
that.
Testing
uncle
DevOps
was
quite
a
manual
and
repetitive
job,
something
that
also
required
a
lot
of
effort
from
a
lot
of
people.
Philippa.
G
A
lot
of
issues
were
open
as
deliverables
more
than
a
week
before
the
7th
and
UX
was
not
included
on
those
as
well
and
those
two
issues
they
were
opened
before.
The
7s
deliver
vote,
weren't
the
results
of
not
including
doing
so
near,
and
it's
not
having
the
like
deciding
what
should
be
done
before
the
last
week
and
often
a
lot
of
UX
concerns
were
dismissed.
There
are
some
links
there
and
the
slack
was.
B
D
Thank
You
Philippa,
so
yeah
also
the
same
topic.
Eventually
we
did
it
so
that's
good,
but
I
recognize
that
was
very
rude,
so
the
main
problem
was
that
future
assurance
failure
that
freezer.
Since
we
were
focusing
on
future
assurance
of
a
specific
path,
that
was
not
the
only
one
so
once
we
did
that
the
full
path
work
through.
We
found
that
that
there
was
something
that
is
not
technically
wrong.
D
Importantly,
we
had
to
move
incredible
speed,
so
we
mostly
did
things
and
then
ask
for
validation
at
the
end.
Everything
murdered,
as
you
extend
engineering
leader
authorized
that
day,
but
we
also
cut
a
lot
of
things
that
were
also
included
in
the
MVP,
but
were
not
done.
Time
were
not
authorized
by
you
weeks
or
engineering
so
that
that
was
quite
bad,
even
if
the
result
was
very
good.
This
also
add
some
implication
on
what
you're
working
on
10.1.
D
H
Fixed
value,
so
we
have
one
of
our
kind
of
large
goals.
410
data
was
to
announce
PGH
a-going
GA.
Unfortunately,
we
weren't
able
to
quite
get
there
react
react
quite
close,
but
a
couple,
a
couple
goalposts
I
wanted
to
have-
was
to
have
a
bring
in
production
with
a
little
bit
of
time
to
make
sure
it
be
kind
of
dog
food
before
we
I
recommended
it
to
our
customers
is
something
they
can
move
their
production
HJ
clusters
on
to.
So
one
doesn't
test
that
first
and
we
just
couldn't
quite
get
that
done
within
time.
H
So
I
think
that
was.
That
was
a
big
one
for
me,
as
well
as
having
a
little
bit
of
a--sort
discussion
around
some
documentation
and
and
other
challenges,
kind
of
improvements,
a
couple
days
of
full
release
there.
So
that
was
that
one.
We
also
didn't
get
all
vertebrate
Asians
that
we
were
planning
to
get
done
included
and
we're
working
on
a
more
clear
application
process
as
well.
I
thinkin
see
the
length
issue
be
consuming
discuss.
H
Well,
that
makes
sense
to
move
that
to
a
broader
area
from
orkut
web
I
couldn't
find
an
official
interpretation
process,
but
one
we're
talking
like
they're
just
so.
We
have
expectations
that
we
kind
of
know
what
we
should
communicate
ahead
of
time
before
we
can
sort
of
start
down
this
path,
but
yeah
I'm,
Martin,
you've
any
further
feedback.
There.
I
Just
to
add
that
PGH
a
has
been
proven
to
be
a
quite
a
difficult
thing
to
test
as
well.
It
has
a
lot
of
moving
parts
so,
basically,
as
we
were
working
on
it
and
doing
the
reviews
and
merging
things
things
that
we
thought
we
fixed
would
get
broken,
even
though
we
had
tests,
so
we
had
to
start
over
reinstall
everything
from
the
beginning
and
that's
quite
a
difficult
and
the
time-consuming
process,
and
that's
one
of
the
other
reasons
why
we
didn't
push
harder
for
forgetting
this
into
GA.
I
Apart
from
what
Joshua
said,
and
as
for
the
duplications,
we
almost
managed
to
get
all
of
them
in,
but
we
ended
up
reverting
some
of
them
because
we
realized
that
we
would
get
probably
more
broken
instances
and
we
even
got
our
instances
broken
at
some
point
because
of
communication
that
failed
somewhere.
So
basically,
this
is
why
the
duplication
process
will
need
to
be
created
for
us
to
be
able
to
move
on
the
technical
that
is
growing
and
we
need
to
handle
it
in
a
timely
manner.
J
If,
if
the
background
jobs
aren't
running
and
things
aren't
updating
and
merging
yourself,
it
happens
in
the
background
job.
So
it's
kind
of
frustrating
I
thought
I
saw
someone.
Add
a
comment
to
this.
I
think
it
was
maybe
Robert,
but
yeah
I,
don't
know
if
anybody
has
any
specific
feedback
on
that
I
think
just
in
general
like
please
don't
unless
it's
a
critical
deploy,
yeah.
E
J
J
J
I
don't
know
if
this
is
because
we're
live-streaming
it
but
they're,
definitely
or
just
because
the
team
is
bigger,
but
it
definitely
feels
like
there's
less
actual
discussion
in
the
retrospective.
It's
mostly
people
like
me,
going
down
through
the
points
that
we've
already
written
in
the
agenda,
which
is
great,
but
you
know
part
of
the
point
of
a
retrospective
is
to
like
have
those
discussions
and
digging
into
things.
So
maybe
we
need
to
schedule
separate
calls
for
those
for,
like
you
know,
for
the
auto
dev
ops
thing
off
of
a
lob
issue
thing.
J
J
K
I'm
just
wondering
when,
if
not
now,
should
we
actually
retrospect
and
solve
the
problems
that
we're
talking
about?
It
seems
like
this
conversation
is
really
good
to
bring
up
the
problems,
but
to
solve
them.
You
don't
necessarily
have
a
process
unless
we
do
it
on
our
own,
which
is
also
fine,
which
we
do
do
as
well.
A
You
know
we
we
shouldn't,
have
meetings
for
no
reason
right,
so
if
you
feel
that
we're
not
getting
any
value
at
this
meeting
to
change
anyway,
the
effect
is
we're.
Live-Streaming
is
just
according
to
our
values,
but
it
shouldn't
influence
the
quality
and
the
purpose
of
this
meeting
so
in
bed.
This
is
a
problem.
We
can
stop
live-streaming.
If
you
feel
that
the
time
limit
is
too
short,
we
can
consider
expanding
it.
A
I
I
do
feel
it
there,
the
balance
between
going
very
deep
into
things
and
having
retrospective
about
particular
things
and
still
having
something,
that's
useful
for
everyone
at
this
call,
it's
very
hard,
so
I'm
not
sure
what
the
solution
is
either
still
having
a
retrospective
with
everyone,
or
you
know,
only
discuss
things
that
are
actually
all
to
everyone.
Phrases.
I
think
that
the
release
process
is
something
that
affects
all
of
us,
so
anything
related
to
the
release
process
should
have
you
know
many
comments.
A
J
Know,
I,
don't
I,
don't
think
we
should
cancel
the
meeting
or
do
I
think
we
should
extend
it.
Cuz
I
think
making
it
longer
is
not
really
solving
a
problem,
but
I
just
think
like.
Maybe
the
balance
has
moved
a
bit
too
far
towards
the
async
meeting,
where
we've
got
everything
written
down
in
advance
and
we
we
then
rattle
through
a
bunch
of
stuff
away
from
that
slightly
looser
form,
but
I
think
maybe
maybe
retrospectives
byproduct
area.
I
think
mark
is
actually
just
typing
that
right
now
Jacob
types
and
stuff
as
well.
B
Yeah,
if
it's
in
purpose
of
a
meeting
just
reading
screens
and
then
we
can
chance
like
I,
wanted
to
add,
I
was
actually
looking
at
some
of
the
rituals
in
this
document.
I
think
there
was
actually
action
items
or
was
I
mistaken
I
mean
that
seems
like
a
common
thing
to
do.
In
retros.
You
have
action
items
at
the
end.
J
B
And
then
we
actually
reviewed
set
items
at
our
next
retro
and
make
sure
that
we've
we've
completed
them.
So
to
me
that
forces
us
to
to
actually
in
addition
to
discussing
there,
it's
it
was
actually
changed
as
affected
from
the
discussion,
or
at
least
has
been
document
has
been
in
an
issue
to
say
that
we
will
address
it
at
some
point,
rather
than
just
be
another
document
where
people
just
talk,
I
think
that's
a
that's
a
good
point.
F
B
B
I
Lot
of
discussion
and
a
lot
of
actionable
items
that
we
had
to
do
the
problem
with
that
was,
though,
that
even
that
we
had
at
the
next
Retro,
what
did
you
do
with
your
action
over
time?
No
one
actually
had
enough
power
enough
will
enough
time,
whatever
to
actually
follow
those
things
through.
So,
if
you
check
out
the
early
notes,
we
had
same
people
repeating
things
over
and
over
again
or.
J
I
Things
just
dropped
off,
people
gave
up
and
then
product
went
in
and
took
over
this
meeting
completely
right
reading
it
completely
and
then
engineering,
or
at
least
how
I
felt
engineering
kind
of
just
back
off,
backed
off
and
left.
This
is
a
product
retro
meeting
rather
than
engineering
graduating.
That
was
original
the
goal.
So
maybe
we
can
find
that
common
ground
for
all
of
us
and
and
actually
have
someone
who
will
follow
this
through
I
think.
H
You
can
look
to
me
to
be
responsible
for
for
a
good
portion
of
this
and,
as
I
say,
focus
is
so
important
if
we
can,
if
you
can
determine
let's
say
one
product
and
one
engineering
thing,
but
like
a
major
thing
that
we're
gonna
fix
before
the
next
one
I'm
sure
there's
10
or
20
things
we
want
to
fix.
If
you
really
focus
on
the
highest
priority
items
and
a
few
number
of
them
over
a
series
of
successes
releases,
all
of
a
sudden
you're
really
start
to
see.
H
Substance
have
changed
rather
than
you
know,
just
spreading
action
items
all
over
the
place
and,
as
you
noted
you
know,
lack
of
follow-up
I
think
focus
is
kind
of
the
answer
to
that.
So
I'll
try
to
I,
obviously
on
the
new
guy.
It's
my
second
day,
but
look
to
me
to
start
to
you
know,
bring
some
some
discipline
around
this
and
and
slow,
but
a
significant
change
over
time.
So.
B
J
L
But
if
you
have
those
five
people
that
are
affected
or
even
whatever
ten
and
then
share
those
learnings
I've
never
actually
seen
this
work
really
well,
but
I've
tried
it
at
other
companies
where
each
team
would
do
retrospectives
and
then,
if
they
learned
something
you'd
share
it
and
I
think
we've
done
that
sometimes
that
product
meetings,
for
example,
we've
had
conversations
where
we
share
things
amongst
product
managers.
So
maybe
this
is
another
firm,
but
of
course,
when
you're
sharing
it,
it's
also
then
one
way
and
it
can
be
shared
asynchronously
using
email
or
something
else.
B
So
one
of
the
things
I
saw
are
observed
in
the
lock
issue
issue
is
we
can
do
a
better
job
in
planning
and
coordination
and
I
wanted
to
highlight
that
the
teams
are
working
really
hard
and
shipping
a
lot
of
features
and
doing
a
lot
of
great
work.
But
one
area
I
think
that
we
can
improve,
is
aligning
said
efforts
and,
for
example,
if
if
the
front
end
is
blocked
by
the
back
end
and
the
front
end
goes
and
does
something
else.
B
Maybe
do
some
really
nice
management
duties
and
then
the
back
end
engineer
comes
back
and
then
does
the
task.
Maybe
the
front
end
engineer
is
no
longer
available
to
to
finish
up
the
task.
So
I
have
observed
that
this
often
is
the
case
and
then
so,
there's
essentially
a
lot
of
parallel
streams
of
workers.
Those
are
a
lot
of
blocking
work
and
my
suspicion
is.
This
is
due
to
our
async
nature
and
open
source
routes
which
I
don't
think
it
should
chain
change
on,
and
so
we
should
try
ways
to
improve
that
I.
Think
always.
B
We
want
to
make
smaller
and
smaller
iterations
and
an
issue.
So
the
suggestion
and
that
I've
worked
all
right
and
in
talking
about
the
discussion
team,
is
we're
gonna
try,
making
even
smaller
issues
or
a
merge
request,
in
particular,
not
issues
small
emerge
requests.
Well,
issues
should
be
one-to-one,
anyways
and
and
trying
to
be
able
to
merge
code
and
more
quickly
so
that
there's
integration
problems,
for
example,
are
not
in
a
huge
bunch,
but
that
you're
integrating
code
into
the
main
branch
a
lot
sooner
and
hopefully
that
will
reduce
some
of
this.
B
D
That's
the
a
note
about
that
yep,
but
later
I
feel
the
process
the
expected
process
to
be
product
than
you
accept
than
engineering
at
that
is
probably
what
is
stated
or
what
is
suspected
sometimes
but
I
feel
that
is
not
fully
working,
at
least
for
big
things.
It
should
be
product
plus
e
weeks
plus
engineering
up
at
the
same
time,
maybe
at
early
time
so
I'm
not
saying
that
you
have
to
do
everything
at
the
end
abut
that
dairy.
D
It
is
very
difficult
from
a
product
perspective
or
from
UX
perspective
to
find
out,
which
are
the
engineering
implications.
So
maybe
early
involvement
of
you
weeks
and
the
engineering
in
the
tip
planning
is
something
that
will
add
value
and
will
allow
mainly
a
better
planning
and
people
will
be
aware
of
everything
in
advance.
So,
even
if
engineering
will
start
engineering
the
feature
after
it,
please
define
the
they
already
know
about
it.
D
C
Basically,
my
item
is
kind
of
connected
with
what
you
mentioned,
because
we
often
recently
start
working
on
something
that
is
not
yet
well
defined.
This
kind
of
makes
it
asked
to
deal
with
a
lot
of
uncertainty,
neeti,
sometimes
and
like
very
often,
because
we
choose
to
do
it
like
that.
But
there
are
some
cases
where
these
things
can
be
like
figure
out
before
we
pick
the
task,
it
can
be
figure
out
that
we
have
this
kind
of
outline.
C
L
So
I
am
a
fully
converted
person
over
to
absolutely.
This
is
a
better
way
to
work.
This
challenge
that
I'm
struggling
with
is
how
to
make
that
work
with
our
culture
and
our
values
and
our
distributed
remote
nature,
because
the
product
discovery
work.
That
I
did
before
was
highly
synchronous,
highly
collaborative
high
bandwidth
on
the
PM's,
and
so
there's
a
lot
of
challenges
there,
which
I
haven't
quite
been
able
to
reconcile,
but
literally
10
times
faster
from
a
calendar
wall,
clock
time
from
coming
up
with
an
idea.
L
It's
actually
shipping
it
and
the
quality
of
the
product
was
much
higher
in
the
end
as
well
to
Jacobs
point.
Yes,
this
is
more
important
for
high
uncertainty
items
like
one
of
the
reasons.
I
think
it's
really
important
is
basically
sometimes
you're.
Gonna
hit
technical
limitations
that
you
can't
know
until
you
actually
said
implementing
and
in
order
to
do
a
technical
valuation
first,
you
basically
have
to
implement
a
proof-of-concept
for
everything
to
know
fully
what
the
design
is
going
to
look
like,
because
you
need
to
fully
understand
everything.
That's
fully
understanding.
L
Everything
is
just
this
really
really
huge
burden,
but
if,
instead,
you
say
well,
let's
just
start
working
and
then
you
hit
a
limitation,
get
other
people
together.
What
to
do
that
limitation
then
move
on
it
just
works
so
much
better,
so
it
works.
It's
far,
more
important
for
high
uncertainty
items
so
usually
accompanies
certain
teams
will
adopt
this
and
other
teams
will
not
because
they
don't
have
these
kind
of
high
on
certain
key
items.
L
But
what
I
will
say
is
hard
for
me
to
forget
this
bias,
but
basically
I
had
hold
teams
doing
this
100%
at
the
time
and
that,
once
you
start
switching
this
way,
you
will
see
that
every
project
can
be
seen
as
a
drug
discovery
sprint,
because
everything
has
uncertainty.
We
are
just
in
that
kind
of
a
space.
L
K
K
I,
don't
know
it's
it's
a
balance.
I
have
to
probably
see
it
in
action,
and
maybe
we
can
practice
it
and
give
that.
But
what
I
was
saying
is
that
maybe
like
when
you're
painting,
you
paint
the
whole
picture
at
once.
If
you
can
like
lightly
sketch
out
and
lightly
engineer
the
whole
thing,
it
doesn't
have
to
be
perfect
to
get
it
kind
of
functioning,
then
you
can
get
some
feedback
early
versus
like
going
hardcore
into
the
details
and
making
everything
perfect
only
to
change
it
yeah.
So
that's
it
next
person
I.
I
Just
just
want
to
ask
a
question
tomorrow:
I
know
it's
a
huge
topic,
so
I
don't
want
to
start.
You
know
like
a
huge
humongous
discussion,
but
I'm
curious,
like
we
have
three
weeks
to
do
something
in
one
release:
right,
maybe
not
even
three
weeks
to
do
that.
How
do
we
you
know
like
it
feels
to
me
from
the
engineering
side
that
there
is
this
huge
pressure
next
vacation
that
we
shipped
something
if
something
doesn't
get
shipped.
We
are
very
much
public,
which
means
everyone
gets
hammered
down
from
the
community
from
customers
disappoint
publicly.
I
Some
poetry
is
very
big,
so
it
from
my
side
that
looks
like
a
huge
pressure
for
anyone
going
into
the
work
when
you
don't
have
anything
like
even
like
the
light
skeleton
set
and
when
you're
kind
of
stumbling
and
and
trying
to
figure
things
out.
So
that's
I'm
not
sure
whether
that
product
discovery
stunt
works
in
in
our
time
constraint.
Well,.
L
We
would
do
everything
and
ship
five
iterations
in
one
week
and
at
the
end
it
was
beautiful,
perfectly
polished,
fully
functional
and
then
you
know,
maybe
at
most
there's
a
couple
of
bugs
you'd
come
up
with
the
following
week.
So
by
my
reckoning
we
should
be
able
to
do
three
or
four
of
these
within
a
release.
So
our
time
pressure,
I'd
say
it's
the
opposite.
The
time
pressure
of
a
month
is
not
a
problem,
except
it's
a
problem.
We're
going
to
do
slow.
L
I
L
In
particular,
by
Wednesday
we'd
have
a
design.
You
know.
We'd
have
the
first
generation,
it
kind
of
looks
ugly
by
Wednesday
afternoon
we'd.
Have
it
looking
a
little
bit
better
by
Thursday
and
be
polished?
More
we'd
have
metrics
in
there,
so
that
we'd
actually
have
it
out
to
beta
customers
by
Thursday
afternoon
and
then
we'd
have
mongering
so
we'd
know
if
the
fit
was
actually
successful
or
not
so
the
Friday.
We
could
report
on
it
and
say:
yes,
we
delivered
it,
here's
what
it
looks
like
and
it's
validated
that
this
solution
actually
worked.
One
week.
F
K
L
No,
no,
absolutely
not!
That
was
throughout
the
design.
That
way,
you
don't
do
it
that
what
you
do
is
you
come
up
with
a
tiniest
little
thing.
First,
with
the
cheapest
ugliest
design,
you
possibly,
can
you
ship
that
and
then
you
iterate
on
it
and
you
improve
it,
improve
it
improvement,
but
you
do
the
small
iterations
five
times
within
one
week,
so
you
don't
absolutely
unequivocally
do
not
start
with
the
full
design
ahead
of
time.
That
would
be
the
wrong
direction.
Go
sounds.
F
L
You
need
an
overlap
of
three
or
four
hours
a
day
with
everybody,
product
design,
engineering,
front-end,
back-end
I
mean
it's
hard
in
our
remote.
You
know
timezone
world,
so
I.
That's
why
I
haven't
been
pushing
this
hard
because
I
don't
want
to
disturb
things,
but
all
I
can
say
in
certain
circumstances
it
works
absolutely
beautifully
and
we
should
figure
out
some
way
to
make
it
work
here.
I
think
the
main
problem.
G
We're
seeing
with
in
this
topic
is
that
we
often
have
a
decision
from
product
and
then
we
design
some
mock-ups
and
then
the
product
change.
Then
we
designer
the
remote
mock-ups
and
then
the
product
change
again-
and
this
is
super
hard
to
at
least
on
the
MDM-
depend
on
their
issue
on
the
issues.
They
often
change
and
it's
actually
developers
to
get
something.
Then
you
know
give
a
lot
of
iterations.
C
But
also
the
other
problem
with
our
velocity,
we
kind
of
see
our
velocity
is
very
big
but
like
if
you
look
at
the
minimal
time
in
order
to
ship,
even
the
smallest
wrench,
when
this
small
is
going
to
actually
done
something
and
very
useful.
It's
right
now,
I,
don't
know
three
four
days,
basically
before
it
gets
reviewed
before
someone
approves
that
before
we
have
the
pipeline
green
before
this
lands
on
that
before
before
anything
else,
so
physics
is
kind
of
impossible
for
us
to
work
today
at
this
pace
with
the
process
that
we
have
today.
M
Just
to
give
a
small
thing
into
like
review
of
Mercia
quest
in
the
most
ideal
sense-
I,
mostly
it
cost
me
ten
minutes,
but
often
it
costs
around
thirty
minutes
to
get
the
GDP
running
and
like
check
out
the
merge
request
and
like
review
it
properly,
find
it
within
the
GDK,
where
the
changes,
etc,
etc.
Like
this
thing
can
all
be
solved
with
review
apps,
but
it
is
not
here
yet
forget,
lab
itself.
D
Maybe
one
of
the
other
province-
maybe
it's
already
there,
but
I'm,
not
really
sure
about
that
I
see
sometimes
engineering
working
on
at
the
decimal
I
see
person
working,
maybe
on
two
different
items:
two
different
issues.
At
the
same
time,
that
is
good
in
order
to
spot
possible
problems
in
advance,
but
is
also
our
the
sensor.
D
Then
we
tend
to
have
murderer
cuesta
murdered
by
the
seventh
or
so,
and
so
it
is
maybe
too
late
to
fix
or
to
add
or
to
change
at
that
point,
focusing
on
one
thing
at
the
time,
so
the
whole
team
or
three
person
persons
at
the
same
time
to
one
specific
issue
deliver
it
the
sort
of
early
feature
freeze
just
for
that
issue
and
then
move
on
to
another.
One
can
be
useful
to
avoid
the
after
feature,
freeze
time
that
we
often
need,
unfortunately,.
D
D
D
I
don't
want
I,
don't
want
to
say
that
that
people
are
working
on
features
in
like
robot,
absolutely,
but
sometimes
I'd
like
to
see
more
involvement
and
to
make
people
aware
of
what
is
really
important
in
this
case
out
to
DevOps,
for
example,
we
felt
felt
a
lot
on
how
to
develop,
to
get
it
done,
and
eventually
we
did
it
that
but
I'm
not
so
sure
that
it
was
clear
that
it
is
a
specific
case.
It
was
a
very
important
item
that
really
want
to
be
the
best
MVP
utley,
the
best
and
VP.
D
G
I
want
is
to
respect
your
ex
decisions
a
little
bit
more.
This
I
often
show
this
on
the
CICE
team
and
I
think
we
can
improve
this
I
think
the
feeling
is
that
we
can
all
decide
on
new
X,
which
I
don't
think
it's
the
process.
If
we
have
a
nuh
thing
is
because
we
need
someone,
experts
in
UX
and
product
and
engineering
things
are
not
experts
on
networks,
so
I
think
we
should
respect
their
decisions
a
little
bit
more.
We
can
improve
on
that.
D
Just
want
to
say
a
word
about
this
yeah,
sometimes
I
feel
that
it
may
may
happen
may
appear
that
this
is
the
fact.
Actually
we
as
a
see
the
product
of
me
personally,
we
are
pushing
things
also
to
uux
in
order
to
make
it
really
clear,
which
is
the
goal
that
that
we
want
to
hear,
which
is
a
value
that
we
want
deliver,
but
frankly,
I'm,
seeing
that
normally
we
are
up
at
least
that
finding
a
middle
way
with
you
week.
So
that
is
a
Sherrod
that
is
agreed.
A
Fabio-
and
this
is
a
good
meeting-
we
wanted
to
be
more
actionable.
We
want
to
be
more
iterative
and
more
communicative,
well,
I
think
I
think
that's
a
pretty
good
conclusion
to
all
of
it
and
I
think
everyone
would
agree
that
if
we
improve
all
of
those,
we
may
even
work
great
so,
and
everyone
have
a
nice
day,
have
a
nice
week
and
see
you
in
a
month.