1
PMI-­‐ACP
Exam
Prep
2-­‐day
Course

Warm
Up
&
Introduc8ons
2
Constellation
Fast intro
What’s in it for me?

PMI-­‐ACP
Exam
Requirements
3
Requirement Descrip8on
General
Project
Experience • 2,000
hours
working
on
project
teams
• These
hours
must
be
earned
within
the
last
5
years
• AcEve
PMP®
or
PgMP®
will
saEsfy
this
requirement
Agile
Project
Experience
• 1500
hours
working
on
agile
project
teams
or
with
agile
methodologies
• These
hours
are
in
addiEon
to
the
2,000
hours
required
in
“general
project
experience”
• These
hours
must
be
earned
within
the
last
3
years
Training
in
Agile
PracEces • 21
contact
hours
• Hours
must
be
earned
in
agile
pracEces
ExaminaEon
• Tests
knowledge
of
agile
fundamentals

4
PMI-­‐ACP
References
Agile
Retrospec8ves:
Making
Good
Teams
Great
Esther
Derby,
Diana
Larsen,
Ken
Schwaber
Agile
Es8ma8ng
and
Planning
Mike
Cohn
Agile
SoIware
Development:
The
Coopera8ve
Game
–
2nd
Edi8on
Alistair
Cockburn
The
Art
of
Agile
Development
James
Shore
The
SoIware
Project
Manager’s
Bridge
to
Agility
Michele
Sliger,
Stacia
Broderick
User
Stories
Applied:
For
Agile
SoIware
Development
Mike
Cohn
Coaching
Agile
Teams
Lyssa
Adkins
Agile
Project
Management
with
Scrum
Ken
Schwaber
Agile
Project
Management:
Crea8ng
Innova8ve
Products
–
2nd
Edi8on
Jim
Highsmith
Lean-­‐Agile
SoIware
Development:
Achieving
Enterprise
Agility
Allan
Shalloway,
Guy
Beaver,
James
R.
TroW
Becoming
Agile:
...in
an
imperfect
world
Greg
Smith,
Ahmed
Sidky
PMI-­‐ACP
Exam
Prep
Mike
Griffiths
Source:
hWp://www.pmi.org/CerEficaEon/~/media/Files/PDF/Agile/PMI000-­‐GainInsightsAIGLE418.ashx

5
100
About
the
Exam
scored questions
20
unscored questions
+
Content %
of
Exam
Agile
tools
and
techniques 50%
Agile
knowledge
and
skills 50%

6
Source:
Mike
Griffiths
Tools & Techniques / Knowledge & Skills

Please do not copy or reproduce
this course materials without
expressed written consent from
SparkAgility.
7
Notice

8
Introduction
! Name
! Role
! Where are you
from?

salah@sparkagility.com @selleithy 410.262.5550
Enabling organizational agility and
enhancing team capabilities
serving as a Project Manager, Scrum
Master, Business analyst, Team Facilitator
and Agile Coach.
9
Salah Elleithy
15 years
Senior Principal Consultant
Agile Coach & Trainer
Certified Trainer in
Training from the
Back of the Room
Masters in Info Systems &
Financial Management

10
Logistics

11
Pledge
of
Learning
• As a participant:
– I will do my best to come on time so that I don’t miss any
portion of the course.
– I will be present physically and mentally so that I can retain
more of what we learn.
– I will do my best to maintain my focus on learning and
participate so that I can get the most out of the course.
– I will respect all participants thoughts and opinions so that I
can benefit from others’ experience.

12
Why
Agile?
! What problems
are you trying to
solve with Agile?
! Pair up and
discuss.
Timebox: 3 minutes

BeXer
Success
Rates
13
Credit: Mike Cohn

14
Source: Standish Group CHAOS Manifesto
2013
Success
factors
1994
2011
2012 - 2013
1
User Involvement
Executive management
support
2
Executive Management Support
Executive management
support
User Involvement
3
Clear Statement of Requirements
Clear business objectives
Optimization
4
Proper Planning
Emotional maturity
Skilled resources
5
Realistic Expectations
Optimization
Project management
expertise
6
Smaller Project Milestones
Agile process
Agile Process
7
Competent Staff
Project management
expertise
Clear Business Objectives
8
Ownership
Skilled resources
Emotional Maturity
9
Clear Vision & Objectives
Execution
Execution
10
Hard-working, Focused staff
Tools & Infrastructure
Tools & Infrastructure

15
Benefits of being Agile
Source:
VersionOne
7th
Annual
State
of
Agile
Development
Survey

Leading causes of failed Agile projects
16
Source:
VersionOne
7th
Annual
State
of
Agile
Development
Survey

17
Origins
of
Agile

Beyond
Agile
Alistair Cockburn
wrote, The Oath
of non allegiance,
I promise not to
exclude from
consideration any
idea based on its
source, but to
consider ideas
across schools
and heritages in
order to find the
ones that best
suit the current
situation.
18
1930
Walter Shewhart,
a quality expert
at Bell Labs who
proposed
a series of short
“plan-do-study-act”
(PDSA)
cycles for quality
improvement.
Quality guru W.
Edwards Deming
began
vigorously
promoting
PDSA.
1960
NASA’s Project
Mercury
applied IID in
Software and
ran with very
short half-day
iterations that
were time-boxed.
Winston Royce,
wrote an article
called ‘Managing
the
Development of
Large Software
Systems’ on
what would
become known
as the waterfall
model.
1970
1972
TRW applied IID in a
major project – the
$100 million TRW/
Army Site Defense
software project for
balistic missile
defense.
Barry Boehm, the
originator of the IID
spiral model in the
mid-1980s, was
chief scientist at
TRW.
Light Airborne
Multipurpose
System, part of the
US Navy’s
helicopter-to-ship
weapon system
used IID. A four year
200-person-year
effort involving
millions of lines of
code, LAMPS was
incrementally
delivered in 45
time-boxed
iterations (one
month per
iteration).
mid-1970
Source:
Larmen
&
Basili.
IteraEve
and
Incremental
Development.
A
brief
History
1976
Tom Gilb, published
Software metrics
coining the term, in
which he addressed
his IID practice-evolutionary
project
management-and
introduced the
terms “evolution”
and “evolutionary”
to the process
lexicon.
System
Development Corp.
project build an air
defense system in
1977 and finished in
1980 using
incremental
development.
1984
1985
Barry Boehm,
published “A Spiral
Model of Software
Development and
Enhancement”.
Fredrick Brooks,
a prominent
software
engineering
thought leader
published the
classic, “No Silver
Bullet” extolling
the advantages of
IID.
1986
1990s
Ken Schwaber and
Jeff Sutherland,
started applying
what would become
known as the Scrum
method. The method
took inspiration from
a Japanese IID
approach used for
non-software
products at Honda,
Canon, and Fujitsu in
the 1980s ; from
Sashimi (“slices” or
iterations) and from a
version of Scrum
described in 1986.
2001
In February 2001, a group
of 17 process experts-representing
DSDM, XP,
Scrum, FDD and others-interested
in promoting
modern, simple IID
methods and principles
met in Utah to discuss
common ground. From
this meeting came the
Agile Alliance and the
now popular catch phrase
“agile methods”, all of
which apply IID
Kent Beck joined
Chrysler C3 payroll
project. It was in this
context that the full
set of XP practices
matured, with some
collaboration by Ron
Jefferies and
inspiration from
earlier 1980s work
with Ward
Cunningham.
1996
2010

“I believe in this concept, but
the implementation described
above is risky and invites
19
Source:
Managing
the
development
of
large
Sogware
System,
Dr.
Winston
W.
Royce
hWp://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
failure.”

20
Source:
Managing
the
development
of
large
Sogware
System,
Dr.
Winston
W.
Royce
hWp://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
“Hopefully, the iterative
interaction between the
various phases is confined to
successive steps.”

21
Shift in Work Type
Characteris8c
Characteris8c
Type
Work
is
visible
Emphasis
on
changing
things
Work
is
invisible
Focus
on
the
right
answers
Work
is
stable
ConEnuous
innovaEon
Define
the
task
ConEnuously
learn
and
teach
Emphasis
on
running
things
Measure
performance
to
strict
standards
More
structure
with
fewer
decisions
Command
and
control
Focus
on
the
right
quesEons
Minimize
cost
of
workers
for
a
task
Strict
standards
Work
is
changing
Focus
on
quality
Understand
the
task
Give
autonomy
Less
structure
with
more
decisions
Treat
workers
as
assets,
not
as
costs
Focus
on
quanEty
Knowledge:
K,
Industrial
:
I

22
Shift in Work
Characteris8c
Characteris8c
Type
Work
is
visible
Emphasis
on
changing
things
K
Work
is
invisible
Focus
on
the
right
answers
I
Work
is
stable
ConEnuous
innovaEon
K
Define
the
task
ConEnuously
learn
and
teach
K
Emphasis
on
running
things
Measure
performance
to
strict
standards
I
More
structure
with
fewer
decisions
Command
and
control
I
Focus
on
the
right
quesEons
Minimize
cost
of
workers
for
a
task
I
Strict
standards
Work
is
changing
I
Focus
on
quality
Understand
the
task
K
Give
autonomy
Less
structure
with
more
decisions
K
Treat
workers
as
assets,
not
as
costs
Focus
on
quanEty
I
Knowledge:
K,
Industrial
:
I

23
Agile
Manifesto

24
We are uncovering better ways of
developing software by doing it and
helping others do it. Through this work
we have come to value:
Individuals and interactions
Working software
Customer collaboration
Responding to change
Processes and tools
Comprehensive documentation
Contract negotiation
Following a plan
That
is,
while
there
is
value
in
the
items
on
the
right,
we
value
the
items
on
the
leI
more.
Source:
agilemanifesto.org

