►
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
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
C
A
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
B
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
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
E
E
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
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
A
E
A
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
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.
A
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.
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.