►
Description
DOES19 London — Based on his work with Fortune 100 enterprises, Dr. Mik Kersten presents a new concept, the Flow Framework, which unravels the enigma of enterprise software delivery, providing an approach that helps organizations better understand the human and system dynamic that underpins their IT infrastructure.
Project to Product: Thrive in the Age of Digital Disruption with the Flow Framework: https://www.amazon.com/Project-Product-Survive-Disruption-Framework/dp/1942788398
Dr. Mik Kersten, CEO, Tasktop
Dr. Mik Kersten spent a decade creating open source developer tools before realizing that programing was not the bottleneck of large-scale software delivery. Since that time, he has been working on creating a model and tools for connecting the end-to-end software value stream. Prior to founding Tasktop, Mik created the Eclipse Mylyn open source project as part of his PhD in Computer Science, pioneering the integration of development tools with the delivery pipeline. As a research scientist at Xerox PARC, Mik implemented the first aspect-oriented programming tools for AspectJ. Mik is the CEO of Tasktop and loves working with IT and thought leaders on transforming how software is built.
DOES19 London
DOES 2019 EUR
DevOps Enterprise Summit
https://events.itrevolution.com/eur/
A
One
of
the
themes
that
have
showed
up
in
every
plenary
talk
over
the
last
two
days.
Is
this
notion
of
projects
to
product?
The
next
speaker
is
dr.
McKeon,
who
literally
wrote
the
book
on
it.
His
book
project,
the
product
is
generally
a
book
that
I
admire
and
envy
when
I
first
read
the
draft
of
it.
My
first
reaction
was
I
wish.
A
I
were
smart
enough
to
have
written
a
book
like
this
I
think
it's
a
very
important
book
because
it
provides
at
last
a
language
that
can
help
span
the
business
community
and
the
technology
community
and,
in
his
talk,
he's
actually
going
to
also
provide
historical
frame
that
suggests
us
anew
as
a
part
of
a
new
manager
mode
that
gets
created
only
once
or
twice
in
the
century.
So
without
further
ado,
dr.
Macpherson.
B
Thank
You,
Jean
and
hello,
everyone
so
for
the
first
decade
of
my
career,
I
spent
all
of
my
time
in
the
code
and
writing
code
and
coming
up
with
new
programming
technologies.
When
I
was
working
at
Xerox,
PARC
and
new
kinds
of
development
tools,
because
I
actually
thought
we
could
code
our
way
out
of
pretty
much
any
problem
and
the
really
interesting
things.
I
learned
as
we
were.
Building
these
tools
were
making
us
more
and
more
productive
and
keeping
more
and
more
of
our
time
in
the
code.
B
B
As
a
whole
and
survive
what's
happening
in
terms
of
the
this
era
of
digital
disruption,
so
I'm
gonna
go
into
some
depth
on
the
flow
frame
of
today
tell
a
little
bit
about
the
flow
metrics
and
tell
you
a
few
of
the
stories
in
the
book
project
a
product
now
the
first
story.
This
was
this.
This
was
the
one
that
really
completely
changed
my
worldview.
This
was
the
first
time
I
had
discussions
with
a
CIO,
and
this
was
when
Nokia
was
trying
to
transform
itself
so
Nokia
realized
a
year
before.
B
B
That
was
that
was
my
phone
up
there
with
shiny
beautiful
stainless
steel,
buttons
very
elegant
devices,
but
with
a
fairly
small
and
very
limited
digital
experience,
and
they
realized
that,
in
order
to
compete
with
Apple
coming
onto
the
market,
where
the
phone
was
going
to
be
all
glass,
it
wasn't
just
about
being
the
source
glass
capacitive
screens
they
were
going
to
need
to
be
able
to
innovate
in
software.
The
entire
user
experience
was
now
going
to
be
based
purely
on
software.
B
With
these
devices
it
was
just
basically
you
know:
things
were
turning
into
a
glass
rectangle
and
so
at
a
leadership
level
at
a
board
level,
they
realized
back
in
2006
that
they
needed
transform.
We
started
working
them
with
them
in
2007
and
certainly
apply
some
of
the
concepts
that
we
learned
in
open
source
and
connecting
developers
to
agile
tools
on
connecting
the
value
stream
at
Nokia.
So
I
got
to
watch
this
firsthand
and
I
got
to
see
also
that
Nokia
was
becoming
through
this
process,
a
poster
child
for
how
you
scale,
agile.
B
They
brought
in
the
best
consultant
Dean
Leffingwell.
Was
there
the
creator
of
the
scaled
agile
framework,
Ken
Schreiber?
Was
there
helping
them
train
everyone
in
scrum,
and
the
entire
agile
transformation
was
actually
being
measured
because
it
was
such
a
key
part
such
a
key
thing
to
the
business.
So
I
remember
when
I
was
at
the
agile
conference
in
Chicago
and
Nokia
was
up
on
every
slide.
B
That's
the
absolute
proof,
point
that
agile
works
at
large
scale
and
some
of
the
ways
that
they
were
testing
that
agile
was
actually
being
adopted
across
Nokia
was
with
the
Nokia
test
trade
by
Nokia,
Siemens
Networks,
which
basically
checked
if
teams
were
using
the
agile
tools
and
if
they
were
trained
on
scrum
and
what
actually
what's
happening
is
that,
while
all
this
was
going
on,
the
business
side
was
thinking.
Everything
was
on
track
because
of
the
way
that
they
were
measuring
their
agile
transformation.
B
So
this
is
a
profound
lesson
to
me
as
I
realize
that
measuring
the
wrong
things
that
measuring
just
this
one
silo
and
using
these
proxy
metrics
of
our
people
trained
on
agile,
are
they
using
my
a
dull
tool,
the
one
that
we
deployed
completely
derailed
this
transformation
and
end
up
destroying
this
company?
So
I
think
nothing
illustrates
this
kind
of
local
optimization
of
your
Valley
Stream
than
John
smart
slide
from
this
conference
last
year.
Where
you
can
see,
we
are
so
freakin
agile
transformations
on
track.
B
But
meanwhile,
if
you
take
the
customers
perspective,
so
for
gnocchi,
they
would
need
to
innovate
on
new
kinds
of
widgets
on
bringing
an
app
store
to
market.
They
had
no
chance
of
doing
it
in
the
window.
That
was
meaningful.
Now
that
was
back
in
around
2007
and
the
concern
that
I
started
increasing
getting
over
the
last
few
years
is
that
not
enough
has
changed
so
as
I
worked
more
closely
with
large
enterprise
organizations.
Also
very
motivated
and
very
driven
to
succeed.
B
Individual
transformations
I
realized
that
there
was
there
were
more
fundamental
problems,
so
this
is
another
story
of
a
top
25
bank
by
revenue.
It
was
on
its
third
transformation.
The
first
two
were
agile
transformation.
This
one
was
the
DevOps,
so
everyone
was
sure
was
found
to
succeed
and
even
more
interestingly,
the
budget
for
this
transformation
was
approximately
a
billion
dollars,
an
incremental
billion
dollars
for
this
digital
transformation.
B
It
sounds
like
a
lot,
but
you'll
actually
here
see
a
bigger
number
and
in
a
couple
of
slides,
the
thing
I
learned
was
that
the
way
this
transformation
was
being
tracked
was
yet
through
another
set
of
proxy
metrics
of
activities.
Everything
was
being
tracked
as
project
plans
which,
to
me
was
completely
foreign
because
coming
from
open
source
and
from
this
product
mentality,
we
always
tracked
results
how
people
were
adopting
what
we
were
doing,
how
much
we
were
delivering.
B
Not
this
year-long
plan
of
different
activities
and
and
costs
and
budgets,
and
the
amazing
thing
is
that
two
years
after
the
transformation
was
that
sorry,
two
years,
the
transformation
after
its
completion,
things
were
successful
in
terms
of
the
budget
results
in
terms
of
the
project
plans
being
hit
everything
with
green,
but
that
green
was
an
illusion
right.
It's
this
watermelon
effect
where,
in
the
project
plan
everything
looks
green,
you
look
inside
and
everything's
actually
red.
B
You
interviewed
any
person
on
the
business
side
on
the
or
on
the
IT
side,
and
they
were
saying
that
we're
actually
delivering
less
than
before,
because
again,
these
proxy
metrics,
these
cost
centers
and
project
management
as
the
guiding
force
connecting
the
business
and
the
technologists
were
just
fundamentally
broken.
So
the
bottom
line
is
that
there's
something
wrong
there
and
we
now
have
companies
on
the
market,
but
I've
been
on
the
market
for
a
while
they're
doing
it
right.
B
So
if
you
compare
the
stock
price
change
of
this,
this
particular
decade
of
Amazon,
who
has
their
product
value
streams,
aligned
to
their
organizational
structure
and
to
pizza
teams
to
their
software
architecture,
micro
services-
you
can
see
the
basic
created
a
disruption
machine.
The
tech
giant's
have
done
this
properly.
It's
they're
just
get
to
choose
what
market
they
go
into
next.
Meanwhile,
those
other
companies
have
long
realized.
B
But
if
you
have
reap
those
benefits
so
we're
talking
about
the
trillion
dollars,
I
saw
I
felt
like
a
person
who
saw
a
billion
dollars,
go
up
in
flames
at
this
one
Bank
you
take
this
collectively.
It's
a
trillion
dollars
and
very
few
are
seeing
the
results.
So
there's
just
something
very
wrong
with
this
approach,
because
of
course,
all
these
organizations
are
very
motivated.
These
are
really
good
people
with
good
intentions,
trying
to
succeed
not
trying
to
lose
their
jobs
or
have
their
companies
decline
in
the
process.
So
I
got
to
wondering
as
I
was.
B
Writing
in
the
book
is
actually
in
the
middle
of
the
book.
Is
you
know
this
rate
of
turn,
this
rate
of
disruption,
the
fact
that
we're
all
with
technologies
changing
and
cloud
runtimes
and
container
orchestration
methods
changing?
What
feels
like
an
almost
on
a
weekly
basis
is,
is
this
normal
is
this
is
what
works
mean
in
our
careers,
normal
and
Jean
pointed
me
at
the
work
of
dr.
Claudia
Perez.
So
in
2002,
dr.
B
Perez
published
a
book
called
technological
revolutions
and
financial
capital
where
she
actually
zoomed
out
for
us
to
look
at
the
last
five
technological
revolutions.
So
there
have
been
five
of
these.
The
Industrial
Revolution
steam
in
railway
is
still
in
heavy
engineering,
oil
and
mass
production
and
what
we're
living
today,
the
age
of
software
in
digital
and
the
really
fascinating
thing
about
her
work,
is
that
she
identifies
in
the
in
her
models
that
each
revolution
has
two
distinct
periods.
B
At
that
point,
you
had
over
300
car
startups,
which
we
don't
remember
the
names
of
today,
but
over
time,
the
new
giants
who
master
that
new
means
of
production
form,
and
we
have
those
giants
today.
Those
giants
foremen
and
we
end
up
with
this
thing,
called
the
turning
point
where
the
just
the
creative
destruction
accelerates
and
accelerates
the
few
companies
like
the
Fords
and
the
GM's
in
the
last
revolution.
B
Who've
mastered
this
new
means
of
production,
accumulate
more
and
more
of
the
world's
wealth
and
we're
today
at
the
point
where
the
fans
of
Facebook
Amazon,
Apple,
Netflix,
Google
Microsoft,
as
well
as
the
bats,
so
Alibaba
by
doing
$0.10,
their
combined
worth
is
the
equivalent
of
the
GDP
of
Japan.
So
those
nine
companies
form
a
combined
wealth
of
the
third
largest
economy
economy
on
the
planet
and
their
continue
to
actually
grow
and
disrupt
further.
B
So
now,
what's
happened
is
in
past
revolutions,
there's
after
the
turning
point,
there's
a
dissemination
of
technology,
and
this
is
why
I
think
this
conference
and
what
you
heard
gene
say
earlier
today
about
this
concert
being
being
for
the
horses,
not
just
the
unicorns
and
that
tech
trying
to
figure
this
out.
That's
what
brings
about
the
deployment
period
where
the
rest
of
the
world
economy
actually
learns.
These
new
means
of
production,
masters
and
scales
them.
B
This
is
actually
where
inequality
and
past
periods
has
actually
gone
down
and
we
get
the
much
richer
and
wealthier
economy,
and
how
are
the
parents
actually
to
call
these
things
the
golden
ages?
So
the
question
really
is:
how
do
we
collectively
work
to
get
through
this
turning-point
get
to
the
next
golden
age
and
make
your
company
and
your
work
a
key
part
of
that,
and
so
hint
is
that
we're
not
going
to
do
it
with
more
project
management,
because
in
each
of
these
revolutions
we've
come
up
with
different
management
methods.
B
There
are
factory
systems,
subcontracting,
Taylorism
Fordism,
and
each
of
them
helps
with
that
particular
means
of
production.
Now,
as
it
turns
out,
project
management
came
from
Taylorism.
It
came
from
being
treating
people
as
interchangeable
and
fungible
cogs
at
a
large
machine
which
you
can
actually
do
if
you're
building
bridges
or
data
centers
or
really
large,
large
buildings
and
things
of
that
sort.
But
Henry
Ford
realized
it
doesn't
work
when
you're
doing
more
complex
work.
B
He
realized
he
actually
needed
to
invest
in
his
staff,
and
Fordism
came
about
so
trying
to
use
Taylorism
for
creative
work
for
news
project
management
and
assuming
you
have
that
much
certainty
over
two-year
multiple
year
projects
is
just
a
completely
flawed
approach
to
innovating,
to
surviving
this
turning
point
in
the
age
of
software.
So
to
get
a
better
sense
of
this,
I
actually
went
and
visited
one
of
our
key
customers
and
tried
to
understand
how
that
company,
how
be
the
BMW
group
had
survived
the
last
turning
point
in
the
age
of
manufacturing?
B
They
are
one
of
the
companies,
the
brands
that
made
it
and
not
so
much
in
terms
of
how
they
did
the
production
itself,
but
how
the
business
and
production
were
connected,
and
it
was
an
absolutely
fascinating
journey.
You've
heard
a
little
bit
from
BMW
yesterday
on
terms
of
the
IT
side.
This
is
purely
on
the
car
production
side,
where
I
went
into
their
most
advanced
plant
with
the
NW
Leipzig
plant,
where
the
one
in
two
series
car
that
cars
are
made
and
those
cars
come
off.
B
These
are
from
Jamal
marks,
book,
Lean,
Thinking
and
everything
at
the,
but
the
plan
embodied
these
even
the
architecture,
the
the
building
from
space
you
can
see
the
one
in
the
two
series
assembly
line
is
very
long.
It's
extensible
the
buildings
actually
get
extended
as
new
manufacturing
steps
got
added
and
it's
completely
automated.
B
An
enterprise
IT
everything
was
up
around
these
integrated
production
lines
and
no
notion
of
disconnected
tool
chains
you
can't
have
disconnect,
and
in
that
kind
of
value
stream
everything
was
managers,
products
and
prices
are
connected,
the
business
value
rather
than
projects.
Everything
was
architect
around
flow.
So
there's
not
one
big
large
enterprise
architecture
that
the
I-89
three
shared
there.
Everything
was
architect
around
the
flow
needs
of
that
particular
value
stream,
not
technology
lawyers,
not
separating
the
persistence
from
the
from
the
data
layer
and
so
on
and
from
the
engagement
layer.
B
Everything
was
optimized
end
to
end,
so
we
always
start
end
to
end
with
customer
centric
measures
like
lead
time,
which
happened
to
be
the
best
predictor
of
car
company
performance
in
the
market,
because
of
course,
they
embody
what
the
customer
experiences,
rather
than
optimizing
in
silos,
and
looking
how
fast
that
we
in
closing
user
stories
and
everything
was
measured
first
in
terms
of
business
results
rather
than
these
proxy
and
silo
metrics.
So
the
key
thing
I
learned
from
this
is
that
we
need
to
apply
these
concepts
of
flow
to
software
delivery.
B
But
to
do
that,
we
need
to
agree
on
what
flows
through
software
value
streams,
and
we
simply
haven't
done
that
through
academia
in
the
industry.
We
know
it's
not
function,
points
on
lines
of
code,
but
we
need
a
common
definition
of
what
flows
where
the
flow
items
are,
and
that's
the
key
point
of
the
flow
framework
and
remember
flow
is
what
customers
pull?
They
don't
pull
releases.
They
pull
what's
in
the
releases,
they
want
your
features.
B
They
want
fixes
to
defects,
that'll,
make
them
choose
your
solution,
the
features
and
the
quality
of
it
rather
than
a
competitive
solution.
Risks
are
now
a
core
part
of
software
delivery,
so
making
sure
that
we
have
data
privacy
and
security
as
key
to
the
market
and
to
our
customers
and
technical
debts
are
also
a
first-class
part:
infrastructure
debt
and
resolving
those
that
is
the
first-class
part
of
software
delivery.
As
we
implement
more
features,
we
actually
build
up
debts
through
taking
shortcuts
to
get
those
features
to
market.
B
So
these
are
the
four
flow
items,
and
these
are
mutually
exclusive
and
comprehensive.
Exhaustive
they're
me
see,
which
means
these
represent
all
of
the
work.
That's
done
in
yourself
to
value
streams,
so,
if
you're
using
something
like
the
scale,
data
frameworks
which
has
a
very
rich
and
refined
taxonomy
over
of
work
items
and
you
might
have
dozens
of
those
each
of
those
work
items
actually
maps
into
one
of
these
flow
items.
B
So
I'll
give
you
a
quick
example
now
of
what
this
looks
like
and
when
I
was
first
preparing
these
slides,
Jean
told
me
make
you
need
to
explain
the
flow
items
just
with
up
and
down
arrows,
because
that's
all
executives
will
pay
attention
to
so
this.
This
will
explain
everything
purely
through
up
and
down
arrows.
B
Think
back
of
your
last
big
push
to
market
and
pushes
to
market
and
those
those
releases
that
you're
putting
out
there.
Success
is
really
dependent
on
the
features
that
you
deliver
right,
because
that
is
what
customers,
what
users
consume,
as
you
do
that
and
as
the
business
is
wanting
more
and
more
of
those
features,
debts
and
risks.
Just
rise
quality
goes
down,
and
then
this
interesting
thing
happens
that
defect
works
goes
up
and
up
to
the
point
where
you
can
get
into
a
death
spiral
where
defect
work
consumes
all
over
the
value
stream.
B
The
business
gets
extremely
frustrated
because
feature
works
goes
down
to
zero,
and
this
is
exactly
the
situation
that
Nokia
found
itself
in
that
developers
understood
why?
Because
they
were
building
on
a
burning
platform
platform
that
was
real
and
technical
debt
and
that
could
never
support,
announced
App,
Store
or
the
Symbian
operating
system
they
had
to
replant
form.
But
of
course
the
business
just
want
more
features
and
just
kept
prioritize.
Some
more
features,
and
this
drove
that
company
into
the
ground.
Now
here's
another
version
of
that
story.
B
Gonna,
stop
all
feature
work
now
and
it's
not
that
Microsoft
didn't
have
competitive
pressures
it
just
that
Bill
Gates,
understood
that
zero-sum
game
and
these
trade-offs-
and
you
have
the
steerer
Microsoft
around
that
and
focus
on
that
work
on
she
couldn't
be
platform.
The
way
say:
Amazon
has
been
platform
because
their
product
portfolio
is
probably
the
most
complex
since
it
actually
started
the
moment.
B
B
So
I'll
give
you
a
quick
overview
right
now
of
it
and
tell
a
few
stories
of
some
of
these
things
that
the
flow
framework
has
you
tracked.
So
the
first
thing
you
start
with
is
you
define
your
product,
your
product
portfolio?
These
are
internal
products,
external
products,
platform
products
and
for
each
product
value
stream.
You
don't
track
how
many
user
stories
or
issues
were
close.
B
You
actually
track
each
of
the
flow
metrics,
and
so
you've
got
this
more
abstract,
high-level,
more
business,
centric
view
of
what
flows
the
flow
metrics,
our
flow
velocity
flow
efficiency,
flow
of
time
and
flow
of
load,
which
I'll
show
you
and
you
correlate
those
flows
to
business
results
so
to
some
notion
of
value.
For
an
external
product
that
could
be
revenue
that
could
be
active
users,
the
cost
and
you
do
not
track
cost
for
how
much
development
costs,
how
much
operations
you
track
cost
for
value
stream.
B
So
all
of
the
people
involved
in
that
product
value
stream,
even
the
hosting
cost
of
that
value
stream,
are
the
cost
of
the
value
stream.
With
those
two
things
together,
you
can
actually
get
to
things
like
Product,
Lifecycle
profitability.
You
track
the
quality
of
that
value
stream
and
you
track
the
happiness
of
the
staff
on
the
value
stream.
So
not
how
happy
all
your
developers
are
and
I'm
happy
all
your
support.
B
People
are
but
happy
all
the
people
on
the
product
value
stream
are
so
you
have
that
early
warning
indicator
if
you've
got
an
architectural
problem,
if
you
actually
to
invest
in
architecture
and
proven
for
this
value
stream,
and
so
I'll
give
you
a
couple
examples
right
now
of
how
these
flow
metrics
can
answer.
The
key
questions
have
been
so
hard
for,
especially
for
business
leaders
to
answer
and
understand.
So
this
is
a
story
from
DevOps
by
summit
in
Vegas,
this
past
fall
and
that
Nationwide
Insurance
shared.
B
You
have
to
take
a
more
customer,
centric
point
of
view
and
actually
optimize
the
flow
for
your
end
to
end
value
stream.
The
way
a
car
manufacturer
does,
as
part
of
this,
of
course,
we're
always
looking
for
where
our
bottlenecks
are,
when
you
start
thinking
this
way
and
we'd
start
thinking
in
terms
of
value
streams,
and
so
this
is
one
of
my
experiences.
Actually,
that
was
quite
interesting,
where
we
were
hiring
more
and
more
developers
because
hands
on
keyboards
and
and
writing
code.
B
You
know
always
to
me,
seemed
like
the
the
most
important
thing
having
come
from
that
background,
and
then
we
started
realizing
from
what
we
were
hearing.
While
we
dug
into
this
that
we
might
have
our
ratio
of
developers
to
designers
wrong
because
adding
those
developers
was
not
producing
more
features
at
the
rate
that
we
thought
you
know
you
actually
more
closely
and
the
fact
that
developers
had
Photoshop
open.
B
It
was
probably
a
an
odd
sign,
but
I
actually
dug
into
this
a
little
bit
and
I
realized
that
we
had
a
ratio
of
one
to
forty
of
developers
to
designers.
Meanwhile,
companies
like
at
lasting
companies
like
Dropbox,
had
actually
shifted
one
to
nine
ratio,
one
to
six
ratio
because
of
how
important
user
experiences
and
great
user
experiences
are
in
today's
consumer
and
in
today's
business
applications.
So
by
tracking
flow
efficiency,
you
actually
learn
where
the
weight
sites
are.
B
Then
there's
this
other
key
one
I
think
a
lot
of
you
have
probably
experienced
as
well
is:
why
is
delivery
slowing?
As
we
add
developers,
this
seems
completely
counterintuitive,
but
yet
it
happens
all
the
time
as
complexity
Rises,
and
this
one's
really
interesting,
and
in
the
last
few
months
of
my
trips
of
helping
companies
adopt
the
flow
framework.
This
is
actually
one
of
the
most
common
issues.
This
shows
up
a
lot
and
dominica
the
grandis
book.
B
In
terms
of
dependencies,
but
so
often
we
see
that
values
that
architectures
the
software
architecture
that
we
use
are
not
actually
aligned
to
the
product
value
streams.
It's
kind
of
the
opposite
of
what
you
see
at
Amazon
with
those
micro
services
and
that
loose
coupling
between
their
product
value
streams.
You've
got
these
enterprise
architectures
that
were
made
to
look
elegant
and
be
future
proof
in
terms
of
extensibility,
and
it's
the
opposite
of
what
you
see
in
that
BMW
plant,
where
the
i8
has
its
own
highly
optimized
value
stream,
so
flow
velocity.
B
We
need,
for
example,
see
why
does
it
take
us
so
long
to
resolve
risks?
Well,
maybe
that
you
should
have
a
value
stream
dedicated
to
your
security
framework,
because
there's
so
much
dependency
on
that
security
framework
and
even
just
ask
everyone
to
implement
gdpr.
So
one
more
story
here:
why
are
the
teams
working
on
this
particular
product
value
stream?
It's
less
happy
than
the
others,
and
this
was
an
another
kind
of
key
lesson
for
me
once
you
start
measuring
things
like
employee
engagement
or
employee
NPS
for
product
value
streams.
B
You'll
actually
start
to
see
this,
and
you
start
to
ask
those
kinds
of
questions,
and
in
our
case
we
noticed
that
it
was
a
flow
load
issue.
So
the
issue
was
that
we
were
putting
so
much
feature
hold
on
this
value
stream.
We
not
allowing
the
developers
to
work
contact
that
they
were
completely
overloaded
with
a
feature
backlog,
and
we
knew
this.
We
were
gonna.
Let
them
pay
down
the
tech
debt.
B
We
just
didn't
realize
how
much
their
engagement
went
down
because
they
would
feel
they
felt
like
they
were
failing
the
company,
which
is
exactly
what
happened
in
Nokia.
You
actually
have
now
studied
forensically
the
employee
engagement
logs
from
Nokia
and
that's
what
was
happening.
Employee
gauge
was
going
down
because
developers
wanted
to
fix.
Those
features
want
to
help
the
company
succeed,
but
they
were
completely
overloaded
with
tech
debt
and
the
flow
load
would
have
indicated
that,
as
well
as
the
per
value
stream,
Net
Promoter
scores
or
other
engagement
scores.
B
B
So
basically
you
make
sure
that
we've
got
these
flow
items
connected
end-to-end
so
that
we
can
trace
them
and
connect
them
in
these
end-to-end
value
streams,
and
then,
from
that
generate
these
flow
metrics,
and
it's
not
as
hard
as
it
seems
because
once
you've
got
those
four
metrics,
you
start
getting
these
insights
and
they're
simply
a
mapping
and
the
modeling
of
the
work
that's
happening
across
your
entire
tool
network.
So
just
as
a
quick
example
our
work
at
task
table,
it
actually
starts
a
lot
of
it
starts
at
Salesforce.
B
It
will
start
in
Zendesk
where
those
customer
requests
come
in.
All
of
that
goes
into
a
product
management
tool
work
it's
done
in
JIRA.
Some
of
it
goes
to
one
of
our
partners
JIRA,
who
helped
us
with
some
of
that
work.
But
all
of
this
is
connected,
and
the
really
neat
thing
is
once
it's
connected
once
it's
abstracted
with
these
models,
you
can
measure
these
flow
metrics
and
you
can
and
actually
see
the
flow
of
business
value
and
these
bottlenecks.
So
here's
an
interesting
one
and
one
of
our
products.
B
We
know
this
that
we
had
a
very
large
feature
backlog
and
we
really
needed
to
get
through
this
feature.
Backlog
is
key
to
this
product
success
so
as
soon
as
you
see
that
spike
over
there
in
flow
load.
So
how
many
features
that
team
has
to
work
on
and
starts
thrashing
as
they
reprioritize
things?
The
flow
time
goes
up
almost
instantly,
so
it's
now
taking
them
way
longer
to
get
anything
done.
B
So
what
we
did
is
we
actually
doubled
the
size
of
this
team
over
here
and
flow
velocity
didn't
go
up
immediately,
and
then
we
got
to
really
worrying
because
we
realized
that
the
core
architecture
for
something
was
was
actually
built
in
Scala.
It
was
our
first
experience
with
Scala
and
we,
the
our
VP,
probably
development,
call
Brian,
I
started
wondering
like
do
to
rip
out
the
Scala
or
people
way
too
slow
to
ramp
up
on
it,
and
we
actually
thought.
Okay
well
should
probably
move
the
Scala
to
things
we
know
like
Java
and
types
typescript.
B
Then
what
happens?
Is
the
team
said?
No,
you
know
what
give
us
a
chance.
Let's,
let's
you
know,
give
us
a
couple
Sprint's
to
ramp
up
and
we
actually
seen
the
flow
velocity
rise
and
improve
and
we
realized
we
were
wrong
and
that
the
Scala
stuff
was
fine
and
that
they
were
able
to
ramp
up.
But
this
shows
you
the
importance
of
having
that
same
common
language.
That's
higher
level
of
abstraction,
that's
close
to
the
business
value
in
terms
of
that
making
it
very
easy
for
the
team
to
show
us
that
we
were
wrong.
B
So
really.
The
goal
here
is
to
use
these
flow
metrics.
This
formatting
work
this
this
layer
over
top
your
agile
tools
and
your
DevOps
practices
to
stop
these
local
optimizations
and
basically
having
waterfall
on
the
ends
and
agile
in
the
middle
and
to
have
this
flow
orientation
where
you
actually
measure
flow,
where
you
can
stop
using
project
management
for
visibility,
and
you
actually
have
a
direct
visibility
of
what's
flowing
through
your
project
value
streams
and
what
business
results
those
are
delivering.
B
This
is
why
companies
like
Google
can
actually
kill
product
so
easily
because
they
realize,
if
they're,
adding
a
bunch
more
features.
It's
not
getting
adopted
more.
It's
not
delivering
more
business
results.
Well,
it's
time
to
kill
that
product
that
doesn't
happen
in
the
world
of
project
management.
It
actually
has
a
really
significant
effect
of
how
you
think
about
budgeting.
So
in
budgeting
and
project
management,
you
bacon
all
the
risks
up
front.
B
It's
not
optimized
for
any
of
the
principles
of
DevOps
of
flow
feedback,
we're
learning,
because
you're
trying
to
pretend
that
you
understand
the
whole
lifecycle
of
this
product
rather
than
learning
through
leases
and
through
iteration,
whereas
in
a
product
oriented
mindset,
you've
actually
invest
further.
When
you
see
those
business
results
happen,
that's
when
you
ramp
up
the
teams,
that's
when
you
make
for
the
investments
products
when
it's
incremental
delivering
results.
Another
really
important
one
is
in
the
project
oriented
mindset
again
that
tailors
mindset,
you're
bringing
people
to
work
and
I'm
still.
It
drives
me
crazy.
B
Whenever
I
see
this,
but
but
we
see
this
all
the
time
you'll
have
developers
assigned
to
810
different
product
values,
so
a
10
different
project
and
guess
what
their
productivity,
not
that
you
see
it
in
project
management,
but
has
tanked
in
the
product
oriented
world
no
developer
or
no
team
is
assigned
to
more
than
one
product
value
stream.
They
get
to
master
the
work
to
get
to
master
that
insane
complexity
of
the
technology
stacks
that
working
with
today
and
I.
B
Think
one
of
the
most
interesting
and
most
impactful
things
that
I've
been
noticing
is
the
effects
of
product
thinking
on
software
architecture.
So
a
lot
of
organizations
are
just
putting
a
ton
of
effort
on
their
business
or
customer
facing
products,
but
it
turns
out
if
you
actually
look
at
the
dependencies
between
your
product
value
streams,
you'll
notice
that
your
internal
products,
your
platforms,
your
API,
is
your
data
pipelines.
B
Those
things
are
actually
a
bottleneck
for
all
those
external
value
streams
and
then
you'll
notice
that
your
actual
value
stream
network,
the
tool
chain
itself
is
one
of
your
most
important
products.
Because
that's
what
makes
all
your
developers
productive,
so
tech,
giant's.
This
is
kind
of
obvious
Satya.
B
Nadella
said
there
cannot
be
a
more
important
thing
for
an
engineer
than
to
work
on
the
system's
the
driver,
productivity,
today's
enterprise,
it's
completely
flipped,
all
the
good
developers
are
other
stuff
on
top
and
you've
got
your
complete
staff
and
stuff
on
the
bottom
tech
giant,
completely
flipped
the
high
speed
developers
or
on
the
bottom
layer
on
the
developer
productivity
tools,
the
value
stream
network,
then
on
the
internal
api's
and
platforms
that
enable
everyone
to
build
great
software.
And
this
is
why
companies
like
BMW
realize
that
their
most
important
product
is
not
that
I
ate.
B
It's
the
factory
it's
the
plant,
so
in
summary,
disruption
is
going
to
accelerate,
so
we
just
need
better
business.
We've
I
think
we
figured
out
the
technical
tools.
We
figured
out
the
ways
of
agile
and
DevOps.
We
now
need
better
business
tools
to
survive
it
and
today's
IT
practices
of
managing
the
value
w3
projects
just
won't
work
for
the
innovation
that
you
need
to
survive.
You
need
to
shift
from
project
a
product
at
an
organization
level
and
you
get
a
shot
to
connect
the
business
with
technology.
B
With
this,
the
simple
language
of
the
full
framework,
so
I
do
hope.
This
works
for
you
to
do
that.
Connecting
value
stream
network
define
that
product
portfolio
track
flow,
metrics
and
connect
them
to
your
business
results
and
to
your
plans.
So
the
idea
is
that
you
go
from
project
within
call
centers
the
product
value
streams
from
silos
and
these
proxy
metrics
that
lead
straight
to
flow
metrics
and
business
results
and
from
fragment
value
students
to
an
integrated
value
stream
network.
B
So
you
can
learn
more
about
the
book
over
here
in
terms
of
the
help
I'm
looking
for
it's
really
I've
been
doing
a
ton
of
learning
and
how
this
works
in
terms
of
changing
your
organization
string
model
connecting
to
finance
so
any
stories
or
wins
or
difficulties
that
you've
had
on
that
front,
please
reach
out
and
with
that.
Thank
you
very
much.