25
Stand
by
your
value
! Find the Agile value
that is most important to
you.
! Stand by your value
and share what made you
choose this value.
! Report back to the
group.
Agile
Values
Timebox: 5 minutes

26
Agile
Principles
1. Our highest priority
is to satisfy the
customer through
early and continuous
delivery of valuable
software.
Source: agilemanifesto.org
2. Welcome changing
requirements, even late
in development. Agile
processes harness
change for the
customer’s competitive
advantage.
5. Build projects
around motivated
individuals. Give them
the environment and
support they need,
and trust them to get
the job done.
3. Deliver working
software frequently,
from a couple of
weeks to a couple of
months, with a
preference to the
shorter timescale.
6. The most efficient
and effective method
of conveying
information to and
within a development
team is face-to-face
conversation.
4. Business people
and developers work
together throughout
the project.

2277
Agile
Principles
10. Simplicity--the art
of maximizing the
amount of work not
done--is essential.
Source: agilemanifesto.org
11. The best
architectures,
requirements, and
designs emerge from
self-organizing teams.
9. Continuous attention
to technical excellence
and good design
enhances agility.
12. At regular intervals,
the team reflects on
how to become more
effective, then tunes
and adjusts its behavior
accordingly.
7. Working software is
the primary measure
of progress.
8. Agile processes
promote sustainable
development. The
sponsors, developers,
and users should be
able to maintain a
constant pace
indefinitely.

Declara8on
of
Interdependence
We are a community of project leaders that are highly successful at delivering
results. To achieve these results:
28
We increase return on
investment by making
continuous flow of
value our focus.
Source:
pmdoi.org
We deliver reliable
results by engaging
customers in frequent
interactions and
shared ownership.
We expect
uncertainty and
manage for it through
iterations,
anticipation, and
adaptation.
We unleash creativity
and innovation by
recognizing that
individuals are the
ultimate source of
value, and creating an
environment where
they can make a
difference.
We boost performance
through group
accountability for
results and share
responsibility for team
effectiveness.
We improve
effectiveness and
reliability through
situationally specific
strategies, processes
and practices.
(DOI)

29
What is Agile?

Manifested through many
different
PRACTICES
Established through
4 VALUES
30
Guided by
12 PRINCIPLES
Doing Agile
Practices
and
Processes
The How?
The Why?
Values and
Principles
Credit: Dr. Ahmed Sidky
SCRUM
Story Mapping
Unit tests
Daily meetings
Backlog
Definition of Ready
Definition of Done
Kanban Board
Three Questions
Iterations
Retrospectives
User Stories
Burndown chart
Acceptance tests
Being Agile
Agile is a…
MINDSET
eXtreme
Programming
Your Agile
Process

31
Agile Practices
Source:
Guide
to
Agile
PracEces.
Agile
Alliance,hWp://guide.agilealliance.org/subway.html

32
Agile Frameworks /
Methodologies

33
SCRUM
Transparency
InspecEon
AdaptaEon
•
Scrum
is
a
process
framework
for
managing
complex
product
development.
•
Scrum
has
4
planned
checkpoints
for
InspecEon
&
AdaptaEon:
1. Sprint
Planning
2. Daily
Scrum
3. Sprint
Review
(Demo)
4. Sprint
RetrospecEve

34
! 3 roles
SCRUM
in
Brief
! ………………
! ………………
! ………………
! 4 Ceremonies
! ………………
! ………………
! ………………
! ………………
! 3 Artifacts
! ………………
! ………………
! ………………
Daily
Scrum
(15-­‐minute
8meboxed
mee8ng)
1. What
has
been
achieved
since
last
meeEng?
2. What
will
be
done
before
the
next
meeEng?
3. What
obstacles
are
in
the
way?
Find
answers
in
chapter
2

35
Used with permission of mitchlacey.com
SCRUM
Framework

Extreme
Programming
(XP)
36
• XP
is
a
sogware-­‐
development-­‐centric
agile
method.
• The
core
values
are:
– Simplicity
– CommunicaEon
– Feedback
– Courage
– Respect
What
is
the
‘iteraEon’
called
in
SCRUM?

Feature-­‐Driven
Development
(FDD)
37
• FDD
is
a
simple-­‐to-­‐understand
yet
powerful
approach
to
building
products
or
soluEons.
Develop
an
overall
model
• FDD
Build
a
feature
list
Plan
by
feature
PracEces
include:
Domain
object
modeling,
developing
by
feature,
individual
class
(code)
ownership,
feature
teams,
inspec8ons,
configura8on
management,
regular
builds,
visibility
of
progress
and
results.
Design
by
feature
Build
by
feature

Dynamic
System
Development
38
Method
(DSDM)
Focus
on
the
business
Deliver
on
Eme
Collaborate
Never
compromise
quality
Build
incrementally
from
firm
foundaEons
Develop
iteraEvely
Communicate
conEnuously
and
clearly
Demonstrate
control
DSDM
is
centered
on
eight
principles.

39
• Crystal
is
a
family
of
methodologies
designed
for
different
size
of
projects.
• The
crystal
methodologies
embrace
and
promote
many
other
agile
principles
as
well,
including:
– Frequent
delivery
– ReflecEve
improvement
– OsmoEc
communicaEons
– Personal
safety
– Focus
Crystal
Number
of
people
involved
CriEcality
(defects
cause
loss
of
…….)

Lean
SoIware
Development
40
Eliminate
waste
Lean
Empower
the
team
Deliver
fast
OpEmize
the
whole
Amplify
Learning
Build
Quality
in
Defer
Decisions
•
Lean
is
a
set
of
principles
that
have
been
taken
from
lean
manufacturing
approach
and
applied
to
sogware
development.
•
These
principles
focus
on
seven
core
concepts.

41
Kanban
Development
• Kanban
development
is
derived
from
the
lean
produc8on
system
used
at
Toyota.
• Kanban
is
a
Japanese
word
meaning
“signboard”.
• Kanban
development
operates
on
five
core
principles.
Visualize
the
workflow
Kanban
core
principles
Limit
WIP
Manage
flow
Improve
collabor
a8vely
Make
process
policies
explicit

How big is the system to
develop?
How many lives lost if the
system fails or how many
billions of dollars lost?
How is the project
remunerated for its effort?
How much of a stable
architecture exist at the
start of the project?
How is the team
distributed? (Collocated,
virtual, outsourced, etc.)
42
How long has the system been
around? (evolution of legacy,
maintenance)
How stable are the
requirements and
surrounding business
environment?
What are the external rules
imposed to the project to
control its trajectory and
how formal they are?
Source(s): SoftEd; Agility in context. Kruchten 2011.
Process
Tailoring

43
Stages
of
Learning
SHU
Follow the
Rule
“Obey”
HA
Break the
Rule
“Detach”
RI
Be the Rule
“Separate”

Value-Driven Delivery
44

45
Why…
do
we
undertake
projects?
To
generate
business
value
Produce
a
benefit
Improve
a
service
Agile
teams
ogen
ask:
Which
choice
would
add
the
most
value
for
the
business
or
customer?

46
Assessing
Value
• Return
on
Investment
(ROI)
is
the
discount
rate
at
which
the
project
inflows
(revenues)
and
project
ouvlows
(costs)
are
equal.”–
The
higher
the
rate,
the
beXer
the
project!
• Net
Present
Value
(NPV)
=
the
total
benefits
(income
minus
the
costs)
for
a
revenue
stream
–
The
higher
the
rate,
the
beXer
the
project!
• Internal
Rate
of
Return
(IRR)
–
The
higher
the
rate,
the
beXer
the
project!
$600,000
$500,000
$400,000
$300,000
$200,000
$100,000
$-
$(100,000)
$(200,000)
$(300,000)
Jan Feb Mar Apr Jun Jul Sep Oct Nov Dec
Cummulative Income Cummulative Spending
Net Cashflow

47
Plan-Driven Delivery
Requirements
Shall do this
Will do that
Shall do this
Will do that
Shall do this
Will do that
Shall do this
Will do that
Idea
Resources
Requirements
Everything
is a
PRIORITY
Schedule
How can we meet our “Initial Plan”?
Deliver
Scope
Budget
Schedule

48
The
biggest
Assump8on
Much of present-day software acquisition procedure
rests upon the assumption that one can specify a
satisfactory system in advance, get bids for
its construction, have it built, and install it. "
I think this assumption is
fundamentally wrong, and
that many software
acquisition problems spring
from that fallacy.
Fredrick Brooks (1986)

Schedule
49
Value-­‐driven
Delivery
1
2
3
4
5
6
7
8
PRIORITIZED
Idea
Resources
Requirements
Schedule
Deliver
Scope
Budget
1
3
4
2
5
6
7
8
How can we deliver the highest value in the time we have?

Plan-­‐driven
vs.
Value-­‐driven
50
Valu
e
Value driven delivery
Plan driven delivery
Time
Time is up
There is value that can
be delivered to the
customer.
There is no value to be
delivered to the
customer.

51
Plan-driven
Value-driven
feedback,
plan,
defined
process,
planning,
learn,
frequently,
plan,
end,
adapt,
finish,
schedule,
coordinate,
value,
frequently,
empirical
process
The
goal
is
to
………..
The
goal
is
to
………….
The
driver
is
the
…………
The
driver
is
the
…………
SEcks
to
the
……..
ConEnuous
learning
and
…………
Uses
a
…………..
control
model
(spends
Eme
upfront
planning
for
all
the
details)
Uses
an
……………
control
model
(evaluates
data
as
they
become
available
and
makes
course
correcEons)
…………….
and
control
Inspect
and
……….
Success
is
to
meet
the
………
Success
is
to
deliver
………
as
quickly
as
possible
Wait
un8l
the
………
to
deliver
value
Deliver
slices
of
value
………….

