SlideShare une entreprise Scribd logo
1  sur  200
Télécharger pour lire hors ligne
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

Contenu connexe

Tendances

Agile Project Management - An introduction to Agile and the new PMI-ACP
Agile Project Management - An introduction to Agile and the new PMI-ACPAgile Project Management - An introduction to Agile and the new PMI-ACP
Agile Project Management - An introduction to Agile and the new PMI-ACPDimitri Ponomareff
 
PMI-ACP Domain 1 Agile Principles and Mindset
PMI-ACP Domain 1 Agile Principles and MindsetPMI-ACP Domain 1 Agile Principles and Mindset
PMI-ACP Domain 1 Agile Principles and MindsetJoshua Render
 
Enterprise Agile Transformation Strategies
Enterprise Agile Transformation StrategiesEnterprise Agile Transformation Strategies
Enterprise Agile Transformation StrategiesMike Cottmeyer
 
What is Agile Project Management? | Agile Project Management | Invensis Learn...
What is Agile Project Management? | Agile Project Management | Invensis Learn...What is Agile Project Management? | Agile Project Management | Invensis Learn...
What is Agile Project Management? | Agile Project Management | Invensis Learn...Invensis Learning
 
Agile Process Introduction
Agile Process IntroductionAgile Process Introduction
Agile Process IntroductionNguyen Hai
 
Agile Program and Portfolio Management
Agile Program and Portfolio ManagementAgile Program and Portfolio Management
Agile Program and Portfolio ManagementMike Cottmeyer
 
Agile transformation best practices
Agile transformation best practicesAgile transformation best practices
Agile transformation best practicesAllyson Chiarini
 
Scrum 101
Scrum 101Scrum 101
Scrum 101beLithe
 
Agile transformation 1.3
Agile transformation 1.3Agile transformation 1.3
Agile transformation 1.3Krystian Kaczor
 
Portfolio Management in an Agile World - Rick Austin
Portfolio Management in an Agile World - Rick AustinPortfolio Management in an Agile World - Rick Austin
Portfolio Management in an Agile World - Rick AustinLeadingAgile
 
Agile methodologiesvswaterfall
Agile methodologiesvswaterfallAgile methodologiesvswaterfall
Agile methodologiesvswaterfallMuthu Natarajan
 
What are the Tools & Techniques in Agile Project Management?
What are the Tools & Techniques in Agile Project Management?What are the Tools & Techniques in Agile Project Management?
What are the Tools & Techniques in Agile Project Management?Tuan Yang
 
Agile Transformation in Telco Guide
Agile Transformation in Telco GuideAgile Transformation in Telco Guide
Agile Transformation in Telco GuideACM
 

Tendances (20)

Agile Project Management - An introduction to Agile and the new PMI-ACP
Agile Project Management - An introduction to Agile and the new PMI-ACPAgile Project Management - An introduction to Agile and the new PMI-ACP
Agile Project Management - An introduction to Agile and the new PMI-ACP
 
PMI-ACP Domain 1 Agile Principles and Mindset
PMI-ACP Domain 1 Agile Principles and MindsetPMI-ACP Domain 1 Agile Principles and Mindset
PMI-ACP Domain 1 Agile Principles and Mindset
 
Enterprise Agile Transformation Strategies
Enterprise Agile Transformation StrategiesEnterprise Agile Transformation Strategies
Enterprise Agile Transformation Strategies
 
What is Agile Project Management? | Agile Project Management | Invensis Learn...
What is Agile Project Management? | Agile Project Management | Invensis Learn...What is Agile Project Management? | Agile Project Management | Invensis Learn...
What is Agile Project Management? | Agile Project Management | Invensis Learn...
 
Scrum and JIRA
Scrum and JIRAScrum and JIRA
Scrum and JIRA
 
Agile Process Introduction
Agile Process IntroductionAgile Process Introduction
Agile Process Introduction
 
Agile Program and Portfolio Management
Agile Program and Portfolio ManagementAgile Program and Portfolio Management
Agile Program and Portfolio Management
 
Waterfall to Agile
Waterfall to AgileWaterfall to Agile
Waterfall to Agile
 
Agile transformation best practices
Agile transformation best practicesAgile transformation best practices
Agile transformation best practices
 
Agile
Agile Agile
Agile
 
Scrum 101
Scrum 101Scrum 101
Scrum 101
 
