►
From YouTube: ENG/UX Progressive Delivery Meeting 2020-07-07
Description
Meeting to improve alignment between Engineering and UX for progressive Delivery
A
Joining
I
really
appreciate
it.
I
set
up
this
meeting
to
create
a
better
understanding
from
both
sides
as
to
like
what
you
know
entails
ux.
What
entails
engineering,
how
I
can
best
help
engineering
and
as
well
a
little
bit,
perhaps
create
some
alignment
on
my
work.
For
you,
part
of
this
is
kind
of
detailed
at
like
immediate
issues
in
progress.
So
like
hey,
is
there
anything
that
I'm
missing
the
boat
on
that
I'm?
A
You
know
like
I'm,
I'm
not
seeing
that,
but
I
have
to
go
there
and
be
there
immediately
in
order
to
be
of
best
service
to
engineering,
and
the
other
side
is
more
like
create
alignment
on
processes
that
we
have
or
don't
have,
because
there's
some
of
that
as
well
and
and
basically
cc.
You
know,
reduce
those
friction
points,
and
so,
for
example,
from
my
side,
I.
A
At
the
same
time,
I
want
to,
you
know,
make
things
from
the
user's
perspective
viable,
be
that
with
feature
flags,
for
example.
I
think,
is
a
great
tool
in
our
toolbox,
which
we
might
or
might
not
be
using
enough
or
that
we
need
to
have
a
more
informed
discussion
about
or
more
standardized
process
around
those,
I
think,
there's
a
lot
of
opportunities
here
to
you
know,
give
each
other
a
high
five
and
achieve
better
results
so
to
open
up
the
discussion,
I
think
we're
not
gonna
be
able
to
discuss
everything.
That
is
not
that's.
A
A
We
make
a
little
bit
more
more
prominent
every
week,
but
I
I
intend
for
it
to
not
be
too
many
times
and
be
mindful
of
everybody's
time,
but
I
would
love
to
know
from
engineering
perspective
where
ux
can
be
of
most
help
like
are
there
things
unclear?
A
Are
there
things
apart
from
like
the
immediate
issues
like
are.
A
You
know
this
is
where
I
need
ux's
help
the
most
right
now.
Let
me
see
I
put
this
together
like
a
week
ago,
so
I'm
a
little
bit
really
into
my
agenda
points
like
how
did
I?
How
did
I
mean
for
this,
but
any
discussion
here
is
is
welcome.
C
So,
as
far
as
I'm
concerned,
I,
in
addition
to
understanding
you
know
where
we're
going
with
the
future
I
find
ux.
I
look
I'm
looking
at
ux
from
the
the
the
issue
weight
angle,
which
means
that
if
I
understand
you
know
where
we're
going
from
ux
point
of
view,
it's
going
to
help
me
to
break
down
future
into
mrs
right.
So.
A
There
is
an
issue
and
when
you
encounter
an
issue,
there
should
ideally
be
figured
out
solution
where
you
know
we
know
what
to
implement
and
then
based
on
that
the
weight
is
either
assigned
or
is
already
existing,
and
only
then
we
go
into
merge
quest
scoping.
Do
I
say
that
right.
C
Yeah,
yes,
take
the
example
of
the
deploy
keys
for
protected
branches.
Remember
you,
you
did
the
markup
of
what
the
deploy
keys
were
going
to
look
like
right
into
that
drop
down
on
protected
branches
and.
B
Once
we
once
we
agreed.
C
C
Point
of
view,
in
terms
of
mr
breakdown.
A
I'm
thinking
of
this
that's
a
good
idea,
so
things
are
rolling
back
into
my
head.
I
want
to
skip
this
a
little
bit
on
the
process,
because
I
did
indeed
think
of
this
more
tailored
towards
the
current
issues
in
progress.
So
I'm
going.
A
Where
I'll
come
back
to
that,
sorry
for
a
little
bit
of
disorganizing,
so
in
terms
of
currently
in
progress
issues
for
this
milestone,
which
you
are
currently
working
on
or
about
to
work
on,
is
there
any
issues
that
currently,
from
a
ux
point
of
view,
you
are
unclear
or
uncertain
about?
You
know
how
to
move
forward,
because
I'm
I'm
trying
to
improve
my
vision
as
to
hey
I'm
skipping
the
boat
here
or
I'm
leaving
things
unattended.
D
I
think
I
think
from
from
my
side
of
things,
if
like.
If
things
are
unclear,
we
try
really
hard
to
bring
those
up
as
early
as
possible,
just
because
we
don't
want
to.
We
don't
want
to
start
down
the
road
of
trying
to
build
something
that
we
ultimately
don't
know
where
we're
going.
That
doesn't
necessarily
mean
it
has
to
be
perfect,
though
I
do.
D
I
do
actually
quite
enjoy
like
a
little
bit
of
wiggle
room,
and
if
I,
if
I
have
a,
I
guess,
a
blocking
question,
which
is
generally
just
me
not
being
able
to
decide
which
way
would
be
the
best
way
to
go
and
those
those
those
come
up,
but
you're,
usually
very
good
at
jumping
on
those
when
they
do
come
up
and
providing
guidance.
So.
A
A
Awesome
that
is
good
to
hear
in
terms
of
ux
involvement
I
like,
if
nobody
has
any
any
more
comments
from
previous
point,
I.
B
A
Done
it
all
300
times
before
this
case,
but
at
this
point
I
want
to
highlight.
A
For
now,
I'm
gonna
go
just
on
like
a
global
level.
If
we
look
at
progressive
delivery,
we
have
our
planning
issues.
We
have
our
needs
weight
issue
where
I
assume
that
engineering
is
looking
beyond
the
current
milestone,
just
like
more
looking
towards
what
is
going
coming
up
next,
you
access
that
same
thing.
We
are
mostly
working
ahead
of
the
curve,
so
we
have
this
kind
of
ux
weight,
epic,
we're
not
using
it
as
an
epics.
A
It's
just
like
it's
it's
it's
basically
more
of
like
we
use
a
description
to
have
this
kind
of
table
to
kind
of
organize
things
in
that
way.
But
what
I'm
ideally
envisioning
is
that
for
some
of
these
things,
for
example,
I'm
currently
working
on
these
issues
allow
parent
pro
project
developers
to
create
pipelines
for.
B
A
Quests
for
forecam
cameras
cancel
employment
jobs.
You
know
some
things
are
kind
of
done.
Some
things
are
less
done
or
a
good
spot
or
are
up
next
and
one
of
the
things
I'm
always
wondering
about-
and
I
think
this
is
this
is
a
perfect
question
for
this
discussion
is,
for
example,
I
am
going
into
this.
This
new
issue
implement
blue
green
switch
on
deploy
boards.
Let's,
let's
open
up
that
issue
and
right
now
I
am
there's
there's
some
discussion.
A
I
see
that
china
is
involved
into
this
a
little
bit,
there's
some
discussion
with
uribe
going
on
and
there's
this
huge
description,
and
now
it's
my
job
to
make
this
into
something
that
is
a
gonna,
be
good
and
b
it's
gonna
be
mvc.
A
Who
do
I
work
with?
How
do
I
know
who
to
mention
and
who's
gonna,
be
my
partners
in
in
crime
to
to
make
this
successful
and
as
a
small
addition
to
that.
So,
though,
that's
going
on
often
on
tangent,
I
need
to
explore
broad
before
I
can
explore
narrow,
like
I'm
always
going
to
go
beyond
the
current
mvc
scope
when
I'm
ideating
and
then
I'm
gonna
scope
down
in
order
to
see
all
right.
What
can
we
deliver
for
this
first
iteration?
But
how
do
you?
B
A
B
B
So,
since
no
one
else
is
talking
I'll
take
a
stab
at
that
one,
so,
generally
generally
dimitri,
we
have
different
engineers
that
will
be
giving
input
to
weight
or
research
a
particular
item
on
the
needs,
weight
or
research
issue,
at
least
a
milestone
prior
and
most
of
the
time.
But
not
always
the
engineers
that
are
asked
to
give
input
on
those
are
the
engineers
that
will
end
up
doing
the
work.
B
So
you
should
be
able
to
find
out
who
to
work
with
on
that
in
terms
of
whoever,
whatever
engineer
is
doing
the
waiting.
So
if
a
tn
is
is
waiting
and
giving
input
on
a
particular
issue,
then
he
would
be
the
one
that
you
would
work
with
in
terms
of
flushing
out
that
feature.
E
E
I
think
that's
right,
except
that
if
dimitri
is
working
so
far
in
the
future,
milestones
and
milestones
ahead,
then
there's
no
in
that
linkage
between
those
those
people
who
are
assigned
to
you
know,
break
down
and
estimate
those
issues.
That's
coming
a
lot
later.
E
So,
if
you're
looking
for
feedback
about
the
a
wide
scope
of
how
to
you
know
thinking
about
the
realms
of
possibility
or
something
in
a
place
that
I
would,
I
would
suggest
just
to
just
ask
the
group-
or
just
you
know,
ask
somebody,
and
maybe
they
can
maybe
they
can
help
you
or
or
not
like,
if
that,
if
there's,
if
we're,
not
ready
to
do
this
the
waiting
bit
yet
I
would
just
I
would
just
reach
out
and
don't
worry
about
if
you
need,
if
you
need
that
kind
of
assistance.
A
Yeah,
and-
and
thank
you
both
so
I
agree
like
if,
if
there's
already
some
involvement
on
an
issue,
it
is
often
quite
easy
to
kind
of
you
know,
continue
that
conversation
or
prod
a
little
bit
the
people
who
are
already
involved
to
some
extent.
A
However,
like
weight
waiting,
an
issue
that
means,
ideally,
if
I'm
correct,
that
issue
should
already
kind
of
have
like
a
solution
figured
out
like
it
doesn't
need
to
be
an
exact
solution.
It
doesn't
need
to
be.
You
know
like
all
right,
we're
100
committed
to
this
one
thing
and
nothing
else,
but
like
ideally,
an
issue
should
be
more
than
what
has
been
offered
here.
This
has
been
an
initial
write-up
by
ored.
There's
been
some
initial
discussion,
but,
like
there's,
there's
gone
little
input
into
this
there's,
there's
no
there's
no
cross-linking
to
any
research.
A
There's
like
there's
some
research
or
some
some
description
of
a
potential
solution
like
if
I'm
correct,
complete.
Please
please
say
if
I'm
not.
I
think
it
would
be
very
hard
for
engineers
to
weight
this
in
its
current
state.
Right
like
this
is
just
impossible.
Almost.
E
Yeah
I
mean
it
certainly
makes
the
job
more
difficult.
I
think
you're
right
about
that.
A
Yeah
so,
and
and
where
I
want
to
go,
and
I've
seen
that
from
other
stage,
groups
like
release
management
is
that
they
are
ahead
of
the
curve
enough,
like
I
don't
want
to
work
months
and
months
and
months
and
months
and
months
ahead,
but
I
want
to
work
enough
ahead,
like
ideally
one
to
two,
perhaps
three
but
let's,
let's
say
between
one
and
two
milestones
ahead,
so
that
when
waiting
comes
when
this
comes
into
the
needs
weights
issue,
the
engineer
that
is
going
to
weigh
this
issue
was
already
involved
in
the
ideation
on
the
concept
that
that
issue
is
involved.
A
So
that
is
where
that
is
where
I
need
the
people
like.
Ideally,
I
want
no
issues
that
go
into
neet
suede
that
has
some
ux
involvement
in
there
to
be
unknown.
Prior
to
that.
So
my
current
take
on
this
is
you
know,
asking
engineering
managers
like
hey,
who
can
I
who
kind
of
work
with
this
on
internal
front-end
and
backhand?
And
I
think
the
most
important
point
here
is.
This
is
not
a
one-time
request
for
contact.
A
This
is
going
to
be
a
back
and
forth
discussion
like
hey.
I
need
some
ideas
from
you
or
hey,
I'm
thinking
in
such
a
way.
What
are
your,
what
are
your
views
and
then
you
respond
back
and
we
I
come
up
with
a
second
iteration.
It's
like
a
little
bit
of
a
sparring
partner,
so
it
it
might
take
up
sometimes
a
little
bit
of
time.
More
than
perhaps
just
like
a
glance
and
like
it's
beyond
breakdown,
it's
it's
bored
and
breakdown.
A
There's
a
little
bit
of
ideation
and
feedback
from
the
universe
like
it
will
mean
that
those
ideas
and
issues
that
will
go
into
the
milestone
will
be
infused
more
by
engineering.
I
think
that
is
going
to
benefit
us
all.
So
in
that
case
is
mentioning
engineering
managers
right
approach,
or
is
it
more
like?
I
should
just
mention
all
engineers
in
in
progressive
delivery
and
hope
that
somebody
like
who's
gonna
be
dri.
That's
what
I'm,
what
I'm
concerned
with
it
needs
to
be
on
somebody's
radar,
yeah.
B
But
I
don't
think
the
intention
of
that
issue
is
that
when
the
engineer
is
looking
at
it,
they
have
all
the
answers
and
can
just
supply
a
weight,
because
even
in
the
description
of
the
issue,
you'll
notice,
it
says,
if
you're
performing
the
final
review
right,
but
we
have
these
issues
assigned
to
each
engineer
and
if
there's
not
enough
information
there
to
give
away,
I
think
that's
the
trigger,
so
to
speak,
that
that
some
conversation
should
be
happening
on
other
teams.
I've
seen
them
actually
separate
needs.
B
B
We
may
want
to
consider
that
the
main
thing,
though,
I
think,
is
that
we
want
to
make
sure
that
we're
time
boxing
it
as
much
as
possible,
not
that
discussions
aren't
happening
throughout
the
release
cycle,
but
that
engineers
have
that
focus
time
for
their
current
deliverables
and
that
we're
trying
to
set
aside
some
time
for
them
to
do
this
discovery
and
flushing
out.
That
would
be
kind
of
my
perspective
on
that.
I
don't
know
if
anyone
else
wants
to
give
input
there.
D
I
think
one
thing
we
could
do
with
that
issue
going
forward
is
kind
of
call
out
a
little
bit
clearer.
What
it
is
is
more
suggested
that
is
ready,
ready
versus
something
that
needs
a
little
more
research,
because
it
makes
it
makes
time
boxing
hard.
If
you
just
have
a
unorganized
list
of
links
to
go.
A
Through
can
I
ask
in
terms
of
like
time
boxing,
can
you
ping
me
a
picture
of
what
that
means
like?
I
know
the
term
time
boxing,
but
I
mean
like
how
would
an
issue
like
how
would
an
engineer
time
box
their
time
and
then
provide
like
like
that
interaction
with
me
like?
How
would
that
hold
it
work.
E
A
B
The
the
main
idea,
though
dimitri,
is
that
this
this
week,
which
is
generally
kind
of
the
first
week
in
that
milestone,
is
that
time
that
the
engineers
are
are
setting
aside
some
time
to
do
this
versus
you
know
like
the
week
of
code,
cut
off
and
they're
getting
pulled
in
from
design
to
get
questions
on
something
three
weeks
out,
but
they're
trying
to
focus
on
getting
things
in
so
from
time
box
perspective.
B
I
think
just
the
timing
of
when
this
issue
is
being
looked
at
by
the
engineers
is
important
and
to
andrew's
point
here.
I'm
going
to
slink
one
of
the
needs
weight
issues
from
release
management,
where
we
kind
of
separate
out
what
we
call
research
versus
things
that
we
feel
are
ready
for
the
actual
waiting.
So
that's
one
way
that
people
I've
seen
do
this
and
we
can
consider
maybe
making
that
more
clear
on
the
needs
weight
issue.
A
Yeah,
I
think
I
think,
that's
helpful.
On
the
other
hand,
I
want
to
I
want
to
make
like
I'm
I'm
trying
to
to
see
how
I
can
make
the
case
more
more
clear,
so
say,
for
example,
this
this
this
implement
blue
green
switch
issue,
is
gonna,
be
in
progress
by
me
because
it's
gonna
it's
going
to
be
like
at
some
point.
I
don't
know
if
this
issue
has
been
updated
with
the
milestone,
and
perhaps
there
are
some
inconsistencies
with
mine.
A
It's
my
epic,
my
planning,
epic
first,
the
actual
planning,
epic
from
but
anyway,
it
doesn't
really
matter
like
this
could
be
any
issue.
So
what
happens
from
my
side
is
I'll
go
in
progress
on
this
issue.
That
means
that
I'll
be
actively
pushing
this
issue
forward.
I'm
gonna
involve
the
people.
I
need
to
be
involved
with
I'm
gonna
ideate,
I'm
gonna
propose
designs
and
I'm
gonna
get
feedback
and
it's
rate
based
on
that
feedback
that
feedback
part
of
that
feedback.
A
A
It
is
not
something
that,
like
I'll,
probably
need
sometimes
five
to
ten
minutes
from
there
from
an
engineer
every
two
to
three
days
on
a
certain
issue,
and
I
will
be
working
on
two
to
four
issues
at
a
time,
so
that
will
mean
that
you
know
for
two
to
three
days:
I'll
need
20
to
40
minutes
of
an
engineer
like
generally
so,
like.
I
think
you
can
time
box
it,
but
it
is
not
just
like
oh
there's
one
week
in
a
milestone.
I
need
some
time.
A
B
So,
just
to
clarify
on
that,
I
don't
think
that's
not
being.
At
least
it
wasn't
my
intention
to
imply
that
people
can't
comment
on
issues
prior
to
this
week
time
period.
I
think
that
there
just
has
to
be
some
awareness
of
the
engineers
trying
to
get
their
deliverables
in
and
if
it's
a
high
level
hey.
What
do
you
think
about
this?
Then,
of
course
you
know
they
can
comment
if
they're
going
to
be
needing
to
spend
some
time
to
dig
in
find
out
if
something's
possible
see
what
the
code
is
doing
now.
B
I
think
that's
where
we
need
to
make
sure
it's
assigned
on
one
of
these
issues
and-
and
they
have
that
designated
time
to
dig
in
especially
if
it's
an
item,
that's
not
clearly
flushed
out
and
needs
some
more
discovery.
Put
it
that
way.
D
You
don't
want
to
like.
I
don't
know,
I
think
it's
just
it's
yeah
you,
if
you
just
have
a
list
of
of
issues
to
to
kind
of
comb
through
you're
gonna,
try
and
and
do
that
in
in,
like
the
designated
time-
or
at
least
I
am
anyways,
but
if
you,
if
you're
mid,
milestone
or
something
and
you're
very
clearly
calling
out
that
you
need
some.
You
just
want,
like
some
some
quick
answers
on
some
on
how
things
are
working
now
or
something
like
that.
That's.
D
Yeah,
I
think,
as
long
as
you're
you're
clear
about
calling
it
out,
then
it's
it's
less
of
a
it's
less
of
an
issue
right
because
we
know
we
know
going
in
what
what
kind
of
like
is
expected.
A
Yeah,
that
makes
a
lot
of
sense.
I'm
kind
of
hearing
two
themes.
I
know
we're
at
the
end
of
the
of
the
meeting
I
kind
of
want
to
propose
something
which
I
think
might
be
a
nice
action,
I'm
coming
out
of
this
first
meeting,
so
I
hear
needs
wave
issue.
A
I
hear
you
know
those
last
two
points,
but
you
andrew
like
time,
purchasation
managing
expectations,
kind
of
come
down,
as
I
feel
like
the
needs
weight
issue
is
kind
of
like
the
focal
point
that
engineering
uses
to
spend
their
time
wisely
understand
that
engineering
needs
to
commit
to
their
time
for
the
deliverables
at
the
same
time.
A
You
know,
like
some
of
this
work,
that
product
management,
product
design
works
on
ahead
of
the
curve
kind
of
goes
unnoticed
or
is
less
trackable,
less
obvious.
That
needs
input.
So
how
about
this?
The
suggestion
of
me
making
it
visible
on
which
two
to
four
issues
I
need
currently
input
from
engineering
on
a
continuous
basis
and
put
that
into
the
needs
weight.
Ux
needs
needs
wave
engineering
issue
and
that
way,
it
kind
of
like
you
you'll
tackle
your
like
prioritized
issues
first,
but
then
we
can
assign
hey.
A
I
have
this
little
list
of
issues
that
I
need
engineering
input
on.
You
can
decide
whoever
is
going
to
be
on
what,
but
for
a
lot
of
the
issues,
I
will
probably
need
someone
from
back
end
and
front
end,
and
then
I
immediately
know
all
right.
Those
two
people
I
need
hey.
I
added
this
issue.
I
removed
this
issue
because
we
changed
something
in
progress
because
of
planning
changes.
E
Yeah
I
mean
like
use
that
needs
weight
issue
as
a
place
for
discussion
as
well
as
just
assignment,
if,
like
we
know,
see
if
we
can
reuse
it
and
and
push
that
there,
instead
of
having
something
separate,
also
track.
B
I
think
two
we
can
try
that,
but
we
may
want
to
consider
having
like
we
were
talking
about
just
calling
it
out
for
specific
engineers,
because
I
think,
if
you
keep
a
general
list,
you
may
not
get
the
feedback
you're
looking
for
versus.
If
we
have
people's
names
tied
to
it
and
that's
when
you're
gonna
probably
get
more
results.
So
it's
just
something
to
think
about
there.
We
can
always
try
it,
though,
and
go.
A
Yeah,
I
was
thinking
of
like
that
list
that
features
the
issue
name
or
the
issue
id
whatever,
and
then
you
will
assign
like
specific
people
after
like
hey,
I
notify
you
of,
like
hey
I've,
added
this
new
issue
to
the
list.
I've
removed
this
other
one
because
it's
less
important
now,
but
I
need
like
either
a
front
end
or
a
back
end
or
both,
and
then
you
put
a
name
on
the
list
and
then
everybody
knows
who
like
needs
to
watch
where
that
would
be
immensely
helpful
to
know
all
right.
A
A
All
right,
thank
you,
so
much
I'll
I'll
make
that
a
reality
I'll
push
the
other
things
for
the
next
meeting.
I
think
this
one's
already
immensely
helpful.
I
think
there's
going
to
be
some
interesting
items
for
the
next
ones
as
well.
So,
for
example,
how
do
we
like
push
merch
quest
forward?