52
Plan-driven
Value-driven
The
goal
is
to
finish
The
goal
is
to
learn
The
driver
is
the
schedule
The
driver
is
the
feedback
SEcks
to
the
plan
ConEnuous
learning
and
planning
Uses
a
defined
process
control
model
(spends
Eme
upfront
planning
for
all
the
details)
Uses
an
empirical
process
control
model
(evaluates
data
as
they
become
available
and
makes
course
correcEons)
Coordinates
and
control
Inspect
and
adapt
Success
is
to
meet
the
plan
Success
is
to
deliver
value
as
quickly
as
possible
Wait
un8l
the
end
to
deliver
value
Deliver
slices
of
value
frequently

Process
53
Chartering
How will it
be
delivered?

54
Value
Stream
Mapping
(VSM)
!
The
purpose
of
the
VSM
is
to
idenEfy
waste
(Ex:
extra
steps,
duplicates
or
delays
in
the
process).
!
Focus
on
the
outcomes
and
not
specific
arEfacts.
Value
stream
mapping
is
a
lean
manufacturing
technique
that
has
been
adopted
by
agile
methods.

Value
Stream
Mapping
(VSM)
2 mins 10 mins
55
You
Buy a
cake
Starting Point
(Who initiates the
process)
End Point
You
47 minutes
Select Checkout
Eat cake
cake
line
Unpack &
slice
Bakery
counter
Bakers Sales
1 min 2 mins 2 mins
4 mins 6 mins 15 mins
5 mins
Value-add
Nonvalue-add
Total cycle time = value-add + Nonvalue-add time
Process cycle efficiency = Total value-add time / Total cycle time
36%

56
VSM
Steps
1. IdenEfy
the
……………
or
……………
you
are
analyzing.
2. Create
a
value
stream
map
of
the
current
process,
idenEfying
………….,
…………….,
……………….
and
informaEon
flows.
3. Review
the
map
to
find
………….,
waste,
and
………………….
4. Create
a
new
value
stream
map
with
the
desired
……………..
state
of
the
process,
opEmized
to
reduce
delays,
waste,
and
constraints.
5. Develop
a
……………….
for
creaEng
the
………………
state.
6. Plan
to
………………..
the
process
in
the
future
to
conEnually
…………………
and
……………………
it.
product
service
delays
constraints
steps
queues
delays
product
future
opEmized
roadmap
revisit
tune
opEmize

57
Receiving
Value
All
we
doing
is
looking
at
the
Eme
line,
from
the
moment
the
customer
gives
us
an
order
to
the
point
when
we
collect
the
cash.
And
we
are
reducing
the
Eme
line
by
reducing
the
non-­‐value
adding
wastes.
–Taiichi
Ohno.
Father
of
TPS
Idea
Usage

58
Waste
Waste
Descrip8on
Example
ParEally
done
work
Work
started
but
not
complete
Source:
7
wastes
in
sogware.
Mary
and
Tom
Poppendieck
" Code
waiEng
for
quality
assurance
(QA)
" Specs
waiEng
for
dev.
Extra
processes
Extra
work
that
does
not
add
value
" Unused
documentaEon
" Unnecessary
approvals
Extra
features
Features
that
are
not
required,
or
thought
of
as
nice-­‐to-­‐haves
" Gold
plaEng
" Technology
features
Task
switching
MulE-­‐tasking
between
several
different
projects
when
there
are
context-­‐
switching
penalEes
" People
on
mulEple
projects
WaiEng
Delays
waiEng
for
reviews
and
approvals
" WaiEng
for
document
approvals
MoEon
The
effort
required
to
communicate
or
move
informaEon
or
deliverables
from
one
group
to
another
" Distributed
teams
" Handoffs
Defects
DefecEve
documents
or
Sogware
needs
correcEon
" Requirements
defects
" Sogware
bugs

Customer-­‐Valued
Priori8za8on
59
• Simple
Schemes
(Ex:
1,2,3,…etc.)
• MoSCOW
(Must
have,
Should
have,
Could
have,
Won’t
have)
• Monopoly
Money
• Kano
Analysis
(Exciters,
SaEsfiers,
DissaEsfiers,
Indifferent)

Customer-­‐Valued
Priori8za8on
Prioritized list
60
• Customer-Valued
Prioritization (what items
yield the highest value to
the customer asap)
– Product Backlog – SCRUM
– Feature list – Feature Driven
Development (FDD)
– Prioritized requirements list –
Dynamic Systems
Development Method
(DSDM)
A
B
C
D
E
Cut-off point

61
MoSCOW
Priori8za8on
Product Backlog
Must have 1 2 3
5 6 7
8 9
4
11 12
10
13 15
Should have
Could have
Would have
Won’t have (or would like to have but not this time) 14
Minimum
marketable
release

Other
Priori8za8on
Techniques
62
• Monopoly money (Buy a feature
using an monopoly money equal
the project budget)
• Kano Analysis (Exciters, Satisfiers,
Dissatisfiers, Indifferent)
• Requirements prioritization
model (rate features for benefit,
penalty, cost and risk on a
relative scale from 1(lowest) to 9
(highest)

63
• A
Product
Roadmap
visual
overview
of
the
product’s
releases
and
its
main
components.
• Provides
project
stakeholders
with
a
quick
view
of
the
primary
release
points
and
intended
func8onality.

64
Product
Roadmap
Sequence
Backbone
Less
op8onal
More
op8onal
Walking
skeleton
First Release
Second Release
Third Release
OpEonality

65
Risk
Adjusted
Backlog
Risk
Management
Process
Plan Risk
mgmt.
Identify Risks
Perform
Qualitative
risk analysis
Perform
Quantitative
risk analysis
Plan Risk
Responses
Monitor &
Control Risks
•
A
risk
is
an
event
or
circumstance
that
could
transpire
and
impact
the
project.
•
What’s
absent
from
this
process?
•
Risk
response
doing!
•
Through
itera8ons,
we
can
tackle
high
risk
areas
of
the
project
sooner
rather
than
later.

Agile
Contrac8ng
Customer Collaboration Agile Value #3: over Contract Negotiation
Time
(Schedule)
66
Plan
Driven
Time
(Schedule)
Cost
Value
Driven
Resources
(Cost)
Scope
(Features/
Functionality)
fixed
Scope
(Features/
Functionality)
vary
Inverted
Triangle
Model

Agile
Contrac8ng
(Cont’d)
Product Backlog
67
• Money
for
Nothing
(allow
customer
to
terminate
project
early
when
they
feel
there
is
no
longer
sufficient
ROI
in
the
backlog
to
warrant
further
iteraEons)
and
Change
for
Free
(allow
customer
to
subsEtute
higher
priority
items
for
other
items
that
are
of
lower
priority
without
gezng
charged)
• Graduated
FP
Contract
(Pay
for
performance)
–
Finish
early,
get
higher
rate,
Finish
on
Eme,
get
regular
rate,
Finish
late,
get
lower
rate)
• Fixed
Price
Work
Packages
(allows
the
customer
to
reprioriEze
remaining
work
based
on
evolving
costs)
A
B
C
D
E

Maximize
Value
/
Minimize
Waste
68
Waste Descrip8on Example
Partially done work
Extra processes
Work started, but not complete
" Code waiting for quality
assurance (QA)
" Specs waiting for dev.
" Unused documentation
" Unnecessary approvals
Extra work that does not add value
Extra features
Features that are not required, or thought of as
nice-to-haves
" Gold plating
" Technology features
Task switching Multi-tasking between several different projects when
there are context-switching penalties
" People on multiple
projects
Waiting
Delays waiting for reviews and approvals " Waiting for document
approvals
Motion
The effort required to communicate or move
information or deliverables from one group to
another
" Distributed teams
" Handoffs
Defects
Defective documents or Software needs
correction
" Requirements defects
" Software bugs

69
Task
and
Kanban
Boards
Backlog
Ready
for
Development
Development
Tes8ng
Accepted
Pending
Complete
Pending
Complete
Pending
Complete
Transparency
Flow
Collaboration

70
• What
Low-­‐tech
/
high-­‐touch
are
we
trying
to
tackle?
1. Data
accuracy
percepEon.
2. Barriers
for
stakeholders
interacEons.
There
is
a
solid
pracEcal
reason
for
not
using
a
more
sophisEcated
analysis:
not
everyone
will
understand
it.
–
Donald
Reinertsen,
Managing
the
Design
Factory

71
• Work
Work
in
Progress
(WIP)
that
has
been
started
but
not
yet
completed.
• Problems
with
excessive
WIP:
– Holds
capital
– Hides
boWlenecks
– PotenEal
rework

72
Backlog Ready
for Dev.
Work
in
Progress
(WIP)
Development
(5)
Testing
(3)
Accepted
(2)
To be
Deployed
In Done In Done In Done
Cycle time
• Is WIP good, bad or necessary?
• Why?
• Why reduce WIP?
Throughput
How
long
it
takes
a
work
item
to
go
through
the
cycle?
How
many
work
items
are
going
through
the
cycle
at
a
given
Eme?

73
Work
in
Progress
(WIP)
The aim of WIP limits is
NOT to optimize
resource utilization
But to optimize
THROUHGPUT

74
Incremental
Delivery
Agile Principle #1:
Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software. Cost of change
Requirements
Time
Analysis
& Design
1
2
Coding Testing UAT Production
Incremental delivery help the
team find issues earlier
and deliver value
faster.

75

76

IKIWISI
(I
Will
Know
It
When
I
See
It)
77
• Re-prioritization
• Prototypes /
Mockups
• Simulation
• Demos
(Iteration
Reviews)
How the customer explained it
What the customer really needed