Agile transformation 1.3
Agile transformation 1.3Agile transformation 1.3
Agile transformation 1.3
 
What Is Agile Scrum
What Is Agile ScrumWhat Is Agile Scrum
What Is Agile Scrum
 
Portfolio Management in an Agile World - Rick Austin
Portfolio Management in an Agile World - Rick AustinPortfolio Management in an Agile World - Rick Austin
Portfolio Management in an Agile World - Rick Austin
 
Agile methodologiesvswaterfall
Agile methodologiesvswaterfallAgile methodologiesvswaterfall
Agile methodologiesvswaterfall
 
Agile & Scrum Training
Agile & Scrum TrainingAgile & Scrum Training
Agile & Scrum Training
 
Agile mindset
Agile mindsetAgile mindset
Agile mindset
 
Scrumban (r)Evolution
Scrumban (r)EvolutionScrumban (r)Evolution
Scrumban (r)Evolution
 
What are the Tools & Techniques in Agile Project Management?
What are the Tools & Techniques in Agile Project Management?What are the Tools & Techniques in Agile Project Management?
What are the Tools & Techniques in Agile Project Management?
 
Agile Transformation in Telco Guide
Agile Transformation in Telco GuideAgile Transformation in Telco Guide
Agile Transformation in Telco Guide
 

Similaire à PMI ACP Prep Course

Agile Basics / Fundamentals
Agile Basics / FundamentalsAgile Basics / Fundamentals
Agile Basics / Fundamentalssparkagility
 
Agile Basics Slides PMIBC - Feb 2015
Agile Basics Slides PMIBC - Feb 2015Agile Basics Slides PMIBC - Feb 2015
Agile Basics Slides PMIBC - Feb 2015sparkagility
 
Fundamentals of Agile
Fundamentals of AgileFundamentals of Agile
Fundamentals of Agilesparkagility
 
What Product Managers Need to Know About Agile Development with Scrum
What Product Managers Need to Know About Agile Development with ScrumWhat Product Managers Need to Know About Agile Development with Scrum
What Product Managers Need to Know About Agile Development with ScrumLaura Klemme
 
"At the Intersection of Agile and Change Management" - ACMP USA
"At the Intersection of Agile and Change Management" - ACMP USA"At the Intersection of Agile and Change Management" - ACMP USA
"At the Intersection of Agile and Change Management" - ACMP USATim Creasey
 
PMI-ACP Exam Prep Course Preview
PMI-ACP Exam Prep Course PreviewPMI-ACP Exam Prep Course Preview
PMI-ACP Exam Prep Course PreviewInvensis Learning
 
Scaling agile. Agile across the enterprise
Scaling agile. Agile across the enterpriseScaling agile. Agile across the enterprise
Scaling agile. Agile across the enterpriseDarren Wilmshurst
 
Next Generation Project Management: Evolving, Transforming and Adapting to th...
Next Generation Project Management: Evolving, Transforming and Adapting to th...Next Generation Project Management: Evolving, Transforming and Adapting to th...
Next Generation Project Management: Evolving, Transforming and Adapting to th...Kaali Dass PMP, PhD.
 
AGILE2017 Top 10 Takeaways by Synerzip
AGILE2017 Top 10 Takeaways by SynerzipAGILE2017 Top 10 Takeaways by Synerzip
AGILE2017 Top 10 Takeaways by SynerzipSynerzip
 
Final synerzip-agile2017-top10-v1
Final synerzip-agile2017-top10-v1Final synerzip-agile2017-top10-v1
Final synerzip-agile2017-top10-v1Hemant Elhence
 
Agile Comes to You (Mironov, Bellevue)
Agile Comes to You (Mironov, Bellevue)Agile Comes to You (Mironov, Bellevue)
Agile Comes to You (Mironov, Bellevue)Enthiosys Inc
 
Professional Project Manager Should Be Proficient in Agile
Professional Project Manager Should Be Proficient in AgileProfessional Project Manager Should Be Proficient in Agile
Professional Project Manager Should Be Proficient in AgileNitor
 
Practical Scrum - one day training
Practical Scrum - one day training Practical Scrum - one day training
Practical Scrum - one day training Anat (Alon) Salhov
 
Let's Talk… AGILE
Let's Talk… AGILELet's Talk… AGILE
Let's Talk… AGILENah Wee Yang
 
Agile concepts and opportunities for contract management r walters
Agile concepts and opportunities for contract management  r walters Agile concepts and opportunities for contract management  r walters
Agile concepts and opportunities for contract management r walters Expressworks International
 

