►
Description
When GitOps Meets UX - Cansu Kavili Örnek & Angels Dimitri Gutierrez, Red Hat
We had the ambition to create a sustainable platform to support development, lower the cognitive load of onboarding new applications and teams, and increase the products' visibility while giving developers the freedom to experiment. Sounds like a lot of work, right? Yet GitOps provided us fast and fine solutions for processes like self-service or onboarding! But that required some design considerations and a strong relationship between platform and developers. And that's where UX comes in!
Join us to talk about how to combine tech and UX practices to bring the best out of GitOps and create a state-of-the-art platform focusing on DevEx! Together we’ll address questions like:
*What are the benefits of working techies and UX together?
*How can we validate the ideas and merge them with devs feedback to create platform features and implement them through GitOps?
*How to simplify GitOps and make it accessible?
*How can we empower devs to own the approach and encourage them to contribute?
A
Yeah
welcome
everyone
for
our
talk.
First
of
all,
I
would
like
to
say
sorry:
we
like
these
colors
better,
that's
why
we
wanted
to
use
these
layouts,
so
we're
gonna
talk
about
some
ux
practices
and
how
we
blend
things
with
githubs
and
how
we
can
achieve
great
directs
together,
but
first,
let's
get
to
know
each
other.
B
A
My
name
is
janssoo,
I'm
a
site,
reliability,
engineer
in
open
animation,
labs
team
in
red
hat
and
today,
I'm
sorry.
I've
seen
really
great
some
techie
talks
before
us,
like
bunch
of
yaml
files
and
bunch
of
take
and
take
tools,
but
this
is
not
a
take
it
all
take
it
all.
So
I
wanted
to
give
a
disclaimer.
Maybe
I
can
show
you
my
yaml
file,
I'm
not
sure
I
don't
exactly
remember,
but
just
wanted
to
set
the
scene,
and
this
is
what
we're
gonna
actually
talk
for
the
next
20
minutes.
A
So
we
want
to
talk
about
how
ux
and
githubs
can
actually
work
together
by
some
myths
that
we've
been
observing
with
our
customers,
and
we
have
this
thing
called
show.
Nutella
we're
gonna
also
share
a
customer
experience
and
a
recent
engagement
that
we've
completed
with
this
topic
and
also
we
wanted
to
touch
a
little
bit
of
platform
as
a
product
concept
that
we
really
seen
it's
getting
really
increased
interest
in
the
in
the
in
this
ecosystem.
B
B
Oh
nice,
let's
see
someone
it's
perfect!
Thank
you,
then.
I
will
ask
you
later
on
next
slide,
please.
So
I
like
to
explain
this
kind
of
story
to
understand.
What's
more
about
the
user
experience
design
so
think
about
the
worst
things
of
staying
in
a
hotel.
I
have
a
friend
of
mine
who
used
to
travel
a
lot
because
of
work
and
he
was
staying
at
the
hotels
and
every
time
he
came
back,
he
was
complaining
about.
B
I
don't
know
the
bed,
the
breakfast
the
service,
whatever
it
was
and
one
day
it
was
very
funny
because
he
came
to
us
and
he
said
you
won't
believe
what
happened.
Someone
brought
him
a
pillow
menu.
It
was
in
front
of
him
with
the
receptionist
and
he
was
like
okay.
What's
this
and
the
receptionist
that
said,
okay,
you
can
choose
with
whatever
pillar
you
want
to
try
we'll
just
bring
it
to
the
hotel
room.
You
can
try
them
and
then
you
can
bring
the
rest
to
us
if
you
don't
want
them.
B
So
at
the
end,
he
had
such
a
nice
experience
that
kills.
He
always
remember
that
hotel.
He
always
will
explain
that
the
story-
yeah,
no,
you
can
continue
so
at
the
end,
this
is
a
kind
of
the
linux
loop
that
we
use.
It's
about
the
thing
my
check
and
also
in
here
you
can
see
it's
a
kind
of
hypothesis
statement
that
I
did
for
this.
So
at
the
end
they
started
to
see
that
it
was
about
reviews
about
the
hotel.
B
They
were
not
happy
so
maybe
because
of
that
they
started
to
do
a
kind
of
a
research
with
qualitative
and
quantitative
data,
and
they
proposed
this
solution
and
then
propose
it
to
the
business.
It
was
good.
It
was
great.
They
had
the
budget
at
the
end.
They
check
it
with
with
the
user
they
test.
It-
and
they
saw
it,
was
better,
maybe
for
the
next
time
they
will
have
the
pillows
in
the
room.
B
A
Meet
number
two
creating
an
amazing
developer.
Experience
requires
all
these
fancy
ui
and
a
big
team
that
needs
to
support
them
like
this
kind
of
consoles
that
you've
been
all
seen
in.
I
don't
know
aws
google
cloud
think
about
it
when
we
work
with
our
customers,
when
we
talk
about
developer
portal
or
developer
experience,
they
all
think
about
these
examples.
These
hyperscaler
examples
and
they
think
that,
like
they
need
a
lot
of
time
to
build
something
like
this,
but
actually
the
reality
is
that
what
is
important
is
that
you
need
to
this.
A
A
And
it's
it's
important
that,
but
you
you
need
to
discover
just
enough
to
identify
your
developer's
pain
point,
identify
what
they
can
help
you
and
then
deliver
it
and
then
go
over
the
loop
to
test
with
them
to
see
what
you
discovered,
but
you
delivered
is
really
addressing
their
problem
and
that's
really
important
to
balance
work.
You
don't
really
go
to
a
big
bank
building
a
cathedral.
B
Number
three:
so
when
building
the
platform,
we
know
our
users
needs
and
we
don't
need
to
talk
to
them.
So,
most
of
the
time
we
see
the
next
slide,
so
we
think
if
we
build
it,
they
will
come.
We
will
wait
that
they
will
put
their
applications
on
and
they
will
deploy
everything
in
the
platform.
But
the
reality
is
that's.
A
Not
what
happens
like
it's
two
weeks
ago,
I
was
in
brussels
talking
with
a
customer,
and
there
was
this
platform
engineer
was
saying
that
oh
we've
been
focusing
on
this
field
in
this
great
platform
for
developers,
but
they're
just
not
coming
and
just
like
deploying
their
application,
and
then
I
was
talking
with
developers
and
they
were
saying.
Oh
yeah.
A
We
are
waiting
for
the
platform
to
be
ready
for
us
so
that
I
can
deploy
it,
but
they
were
not
talking
each
other,
it's
just
because
they
don't
know
what's
their,
what
they
expect
from
each
other.
So
it's
when
you
have
such
sort
of
like
map
talking
with
your
ant
users,
even
though
they
are
internal
users,
you
got
this
empty
cluster
empty
cluster
problem.
What
we
call
they
just
don't
come
they
don't
come,
so
you
might
think
that
yeah
yeah.
That
sounds
familiar
this
kind
of
thing,
so
what
you
guys
are
suggesting.
A
So
we,
what
we
suggest
is
we
say
plant
your
ux
ux
designer
with
your
developers
and
treats
your
platforms
as
a
product.
So
what
we
mean
in
that
actually,
so,
if
you
think
about
these
classical
cloud
native
organizations,
we
have
this
classical
three
layers:
infrastructure
layers,
platform,
layer
and
application
layer,
and
what
we've
seen
in
our
customers
generally
is
that
they've
been
in
platform
engineered
layers.
A
We've
seen
these
like
keep
increasing
cognitive
law,
because
previously,
if
you
think
that,
like
you,
write
your
java
code,
picked
it
up
and
throw
over
some
wall
and
someone
else
is
tested,
someone
else
has
run
it
operate
it
in
the
different
environments.
But
now
we
have
this
with
the
cloud
native
approach.
We
say
this
like
engineers
should
be
like
t-shaped,
it's
having
some
sort
of
a
depth,
knowledge
of
some
topic
and
a
breath
of
knowledge,
a
couple
of
knowledge
so
that
they
can
build
their
thing.
They
can
own
their
thing.
A
They
can
run
their
thing,
but
what
we've
seen
in
the
reality?
Actually
we
sort
of
created
this
rectangular
shape
engineers
like
what
we
call
these
like
mythical,
mystical,
unicorn
type
of
engineers.
We
expect
them
to
do
everything
at
that
moment
in
the
in
the
enough
depth
of
knowledge
to
run
their
thing
test.
Their
things
create
like
build
their
thing,
and
production
and
etc,
and
that
creates
a
huge
cognitive
load
for
them
that
create.
They
eventually
lead
some
sort
of
burnout
type
of
feeling.
A
So
what
we
are
suggesting
is
that,
when
it
comes
to
platform,
is
that
like
creating
some
services
to
take
those
kind
of
load
from
developers,
but
not
taking
the
responsibilities
but
delivering
some
sort
of
capabilities
delivering
some
sort
of
services
for
them
to
help,
they
have
to
do
their
work
and
the
way
that
we
actually
address
this.
Has
anyone
read
team
topologies
in
here
or
devops
topologies,
which
is
the
odd
word?
A
That's
a
great
book
that
we
highly
suggested.
We
totally
advocate
about
this
book,
so
this
book
is
talking
about
the
separating
of
concerns
and
how
you
can
organize
your
teams
for
this
cloud
native
of
development
methodology,
and
it
has
some
sort
of
great
team
types
and
as
red
hat,
we
usually
work
like
an
enabling
teams
for
the
customers.
A
So
we
help
them
to
enable
enable
our
customers
with
our
technology,
with
our
ux
practices
and
all
and
the
problem
we
are
trying
to
solve
in
here,
actually
creating
the
right
platform
to
fit
for
purpose
so
that
it
can
be
like
it
can
be
a
great
platform
for
developers
that
they
can't
raise
this
and
they
just
come
and
use
it.
So
we
are
what
we
are
trying
to
focus
is
building
the
capabilities
like
let's
say:
psych,
reliability,
engineering
or
helping
them
to
practice
their
own
github
space.
A
They
because
you've
been
seeing
bunch
of
different
github
stores
during
the
day,
you've
seen
bunch
of
different
different
ways
to
apply
these
different
tools
like
customize,
home,
etc.
What
we
want
developers
to
they
want.
We
want
them
to
enable
with
this
approach,
and
we
want
them
to
practice
this
approach
and
while
doing
it,
we
don't
want
them
to
recover
rediscover
the
world
again.
A
So
if
you
can
provide
those
services,
like,
let's
say,
observability
as
a
service
logging
as
a
service
data
as
a
service,
you
take
that
load
from
them
and
you
help
them
to
actually
focus
on
what
is
important,
which
is
the
business
business
business
problem,
what
they're
trying
to
solve.
So
what
we
are
trying
to
do
actually
in
here.
B
Is
to
apply
a
product
mindset
and
this
might
sound
quite
fluffy
and
it
can
be
confusing,
but
there's
the
next
slide
about
the
this
venn
diagram
that
we
use
while
describing
what's
the
product
and
which
phases
or
which
things
it
has
to
have
in
balance.
So
here
you
can
see
that
it
has
to
be
desirable.
It
has
to
build
a
product
that
customers
want,
it
has
to
be
viable,
it
has
to
be
built
the
right
thing
and
at
the
end
it
has
to
be
feasible.
It
has
to
be
the
thing
right.
B
A
Tinnitus
filebook
platform-
that's
the
most
important
thing
in
here,
because
your
platform
doesn't
have
to
be
all
this
fancy
ui
or
anything.
It
just
can
be
a
yaml
file
which
we've
been
delivering
this
it's
up,
which
we've
been
using
this
as
a
starting
point
for
our
customers
for
to
for
last
year,
and
we
also
actually
deliver
a
talk,
technical
talk,
how
we
apply
implement
this
with
a
leading
airline
company-
and
let's
say
this
like
that,
so
we
always
use
we
start
with
github's.
A
We
put
a
github's
approach
to
how
to
onboard
the
applications,
how
to
onboard
the
teams
and
have
some
sort
of
scaffolding
in
the
behind.
So
it
doesn't
have
to
be
a
fancy
ui
because
your
developers
are
already
interacting
with
kids,
you
already
interacting
with
kids.
So
why
not
start
from
there?
Why
not
leverage
the
github's
practices?
Why
not
leverage
the
benefit
of
githubs
in
order
to
import
your
applications
or
upload
onboard
the
new
people?
A
So
you
might
think?
Okay,
I
don't
believe
you
but
continue.
This
is
what
we
call
shown
hotel
so
last
winter.
Actually
we
were
in
up
up
north
right
below
the
arctic
circle.
In
a
norwegian
we
were
working
with
this
norwegian
company,
it's
a
highly
regulated
company
and
they
wanted
to
build
a
state-of-the-art
platform
in
order
to
in
order
to
improve
their
developer.
Experience
improve
their
time
to
market,
so
they
engage
with
us
and
they
have
different
type
of
developers.
A
So
there
are
not
that
not
all
the
developers
are
the
same,
so
they
have
these
developers
that
are
looking
for
just
take
the
problem
away
from
me.
Just
give
me
the
bit
so
that
I
can
do
my
job,
but
they
have
also
some
sort
of
creative
developers,
but
that's
what
we
call
them.
They
want
to
innovate.
They
want
to
experience
with
the
new
tools.
They
want
some
space.
They
want
some
more
responsibility,
so
the
company
was
looking
to
address
a
platform
to
work
with
both
of
them
so
just
to
set
the
scene.
A
This
is
their
let's
say
the
old
cicd
pipeline.
So
it
was
like
a
black
box
for
the
developers.
They
were
just
I'm
pushing
their
codes
and
hoping
that
it
would
it
would
deploy
somewhere.
Actually,
their
ux
designer
did
a
great
analogy
for
this.
While
they
were
introducing
us
on
their
current
state,
ux
designer
said
that
it
is
like
a
water
slide
in
the
pool
like
the
developers
put
in
their
child
and
hoping
that
they
would
come
out,
but
they
they
don't
know.
A
A
B
We
did
is,
we
also
did
the
platform
as
a
product
workshop,
which
is
a
workshop
that
we
developed
it's
a
half
day
and
in
here
we
set
the
scene
because
it's
a
quite
a
new
concept,
so
we
were
discussing
together
with
the
customer.
What's
a
platform
what's
a
product
for
them,
how
all
of
this
can
get
together
and
also
actually
here
you
can
see
the
venn
diagram
that
I
just
saw,
and
it
was
very
important
for
us
to
get
data
linen
before,
starting
to
build
a
platform.
A
And
this
is
one
of
the
practices
that
we
use.
It
is
called
event
storming
coming
from
domain-driven
design,
so
the
company's
ambition
was
to
create
such
platform,
like
have
a
high
trust
in
the
platform
that
even
the
one
person
that
it
starts
in
the
like
a
first
day
in
the
in
their
company,
they
can
deploy
to
the
production.
So
this
is,
you
always
set
a
scenario
in
even
storming,
and
that
was
our
scenario
like
the
one
where
mary
deploys
the
production
on
her
first
day.
A
So
what
we
did
in
here,
we
identify
what
sort
of
pain
points,
what
sort
of
things
that
developers
needs
in
order
to
achieve
this
and
how
we
envision
for
developers
to
interact
with
the
platform.
So
there
are
a
couple
of
questions
that
we
identify
while
discussing
with
developers
and
the
platform
people
and
the
business
people
in
the
same
room,
and
one
of
the
points
was
like.
A
Okay
developers
need
a
sandbox,
and
at
the
that
moment
they
didn't
have
any
sandbox
environment,
so
they
were
working
locally
and
the
cluster
was
some
other
story
completely
or
like.
How
can
what
sort
of
branching
strategy
they
should
have,
or
every
developer
has
their
own
way
of
doing
things,
which
is
fine?
What
should
be
addressed
in
the
platform.
B
So
in
here
you
can
see
what
we
did
spring
by
spring
in
a
kind
of
a
research
perspective,
as
chancellor
was
saying
previously,
they
wanted
this
kind
of
sandbox
or
deaf
environment,
but
we
didn't
know
what
it
was
about,
what
it
has
to
have
inside
how
it
was
developed.
Why
do
they
want
it
or
how
would
they
use
it?
So
it
was
quite
interesting
because,
after
that,
I
think
we
just
point
down
the
project
and
the
whole
journey
of
it.
B
After
that,
we
also
took
in
consideration
about
the
onboarding
research,
how
it
has
to
be
all
the
stuff
provided
to
the
developer,
which
is
the
best
experience
for
them
things
like
that,
then
we
also
simplified
the
like
the
visualization
of
the
overall
process.
I
mean
in
a
sense
that
we
saw
the
architecture.
B
It
was
very
complex
with
a
lot
of
technologies,
but
we
also
needed
from
the
business
perspective,
to
be
consumable,
so
we
also
simplified
that,
and
by
the
end
we
organize
the
documentation
in
a
sense
how
it
has
to
be
organized
which
kind
of
information
the
device
expects
out
of
it.
Also
in
sections,
maybe
in
kind
of
in
a
architectural
information
I
would
say-
and
this
is
what
we
did
and
just
to
give
you
a
kind
of
a
ux
toolkit.
I
won't
talk
about
any
of
these
practices.
B
I
just
want
to
point
them
out
and
to
highlight
again
the
thin
phase,
which
is
about
the
research
in
where
we
really
talk
with
the
user.
We
empathize
with
them
and
really
we
really
see
the
pain
points
in
there.
Then
we
move
into
the
make
phase
in
where
we
synthesize
all
the
information
that
we
have
from
the
previous
phase
and
we
also
prototype
or
make
some
kind
of
process
or
something
that
we
really
need.
B
We
really
can't
put
the
hands
to
the
to
the
user
and
at
the
end,
of
course,
we
we
check
and
we
test
it
at
the
end.
What
we
want
to
all
of
this
process
is
bring
developers
to
the
platform
team
room
together,
so
they
work
together
and
really
re.
They
really
gather
the
feedback
that
really
needed
for
the
platform.
B
Also,
this
is
a
final
life
document.
It's
a
kind
of
a
user
journey
service
blueprint,
but
in
where
we
mapped
all
the
pain
points,
all
the
documentation
tasks,
all
the
touch
points,
and
also
the
users
in
here
and,
as
you
can
see
here,
the
metrics
it's
empty
because,
as
I
said,
it's
something
that
it's
live
and
afterwards,
the
customer
and
together
with
the
platform,
the
users
and
the
developers
they
define.
B
A
A
It's
like
it's
the
same
as
we
discussed
as
we
envisioned
and
getting
their
feedback
if
they
are
like
looking
for
something
like
takes
time
for
them
to
find
something
that
we
were
taking.
No,
so,
okay,
we
need
to
simplify
this.
We
were
mocking
some
stuff
and
going
back
to
them.
So
that's
that's
the
most
important
thing
you
need
to
bring
the
users
to
a
development
space.
You
don't
have
to
really
build
a
fancy,
ui
or
anything
or
or
you
don't
have
to
like,
like
dictate
a
github's
way
of
working
or
a
tool
for
them.
They.
A
They
are
good
enough
to
work
this.
It's
just.
You
need
to
simplify
the
process
for
them.
So
for
the
for
that
what
we
were
doing
as
platform
team,
we
were
providing
some
lego
bricks
to
them.
We
created
a
hand
chart
library
within
the
company.
For
example,
we
were
developing
some
mostly
most
used
hand,
chart
let's
say
but
putting
out
there
and
they
were
automatically
syncing
to
the
cluster
because
of
the
our
github
controller,
let's
say,
and
we
were
we
were
using
tekton
if
you
are
familiar
with
tekton.
A
Has
this
notion
of
cluster
tasks,
which
is
cluster
cluster-wide
available
tasks?
So
we
were
creating
some
cluster-wide
tasks
that
we
know
that
every
developer
would
need
like,
let's
say,
cloning,
the
gate
or
container
containerization,
or
I
don't
know
like
running
some
sort
of
home
package
harmless.
So
we
were
putting
creating
this
kind
of
tasks
openly
in
a
git
repository
and
we
were
thinking
those
kind
of
changes.
Whatever
is
the
new
task
is
coming,
throwing
it
up
on
the
cluster
and
developers
were
looking
at
this
open
like
they
can
see
it
easily.
A
A
So
this
is
an
example
of
these
cluster
tasks
that
we
created.
We
were
annotating
them
and
we
were
have
some
sort
of
versioning
system,
just
a
screenshot
from
a
cluster.
So
we
were
creating
this
for
them,
and
if
this
is
not
working
for
them
they
don't
they
just
don't
wait
for
anyone,
they
create
their
own
tasks.
So,
as
a
as
an
example
for
the
final
results,
it
was
transparent
for
them.
They
ever
empowered
how
to
onboard
their
applications,
how
to
run
their
pipelines,
how
to
what
sort
of
stages
they
should
have
in
their
pipeline.
A
It
was
obvious
to
them,
so
it
was.
They
were
easily
see
if
there's
a
problem.
They
were
easily
know
what
should
improved
or
because
of
these
kind
of
interviews
or
the
feedback
loops.
They
were
more
confident
to
come
to
the
platform
team
like
they
were
easy
to.
They
knew
how
to
communicate
with
the
platform
team,
so
they
were
speaking
the
same
language.
A
A
And,
as
I
said,
share
tools
really
help
them
to
share
the
speak.
The
same
language
like
git
is
the
biggest
shared
tool
in
the
moment
in
the
ecosystem
between
them
and
ops,
and
they
were
both
interacting
with
kit
when
they
were
identifying
their
own
things
on
tools
or
the
objects
as
yaml
files,
or
of
this
some
sort
of
plain
text
files.
A
It's
really
hard
time
to
facilitate
the
conversation
easily
like
it's
githubs
itself,
really
helped
us
a
lot
in
this
kind
of
in
this,
because
before
that,
a
couple
of
years
ago,
I
didn't
even
see
the
usage
of
kids
in
the
ops
teams.
They
just
some
sort
of
ansible
files
sitting
in
some
sort
of
folders
inside
may,
a
common.
I
said
the
common
server
like
of
developers
use.
A
So
it's
the
same
for
the
like
going
going,
the
same
for
observability
tools
or
the
logging
tools,
when
their
tools
are
becoming
more
common
and
common,
it's
really
helped
them
to
speak
the
same
language
and
they
create
that
feedback
loops
easily
and
again,
it's
all
about
empowering
devs
to
own
their
thing,
and
it's
all
about
bringing
their
knowledge
bringing
their
newly.
Let's
say
the
newly
created
things
experiencing
to
the
platform,
so
platform
is
not
something
that
now
a
platform
team
or
a
couple
of
people
building
on
the
site.
A
It
is
something
that
is
evolving
constantly
with
the
developers
feedback
with
their
input,
which
we
say,
hashtag
never
done,
because
it's
a
product
it
needs
to
get
evolved
over
time.
It
needs
to.
It
can't
keep
the
same,
because
if
you
think
about
the
products
products
spec
like,
if
you
think
about
a
product,
it
needs
to
be
like
it
needs
to
solve
a
problem
and
it
needs
to
evolve
over
time.
Otherwise
you
will
stop
using
it
if
it
doesn't
really
address
your
problems
anymore,
because
your
problems
also
change.
A
A
D
A
It
was
honestly
the
same
it's
for
me
because
it's
all
about
what
the
end
user
thinks,
what
the
end
user
feels,
what
their
pain
points.
What
sort
of
improvement
points
that
we
can
get
from
the
users?
It
was
the
same
honestly
like
angels,
were
it
just
was
doing
the
interviews
with
the
users,
and
we
were
on
the
side
taking
this
kind
of
notes.
It
was
just
like
the
same
that
the
user
using
the
app
it's
just
the
difference
like
if
you
don't
see
a
user
using
it.
A
It
was
a
phone
to
interact
with
it
was
using
the
keyboard
and
interacting
with
your
documentation
that
you
create
the
git,
the
git
repos
that
you
created.
So
it's
field
is
the
same.
The
outcome,
it's
just
the
tools
are
different,
but
the
way
that
we
were
doing
it
was,
I
think
it
was
the
same
yeah
anything
you
want
to
add:
yeah,
okay,
okay,
oh
sorry,
a.
E
A
Would
you
like
to
answer
that
slightly
the
first,
the
first
first
feedback
loop
yeah.
I
remember
that
a
couple
of
years
ago,
when
I
was
working
the
bank,
it
was
the
same.
I
just
took
my
laptop
and
went
to
the
developers
like
just
show
me
how
you
do
it
show
me
why
you
don't
do
this
like
we
started
to,
I
started
to
talk
with
dave,
but
later
on,
I
started
to
do
some
sort
of
brownback
sessions
within
the
company
like
open,
open-ended
like
come,
and
talk
with
us
ask
us
any
questions.
A
Here
is
a
new
capability
of
the
platform
that
I
want
to
display
and
they
started
to
join
it
regularly,
and
then
they
were
bringing
their
questions
and
you
see
actually
when
the
questions
are
actually
coming
from
some
sort
of
problems
that
difficulties
they
are
having,
while
interacting
with
the
with
the
platform.
So
you
start
to
actually
think
about
how
things
get
better.
But
honestly,
what
I
did
was
just
starting
the
conversation
with
them.
A
There
are
a
couple
of
practices,
help
you
to
facilitate
these
conversations,
either
virtually
or
or
face
to
face
that
we
can
maybe
point
point
out.
We
have,
we
have
a
website
called
openpracticelibrary.com.
Why
we,
I
mean,
is
the
community
website?
Is
it?
Has
all
this
kind
of
practices
about
discovering
the
work
you
need
to
do
and
some
sort
of
delivery
practices
and
some
good
foundational
practices?
There
are
a
couple
of
ux
practices
as
well
there.
That
might
be
help
you
to
have
this
kind
of
conversation
as
well.
Openpracticelibrary.Com
awesome.
C
C
A
A
We
sort
of
come
up
with
a
good
way
of
a
good
way
of
practice
get
ups
for
us,
and
it
was
just
like
the
talk
that
before
us,
showing
that,
like
you,
have
this
application
repository
and
you
have
a
github
repository
for
like
the
overwrite
values
for
the
different
values
per
environment
and
one
of
the
developers
just
say
that
I
keep
forgetting
about
this
repository
like
can
I
have
these
different
values
in
my
own
repository?
Is
that
possible,
or
or
just
or
it's
this
old
and
we're
like?
A
Okay,
that's
another,
maybe
thing
that
we
can
provide,
but
it
needs
some
discussion
before
platform
teams
like
we
want
do.
We
want
to
really
cover
this
edge
case,
or
is
it
something
that
we
can
say?
Okay,
you
can
do
it
this
way,
but
we
don't
really
provide
it
out
of
the
box
in
here.
So
we
started
the
discussion
and
we
realized.
A
F
A
Yeah
what
we
started
to
do
is
like
we
give
some
like
ready
to
use
templates.
Let's
say
like
you,
don't
have
to
understand
helm
or
you
don't
have
to
understand
github's
all
you
just
need
to
clone
these
templates
just
change.
The
name
list
put
your
application
name
and
just
it
would
just
work.
But
if
you
want
to
know
more
here
are
the
here
are
all
the
explanations
of
these
are
hr
documentations,
and
here
are
the
sessions
that
we
are
always
doing.
We
have
an
enabling
team
concept
in
companies
when
we
interact
with
companies.
A
So
we
look
for
like
easy
to
easy
to
use
blogs
like
just
copy
this
one.
It
will
work,
it
will
just
build
back,
deploy
your
application,
but
if
you
want
to
get
to
know
like
get
to
know
or
just
come
to
us
here,
is
our
room
or
join
our
brownback
sessions
write
a
slick.
We
always
give
this
kind
of
guidance
to
developers
too,
so
that
they
can
learn
more
if
they
want
to
learn
more
cool.
Thank.