Requirements
Evolve
with
Itera8ons
X3
O3
78
X1
O1
FuncEonality
Time
IteraEon
1
X
=
Requirement
O
=
As
built
X1
O1
FuncEonality
Time
IteraEon
2
X
=
Requirement
O
=
As
built
X1
O1
FuncEonality
Time
IteraEon
3
X
=
Requirement
O
=
As
built
X2
O2
X2
O2
When
teams
demonstrate
funcEonality,
two
things
occur.
First,
we
learn
about
the
differences
between
what
was
asked
for
and
what
was
interpreted
and
built
(the
gulf
of
evaluaEon).
Second,
we
learn
about
new
or
adjusted
func8onality
(IKIWISI).

Itera8on
Demo
What the customer really needed
79
• Gulf of evaluation
(the difference
between what was
asked for and what
was interpreted and
built)
• IKIWISI (new or
adjusted functionality) How the customer explained it
What the customer really needed

Agile
Earned
Value
“S-­‐curve”
80
$100,000
$90,000
$80,000
$70,000
$60,000
$50,000
$40,000
$30,000
$20,000
$10,000
$-­‐
EsEmate
Actual
One of the key benefits of
earned value is that is that
it is a leading indicator
Schedule
Cost
But does spending tell the whole story?

Double
S-­‐curve
Velocity
Progress is steady
81
$6,000.00
$5,000.00
$4,000.00
$3,000.00
$2,000.00
$1,000.00
$-­‐
3000
2500
2000
1500
1000
500
0
Spending
Scope
(Points)
Scope
built
Spending
Progress is slow

82
600
500
400
300
200
100
0
Apr
May
Jun
Jul
Aug
Sep
Total
features
Date
Total
In
Progress
Completed
Cumula8ve
Flow
Diagram
(CFD)
A
B
B
=
Queue
in
length
(units)
A
=
Queue
in
duraEon
(Eme)

Stakeholders
Engagement
83

84
Stakeholders
• Any people or groups
who will be impacted
by or have an impact
on the project.
(PMBOK Guide)
• Getting stakeholders
involved (engaging
them in the project is
absolutely essential for
an agile project’s
success.

85
Source: Standish Group CHAOS Manifesto
2013
Success
factors
1994
2011
2012 - 2013
1
User Involvement
Executive management
support
2
Executive Management Support
Executive management
support
User Involvement
3
Clear Statement of Requirements
Clear business objectives
Optimization
4
Proper Planning
Emotional maturity
Skilled resources
5
Realistic Expectations
Optimization
Project management
expertise
6
Smaller Project Milestones
Agile process
Agile Process
7
Competent Staff
Project management
expertise
Clear Business Objectives
8
Ownership
Skilled resources
Emotional Maturity
9
Clear Vision & Objectives
Execution
Execution
10
Hard-working, Focused staff
Tools & Infrastructure
Tools & Infrastructure

Aligning
Stakeholders’
Understanding
86
• Wireframes
(Quick
mock-­‐up
of
the
product)
• Personas
(Quick
guides
or
reminders
of
the
key
stakeholders
on
the
project
and
their
interests)
• User
Stories
(Small
chunks
of
business
funcEonality)
• Backlogs
(A
visible
list
of
work
“broken
into
small
chunks”
to
be
done)

Why align Stakeholder’s
Understanding?
87

88
• Wireframes
Wireframes
models
are
popular
way
of
creaEng
a
quick
mock-­‐up
of
the
product.
• Serve
as
a
useful
visual
for
stakeholders
to
refer
to
and
adjust
unEl
they
achieve
consensus.
• Are
a
form
of
“low-­‐
fidelity
prototyping”.

89
• Are
quick
guides
or
reminders
of
the
key
stakeholders
on
the
project
and
their
interests.
• When
used,
personas
should:
– Provide
an
archetypal
descripEon
of
users
– Be
grounded
in
reality
– Be
goal-­‐oriented,
specific
and
relevant
– Be
tangible
and
acEonable
– Generate
focus
Personas
Name: Bob the movie buff
Description: Bob loves
movies. On average he rents
5 movies per week : from his
local rental store.
His two children also like to
watch children’s TV shows.
They often like to watch the
same shows more than
once, which means that Bob
sometimes has to pay late
fees.

90
• User
User
Stories
stories
are
bite-­‐
sized,
understandable
chunks
of
business
func8onality.
• Help
align
team
priori8es
with
the
needs
of
the
business.

91
As
a
<Role>,
I
want
<Func)onality>
so
that
<Business
Benefit>
Who’s
asking
for
it?
Why
are
we
doing
this?
Independent
NegoEable
Valuable
EsEmatable
Small
Testable
INVEST
User
Stories

92
Non-­‐func8onal
Stories
• Non-­‐funcEonal
or
system-­‐
based
requirements
also
use
the
following
format:
Given
the
account
is
valid
and
the
account
has
a
MovieCredit
balance
of
greater
than
0
When
the
user
redeems
credit
for
a
movie
Then
issue
the
movie
and
reduce
the
user’s
MovieCredit
balance
This
format
is
also
used
with
Acceptance
Criteria

User
Story
‘INVEST’
Criteria
93
Independent
Source:
Bill
Wake
Can
be
scheduled
and
implemented
in
any
order
NegoEable
Capture
the
essence
NOT
the
details
Valuable
Needs
to
add
value
to
the
customer
EsEmable
Just
enough
esEmate
to
help
the
customer
rank
and
schedule
Sized
appropriately
Can
be
planned
and
fit
an
into
an
iteraEon
Testable
The
story
can
be
verified
and
tested

94
Feature
Feature
Story
StoUrsye
r
Story
Task
1
Task
4
Task
3
Task
2
Requirements
Hierarchy
Feature
Epic
Story
StoUrsye
r
Story
Task
1
Task
4
Task
3
Task
2
Feature
Epic
FeatuErpeic
Story
StoUrsye
r
Story
Task
1
Task
4
Task
3
Task
2
Feature
Story
StoUrsye
r
Story
Task
1
Task
4
Task
3
Task
2
Feature
Epic

95
Story
Maps
Sequence
Less
Backbone
op8onal
More
op8onal
Walking
skeleton
First Release
Second Release
Third Release
OpEonality

96
Stakeholders
Value
Individuals and interactions
over
Processes and tools
Working Software
over
Comprehensive documentation
Customer Collaboration
over
Contract Negotiation
Responding to change
over
Following a plan
#
Engage
business
in
the
prioriEzaEon
of
requirements.
#
Invite
stakeholders
to
planning
meeEngs
Agile Principle #4: Business people and developers must work together
daily throughout the project.

97
Stakeholders
Management
• Executives and
project sponsors
• Managers
• The project team
• The user
community
• Supporting groups
IdenEfy
Educate
Address

98
Vendor
Management
• Stakeholders
who
are
external
to
the
organizaEon
but
are
involved
in
the
project.
• Agile
approach
should
be
outlined
in
the
Request
For
Proposal
(RFP).

99
Defini8on
of
Done
What
does
“Done”
look
like?
– Tested
– Coded
– Designed
– Integrated
– Builds
– Installs
– Migrates
– Reviewed
– Fixed
– Accepted

Communica8on
Management
100
Source:
Alistair
Cockburn

101
• Highly
Informa8on
Radiators
visible
ways
to
display
informaEon
(Examples:
Backlog,
Burn
Down
charts,
Burn
Up
charts,
CumulaEve
Flow
Diagram)
• Velocity
(the
measure
of
a
team’s
capacity
for
work
per
iteraEon)

102
Burn
Up
charts
Story points
Expected velocity: 10 points/iteration
Iteration
Velocity
Iteration
Expected
Actual
0
0
0
1
10
10
2
20
19
3
30
20
4
40
35
5
50
50
6
60
58
7
70
63
8
80
63
9
90
78
10
100
90
11
110
100
12
120
105
Forecasted
Additional iterations: 2
Burn Up charts give an indicator whether the team will deliver the functionality or
need to add more iterations.

Velocity
Burn down charts shows the points remaining at the beginning of each iteration
103
Burn
down
charts
Expected velocity: 10 points / Iteration
Iteration
Expected
Actual
0
120
120
1
110
120
2
100
110
3
90
100
4
80
97
5
70
95
6
60
80
7
50
70
8
40
62
9
30
45
10
20
37
11
10
25
12
0
20
Additional iterations: 2
Forecasted

104
Draw
a
burn-­‐down
chart
Draw a burn down chart based
on the data in the release
Sprint
Planned
Actual
0
100
100
1
90
100
2
80
95
3
70
90
4
60
80
5
50
70
6
40
60
7
30
55
8
20
40
9
10
30
10
0
20

105
Velocity
!
Velocity
is
a
measure
of
a
team’s
capacity
for
work
per
iteraEon.
!
It
helps
gauge
how
much
work
the
team
is
able
to
do,
based
on
the
number
of
user
stories
completed
in
past
iteraEons.
Velocity
is
a
measure
of
predictability.

106
Measuring
Velocity
Guesstimate
Historical
data
Empirical
data (Trial
iteration)
Time
Accuracy

107
Agile
Modeling
• The value is in the
creation, not the
beautification and
preservation of the
model in a specialized
modeling tool.
• Agile models are
typically lightweight,
or “barely-sufficient”.
Regardless of the type of model you create, remember that the goal is
still to deliver value not extraneous documentation

108
• NegoEaEon
Cri8cal
SoI
Skills
(Not
a
zero-­‐sum
game
rather
a
healthy
negoEaEons
that
allow
each
party
to
invesEgate
the
trade-­‐offs
and
present
alternaEve
perspecEves
–
give
and
take)
• AcEve
Listening
– Level
1:
Internal
Listening
(How
is
this
going
to
affect
me?)
– Level
2:
Focused
Listening
(We
put
ourselves
in
the
mind
of
the
speaker)
– Level
3:
Global
Listening
(Pick
up
subtle
physical
and
environmental
indicators)