Similaire à PMI ACP Prep Course (20)

Agile Basics / Fundamentals
Agile Basics / FundamentalsAgile Basics / Fundamentals
Agile Basics / Fundamentals
 
Agile Basics Slides PMIBC - Feb 2015
Agile Basics Slides PMIBC - Feb 2015Agile Basics Slides PMIBC - Feb 2015
Agile Basics Slides PMIBC - Feb 2015
 
Fundamentals of Agile
Fundamentals of AgileFundamentals of Agile
Fundamentals of Agile
 
What Product Managers Need to Know About Agile Development with Scrum
What Product Managers Need to Know About Agile Development with ScrumWhat Product Managers Need to Know About Agile Development with Scrum
What Product Managers Need to Know About Agile Development with Scrum
 
Agile Fundamentals for Project Managers.pdf
Agile Fundamentals for Project Managers.pdfAgile Fundamentals for Project Managers.pdf
Agile Fundamentals for Project Managers.pdf
 
Agile Project Management
Agile Project ManagementAgile Project Management
Agile Project Management
 
What is agile?
What is agile?What is agile?
What is agile?
 
"At the Intersection of Agile and Change Management" - ACMP USA
"At the Intersection of Agile and Change Management" - ACMP USA"At the Intersection of Agile and Change Management" - ACMP USA
"At the Intersection of Agile and Change Management" - ACMP USA
 
PMI-ACP Exam Prep Course Preview
PMI-ACP Exam Prep Course PreviewPMI-ACP Exam Prep Course Preview
PMI-ACP Exam Prep Course Preview
 
Scaling agile. Agile across the enterprise
Scaling agile. Agile across the enterpriseScaling agile. Agile across the enterprise
Scaling agile. Agile across the enterprise
 
Ben Mkt 347 Week 4
Ben Mkt 347 Week 4Ben Mkt 347 Week 4
Ben Mkt 347 Week 4
 
Agile for Business
Agile for BusinessAgile for Business
Agile for Business
 
Next Generation Project Management: Evolving, Transforming and Adapting to th...
Next Generation Project Management: Evolving, Transforming and Adapting to th...Next Generation Project Management: Evolving, Transforming and Adapting to th...
Next Generation Project Management: Evolving, Transforming and Adapting to th...
 
AGILE2017 Top 10 Takeaways by Synerzip
AGILE2017 Top 10 Takeaways by SynerzipAGILE2017 Top 10 Takeaways by Synerzip
AGILE2017 Top 10 Takeaways by Synerzip
 
Final synerzip-agile2017-top10-v1
Final synerzip-agile2017-top10-v1Final synerzip-agile2017-top10-v1
Final synerzip-agile2017-top10-v1
 
Agile Comes to You (Mironov, Bellevue)
Agile Comes to You (Mironov, Bellevue)Agile Comes to You (Mironov, Bellevue)
Agile Comes to You (Mironov, Bellevue)
 
Professional Project Manager Should Be Proficient in Agile
Professional Project Manager Should Be Proficient in AgileProfessional Project Manager Should Be Proficient in Agile
Professional Project Manager Should Be Proficient in Agile
 
Practical Scrum - one day training
Practical Scrum - one day training Practical Scrum - one day training
Practical Scrum - one day training
 
Let's Talk… AGILE
Let's Talk… AGILELet's Talk… AGILE
Let's Talk… AGILE
 
Agile concepts and opportunities for contract management r walters
Agile concepts and opportunities for contract management  r walters Agile concepts and opportunities for contract management  r walters
Agile concepts and opportunities for contract management r walters
 

Plus de sparkagility

Agile Indicators: Start with Questions!
Agile Indicators: Start with Questions!Agile Indicators: Start with Questions!
Agile Indicators: Start with Questions!sparkagility
 
Growing an agile mindset
Growing an agile mindsetGrowing an agile mindset
Growing an agile mindsetsparkagility
 
3 Essential Coaching Skills
3 Essential Coaching Skills3 Essential Coaching Skills
3 Essential Coaching Skillssparkagility
 
Agile Charm 2020 Baltimore
Agile Charm 2020 BaltimoreAgile Charm 2020 Baltimore
Agile Charm 2020 Baltimoresparkagility
 
