►
From YouTube: Jason and Fabian discuss Geo's Kanban system
A
Fabien
well,
thanks
for
jumping
on
the
call
to
give
a
little
bit
of
context.
We
actually
started
this
in
a
another
thread,
so
I'll
just
do
a
super
quick
recap
on
the
CR
CDT
challenges,
where
the
we
have
the
stack
rank
going
into
planning
and
what's
happening,
then,
is
that
on
the
planning
day,
basically,
the
engineering
manager
is
going
through
the
stack
rank
on
the
way
down
and
kind
of
like
dealing
it
out
like
a
deck
of
cards
yeah.
A
So
one
engineer
gets
one
next
engineer
gets
one
and
we
work
our
way
down
the
stack
retic
until
all
the
engineers
say:
okay,
I
feel
full,
and
that
ends
up
being
the
cut
line
where
we
work
and
that
part
actually
works
great.
It
ensures
that
the
top
items
move
and
that
we
get
a
pretty
clear
cut
line,
because
everybody
has
like
a
good
sense
of
specific
items
that
they're
going
to
be
working
on.
But
then
what
comes
out
of
that
is
that
all
of
the
context
from
the
stack
rank
is
lost.
A
So
we
go
into
development
and
people
just
work
on
whichever
ones
seem
to
make
sense
to
them
or
or
whatever
and
in
theory
the
engineering
manager
can
kind
of
remember
the
stack
rank
and
help
people
stay
on
task
within
engineering,
but
in
practice
that's
really
really
hard
to
do
because,
and
so
we
were
looking
at
the
Gio
process,
which
uses
a
Kanban
board,
which
is
nice,
because
it
limits
WIPP
both
in
terms
of
the
delivery
side
and
in
terms
of
kind
of
queuing
up.
The
next
work
to
be
done.
A
B
The
observation
was
that
a
like
reality
at
the
end
of
the
month
would
look
pretty
different
for
various
reasons,
but,
like
other
things,
pop
up
right,
like
people
like
me
to
like
jump
on
like
customer
issues,
whatever
it
may
be.
So
there
was
a
joint.
Also
folks
didn't
have
enough
context
right.
It's
like
they
were
sort
of
individual
issues
that
you
know,
maybe
at
like
the
time
when
I
scheduled
them.
B
It
made
sense
right,
but
people
were
not
really
able
to
I
think
really
fully
understand
what
was
happening,
and
there
was
also
them
like
just
one
big
board
right
and
I
think
it
was
a
little
bit
overwhelming
to
have
this
long
list
off
of
stuff
and
also
for
Rachel
and
myself.
Rachel
is
the
engineering
manager
I
worked
with.
B
We
felt
that
we
had
a
very
hectic
one
week
where
we
needed
to
do
all
the
planning
we
needed
to
think
about
the
milestone
and
kind
of
get
all
of
this
done,
and
then
you
have
this
sort
of
big
relief
moment.
It's
like
I,
it's
we
are
done
now
now.
You
know
like
we
can
go
off
and
do
other
things
that
didn't
work
out
so
well,
so
rachel
is
suggested
to
do
a
more
continuous
process,
which
is
the
Kanban
process.
B
So
essentially
the
idea
was
that
we
would
do
a
couple
of
things
differently
to
make
it
work.
So
we
have
essentially
this
sort
of
dual
track
system
where
there
is
a
planning
process
which
we
can
talk
about
a
little
bit
and
then
there
is
the
actual
sort
of
build
process
and
there
being
linked
by
the
super
scheduling
step
which
is
I
call
it.
B
B
So
just
trying
to
so
this
is
the
the
current
billboard
and
you
will
you'll
have
the
usual
workflow
right
there,
education
in
with
you,
blocked
in-depth
ready
for
development
and
they
sort
of
open
column
here,
but
I
can
actually
close
this.
So
this
is
where
we're
engineers
essentially
should
look
like
to
grab
new
work
from
the
workflow
ready
for
development,
and
this
is
roughly
stack
rank.
B
So
the
most
important
next
thing
to
do
should
be
at
the
top,
and
at
the
moment
you
can
see-
and
this
is
probably
a
function
of
where
we
are
in
the
release-
there's
a
lot
of
work
in
development
and
not
very
much
in
review
right
now,
so
it
kind
of
makes
sense,
but
you
can
also
see
here.
These
are
sort
of
the
closed
items
that
we're
delivered
this
week
and
for
like,
let's
say
our
engineering
team.
They
don't
need
to
go
anywhere
else
right.
B
So,
as
you
can
say
like
see
at
the
moment
is
pretty
pretty
lean
and
how
we
decide
to
actually
pull
in
issues
here
is
hard
of
our
scheduling,
call
that
Rachel
and
I
have
synchronously
every
every
Friday.
So
we
need
for
an
hour,
and
the
first
thing
we
do
is
we
essentially
goes
through
the
state
or
from
the
build
port
and
actually
say
are
things
moving?
You
know,
are
they
like
certain
blockers?
Are
we
still
doing
the
right
thing?
Do
we
change
something,
and
then
the
next
bit
is
essentially
saying?
A
B
B
They
are
essentially
ready
to
be
picked
up
by
engineering,
and
ideally
this
long
list
here
is
also
more
or
less
stack,
ranked
I
struggle
with
this
a
little
bit,
because
I
can't
see
my
epics
right,
I
have
no
swimlanes,
so
it
is
just
a
big
pile,
but
this
is
essentially
like
fifty
nine
days
of
of
engineering
time
that
I
I
know
could
happen
more
or
less
right
now,
mm-hmm.
What
we
then
do
is
we
we
go
through
this
and
I
essentially
sort
of
freezing
it
the
number
of
items
and
say
hey.
B
Actually,
we
still
need
to
create
the
server
architecture
diagram,
but
I
think
this
is
something
we
should
do
next.
I
also
think
we
should
organize
this
this
meeting
here
and
those
things
and
Rachel
and
I
have
a
discussion
every
week.
If
you
know
she
understands,
you
know
what
this
means.
If
it
is
well
enough
defined
right,
if
all
of
the,
if
this
would
make
sense
as
a
package
and
then
we
go
ahead
and
schedule
it,
okay.
A
A
B
A
B
A
B
B
A
The
other
question
that
I
have
is
how
this
interacts
with
the
monthly
release
cycle
and
the
kickoff
in
particular,
so
I
know
you're
using
epics
and
that's
sort
of
even
a
different
element
to
it.
But
setting
epics
aside
the
on
the
you
know:
I
weigh
whatever
data
cache.
Okay,
I'll
stop
my
head,
I'm,
not
sure
the
we
have
to
know
roughly
where
the
cut
line
is
so
like
when
I
was
talking
about
my
process
where
engineering
breaks
it
down
and
like
it's
a
very
accurate
cut
line.
A
I
use
that
then
to
know
roughly,
what's
going
to
make
it
in
the
kickoff.
With
this
process,
it
seems
like
you're
more
doing
that
as
the
milestone
progresses.
So
how
do
you
know
what
the
cut
line
is
and
also
who
makes
the
call?
Is
it
the
engineering
manager
or
like
who's
who's
deciding
what
the
cut
line
is
for?
What's
included
in
the
kickoff.
B
So
I
do
this,
I
mean
I.
Think
from
like
this
is
actually
one
of
the
big
challenges,
because
this
machinery
here
is
essentially
continuous
right.
It
never
really
stops
right.
It
just
continues
ideally
right
and
we
deliver
things
at
different
points
in
the
month
right.
So,
for
example,
let's
say
I
have
hope
that
one
of
my
my
epics
that
didn't
actually
make
it
into
12.4
will
be
done
in
let's
say
a
week
or
so
right.
So
then
you
know
I'm
pretty
confident
that
that
will
make
it
for
other
things.
B
B
This
is
one
of
the
challenges
with
this
right,
because
our
release
timeline
at
the
moment
is
aligned
to
our
product
development
timeline
yeah,
and
it
was
certain
extent,
my
like
or
the
process
we
use
in
geo
is
decoupled
right.
It's
like
we
because
it's
continuous,
like
things
can
happen
like
throughout
the
entire
month
and
then
what
I
essentially
do
and
that's
kind
of
similar
to
what
happened
with
you
is,
let's
say
a
week
before
the
actual
release.
I
have
a
pretty
good
understanding
of
where
we
are
like
with
regards
to
some
of
the.
B
So
if
the
deliverable
ethics
and
I
can
then
speak
with
Rachel
and
say
like
we're
pretty
confident
that
this
is
going
to
to
actually
make
it,
you
know
I
write
my
the
East
Coast
item
right
and
then
that
that
turns
out.
We
okay,
but
it's
a
it's.
A
challenge.
I
haven't
really
figured
out
the
milestone
stuff
yet
and
I'm
also
conscientious.
That,
for
example,
the
way
we
work
here
in
the
absence
of
being
able
to,
for
example,
include
epics
in
the
kickoff
document
means
that
I
highlight
a
bunch
of
issues.
A
B
B
A
B
Compare
like
historically
like
I've,
seen
like
my
kickoff
items,
are
very
short
right.
Usually
I
have
like
two
or
three
things
in
there.
That
are,
you
know
like
more
chunky
like
well,
then
I
don't
want
to
give
the
impression,
as
if
we
don't
iterate
right,
but
it
is
not
a
long
list
of
things.
I
did
it's
often
sort
of
a
higher
a
higher
level
statement.
A
Well,
maybe
that
makes
sense,
get
take
the
direction
label
off
of
so
many
things
that
we're
doing
now
and
focus
on
like
the
bigger,
clear
deliverables
that
are
worth
talking
about,
and
maybe
that
can
help
balance
that
the
kickoff
and
doesn't
need
to
be
quite
as
accurate
in
terms
of
you
know
down
to
the
the
issue.
What
you're
gonna
be
delivering
yeah
and
I
think
there's.
B
B
We
didn't
actually
get
through
all
issues
for
this
ethic,
for
the
12.4
release
and
then
I
had
a
discussion
with
engineering
and
said
like
oh
okay,
let's
down
scope
and
like
is
it's
what
we
have
already
something
that
we
can
talk
about
and
live
as
customers
value,
and
we
want
to
actually
write
about
and
we
agreed
and
then
we
said
like
okay.
This
is
fine,
that's
actually
like
say
yes,
this
is
this
is
what
it
is
and
the
other
things
can
come
a
little
bit
later.
So
yeah.
B
So
let's
say
four
hours
a
month
at
least
about
this
and
so
I
think
that's
actually
really
powerful,
because
we've
had
quite
a
few
instances
in
the
past
where
we
set
out
to
do
something
and
it
turned
out
to
be
really
not
a
good
idea
right
or
maybe
too
large
or
like
whatever
it
was,
and
then
we
could
course
correct
pretty
quickly
and
I.
Think
that
that's
really
nice
I
enjoyed
that
a
lot
yeah.
B
Often,
but
sometimes
you
get
customer
issues
read
where
folks
are
having
some
trouble
with
something
and
I
want
to
be
in
a
position
where
I
can
say.
This
is
really
highly
like
important
right
now
to
do
and
have
the
Liberty
to
have
the
team
work
on
this
relative
plan
without
sort
of
disrupting
all
of
the
other
things
right
right,
because
that
was
I.