109
Cri8cal
SoI
Skills
(Cont’d)
• FacilitaEon
methods
– Goals
(Establish
a
clear
goal
for
each
meeEng
or
session)
– Rules
(Establish
some
basic
ground
rules)
– Timing
(DuraEon
of
the
session
and
Emekeeping)
– Assis8ng
(Ensure
the
meeEng
is
producEve
and
that
everyone
is
parEcipaEng)
• Culture
dynamics
(Distributed
teams
–
geographically
and
across
different
Eme
zones)

110
• Is
Conflict
conflict
good
or
bad?
• Conflict
is
normal
and
inevitable
when
people
work
closely
together.
• Assess
the
severity
of
the
conflict
before
trying
to
resolve
it.

111
• Conflict
Handling
Conflict
ResoluEon
– Level
1
(Problem
to
solve,
InformaEon
sharing
and
collaboraEon)
– Level
2
(Disagreement,
Personal
protecEon
trumps
resolving
the
conflict)
– Level
3
(Contest,
Winning
trumps
resolving
the
conflict)
– Level
4
(Crusade,
ProtecEng
one’s
own
group
becomes
the
focus)
– Level
5
(World
war,
Destroy
the
other!)
Intervene when necessary and focus on de-escalating the problem by separating
facts from emotions and look for ways to help people move forward despite their
differences
Source:
Lyssa
Adkins

Par8cipatory
Decision
Models
112
• Simple
VoEng
(“for”
or
“against”)
• Thumbs
Up/Down/Sideways
• Fist-­‐of-­‐Five
VoEng
– Five
fingers:
I
totally
support
this
opEon.
– Four
fingers:
I
support
this
opEon
with
some
minor
reservaEons
that
we
probably
don’t
need
to
discuss
– Three
fingers:
I
have
concerns
that
we
need
to
discuss
– Two
fingers:
I
object
and
want
to
discuss
the
issue
– One
finger:
I
am
against
this
decision
–
No
Fingers
(Fist):
No
support

Management
vs.
Leadership
113
Management
Focus Leadership
Focus
Tasks/things People
Control Empowerment
Efficiency EffecEveness
Doing
things
right Doing
the
right
things
Speed DirecEon
PracEces Principles
Command CommunicaEon

114
Servant
Leadership
There
are
four
primary
du8es
of
a
servant
leader:
1. Shield
the
team
from
interrup8ons
(Isolate
and
protect
the
team
members
from
diversions,
interrupEons,
and
requests
for
work
that
aren’t
part
of
the
project).
2. Remove
impediments
to
progress
(Clear
obstacles
from
the
team’s
path
that
would
cause
delay
or
nonvalue-­‐adding
work).
3. Re-­‐Communicate
project
vision
(CommunicaEng
and
recommunicaEng
project
vision
is
criEcal
to
successfully
leading
a
team).
4. Carry
food
and
water
(Provide
the
essenEal
resources
the
team
needs
to
keep
them
nourished
and
producEve).

115
1. Learn the team members’ needs.
2. Learn the project requirements.
3. Act for the simultaneous welfare of the
team and the project.
4. Create an environment of functional
accountability.
5. Have a vision of the completed project.
6. Use the project vision to drive your own
behavior.
7. Serve as the central figure in successful
project team development.
8. Recognize team conflict as a positive
step.
9. Manage with an eye toward ethics.
10. Remember that ethics is not an
afterthought but an integral part of our
thinking.
11. Take time to reflect on the project.
12. Develop the trick of thinking backwards.
12
Principles
Source:
Jeffery
Pinto
Twelve
Principles
for
Leading
Agile
Projects

116
• Honesty
The
Leadership
Challenge
(Paying
aWenEon
to
transparency
and
follow
through
on
what
they
say
they
will
do)
• Forward-­‐looking
(Ability
to
explain
to
the
team
what
they
are
ulEmately
aiming
for)
• Competent
(Understand
the
team
dynamics)
• Inspiring
(Explain
the
project’s
vision
and
journey
with
genuine
enthusiasm)
The
Leadership
Challenge
(a
10-­‐
year
study
that
asked
more
than
75,000
people),
“What
values,
personal
traits,
or
characteris3cs
do
you
look
for
or
admire
in
your
leader?

117
Leading
by
Example
• CommunicaEng
the
project
vision.
• Enabling
others
to
act.
• Being
willing
to
challenge
the
Status
Quo.

Boos8ng
Team
Performance
Prac8ces
118

119
Agile
Values
Individuals and interactions
over
Processes and tools
Working Software
over Comprehensive documentation
Customer Collaboration
Contract Negotiation
over
Responding to change
over Following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Understanding
Team
Performance
120
• Examples
of
processes:
Backlog Iterations Reviews
Individuals and interactions
over
Processes and tools
The
soI
stuff
is
the
hard
stuff.

Performing
121
• Adap8ve
leadership:
is
adapEng
how
we
lead
a
team
based
on
the
specific
circumstances
and
how
mature
the
team
is
in
its
formaEon.
• Stages
of
Team
FormaEon
&
Development
(Tuckman).
• SituaEonal
Leadership
(Blanchard
and
Hersey)
• Come
together
as
a
team
Forming
Storming
• Turmoil
occurs
• Team
normalizes
Norming
• Work
effecEvely
together
Adjourning
Adap8ve
Leadership

Stages
of
Team
Forma8on
&
Development
122
NORMING
A
poten8al
team
that
is
working
with
each
other
and
developing
into
a
real
team
A
pseudo
team
that
is
challenging
each
other
and
developing
into
a
poten8al
team
STORMING
PERFORMING
A
real
team
that
is
working
as
one
and
becomes
a
high
performing
team
A
working
group
that
is
learning
about
each
other
FORMING
4
1
3
2

123
SUPPORTING
Team
Members:
Moderate/high
competence,
variable
commitment
Leadership:
Low
direcEve,
high
supporEve
behavior
Team
Members:
Low/some
competence,
low
commitment
Leadership:
High
direcEve,
high
supporEve
behavior
COACHING
DELEGATING
Team
Members:
High
competence,
high
commitment
Leadership:
Low
direcEve,
low
supporEve
behavior
Team
Members:
Low
competence,
high
commitment
Leadership:
High
direcEve,
low
supporEve
behavior
DIRECTING
Situa8onal
Leadership
Model
4
1
3
2

124
Forming
Storming
Norming
Performing
Match
Styles
SupporEng
DelegaEng
DirecEng
Coaching

125
Emotional Intelligence: is our ability to identify, assess, and
influence the emotions of ourselves, other individuals, and groups.
Self Others
Self-Management
Self-Control
Conscientiousness
Adaptability
Drive and motivation
Social Skills
Self-Control
Inspirational leadership
Developing others
Teamwork and collaboration
Self-Awareness
Self-Confidence
Emotional Self-Awareness
Accurate Self-Assessment
Social Skills
Self-Control
Conscientiousness
Adaptability
Drive and motivation
Regulate
Recognize
Aspects of
Emotional
intelligence
Emo8onal
Intelligence

Building
Empowered
Teams
126
• Self-Organizing Teams:
Instead of “directing” style, which is a
command-and-control approach
where instructions are passed from the
project manager to team leads down
to team members; agile projects take
a servant leadership approach, where
the project manager or leader shields
the team from interruptions, removes
impediments, communicates the
project vision, and provides support
and encouragement.
• Self-Directing Teams: Teams that
work collectively to create team norms
and make their own local decisions.
Keep in mind that the self-organizing
and self-directing
attributes of agile
teams are goals; we do
not start there.

Test
your
Knowledge
Behavior Command and Control Servant Leadership
127
Handing out detailed tasks lists
Doing administrative work for
team members
Creating the entire project’s WBS
one weekend as not to disturb the
team
Posting the project Gantt chart on
the office wall
Posting a “suggestions” box on
the office wall
Source: PMI-ACP Exam Prep P.176
✔
✔
✔
✔
✔

Building
High-­‐Performance
Teams
128
• Team:
– a small number of people (12 or
fewer members; Scrum 7 ±2)
– with complementary skills
(Generalizing-specialists with cross
functional skills can perform many
different tasks on the projects and
can help smooth resourcing peaks
and troughs)
– who are committed to a common
purpose (aligned behind a project
goal that supersedes their personal
agendas)
– performance goals and approach
for which they hold themselves
mutually accountable (has shared
understanding and ownership for
the outcome of the project)
Source: The wisdom of teams

Building
High-­‐Performance
Teams
(Cont’d)
129
Guidelines for Building
High-Performing teams:
① Create a shared vision for
the team
② Set realistic goals (SMART
goals)
③ Limit the size to 12 or fewer
members
④ Build a sense of team
identity
⑤ Provide strong leadership
(Point the way and let the
team own the mission)
The Five Dysfunctions of a Team
1. Absence of Trust: Team members are
unwilling to be vulnerable within the
group.
2. Fear of conflict: The team seeks artificial
harmony over constructive, passionate
debate.
3. Lack of Commitment: Team members
don’t commit to group decisions or
simply feign agreement with them.
4. Avoidance of accountability: Team
members duck the responsibility of calling
their peers on counterproductive
behavior or low standards.
5. Inattention to results: Team members
prioritize their individual needs, such as
personal success, status, or ego before
team success.
Constructive disagreement is vital for really understanding and welcoming issues.

Source: Alistair Cockburn
130
+
-
Undermining /
Resistance
Team
Mo8va8on
Passive
Compliance
Active
Participation
Committed
Dedication
Passionate
Innovation
Net Contribution
Nonaligned team Net Vector Aligned team
Net Vector
Candid conversations explaining why the project is important to the company can also
help motivate the team.