Agile DC 2019: Agile Indicators: Start with Questions!
Agile DC 2019: Agile Indicators: Start with Questions!Agile DC 2019: Agile Indicators: Start with Questions!
Agile DC 2019: Agile Indicators: Start with Questions!sparkagility
 
A&B2019 Mobbing for Learning!
A&B2019 Mobbing for Learning!A&B2019 Mobbing for Learning!
A&B2019 Mobbing for Learning!sparkagility
 
Goals driven delivery with impact mapping pmi-march2019
Goals driven delivery with impact mapping pmi-march2019Goals driven delivery with impact mapping pmi-march2019
Goals driven delivery with impact mapping pmi-march2019sparkagility
 
Kicking Off Your First Agile Project @PMIWDC
Kicking Off Your First Agile Project @PMIWDC Kicking Off Your First Agile Project @PMIWDC
Kicking Off Your First Agile Project @PMIWDC sparkagility
 
Mobbing for learning @Agile DC 2018
Mobbing for learning @Agile DC 2018Mobbing for learning @Agile DC 2018
Mobbing for learning @Agile DC 2018sparkagility
 
Pmiwdc 3key-ingredients-to-organizational-agility
Pmiwdc 3key-ingredients-to-organizational-agilityPmiwdc 3key-ingredients-to-organizational-agility
Pmiwdc 3key-ingredients-to-organizational-agilitysparkagility
 
Three_keys_to_self-direction_and_leadership_agile2015_Christopher_Avery
Three_keys_to_self-direction_and_leadership_agile2015_Christopher_AveryThree_keys_to_self-direction_and_leadership_agile2015_Christopher_Avery
Three_keys_to_self-direction_and_leadership_agile2015_Christopher_Averysparkagility
 
Government PO What to expect when they are expecting
Government PO What to expect when they are expectingGovernment PO What to expect when they are expecting
Government PO What to expect when they are expectingsparkagility
 
Agile2015 - Our Business Pipeline is Broken
Agile2015 - Our Business Pipeline is BrokenAgile2015 - Our Business Pipeline is Broken
Agile2015 - Our Business Pipeline is Brokensparkagility
 
Changing ways agile meetup 2015 11-12
Changing ways   agile meetup 2015 11-12Changing ways   agile meetup 2015 11-12
Changing ways agile meetup 2015 11-12sparkagility
 
The Data Greenhouse DevOps Measurement at Scale
The Data Greenhouse  DevOps Measurement at ScaleThe Data Greenhouse  DevOps Measurement at Scale
The Data Greenhouse DevOps Measurement at Scalesparkagility
 
ReadyforAgile Webinar hosted by ICAgile
ReadyforAgile Webinar hosted by ICAgileReadyforAgile Webinar hosted by ICAgile
ReadyforAgile Webinar hosted by ICAgilesparkagility
 
Training from the BACK of the Room
Training from the BACK of the RoomTraining from the BACK of the Room
Training from the BACK of the Roomsparkagility
 
Designing productive meetings
Designing productive meetingsDesigning productive meetings
Designing productive meetingssparkagility
 
3 key ingredients-to-enabling-agility
3 key ingredients-to-enabling-agility3 key ingredients-to-enabling-agility
3 key ingredients-to-enabling-agilitysparkagility
 

Plus de sparkagility (20)

Agile Indicators: Start with Questions!
Agile Indicators: Start with Questions!Agile Indicators: Start with Questions!
Agile Indicators: Start with Questions!
 
Growing an agile mindset
Growing an agile mindsetGrowing an agile mindset
Growing an agile mindset
 
3 Essential Coaching Skills
3 Essential Coaching Skills3 Essential Coaching Skills
3 Essential Coaching Skills
 
Agile Charm 2020 Baltimore
Agile Charm 2020 BaltimoreAgile Charm 2020 Baltimore
Agile Charm 2020 Baltimore
 
Agile DC 2019: Agile Indicators: Start with Questions!
Agile DC 2019: Agile Indicators: Start with Questions!Agile DC 2019: Agile Indicators: Start with Questions!
Agile DC 2019: Agile Indicators: Start with Questions!
 
A&B2019 Mobbing for Learning!
A&B2019 Mobbing for Learning!A&B2019 Mobbing for Learning!
A&B2019 Mobbing for Learning!
 
Goals driven delivery with impact mapping pmi-march2019
Goals driven delivery with impact mapping pmi-march2019Goals driven delivery with impact mapping pmi-march2019
Goals driven delivery with impact mapping pmi-march2019
 
