►
From YouTube: The Geo Build Board - A short tour
Description
The Geo team uses a single source of truth to help us build things fast: The Geo Build Board! Here it is: https://gitlab.com/groups/gitlab-org/-/boards/1181257?label_name[]=geo%3A%3Aactive
Nick (the Engineering Manager for Geo) and Fabian (the Product Manager for Geo) give an overview of how it is used and why we like it!
Detailed docs on the process: https://about.gitlab.com/handbook/engineering/development/enablement/geo/process.html
A
Just
need
to
set
something
up:
okay,
there
we
go
okay,
so
for
everybody
watching.
This
is
a
little
bit
in
the
context
of
our
product
development
flow.
So
we're
not
going
to
touch
on
the
validation
track.
We
are
going
to
touch
more
on
the
build
track,
because
this
is
you
know
what
we
can.
I
talk
about
most
I'd
say
so:
yeah
maybe
I'll
hand
it
over
to
you
nick.
B
B
I
don't
think
we
have
a
specific
time
frame
on
on
that
I'd,
say:
maybe
things
that
we're
looking
at
in
the
next
week
or
two.
Sometimes
things
will
end
up
sitting
on
the
board
for
a
while
and
and
since
we
have
weekly
scheduling
calls,
that's
always
a
good
time
to
re-evaluate
things
that
may
be
sitting
in
the
open
or
ready
for
development
column
for
too
long
and
and
decide
if
they
really
are
items
that
we
are
going
to
work
on.
B
A
A
We
really
keep
the
team
focused
on
what
we
think
is
most
important
right
now
to
reach
our
overall
goals
here,
and
this
is
why
we
scope
it
to
a
relatively
small
set
of
items,
because
otherwise
you
have
everything
that
geo
worked,
should
work
on
hundreds
of
issues
here
and
then
thousands
of
issues
in
the
closed
column.
It's
it's
not
super
nice,
so
yeah
that
I
think
that's
sort
of
my
perspective
on
it
and
the
nice
thing
about
the
epic
swim
lanes.
A
Is
we,
or
at
least
I
think
this
is
also
why
you
started
it
initially?
Is
you
get
sort
of
an
overview
of
do?
We
have
too
many
things
happening
in
parallel
at
the
moment
right
for
for
the
team,
and
so
at
the
moment,
for
example,
we
have
a
few
problems
like
it
looks
a
little
bit
more
than
it
actually
is
because
we
have
sort
of
test
gaps
in
in
geo
that
actually
belong
to
testing
maintenance,
mode
and
maintenance
mode
in
turn
is
something
else
here
on
the
board.
A
So
it
looks
a
little
bit
larger,
but
it
focuses
overall
on
these
sort
of
core
initiatives
that
we're
working
on.
So,
for
example,
here
testing
for
maintenance
mode
is
something
that's
actively
being
worked
on
by
a
couple
of
team
members.
Pushing
petroni
into
beta
support
is
another
sort
of
initiative.
You
can
kind
of
see
the
the
flow
of
these
issues
through
the
overall
working
board,
so
that
works,
I
think
quite
well
for
us.
B
A
A
A
No
so,
for
example,
even
this
other
view
which
I
still
use
quite
a
bit
rather
than
the
epic
views,
gives
you
also
a
good
overview
of
all
the
work
that
has
happened
in
the
last
week
or
so,
and
then
how
many
things
are
done
in
parallel?
Is
this
too
much
right?
That's
going
on?
Are
there
things
that
we
should
reduce?
Are
there
too
many
things
really
in
ready
for
development?
Is
it
overwhelming?
A
B
I
don't
know,
I
think
we
should
do
away
with
the
scheduling
call
no
just
just
kidding.
The
scheduling
call
is
great.
I
think
I
think
it
is
probably
the
key
part
of
what
makes
makes
all
this
work,
because
it
can
certainly
be
easy
to
set
up
a
nice
board
and
then
let
things
let
things
kind
of
go
stale
quickly
and
not
reflect
the
actual
state
of
what's
going
on.
B
We
try
to
have
multiple
engineers
focused
on
an
epic
to
to
help
focus
on
our
efforts
and
and
spread
knowledge
as
much
as
possible,
and
so
so
that
way
we
can.
If
that
engineer
is
on
the
call,
we
can
get
a
get
a
high
level
overview
of
where,
where
things
are
at
in
that
epic,
otherwise
usually
I'll
provide
provide
an
update
from
the
engineering
side
and
then
and
then
we'll
have
and
then
yeah
we
can.
We
talk
about
that.
B
Sometimes
we
need
to
update
the
progress
of
things
like
you
know.
Something
is
actually
in
review
versus
in
dev
or
something
can
be
closed.
I
think,
and
then
you
will
often
talk
about
the
the
priority
of
something
or
you
know,
kind
of
help
us
get
the
big
picture
of
of
some
work
so
yeah.
I
think
it's
just
a,
and
it's
also
so
so.
A
Yeah,
no,
I
actually
agree
I
mean
for
me
it's
probably
the
one
of
the
most
valuable
activities
in
the
week,
not
so
much
because
I
I
want
to
understand
every
little
issue
that
we're
facing
in
development,
but
more
because
it
allows
us
to
talk
about
these
items
and
why
they're
important
how
they're
going
and
what
we're
trying
to
achieve-
and
I
think
having
that
context
is-
is
really
valuable
as
if
we
look
at
petroni
right
just
checking
in
and
saying
like.
I
think
we
had
a
discussion
this
week
where
we
were
like.
A
Do
we
need
to
do
all
of
the
things
that
are
currently
in
this
this
epic
for
for
beta?
Have
we
is
this
bloated?
Should
we
should
we
cut
some
scope
right
to
iterate
faster?
I
think
having
these
touch
points
really
frequently,
it
helps
everyone
in
the
team
to
have
enough
context
plus
when
things
become
stale.
We
see
them
like.
A
We
see
them
not
after
four
weeks,
two
days
before
the
release
right,
we
see
this
and
we
can
react
very
quickly,
and
so
I
I
really
like
that
personally
so
yeah,
I
think
that's
that's
kind
of
it.
I
think
the
I
think,
if
I
had
to
summarize
it
from
from
my
perspective,
is
it
requires
some
prerequisites
right.
You
will
not
benefit
from
having
epics
if
you
don't
have
an
epic
tree,
but
regardless
of
that
having
a
single
board
that
actually
corresponds
to
our
product
development.
Workflow.
A
Here,
I
think,
is
pretty
useful
scoping
it
to
only
the
things
that
are
actually
going
to
be
worked
on.
I
think
is
also
really
important
and
keeping
like
an
eye
on
on
the
board
and
keeping
it
up
to
date,
because
you
don't
right,
I
think,
as
as
any
process,
and
we
talked
about
that
before
it's
like
it
is
sort
of
the
ability
to
make
it
a
ritual,
something
that
the
team
sort
of
understands
and
gathers
around
right.
Where
the
collaboration
happens.
I
think
that's
that's
important
yeah.
A
I
think
the
last
thing
that
we
forgot
to
mention
is,
I
think,
every
week
when
we
see
how
many
things
are
closed,
we
have
an
opportunity
to
celebrate
that
as
well.
It's
like
often
we've
talked
about
those
things
four
times
in
the
call
and
talked
about
the
difficulties
and
why
that's
maybe
challenging
or
whatnot,
and
then
you
see
it
closed
and
people
are
excited
to
see
their
own
velocity
and
that's
something
that
happens.
B
Yeah
agreed
one
other
point
I
wanted
to
make
is
that
is
that
anyone
can
can
bring
an
issue
onto
the
board,
so
this
isn't
something
where
only
fabian,
or
only
you
know,
fabian
and
me
can
decide
what
goes
on
the
board.
Anyone
can
bring
on
the
board
and
because
we
have
this
weekly
call,
we
can
then
sort
of
revisit.
Like
is
yeah.
Okay.
B
A
Also,
really
nice
because,
let's
say
there's
a
high
priority
bug
that
happened.
I
think,
last
last
week,
a
couple
of
weeks
ago,
we
had
an
issue
douglas
saw.
It
thought
this
is
important,
felt
empowered
to
assign
it
to
himself
pull
it
onto
the
board,
started
working
on
it,
explain
it
in
the
scheduling,
call
closed
it
and
that's,
I
think,
the
dynamic
that
you
that
I
really
appreciate
where
that
is
something
that
can
just
happen,
and
you
don't
need
to
say.
B
A
I
think
that's
kind
of
it.
I
think
that's
a
good
good
overview.
I
realized
talking
through
that
there's
actually
a
lot
of
things
going
on
and
we've
been
doing
it
for
a
while
and
I'll.
I
think
we
have
it
documented.
So
that's
good,
but
I
I
love
it.
It's
my
favorite
way
of
working
and
for
anybody
who
has
watched
this
to
the
end.