131
Daily
Standup
• Short - timeboxed to
15 minutes, focused
meetings that negate
the need for most
other team status
meetings.
• Only report issues but
discuss resolutions off-line.
SCRUM
① What have you worked on
since the last meeting?
② What do you plan to finish
today?
③ Are there any roadblocks or
impediments to your work?

132
Coaching
and
Mentoring
• Help the team stay on
track, overcome issues,
and continually
improve theirs skills.
• Outline for coaching
and mentoring agile
teams by Lyssa Adkins:
> Meet them a half-step
ahead
> Guarantee safety
> Partner with managers
> Create positive regard

133
Brainstorming
Techniques
• Quiet Writing (Team members
generate a list of ideas individually
within a given time “Timebox”).
• Round-Robin (Everyone takes
turn suggesting their idea).
• Free-for-All (People just shout
out their ideas).
Sort the ideas, prioritize them
and then act on them
• Prioritization techniques
– MoSCoW
– Dot Voting or Multi-Voting
Gather
Evaluate
Decide

Green
Zone
/
Red
Zone
Model
(Examples)
134
A Person in the Green Zone… A Person in the Red Zone…
Takes responsibility for the circumstances of
his or her life
Blames others for the circumstances of his or
her life
Seeks to respond nondefensively Feels threatened or wronged
Uses persuasion rather than force Use shame, blame, and accusation
Can be firm, but not rigid, about his or her
interests
Welcome feedback See others as the problem or enemy
Accepts responsibility for consequences of his
or her actions
Communicates high levels of disapproval
and contempt
Continuously seeks deeper levels of
understanding
Focuses on short-term advantage and gain
Seeks excellence rather than victory Is black/white, right/wrong in thinking
Listens well Does not listen effectively
Source: Coaching Agile Teams by Lyssa Adkins