Kicking Off Your First Agile Project @PMIWDC
Kicking Off Your First Agile Project @PMIWDC Kicking Off Your First Agile Project @PMIWDC
Kicking Off Your First Agile Project @PMIWDC
 
Mobbing for learning @Agile DC 2018
Mobbing for learning @Agile DC 2018Mobbing for learning @Agile DC 2018
Mobbing for learning @Agile DC 2018
 
Pmiwdc 3key-ingredients-to-organizational-agility
Pmiwdc 3key-ingredients-to-organizational-agilityPmiwdc 3key-ingredients-to-organizational-agility
Pmiwdc 3key-ingredients-to-organizational-agility
 
Three_keys_to_self-direction_and_leadership_agile2015_Christopher_Avery
Three_keys_to_self-direction_and_leadership_agile2015_Christopher_AveryThree_keys_to_self-direction_and_leadership_agile2015_Christopher_Avery
Three_keys_to_self-direction_and_leadership_agile2015_Christopher_Avery
 
Government PO What to expect when they are expecting
Government PO What to expect when they are expectingGovernment PO What to expect when they are expecting
Government PO What to expect when they are expecting
 
Agile2015 - Our Business Pipeline is Broken
Agile2015 - Our Business Pipeline is BrokenAgile2015 - Our Business Pipeline is Broken
Agile2015 - Our Business Pipeline is Broken
 
Changing ways agile meetup 2015 11-12
Changing ways   agile meetup 2015 11-12Changing ways   agile meetup 2015 11-12
Changing ways agile meetup 2015 11-12
 
The Data Greenhouse DevOps Measurement at Scale
The Data Greenhouse  DevOps Measurement at ScaleThe Data Greenhouse  DevOps Measurement at Scale
The Data Greenhouse DevOps Measurement at Scale
 
ReadyforAgile Webinar hosted by ICAgile
ReadyforAgile Webinar hosted by ICAgileReadyforAgile Webinar hosted by ICAgile
ReadyforAgile Webinar hosted by ICAgile
 
Unless accwc
Unless accwcUnless accwc
Unless accwc
 
Training from the BACK of the Room
Training from the BACK of the RoomTraining from the BACK of the Room
Training from the BACK of the Room
 
Designing productive meetings
Designing productive meetingsDesigning productive meetings
Designing productive meetings
 
3 key ingredients-to-enabling-agility
3 key ingredients-to-enabling-agility3 key ingredients-to-enabling-agility
3 key ingredients-to-enabling-agility
 

Dernier

Prescribed medication order and communication skills.pptx
Prescribed medication order and communication skills.pptxPrescribed medication order and communication skills.pptx
Prescribed medication order and communication skills.pptxraviapr7
 
Drug Information Services- DIC and Sources.
Drug Information Services- DIC and Sources.Drug Information Services- DIC and Sources.
Drug Information Services- DIC and Sources.raviapr7
 
How to Add a many2many Relational Field in Odoo 17
How to Add a many2many Relational Field in Odoo 17How to Add a many2many Relational Field in Odoo 17
How to Add a many2many Relational Field in Odoo 17Celine George
 
Easter in the USA presentation by Chloe.
Easter in the USA presentation by Chloe.Easter in the USA presentation by Chloe.
Easter in the USA presentation by Chloe.EnglishCEIPdeSigeiro
 
UKCGE Parental Leave Discussion March 2024
UKCGE Parental Leave Discussion March 2024UKCGE Parental Leave Discussion March 2024
UKCGE Parental Leave Discussion March 2024UKCGE
 
AUDIENCE THEORY -- FANDOM -- JENKINS.pptx
AUDIENCE THEORY -- FANDOM -- JENKINS.pptxAUDIENCE THEORY -- FANDOM -- JENKINS.pptx
AUDIENCE THEORY -- FANDOM -- JENKINS.pptxiammrhaywood
 
Practical Research 1: Lesson 8 Writing the Thesis Statement.pptx
Practical Research 1: Lesson 8 Writing the Thesis Statement.pptxPractical Research 1: Lesson 8 Writing the Thesis Statement.pptx
Practical Research 1: Lesson 8 Writing the Thesis Statement.pptxKatherine Villaluna
 
In - Vivo and In - Vitro Correlation.pptx
In - Vivo and In - Vitro Correlation.pptxIn - Vivo and In - Vitro Correlation.pptx
In - Vivo and In - Vitro Correlation.pptxAditiChauhan701637
 
