This paper discusses the changing role of project managers in agile projects, and how to organize a more facilitative approach in your (IT) projects when using agile as methodology.

1.
-­‐
Towards
Facilitative
Project
Management
-­‐
Source:
Managing
agile
projects
(Bert
Hedeman)
Towards
Facilitative
Project
Management
The
changing
role
of
project
managers
in
agile
projects
N.B.
This
article
was
originally
featured
in
‘Projectie
08/2014’
Research
shows
that
(project)
managers
and
executives
experience
a
lot
less
control
in
projects
with
an
agile
approach.
After
all,
the
scope
of
the
project
is
not
fixed
and
the
teams
are
self-­‐directing.
Nevertheless,
it
doesn’t
have
to
be
that
agile
leads
to
less
control.
When
agile
is
implemented
correctly,
an
organization
retains
control
over
money,
time,
scope
and
quality.
However,
the
role
of
the
project
manager
will
have
to
change.
Instead
of
directing,
the
emphasis
will
be
on
facilitating
and
communicating.
Regular
measurement
of
and
reporting
about
the
quality
of
the
product
and
process
remains
important.
This
enables
organizations
to
‘release
their
projects
in
a
controlled
way’
and
be
confident
about
the
execution
of
the
projects
by
the
self-­‐directing
teams.
Cultural
change
The
‘8th
Annual
State
of
Agile
Survey’
shows
that
loss
of
management
control
and
the
lack
of
up-­‐front
planning
are
the
main
concerns
for
organizations
that
work
based
on
an
agile
philosophy.
The
survey
shows
that
30%
of
the
3,500
respondents
find
these
two
concerns
as
most
important.
Organizations
and
(project)
managers
are
primarily
used
to
being
directive
and
determining
everything
in
detail
before
the
execution
stage(s).
This
is
often
the
case
with
a
traditional
waterfall
approach.
This
approach
gives
organizations
often
more
sense
of
grip
and
control,
but
doesn’t
always
result
in
the
desired
final
product.
During
the
project
a
lot
of
things
can
change
because
of
external
factors
which
will
require
adjustments
in
the
final
product.
Apparently,
organizations
struggle
to
give
self-­‐directing
teams
enough
space
and
find
it
difficult
not
to
determine
the
final
product
in
advance.
In
many
organizations,
projects
with
an
agile
approach
require
a
cultural
change.
Besides,
PRINCE2
also
does
not
state
that
every
detail
must
be
covered
in
the
project
plan.
These
are
also
developed
further
in
the
stage
plan.
Agile
governance
It
is
therefore
a
misconception
that
agile
leads
to
less
control.
When
agile
governance
is
implemented
correctly,
an
organization
retains
control
over
money,
time,
scope
and
quality.
Governance
stands
among
others
for
management
and
supervision.
Determining
expectations,
delegating
tasks
and
verifying
performance
are
the
key
components
of
governance.
In
other
words,
this
is
the
role
of
a
project
manager
in
an
agile
project.
The
principles
of
Atern,
one
of
the
most
complete
agile
methodologies,
state
that
it
is
important
to
focus
on
the
business
needs,
continually
communicate
clearly
and
ensure
visible
control.
In
agile
projects,
a
prioritized
requirements
list
will
be
prepared
during
the
Feasibility
and
Foundation
stage
and
all
stakeholder
expectations
will
be
determined.
Subsequently,
the
Business
Visionary
or
Senior
User
has
to
approve
them.
The
requirements
list
will
be
developed
further
during
the
Exploration
and
Engineering
stages.
The
Business
Ambassador
or
Product
Owner,
in
agile
projects
part
of
the
Solution
Development
Team,
is
made
responsible
for
the
translation
of
the
business
needs
to
the