135
• Co-located Teams
– Caves and Common (Caves refer to a space
where team members can retreat for quiet
time or privacy, and common is the area
where the team members can work as a
group)
– Osmotic Communication (Refers to the
useful information that flows as part of everyday
conversations and questions when they work in
close proximity with each other.
– Tacit Knowledge (Refers to information that is not
written down but is instead supported through
collective group knowledge)
• Distributed Teams
– Videoconferencing
– Web-based meeting facilitators
– Survey applications
– Instant messaging (IM) and VOIP (Voice over
IP) headsets
– Presence-based applications
– Interactive whiteboards
Team
Space

Tips
for
Managing
Distributed
Teams
136
• Maintain a metaphor (Help the team stay
focused on the project mission or vision).
• Apply frequent communications (add in
more scheduled check points)
• Intensify facilitation (Ask more questions,
repeat responses more frequently when on
conference calls, and work to keep
everyone engaged)
• Collaboration practices for conference calls
(Keep conference calls effective and
productive so people are willing to attend
and contribute). Basic guidelines include:
– Keep on track (No fuzzy agendas)
– Keep on time (keep calls to a one-hour limit)
– Keep track of who is on the call
– Keep the decisions flowing (Send agendas in
advance)
– Keep the answers coming (Engage participants with
questions)
– Keep it fair (Maintain fair telephone control)
– Keep it facilitated (Don’t take control of decisions)
– Keep it documented (Send feedback “Notes”
promptly)

137
• Low-tech, High-touch tools
(Promote communication and
collaboration which is where
learning and knowledge
transfer really occur on a
project.
• Digital tools
– Agile project management
software
– Virtual card walls
– Smart boards
– Digital cameras
– Wiki sites, document management
tools and collaboration websites
– Automated testing tools,
automated build tools, and traffic-light-
type signals
– CASE tools
Agile
Tools

138
Adap8ve
Planning

139
• AdapEve
planning
is
the
conscious
acceptance
that
early
plans
are
both
necessary
and
likely
to
be
flawed.
• Uncertainty
drives
the
need
to
replan.
Plan
to
Replan
Plan
Replan

140
Timeboxing
• Timeboxes: are short,
fixed-duration periods
of time in which
activities or work are
undertaken.
• Examples:
– Daily stand-up meetings
are timeboxed to 15
minutes
– Iterations are timeboxed
to (typically) 2 weeks
Must Should Must
User
Story 1
User Story 3
Must Should Could
User
Story 6
User
Story 4
User
Story 2
User
Story 5
Timebox
(Fixed Capacity)
An architectural spike is a period of time dedicated to a proof of concept.

141
Upfront
Planning
(10% - 15%)
Schedule
Close
Out
5%
Schedule
Release Plan
80% - 85%
Schedule
Iterations
Now
Progressive
Elabora8on

142
•
Process
Tailoring
Retrospec8ves
are
the
main
trigger
for
driving
process
change.
•
At
the
end
of
each
iteraEon
(Emebox),
the
team
meet
to
explore:
-
What
is
going
well?
-
What
area
could
use
improvement?
-
What
should
we
be
doing
differently?

Minimally
Marketable
Feature
(MMF)
143
•
MMF
refers
to
this
package
of
funcEonality
that
is
complete
enough
to
be
useful
to
the
users
or
market,
yet
small
enough
that
it
does
not
represent
the
enEre
project.
MMF Additional
Releases
>> Transport
occupants from
point A to point B
>> Road legal
>> Safe
>> Air conditioner
and heater
>> Fuel efficient
>> Comfortable
>> Sporty
performance
>> Aesthetically
pleasing

144
Value-­‐Based
Analysis
• Value-based analysis
is the process of
considering business
value of work items
and then acting
accordingly.
• Analyzing real
business value help in
prioritizing the features
appropriately.
$5000
Business
Benefit
$4000
Cost to
Build
$3000
Business
Benefit
$1000
Cost to Build

Value-­‐Based
Decomposi8on
&
Priori8za8on
145
1. Design
the
Product
Box
vision
exercise
(Product
Name)
2. Feature
Workshops
3. Candidate
Feature
List
4. IteraEve
Development
Cycle
(PrioriEzed
Feature
List,
Selected
Features,
Plan>Develop>Evaluate>Le
arn,
New
FuncEonality)
1. Plan
2.
Develop
4. Learn
3.
Evaluate

146
2
• Wideband Delphi: is a group
based estimation approach. A
panel of experts submit
estimates anonymously. (The
anonymous approach
produces improved estimates
because it minimizes the
“bandwagon effect”).
• Benefits of this technique:
• Iterative
• Adaptive
• Collaborative
• Planning Poker: This technique
combines all of the essential
elements of wideband Delphi in
a fast, collaborative process.
3
8
5
13
Es8ma8on

147
Ideal
Time
• Ideal time is how long
something would take, if all
other peripheral work and
distraction were removed.
It assumes that user story being
estimated is the only thing being
worked on, that there will be no
interruptions, and that we have
everything we need, meaning
we are not waiting for someone
to deliver work or provide
information.

148
• RelaEve
Rela8ve
Sizing
sizing
and
Story
points
solved
two
common
problems:
• People
are
not
very
good
at
predicEng
the
absolute
size
of
work
• The
esEmaEon
process
is
difficult
and
unpopular
• Example:
• Get
to
the
grocery
store
by
driving
1.3
miles
southeast
• Get
to
the
grocery
store
by
going
8-­‐9
blocks
unEl
you
reach
the
park
then
another
5
blocks.

149
Story
Points
• Relative sizing and Story points
solved two common problems:
• People are not very good at
predicting the absolute size of
work
• The estimation process is
difficult and unpopular
• Example:
• Get to the grocery store by
driving 1.3 miles southeast
• Get to the grocery store by
going 8-9 blocks until you
reach the park then another 5
blocks.

150
Affinity
Es8ma8on
• Affinity
estimating is
the process of
grouping
requirements
into categories
or collections.

Time,
Budget
&
Cost
Es8ma8on
151
• Steps of Estimating:
1. Determine the size of the project in
story points or ideal time.
2. Calculate the effort for the work in
hours or person days (or person weeks
or months) by determining the
availability and capacity of the team.
3. Convert effort into a schedule by
factoring in the team size, required
resources, and dependencies.
4. Calculate the cost by applying labor
rates and adding in the other project
cost elements.

Parkinson’s
Law
and
Student
Syndrome
152
• Agile projects measure the
progress by the number of
accepted user stories,
rather than an estimate of
“percent complete”
against analysis or design
deliverables.
• Parkinson’s Law and
Student Syndrome: Work
tends to expand to fill the
time available.

153
Agile
Plans
• Agile planning varies from
traditional projects in three
key ways:
– Trial and demonstration
uncover true requirements,
which then require replanning
– Agile planning is less of an
upfront effort, and instead is
done more throughout the
project.
– Midcourse adjustments are the
norm.

154
W5H Questions
GO or No GO
How
How will be
undertaken?
(A description
of the
approach
especially if
agile methods
are new to the
organization)
Agile
Charters

Elevator
Statement
(“Pitch”)
155
For: Target Customers
Who: Need (opportunity or problem)
The: Product/service name
Is a: Product category
That: Key benefits / reason to buy
Unlike: Primary competitive
alternativ(s)
We: Primary differentiation

Itera8on
and
Release
Planning
156
Project
Release Release
A release may be:
$ Date driven (We need
something to demo at the
trade show)
$ Functionality driven (Once we
can capture and process
customer orders, we want to go
live, other functionalities can
come later)
Iterations (Each with an iteration plan)

157
Planning
a
Release
• Prioritization
(MoSCOW)
• Velocity
(Historical, Guess
or Experiment)
• Story Map (What
gets build first?)
Sequence
High
Priority
Low

158
Test
your
Knowledge
The team’s velocity remains fairly
stable, averaging 20 points per
iteration. They have 200 points’
worth of functionality left in the
backlog for this release. With
each iteration, they have been
discovering about a 10 percent
growth in work due to change
requests and new functionality.
The sponsors would like to know
how many more iterations it will
take before the release will be
done.
" Backlog size:
200 + 200 *
0.1(10% growth
in work) = 220
points
" 220/20
(average
velocity per
iteration) = 11
iterations

Problem
Detec8on
and
Resolu8on
159

160
Cycle
Time
Cycle time is a measure of how long it
takes to get things done. It spans from
when the team starts working on a
piece of the project such as a user story
until that item is finished, is accepted,
and can deliver business value. The
project cycle time is the average of
work items cycle times.
Cycle time = WIP / Throughput
Agile and lean
approaches
aim to limit WIP
The amount of output from a process
(in other words, the amount of work
the project team is able to do.

161
Test
your
Knowledge
Imagine a bicycle factory that produces
25 bikes per day and typically works on
100 bikes at any given time. Calculate
the average length of time it takes to
make a bike.
Answer:
WIP =
Throughput =
Cycle time =
Cycle time = WIP / Throughput

162
Benefits
$ Throughput allows us to forecast future
capability without specifically needing to
know what the team might be asked to
do.
$ Cycle time allows us to make reliable
commitment to the customer or
organization about how long it will take
to deliver work.
$ WIP measures how much work we have
“in the hopper” and gives us insight into
issues, bottlenecks in the process, and
rework-related risks.

163
Escaped
Defects
$ Defects that are not discovered
during the project’s testing and
validation processes and instead
make it to the customer. They are
most costly to fix and are at the
top of the cost of change graph.
$ Escaped defects found metric
counts the number of escaped
defects discovered over a period
of time (days, weeks, or months) Source: Scott Ambler

Project
and
Quality
Standards
164
$ Problem detection and resolution is
closely related to quality management.
The testing processes and other
practices we put in place to find
defects are part of the quality
assurance and quality control efforts on
our projects.
$ Project and Quality standards refers to
the agreed-upon approach the team
will take to measure “fitness for purpose”
– What will the team do to ensure the
quality and value of the product?

Quality
Standards
and
Prac8ces
165
Quality standards and practices can include:
$ Measuring product quality by tests passed and
customer acceptance
$ Automating as many tests as possible
$ Making sure testing occurs as part of every iteration
$ Trying to fix at least 90% of defects found within the
next iteration
$ Encouraging the quality control and quality
assurance representatives to work with the developers
and business representatives to understand the
acceptance criteria for each feature
$ Only classifying defects as fixed when the business
representatives, not the developers, say they are done
$ Ensuring testers collaborate with developers on
defects found and walking through the steps to
recreate the defect

Failure
Modes
and
Alterna8ves
166
These ideas relate to the human side of performance and
process:
1. Making mistakes: This is one of the main reasons iterative and
incremental development was created- to recognize the fact
that mistakes happen and to provide mechanisms to recover
and quickly overcome that fact.
2. Preferring to fail conservatively: People tend to revert back to
what they know, even if they are aware that it might not be
the optimal approach to take.
3. Inventing rather than researching: Many people tend to
invent ways of doing things rather than research available
options and then reuse them
4. Being creatures of habit: Even when we know there are better
approaches, we do not adopt them because at some level
(consciously or unconsciously), change is unappealing
5. Being inconsistent: The challenge is not just finding better
ways of doing things, it is getting people to accept the new
ways, change their own approaches, and then apply the
new approaches consistently.

167
Success
Modes
Success modes include:
1. Being good at looking around: refers to
people’s ability to observe, review, and
notice when things are not right.
2. Being able to learn: After seeing what’s
wrong, we find ways to fix it and grown
our skills and knowledge along the
way.
3. Being malleable: The ability to change
and accept new ideas and
approaches.
4. Taking pride in work: The ability to step
outside of our job descriptions to repair
or report an issue, because it is the right
thing to do for the project.

Strategies
for
Overcoming
Failure
Modes
168
1. Countering with discipline and
tolerance
2. Start with something concrete and
tangible
3. Copying and altering
4. Watching and listening
5. Supporting concentration and
communication
6. Personality-matched work assignments
7. Talent
8. Rewards that preserve joy
9. Combining rewards
10. Feedback
Source: PMI-ACP Exam Prep P. 259-261

Variance
and
Trend
Analysis
169
$ Variance is the measure of how far
apart things are (or how much things
vary from each other).
$ Variance is normal and should be
expected, but we need to learn how
to live within acceptable limits. And if
variance fluctuates beyond
acceptable limits, we need to know
how to act.
Quality expert W. Edward Deming classifies variance into common cause variation
and special cause variation. Common cause variation refers to the average day-to-day
differences of doing work, and special cause variation refers to the greater
degrees of variance due to special or new factors.

170
Varia8on
Common cause variation Special cause
Someone
turns off
the lights
Deming describes the two classic mistakes manager make as:
Mistake 1: To react to an outcome as if it came from a special
cause, when actually it came from common causes of variation.
Mistake 2: To react to an outcome as if it came from common
causes of variation, when actually it came from a special cause.

Con8nuous
Integra8on
Fail
Pass
171
$ Continuous integration is a
software development process.
Using this technique, the team
frequently integrates new and
changed code into the project
code repository.
$ The following are the
components of a continuous
integration system:
$ Source code control system
$ Build tools
$ Test tools
$ Scheduler or trigger
$ Notifications
Source code
control system
Source code
Source code
Source code
Continuous
integration
Fail
Pass
Source code
build and test
Notification
Notification

Fast failure Late failure
172
$ A risk-based spike is a
short proof of concept
exercise that the team
undertakes to
investigate an issue.
$ This approach of
doing short
experiments to
investigate risky
portions of the project
is at the heart of risk-based
spikes
Time
Risk
Fast Failure
%
%
Saved resources
Early risk reduction
via risk-based spikes
Late risk
reduction
Risk-­‐Based
Spike

Frequent
Verifica8on
and
Valida8on
months
weeks
173
$ Frequent verification
and validation is
practiced at many
levels on agile projects.
$ The idea behind
frequent verification
and validation is all
about finding issues as
soon as possible and
keeping them low on
the cost of change
curve.
IteraEon
demo
Acceptance
test
Stand-­‐up
meeEng
Customer
CollaboraEon
Pair
Programming
Code
Unit
test
hours
minutes
seconds
one
day
Release
days

Test-­‐Driven
Development
(TDD)
/
Test-­‐First
Development
(TFD)
174
$ Test-driven development (TDD)
and test-first development (TFD)
are also techniques from the
software development industry.
$ The philosophy behind TDD is
that tests should be written before
the code is written. In other words,
developers should first think about
how the functionality should be
tested then write tests in a unit
testing language (like NUnit or
JUnit) before they actually begin
developing the code.
Add
test
Run
tests
Write
code
Run
tests
Is
more
funcEonality
sEll
needed?
Refactor
/
Clean
pass
No
Yes
Development
conEnues
if
more
funcEonality
is
needed
All
tests
pass,
so
we
refactor
and
stop
development
Fail
Fail
Red
Green
Also review Acceptance Test-
Driven Development (ATDD)

Problem
Solving:
Gather
Data
175
1.
Gather
data
2.
Generate
insights
3.
Decide
what
to
do
$ Data gathering activities help create a
shared vision of the problem. Without
data, the team is simply speculating on
what changes and improvements should
be made
$ Team-based facilitation techniques
that can be used to help gather data
includes:
$ Timeline
$ Triple nickels
$ Color code dots
$ Mad, sad, glad
$ Locate strengths
$ Satisfaction histograms
$ Team radar
$ Like to like

Problem
Solving:
Generate
insights
176
1.
Gather
data
2.
Generate
insights
3.
Decide
what
to
do
$ This step involves collaborative exercises
that are aimed at analyzing the data
gathered in the previous step and making
sense out of it.
$ Activities to help team generate insights
includes:
$ Brainstorming
$ Five whys
$ Fishbone
$ Prioritize with dots
$ Identify themes

Problem
Solving:
Decide
What
to
do
177
1.
Gather
data
2.
Generate
insights
3.
Decide
what
to
do
$ The last step in the problem-solving process
is deciding what to do about the problem.
What actions need to be taken to solve the
problem?
$ The techniques commonly used in this
process include:
$ Short subjects
$ What went well, Do differently next
time
$ Keep, Drop, Add
$ Start Doing, Stop Doing, Do More
Of, Do Less Of
$ SMART goals (Specific, Measurable,
Attainable, Relevant, and Timely)
$ Retrospective planning game
$ Circle of questions

Why
such
focus
on
engaging
the
team?
178
$ Benefits of team engagement:
1. By asking the team for a solution,
we inherit consensus for the
proposal
2. Engaging the team gives us
access to a broader knowledge
of the facts
3. Solutions are practical
4. When consulted, people work
hard to generate good ideas
5. Asking for help shows confidence,
not weakness
6. Seeking others’ ideas models
desired behavior
Usages and Cautions:
$ Solve real problems
$ Poor team cohesion
$ Team and project
changes
$ Follow-through

179
Con8nuous
Improvement

180
Kaizen
• To make better
(Continuous
improvement)
• Aims to eliminate
waste

181
Lessons
Learned
What is the biggest
problem with lessons
learned on projects?
They
are
NEVER
used
To capture lessons learned while they
are still actionable.

182
Retrospec8ves
• A retrospective is a
special meeting
that takes place
after each
iteration, in which
the team members
gather to inspect
and improve their
methods and
teamwork.

183
Benefits
of
Retrospec8ves
Improved
Productivity
Team can get more
productive by
applying lessons
learned reducing
rework
Capability
Provides a venue to
spreading scarce
knowledge
Quality
Improve quality by
finding the
circumstances that
led to defects and
remove the causes
Capacity
Focus on finding
process efficiency
improvements
which can improve
the team’s
capacity to do
work

184
1. Set the
stage
2. Gather Data
3. Generate
insights
4. Decide
what to do
5. Close the
retrospective
3. Deliver completed
user stories for
evaluation
2. Build and test
selected user stories
1. Plan the iteration,
incorporating
improvements and
experiments identified
in the retrospective
Retrospective
Steps
of
a
Retrospec8ve

185
1. Set the
stage
2. Gather Data
3. Generate
insights
4. Decide
what to do
5. Close the
retrospective
Retrospective
Set
the
Stage
$ Create an atmosphere where people feel
comfortable speaking about things that may not have
gone so well
$ Outline the retrospective’s approach and topics for
discussion with a clear purpose and agenda
$ Help people focus on the task at hand of reflecting on
how things went
$ Establish a team-owned working agreement about
what is acceptable and what is not acceptable during
the retrospective
$ Prepare the participants in the next steps in the
retrospective
$ Get people in the right mode for contributing
information and ideas
Activities include:
- Check-In: In a round robin format, ask people to
summarize one or two words what they hope to get
from the retrospective, the main thing on their mind, or
how they are feeling about the retrospective

186
1. Set the
stage
2. Gather Data
3. Generate
insights
4. Decide
what to do
5. Close the
retrospective
Retrospective
$ Create a shared picture of what happened during
the iteration (or release or project)
Activities include:
- Timeline: The team could use this technique to
diagnose the origin and progression of a single problem
or a number of problems
1
2
3
4
5
good
Problematic
Significant
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
Glad
Sad
Gather
Data

187
1. Set the
stage
2. Gather Data
3. Generate
insights
4. Decide
what to do
5. Close the
retrospective
Retrospective
$ Analyze the data gathered in the previous step and
making sense out of it.
Activities include:
- Brainstorming: This exercise aim to generate a large
number of ideas that are then filtered into a select
list of ideas to move forward on the process
(Examples of techniques used include: Free-for-all,
Round-robin, Quiet time)
- Five whys: The aim of this exercise is to discover the
cause-and-effect relationships underlying particular
problem and get to the root cause of the problem.
Fishbone: A fishbone diagram is a visual tool that
often accompanies the five why exercise. It is a way
to display the root cause analysis of problems.
Failed
PMI-­‐
ACP
Exam
Generate
Insights

188
1. Set the
stage
2. Gather Data
3. Generate
insights
4. Decide
what to do
5. Close the
retrospective
Retrospective
Decide
What
to
Do
$ Identify the highest-priority action items
$ Create a detailed plan for experiments
$ Set measurable goals to achieve the desired results
Activities include:
- Short Subjects: This activity helps the team agree on
problem-resolution actions. The team is presented
with flip chart or whiteboards with categories written
on them, and the team then agrees on which ideas
to pursue. The categories may include:
- What Went Well, Do Differently Next Time
- Keep, Drop, Add
- Start Doing, Stop Doing, Do More Of, Do Less Of
- SMART Goals: This activity helps the team create
goals that are Specific, Measurable, Attainable,
Relevant, and Timely. (Instead of “We need to do
more testing”, SMART goal would be “Each module
must have and pass a unit test, functional test, and
system test before iteration end.”

Close
the
Retrospec8ve
Plus
Delta
189
1. Set the
stage
2. Gather Data
3. Generate
insights
4. Decide
what to do
5. Close the
retrospective
Retrospective
$ Reflect on what happened during the retrospective
$ Express appreciation to each other
$ Summarizes what the team decided to do going
forward
$ Round out the retrospective and reinforce its value
to the project
Activities include:
- Plus/Delta Activity: In this exercise, we capture
and validate the teams’ ideas for what we should
do more of (things that are going well) and what
we should change (things that are not going well)
on a whiteboard or flip chart.
- Appreciations: During this exercise, team
members have a chance to express appreciation
to other team members for their help,
contributions, problem-solving efforts, etc.

190
Knowledge
Sharing
$ Knowledge sharing is a key component of agile
methods. (A knowledge worker project is
characterized by subject matter experts
collaborating to create or enhance a project or
service.)
$ Examples of knowledge transfer vehicles:
$ Product demos: The purpose is share
knowledge through a dialogue.
$ Co-location: To leverage the sharing of tacit
(unwritten) knowledge that occurs in face-to-face
environments and through osmotic
communication.
$ Daily stand-up: the real goal of the stand-up
meeting is to share information within the team.
$ Retrospective: Sharing ideas about what
works, what doesn’t and what to do to improve
Team to customer: Here is
what we think you asked for
and what we have been
able to build. Please tell us
if we are on the right track.
Customer to team: I like the
way the screens look, and
this is ok, but you got this
piece wrong. Oh, and that
reminds me—we really
need something over here
to do X.
Individuals are mostly rewarded for what they know, not what they share. –Kimiz Dalkir (Knowledge
Management in Theory and Practice)

Measuring
Up
You get what you measure, in fact
you only get what you measure,
nothing else. So you tend to lose the
things that you can’t measure, like
knowledge sharing, insight,
collaboration and creativity. – Robert
Austin, Measuring and Managing Performance in
Organizations
191
$ Measuring up refer to measuring
something at one level above the
normal span of control (e.g., at the
team level, rather than the
individual level) to encourage
cooperation and knowledge
sharing
$ Example:
$ Velocity (Capacity) is measured
at the team level
$ Team accomplishments
(Reward team
accomplishments, so that there
are no benefit of hoarding
information)

Process
Tailoring
Removing or augmenting elements without
understanding the relationship between
them can lead to problems…
If you remove one practice without
understanding its counterbalance, you
may be headed for trouble.
-Mike Griffiths, PMI-ACP Exam Prep
192
Shu
(Obey
the
rule)
Ha
(Detach
from
the
rule)
Ri
(Be
the
rule)
$ Scrum vs. Kanban: Scrum is less
keen on tailoring while “Kanban as
noted by David Anderson, is giving
permission…to create a tailored
process optimized to a specific
context
$ Benefits and risks are in both
extremes
$ Process-per-project-approach (Jim
Highsmith and Alistair Cockburn):
This means creating processes that
are situationally specific for the job
at hand
$ The balance is in risk mitigation. The
risk of failure is high when people
inexperienced in agile methods
modify the methods

Principles
of
Systems
Thinking
Agile works
well here
193
Low
complexity
Simple
Anarchy /
chaos
Complex
Far from
agreement
Requirements
Close to
agreement
Low
complexity
Technology Close to
certainty
Far from
certainty

Process
analysis
include
reviewing
and
diagnosing
issues
with
agile
methods
or,
more
likely
our
home-­‐grown
add-­‐ons
and
replacements
to
agile
methods.
194
Methodology
an8-­‐paXerns
(or
bad
things
about
methodologies
to
watch
out
for):
1. One
size
for
all
projects
(be
wary
of
claims
of
a
one-­‐size-­‐fits-­‐all
approach)
2. Intolerant
(have
liWle
wiggle
room
for
the
team
to
be
flexible)
3. Heavy
(There
is
a
common
but
incorrect
belief
that
the
heavier
a
methodology
in
its
arEfacts
and
pracEces,
the
safer
it
is)
4. Embellished
(We
add
in
things
that
we
think
we
“ought
to”
or
“should”
be
doing)
5. Untried
(They
are
proposals
created
from
nothing
and
are
full-­‐
blown
“shoulds”
in
acEon)
6. Used
once
(Just
because
an
approach
worked
under
one
set
of
circumstances
does
not
guarantee
it
will
work
under
another)
Source: Alistain Cockburn
Process
Analysis

Continuous improvement is the ongoing process of enhancing the project
approach, and the product.
Continuous Process Improvement Continuous Product Improvement
195
Plan
Do
(Develop)
Act
(Learn)
Check
(Evaluate)
Con8nuous
Improvement
Processes

196
• A
standard
pracEce
for
agile
teams
to
con8nuously
reflect
on
how
well
they
are
doing
and
to
look
for
things
they
can
improve.
• Use
self
assessment
tools
to
measure
where
you
stand.
Self-­‐Assessment
Self-­‐Assessment
Scoring
Model
Developing
Thinking
CollaboraEng
Planning
Releasing

197
1. Self-­‐organiza8on
2. Empowered
to
make
decisions
3. Belief
in
vision
and
success
4. CommiXed
team
5. Trust
each
other
6. Par8cipatory
decision
making
7. Consensus-­‐driven
8. Construc8ve
disagreement
Source: Jean Tabaka
High-­‐Performing
Team
Our
ul8mate
goal
is
to
grown
and
develop
high-­‐performing
teams.

198
• Apply
and
prepare
for
the
exam.
• Set
a
Emeline
to
take
the
exam.
• Review
the
PMI-­‐ACP
book
at
least
twice.
• Remember
to
go
over
the
quesEons
at
the
end
of
each
chapter.
• Take
as
many
pracEce
exams
as
you
can
(www.agileexams.com)
• Celebrate
your
accomplishment
(passing
the
exam).
Next
Steps

199
• PMI-­‐ACP
References
/
Resources
Exam
Prep
by
Mike
Griffiths
• Agile
Project
Management
by
Jim
Highsmith
• Being
Agile
in
an
imperfect
world
by
Dr.
Ahmed
Sidky
and
Greg
Smith
• Agile
Planning
and
EsEmaEng
by
Mike
Cohn
• Coaching
Agile
Teams
by
Lyssa
Adkins
• RetrospecEves:
making
good
teams
great
by
Esther
Derby
and
Diana
Larsen
• PMI
Agile
Community
of
PracEce
• Agileexams.com

200
Contact
Informa8on
Salah
Elleithy
410.262.5550
salah@sparkagility.com
Linkedin.com/in/selleithy