Education and training program in the hospital APR.pptx
Education and training program in the hospital APR.pptxEducation and training program in the hospital APR.pptx
Education and training program in the hospital APR.pptxraviapr7
 
Clinical Pharmacy Introduction to Clinical Pharmacy, Concept of clinical pptx
Clinical Pharmacy  Introduction to Clinical Pharmacy, Concept of clinical pptxClinical Pharmacy  Introduction to Clinical Pharmacy, Concept of clinical pptx
Clinical Pharmacy Introduction to Clinical Pharmacy, Concept of clinical pptxraviapr7
 
3.21.24 The Origins of Black Power.pptx
3.21.24  The Origins of Black Power.pptx3.21.24  The Origins of Black Power.pptx
3.21.24 The Origins of Black Power.pptxmary850239
 
Benefits & Challenges of Inclusive Education
Benefits & Challenges of Inclusive EducationBenefits & Challenges of Inclusive Education
Benefits & Challenges of Inclusive EducationMJDuyan
 
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRADUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRATanmoy Mishra
 
Patient Counselling. Definition of patient counseling; steps involved in pati...
Patient Counselling. Definition of patient counseling; steps involved in pati...Patient Counselling. Definition of patient counseling; steps involved in pati...
Patient Counselling. Definition of patient counseling; steps involved in pati...raviapr7
 
How to Show Error_Warning Messages in Odoo 17
How to Show Error_Warning Messages in Odoo 17How to Show Error_Warning Messages in Odoo 17
How to Show Error_Warning Messages in Odoo 17Celine George
 
Presentation on the Basics of Writing. Writing a Paragraph
Presentation on the Basics of Writing. Writing a ParagraphPresentation on the Basics of Writing. Writing a Paragraph
Presentation on the Basics of Writing. Writing a ParagraphNetziValdelomar1
 
The basics of sentences session 10pptx.pptx
The basics of sentences session 10pptx.pptxThe basics of sentences session 10pptx.pptx
The basics of sentences session 10pptx.pptxheathfieldcps1
 
How to Use api.constrains ( ) in Odoo 17
How to Use api.constrains ( ) in Odoo 17How to Use api.constrains ( ) in Odoo 17
How to Use api.constrains ( ) in Odoo 17Celine George
 

Dernier (20)

Prescribed medication order and communication skills.pptx
Prescribed medication order and communication skills.pptxPrescribed medication order and communication skills.pptx
Prescribed medication order and communication skills.pptx
 
Drug Information Services- DIC and Sources.
Drug Information Services- DIC and Sources.Drug Information Services- DIC and Sources.
Drug Information Services- DIC and Sources.
 
How to Add a many2many Relational Field in Odoo 17
How to Add a many2many Relational Field in Odoo 17How to Add a many2many Relational Field in Odoo 17
How to Add a many2many Relational Field in Odoo 17
 
Easter in the USA presentation by Chloe.
Easter in the USA presentation by Chloe.Easter in the USA presentation by Chloe.
Easter in the USA presentation by Chloe.
 
Personal Resilience in Project Management 2 - TV Edit 1a.pdf
Personal Resilience in Project Management 2 - TV Edit 1a.pdfPersonal Resilience in Project Management 2 - TV Edit 1a.pdf
Personal Resilience in Project Management 2 - TV Edit 1a.pdf
 
UKCGE Parental Leave Discussion March 2024
UKCGE Parental Leave Discussion March 2024UKCGE Parental Leave Discussion March 2024
UKCGE Parental Leave Discussion March 2024
 
AUDIENCE THEORY -- FANDOM -- JENKINS.pptx
AUDIENCE THEORY -- FANDOM -- JENKINS.pptxAUDIENCE THEORY -- FANDOM -- JENKINS.pptx
AUDIENCE THEORY -- FANDOM -- JENKINS.pptx
 
Practical Research 1: Lesson 8 Writing the Thesis Statement.pptx
Practical Research 1: Lesson 8 Writing the Thesis Statement.pptxPractical Research 1: Lesson 8 Writing the Thesis Statement.pptx
Practical Research 1: Lesson 8 Writing the Thesis Statement.pptx
 
Finals of Kant get Marx 2.0 : a general politics quiz
Finals of Kant get Marx 2.0 : a general politics quizFinals of Kant get Marx 2.0 : a general politics quiz
Finals of Kant get Marx 2.0 : a general politics quiz
 