2.
-­‐
Towards
Facilitative
Project
Management
-­‐
needs
of
the
customer.
Even
though
not
everything
is
captured
in
detail
in
advance,
there
is
up-­‐front
alignment
about
the
final
product.
Parameters
for
agile
projects
To
be
able
to
provide
self-­‐directing
teams
enough
room
to
maneuver
and
still
ensure
adequate
management
control
for
the
organization,
the
project
manager
has
to
provide
the
Project
Board
with
sufficient
progress
information.
By
reporting
regularly,
the
project
manager
ensures
that
self-­‐directing
teams
can
do
their
job.
In
addition
to
reporting
on
standard
parameters
such
as
hours,
costs
and
results,
the
Scope
Churn
(the
number
of
changes
in
the
back
log),
Effort
at
Risk
(item
has
been
built
or
supplied,
but
is
not
in
production
yet)
and
the
Earned
Value
(the
value
of
the
delivered
work)
are
parameters
the
project
manager
could
report
on.
(also
see
break-­‐out
section
on
‘Agile
governance
for
more
grip
on
agile’
on
how
to
measure
agile
software
projects).
Other
techniques,
such
as
a
Kanban
board,
burn-­‐down
chart,
release
chart,
sprint
quality
and
code
quality
are
indicators
for
the
Solutions
Development
Team.
Some
project
management
tools
offer
this
kind
of
information
by
default.
The
information
will
help
the
team
to
get
insight
in
the
progress
during
the
sprint
and
in
the
quality
of
the
delivered
work.
It
also
helps
the
team
to
learn
and
improve
themselves
in
the
next
sprint.
These
parameters
are
less
interesting
for
the
Project
Board.
From
being
directive
to
being
facilitative
All
agile
methodologies
emphasize
that
project
managers
do
not
necessarily
need
to
have
sufficient
knowledge
of
the
actual
project
contents
(this
is
also
the
case
when
using
with
PRINCE2).
Too
much
knowledge
about
the
project
content
can
even
be
a
risk,
because
the
project
manager
will
then
take
the
place
of
the
Team
Manager
or
Team
Member.
The
emphasis
for
the
project
manager
in
agile
projects
is
more
on
facilitating
and
communicating.
The
project
manager
is
responsible
for
the
progress
of
the
project
as
a
whole
and
has
to
shield
the
team
from
the
rest
of
the
organization,
in
order
to
minimize
disruptions.
In
general,
self-­‐directing
teams
are
capable
enough
to
translate
the
business
needs
to
a
technical
solution
and
associated
planning
all
by
themselves.
The
project
manager
should
pay
special
attention
to
ensuring
that
the
right
conditions
are
in
place
–
conditions
which
enables
the
team
to
work
as
effectively
as
possible.
Moreover,
a
team
does
not
simply
become
self-­‐
directing.
This
requires
experience
and
time.
This
can
be
achieved
by
gradually
being
less
strict
and
directive
towards
a
team.
The
team
has
to
have
the
chance
and
room
to
learn
instead
of
being
criticized
or
regulated.
“Letting
go
is
to
fear
less
and
love
more”
according
to
a
famous
quote
by
Nelson
Mandela.
The
‘controlled
letting
go’
is
vital
to
let
agile
projects
succeed.
When
a
team
is
‘released’
too
fast
or
too
slow,
the
trust
between
the
Project
Team,
the
Project
Manager
and
the
Project
Board
will
be
put
under
pressure.
This
endangers
the
success
of
agile
projects.
Conclusion
Using
agile
governance
and
the
controlled
release
of
the
teams,
organizations
are
able
to
make
agile
projects
a
success
without
losing
control
over
the
projects.
Just
like
with
every
other
project
methodology,
it
is
important
to
continually
measure
the
progress
of
the
project
and
to
intervene
as
soon
as
one
of
the
parameters
is
likely
to
be
exceeded.
Clear
and
automated
reports
for
the
team
and
for
the
executives
are
crucial.
This
allows
the
Project
Manager
–
and
the
rest
of
the
organization
–
to
hand
over
the
project
to
the
self-­‐directing
team
with
confidence.

3.
-­‐
Towards
Facilitative
Project
Management
-­‐
Agile
governance
for
more
grip
on
agile
Research
into
the
quality
of
software
systems
shows
that
‘applying
agile’
often
stops
at
the
borders
of
the
Solution
Development
Team.
This
triggered
Professor
Joost
Visser
of
the
Software
Improvement
Group
to
investigate
ways
how
to
increase
control
over
agile
software
development
projects.
This
research
was
conducted
together
with
the
Radboud
University
Nijmegen
and
VU
University
Amsterdam,
and
resulted
in
a
new
Agile
Governance
Quality
Model.
Measurement
and
metrics
for
software
and
projects
Measuring
software
serves
two
purposes:
1. Internal:
to
give
members
of
the
Project
Team
insight
into
the
progress
of
their
work;
this
allows
for
adjusting
things
within
the
team
and
for
the
individual.
2. External:
to
give
the
Project
Team
the
possibilities
to
show
the
Project
Sponsors
the
progress
and
when
it
will
be
finished;
this
allows
for
adjusting
the
project.
These
are
two
scenarios
that
require
a
different
approach
and
different
metrics.
It
is
not
desirable
to
use
internal
metrics
(for
the
Project
Team)
without
the
team’s
approval,
outside
the
team.
This
may
result
in
a
team
losing
trust
and
the
measurements
to
become
less
valuable.
It
is
also
important
that
performing
the
measurements
requires
very
little
effort
from
the
individual
Project
Members,
so
they
can
stay
focused
on
their
work
as
much
as
possible.
The
Agile
Governance
Quality
Model
The
Agile
Governance
Quality
Model
utilizes
pattern
every
agile
or
scrum
project
offers
in
the
form
of
iterations
or
sprints.
Typically
at
the
end
of
every
sprint,
working
software
is
delivered
and
accepted.
At
the
beginning
of
a
sprint
the
back
log
is
updated
and
eventually
the
built
software
will
be
taken
in
to
production.
Using
the
available
information
in
the
sprints,
the
following
characteristics
for
an
agile
development
process
have
been
defined.