In - Vivo and In - Vitro Correlation.pptx
In - Vivo and In - Vitro Correlation.pptxIn - Vivo and In - Vitro Correlation.pptx
In - Vivo and In - Vitro Correlation.pptx
 
Education and training program in the hospital APR.pptx
Education and training program in the hospital APR.pptxEducation and training program in the hospital APR.pptx
Education and training program in the hospital APR.pptx
 
Clinical Pharmacy Introduction to Clinical Pharmacy, Concept of clinical pptx
Clinical Pharmacy  Introduction to Clinical Pharmacy, Concept of clinical pptxClinical Pharmacy  Introduction to Clinical Pharmacy, Concept of clinical pptx
Clinical Pharmacy Introduction to Clinical Pharmacy, Concept of clinical pptx
 
3.21.24 The Origins of Black Power.pptx
3.21.24  The Origins of Black Power.pptx3.21.24  The Origins of Black Power.pptx
3.21.24 The Origins of Black Power.pptx
 
Benefits & Challenges of Inclusive Education
Benefits & Challenges of Inclusive EducationBenefits & Challenges of Inclusive Education
Benefits & Challenges of Inclusive Education
 
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRADUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
 
Patient Counselling. Definition of patient counseling; steps involved in pati...
Patient Counselling. Definition of patient counseling; steps involved in pati...Patient Counselling. Definition of patient counseling; steps involved in pati...
Patient Counselling. Definition of patient counseling; steps involved in pati...
 
How to Show Error_Warning Messages in Odoo 17
How to Show Error_Warning Messages in Odoo 17How to Show Error_Warning Messages in Odoo 17
How to Show Error_Warning Messages in Odoo 17
 
Presentation on the Basics of Writing. Writing a Paragraph
Presentation on the Basics of Writing. Writing a ParagraphPresentation on the Basics of Writing. Writing a Paragraph
Presentation on the Basics of Writing. Writing a Paragraph
 
The basics of sentences session 10pptx.pptx
The basics of sentences session 10pptx.pptxThe basics of sentences session 10pptx.pptx
The basics of sentences session 10pptx.pptx
 
How to Use api.constrains ( ) in Odoo 17
How to Use api.constrains ( ) in Odoo 17How to Use api.constrains ( ) in Odoo 17
How to Use api.constrains ( ) in Odoo 17
 

PMI ACP Prep Course

  • 1. 1 PMI-­‐ACP Exam Prep 2-­‐day Course
  • 2. Warm Up & Introduc8ons 2 Constellation Fast intro What’s in it for me?
  • 3. 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. 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. 5 100 About the Exam scored questions 20 unscored questions + Content % of Exam Agile tools and techniques 50% Agile knowledge and skills 50%
  • 6. 6 Source: Mike Griffiths Tools & Techniques / Knowledge & Skills
  • 7. Please do not copy or reproduce this course materials without expressed written consent from SparkAgility. 7 Notice
  • 8. 8 Introduction ! Name ! Role ! Where are you from?
  • 9. 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
  • 11. 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. 12 Why Agile? ! What problems are you trying to solve with Agile? ! Pair up and discuss. Timebox: 3 minutes
  • 13. BeXer Success Rates 13 Credit: Mike Cohn
  • 14. 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. 15 Benefits of being Agile Source: VersionOne 7th Annual State of Agile Development Survey
  • 16. Leading causes of failed Agile projects 16 Source: VersionOne 7th Annual State of Agile Development Survey
  • 17. 17 Origins of Agile
  • 18. 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
  • 19. “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. 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. 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. 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
  • 24. 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. 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. 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.
  • 27. 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.
  • 28. 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. 29 What is Agile?
  • 30. 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. 31 Agile Practices Source: Guide to Agile PracEces. Agile Alliance,hWp://guide.agilealliance.org/subway.html
  • 32. 32 Agile Frameworks / Methodologies
  • 33. 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. 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. 35 Used with permission of mitchlacey.com SCRUM Framework
  • 36. 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?
  • 37. 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
  • 38. 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. 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 …….)
  • 40. 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. 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
  • 42. 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. 43 Stages of Learning SHU Follow the Rule “Obey” HA Break the Rule “Detach” RI Be the Rule “Separate”
  • 45. 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. 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. 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. 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)
  • 49. 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?
  • 50. 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. 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. 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
  • 53. Process 53 Chartering How will it be delivered?
  • 54. 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.
  • 55. 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. 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. 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. 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
  • 59. 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)
  • 60. 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. 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
  • 62. 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. 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. 64 Product Roadmap Sequence Backbone Less op8onal More op8onal Walking skeleton First Release Second Release Third Release OpEonality
  • 65. 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.
  • 66. 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
  • 67. 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
  • 68. 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. 69 Task and Kanban Boards Backlog Ready for Development Development Tes8ng Accepted Pending Complete Pending Complete Pending Complete Transparency Flow Collaboration
  • 70. 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. 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. 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. 73 Work in Progress (WIP) The aim of WIP limits is NOT to optimize resource utilization But to optimize THROUHGPUT
  • 74. 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. 75
  • 76. 76
  • 77. 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
  • 78. 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).
  • 79. 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
  • 80. 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?
  • 81. 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. 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)
  • 84. 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. 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
  • 86. 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)
  • 87. Why align Stakeholder’s Understanding? 87
  • 88. 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. 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. 90 • User User Stories stories are bite-­‐ sized, understandable chunks of business func8onality. • Help align team priori8es with the needs of the business.
  • 91. 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. 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
  • 93. 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. 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. 95 Story Maps Sequence Less Backbone op8onal More op8onal Walking skeleton First Release Second Release Third Release OpEonality
  • 96. 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. 97 Stakeholders Management • Executives and project sponsors • Managers • The project team • The user community • Supporting groups IdenEfy Educate Address
  • 98. 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. 99 Defini8on of Done What does “Done” look like? – Tested – Coded – Designed – Integrated – Builds – Installs – Migrates – Reviewed – Fixed – Accepted
  • 100. Communica8on Management 100 Source: Alistair Cockburn
  • 101. 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. 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.
  • 103. 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. 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. 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. 106 Measuring Velocity Guesstimate Historical data Empirical data (Trial iteration) Time Accuracy
  • 107. 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. 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. 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. 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. 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
  • 112. 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
  • 113. 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. 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. 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. 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. 117 Leading by Example • CommunicaEng the project vision. • Enabling others to act. • Being willing to challenge the Status Quo.
  • 118. Boos8ng Team Performance Prac8ces 118
  • 119. 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.
  • 120. Understanding Team Performance 120 • Examples of processes: Backlog Iterations Reviews Individuals and interactions over Processes and tools The soI stuff is the hard stuff.
  • 121. 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
  • 122. 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. 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. 124 Forming Storming Norming Performing Match Styles SupporEng DelegaEng DirecEng Coaching
  • 125. 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
  • 126. 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.
  • 127. 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 ✔ ✔ ✔ ✔ ✔
  • 128. 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
  • 129. 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.
  • 130. 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. 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. 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. 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
  • 134. 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. 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
  • 136. 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. 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
  • 139. 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. 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. 141 Upfront Planning (10% - 15%) Schedule Close Out 5% Schedule Release Plan 80% - 85% Schedule Iterations Now Progressive Elabora8on
  • 142. 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?
  • 143. 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. 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
  • 145. 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. 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. 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. 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. 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. 150 Affinity Es8ma8on • Affinity estimating is the process of grouping requirements into categories or collections.
  • 151. 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.
  • 152. 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. 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. 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
  • 155. 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
  • 156. 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. 157 Planning a Release • Prioritization (MoSCOW) • Velocity (Historical, Guess or Experiment) • Story Map (What gets build first?) Sequence High Priority Low
  • 158. 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
  • 159. Problem Detec8on and Resolu8on 159
  • 160. 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. 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. 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. 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
  • 164. 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?
  • 165. 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
  • 166. 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. 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.
  • 168. 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
  • 169. 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. 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.
  • 171. 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
  • 172. 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
  • 173. 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
  • 174. 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)
  • 175. 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
  • 176. 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
  • 177. 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
  • 178. 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
  • 180. 180 Kaizen • To make better (Continuous improvement) • Aims to eliminate waste
  • 181. 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. 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. 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. 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. 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. 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. 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. 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.”
  • 189. 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. 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)
  • 191. 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)
  • 192. 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
  • 193. 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
  • 194. 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
  • 195. 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. 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. 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. 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. 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. 200 Contact Informa8on Salah Elleithy 410.262.5550 salah@sparkagility.com Linkedin.com/in/selleithy