4.
-­‐
Towards
Facilitative
Project
Management
-­‐
• Scope
churn
is
a
measurement
of
the
scope
of
the
project,
as
it
is
recorded
in
the
back
log.
The
back
log
can
change
because
extra
work
is
coming
in,
and
tasks
are
deleted,
modified
or
rejected
by
the
stakeholders.
• Value
is
a
measurement
for
the
amount
of
value
that
has
been
created
for
the
business,
relative
to
the
agreed
initial
value.
By
measuring
the
value
it
is
possible
to
regularly
test
whether
the
business
case
is
still
valid.
• Effort
at
risk
is
the
amount
of
work
and
costs,
that
have
already
been
made,
but
not
yet
resulted
in
a
working
software
product.
This
also
includes
the
effort
to
define
the
requirements.
Earlier
in
the
project
it
is
more
likely
that
a
requirement
will
not
be
implemented.
Later
in
a
project,
the
amount
of
effort
invested
in
building
a
requirement
will
be
much
higher.
• The
sprint
quality
indicates
how
well
the
team
executes
a
planned
sprint.
When
there
is
a
lot
of
failure
or
a
low
effectivity,
the
team
is
able
to
make
improvements.
• For
measuring
the
code
quality
models
have
been
designed
based
on
ISO
25010
for
software
quality.
With
this,
the
performance,
reliability,
security
and
maintainability
of
the
software
can
be
measured.
With
the
results,
which
are
expressed
on
a
scale
from
1
to
5
stars,
the
software
can
be
improved
these
specific
areas.
For
example,
for
determining
the
maintainability
of
the
software,
system
properties
are
measured
such
as
the
volume
(number
of
lines
of
code),
level
of
de-­‐duplication,
the
unit
size
and
the
unit
complexity.
The
measurements
are
compared
with
benchmark
figures,
where
the
score
is
calculated
relative
to
other
systems
in
the
benchmark.
From
the
start
of
the
project,
it
is
important
to
maintain
a
consistent
and
traceable
administration
in
the
back
log.
This
means
that
from
the
beginning
of
a
project
it
should
be
clear
what
units
of
work
are,
thus
which
functional
‘parts’
the
Project
Sponsor
will
recognize.
These
can
be
epics,
stories
or
requirements;
in
practice
the
terminology
often
differs.
All
stories
should
be
unique,
even
when
changes
are
made
such
as
extensions,
separations
or
further
developments
at
a
later
stage.
Removed
and
rejected
stories
should
also
remain
in
the
back
log,
so
there
is
a
clear
picture
of
the
realized
scope
relative
to
the
initial
scope
of
the
project
in
every
stadium.
An
advantage
of
working
agile
is
the
flexible
scope.
However,
in
practice
the
initial
expectations
of
the
stakeholders
often
remain.
Especially
if
there
is
a
distance
between
them
and
the
Solution
Development
Team.
The
concepts
of
scope
churn,
value
and
effort
at
risk
are
translated
in
the
quality
model
in
11
metrics,
such
as
the
size
of
the
back
log,
the
extent
to
which
stories
are
added,
modified
or
expired,
and
the
extent
to
which
stories
are
transformed
in
working
software
and
the
effect
on
the
expected
lead
time
and
final
scope.
Changes
of
stories
can
be
the
content
(the
functionality
changes),
but
it
can
also
be
a
change
of
the
priority
(a
feature
has
become
more
important)
or
estimation
(the
story
takes
more
time
to
be
developed
then
originally
expected).

5.
-­‐
Towards
Facilitative
Project
Management
-­‐
Example:
project
in
7
sprints;
optimistically
planned,
realism
sets
in
During
the
course
of
this
example
project
more
and
more
requirements
will
expire,
for
example
to
meet
a
deadline.
This
will
decrease
the
expected
value
upon
completion.
The
‘effort
at
risk’
will
also
continue
to
grow
because
there
is
virtually
no
functionality
brought
to
production
useful
for
the
production.
A
possible
course
of
an
agile
project
in
7
sprints
will
look
like
this:
Benefits
for
the
Project
Manager
The
results
of
the
above
model
give
the
Project
Manager
insight
into
the
trends
and
behaviour
of
his
agile
project.
It
provides
objective
perspectives
on
the
shared
reality.
With
these
insights
it
is
possible
to
make
better
estimations
about
scope
and
end
date.
It
enables
the
Executive
and
Project
Manager
to
agree
about
what
can
be
done
to
increase
the
chance
of
success.
For
instance,
they
could
decide
to:
1. Add
more
people
to
the
project
2. Decrease
the
scope
of
the
project
3. Monitor
the
scope
in
the
backlog
better
4. Define
more
realistic
milestones
By
measuring
and
monitoring
agile
projects
and
their
software
characteristics,
more
control
over
the
projects
will
be
realized.
This
helps
avoid
undesirable
situations
in
an
early
stage.
During
the
alignment,
the
Project
Manager
will
continue
to
fulfill
a
crucial
role
between
the
Solutions
Development
Team
and
the
Stakeholders.
The
authors
Erik
Aalbersberg
Niels
van
der
Zwan
Fortes
Solutions
Software
Improvement
Group