2. Please do not copy or reproduce this course
materials without expressed written
consent from SparkAgility. Anyone who
engage in unauthorized duplication of the
course materials will be held duly
accountable by the PMI Ethics Committee.
Notice
2
3. Warm Up & Introductions
Constella,on
Fast
intro
What’s
in
it
for
me?
3
4. ! Founder, Managing Consultant and Trainer
! Over 15 years of experience; business analysis, project
management, team facilitation & development, process improvement
and agile coaching
! Driven by helping individuals and teams reach their full potential
! Passionate about spreading agility to the community (PMI Agile
Community of Practice, PMI local chapter and Meetups)
! Bachelors in Business / Accounting and Masters in Information
Systems & Financial Management
! Project Management Professional (PMP), Agile Certified
Practitioner (ACP), Certified Scrum Master (CSM), ICAgile Certified
Professional in Agile Coaching & Facilitation (ICP-TC), Certified
Trainer in Training from the Back of the Room
Salah Elleithy
@selleithy
salah@sparkagility.com
4
410.262.5550
5. Our Backlog
5
Origins of
Agile!
Agile
Manifesto!
Agile beyond
SW
Development!
Understand the
Agile Mindset!
Establishing
the Agile
Mindset!
Developing
Soft Skills!
Understanding
Communication
Barriers!
Sharing
Knowledge!
Collaboration
Techniques!
Shift in
roles!
Value based
work!
Work in
progress!
6. Our Backlog
6
Involving the
customer!
Continuous
Delivery!
Continuous
Integration!
User
involvement!
Involving the
customer!
User
feedback!
Planning!
Estimation!
Status
(Tracking)!
Process
adaptation!
8. • As a participant:
– I will do my best to be 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 is covered
– 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
Pledge of Learning
8
10. High Level Outcomes
Explore Agile
history and
mindset
Identify the difference between
‘being’ agile & ‘doing’ agile
Discover the
importance of
individuals and
interactions
Apply different
techniques for
planning,
estimation and
tracking progress
Demonstrate the
ability to adapt
based on regular
inspection and
introspection
10
ICAgile Certified professional
www.sparkagility.com
24. Crystal
Methods
(Alistair
Cockburn)
2001
and
beyond
Dynamic Systems
Development
Methods
(Arie van
Bennekum)
SCRUM (Ken
Schwaber &
Jeff Sutherland
Feature Driven
Development
(FDD)
(Jon Kern)
Adaptive
Planning (Jim
Highsmith)
An Evolution in the making
24
Waterfall
(Winston
Royce
40
years
ago
Declaration of
Interdependence
Agile
Manifesto
Agility as a way
of thinking
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.
- Alistair Cockburn
Lean/Kanban
25. Source: Dr. Winston W. Royce
“I believe in this concept,
but the implementation
described above is risky and
invites failure.”
25
26. Source:
Managing
the
development
of
large
SoKware
System,
Dr.
Winston
W.
Royce
hRp://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
“Hopefully, the iterative
interaction between the
various phases is confined
to successive steps.”
26
28. Responding to change
Customer collaboration
Working software
Individuals and interactions
That is, while there is value in the items on the right, we value the
items on the left more.
We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
Following a plan
Contract negotiation
Comprehensive documentation
Process and tools
Agile manifesto
28
29. " 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
Stand by your value
Agile
Values
29
Timebox: 5 minutes
30. 1 Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2 Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
3 Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
4 Business people and developers must work together daily throughout the project.
5 Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6 The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
Agile Principles
30
31. Agile Principles (cont.)
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.
9 Continuous attention to technical excellence and good design enhances agility.
10 Simplicity--the art of maximizing the amount of work not done--is essential.
11 The best architectures, requirements, and designs emerge from self-organizing
teams.
12 At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
31
32. We are a community of project leaders that are highly
successful at delivering results. To achieve these
results:
# We increase return on investment by making
continuous flow of value our focus.
# 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.
Declaration of Interdependence (DOI)
Source:
pmdoi.org
Declaration Of
Interdependence
Project leaders!
Signed by:
32
32
34. $ Jim Highsmith: Agility is the
ability to both create and
respond to change in order
to profit in a turbulent
business environment.
$ Ahmed Sidky: Agility is the
flexibility to navigate the
constraints of your project
to get the most value as
quickly as possible.
Agility defined
34
36. Framework
Discover
(build the right product)
Develop & Deliver
(build the product right)
Build
Measure
Learn
The Leanstartup Machine
Plan
Construct
IDEA CONSTRUCT SHIP
Agile Framework/Practices
Ship
Learn
Charter,
Backlog,
Release plan
Code, test and
deploy
36
Experience
product or
service
How can we
work better?
And deliver
more value?
37. Build a game that facilitate information
sharing and encourage learning for
college students
Exercise
VISION
• High level design
• Key Features (Minimally marketable features - MMF)
Outcomes
37
Timebox: 10 minutes
38. As you were working
together to identify
high level design
and key features:
" What went well?
" What needs
improvement?
Inspect & Adapt
Timebox: 5 minutes 38
40. Characteris:c
Fixed
Growth
Avoid
Failure
☐
☐
Con,nuous
Learning
☐
☐
Exert
effort
to
learn
☐
☐
Embrace
challenges
☐
☐
Ask
for
feedback
☐
☐
Cri,cism
is
personal
☐
☐
Look
smart
☐
☐
S,ck
to
what
I
know
☐
☐
Not
afraid
to
fail
☐
☐
Cri,cism
is
about
capabili,es
☐
☐
Failure
means
lack
of
talent
☐
☐
Ability
Growth vs. Fixed Mindset
40
41. Characteris:c
Fixed
Growth
Avoid
Failure
"
☐
Con,nuous
Learning
☐
"
Exert
effort
to
learn
☐
"
Embrace
challenges
☐
"
Ask
for
feedback
☐
"
Cri,cism
is
personal
"
☐
Look
smart
"
☐
S,ck
to
what
I
know
"
☐
Not
afraid
to
fail
☐
"
Cri,cism
is
about
capabili,es
☐
"
Failure
means
lack
of
talent
"
☐
Ability
Inherent
and
sta:c
Can
grow
Growth vs. Fixed Mindset
41
42. “Are you sure you can do this,
maybe I don’t have the
talent.”
“What if I fail – I’ll be a failure.”
“If I don’t try, I can protect
myself and keep my dignity.”
“This would have been a snap if
I really had talent.”
“It’s not my fault. It was
something or someone else’s
fault.”
“I’m not sure I can do it now but I think I
can learn to with time and effort.”
“Most successful people had failures
along the way.”
“If I don’t try, I automatically fail.
Where’s the dignity in that?”
“That is so wrong. Basketball wasn’t
easy for Michael Jordan and science
wasn’t easy for Thomas Edison. They
had a passion and put in tons of
effort.”
“If you don’t take responsibility, you
can’t fix it. My advise is to listen –
however painful it is – and learn
whatever you can.”
What's driving this kind of behavior?
How can we promote?
Exercise
42
Timebox: 5 minutes
How can we change?
45. Agile is a MINDSET
Agile is a
MINDSET
Established through
4 VALUES
Guided by
12 PRINCIPLES
Manifested through many different
PRACTICES
Credit: Dr. Ahmed Sidky
45
46. Source:
Guide
to
Agile
Prac,ces.
Agile
Alliance,hRp://guide.agilealliance.org/subway.html
Frameworks/Practices
46
47. The Agile Mindset
Mindset
Values (4)
Principles (12)
Frameworks
Practices
Credit: Dr. Ahmed Sidky
(how we work?)
Scrum
XP
FDD DSDM
Daily meetings
Kanban Board
Definition of Done Three Questions
Iterations
Story Mapping
Retrospectives
User Stories
Burndown chart
Backlog
Unit tests
Acceptance tests
Definition of Ready
47
48. With your table group, discuss who will the
key stakeholders and target audience to
use the learning game
Exercise
WHO
• Key Stakeholders
• Personas (Name / Goals)
OUTCOMES
48
Timebox: 10 minutes
49. As you were working
together to identify
the key
stakeholders and
personas:
" What went well?
" What needs
improvement?
Inspect & Adapt
Timebox: 5 minutes 49
51. Processes and tools
Comprehensive documentation
Contract Negotiation
Following a plan
Individuals and interactions
Customer collaboration
Working software
Responding to change
over
over
over
over
Agile Values
51
53. " Identify 5-10 soft
skills that are most
important to you
" Prioritize them from
high to low
" Identify 2 action
items to improve the
identified skills
Exercise
53
Timebox: 3 minutes
54. Source: Peter Bregman. https://www.youtube.com/watch?v=CuPfbTAVBP4#t=15
Ownership Commitment
Trust
Morale
Responsibility
Community
Attitude
Courage
Soft Skills
Servant Leadership
Collaboration
54
55. Tony is one of your most talented
developers. Most team
members go to him for advise
on technical issues. You are the
leading the project and noticed
that when it comes to meetings,
he’s usually late. You brought it
up to his attention a several
times but this behavior continue
to persist. It is hurting the team
progress and affecting morale.
Exercise
55
• What are the different
approaches we need to
consider to rectify this
issue?
• Discuss with your table
group.
Timebox: 3 minutes
57. Communication barriers
" Identify the most
common
communication
barriers in your
organization
" What could you do
to minimize them
57
Timebox: 3 minutes
58. 58
Listening
Level 1:
Ignoring
(Not really
listening at
all)
Level 2:
Pretending
(Yeah, uh-
huh, right)
Level 3:
Selective
Listening
(Hearing only
parts)
Level 4:
Attentive
Listening
(Focusing
and paying
attention to
the words)
Source: The 7 habits of highly effective people by Stephen Covey
Level 5:
Empathic
Listening
(Understand
the other
person’s
paradigm and
how they
feel)
59. We evaluate:
we agree or
disagree
We probe:
ask questions
from our own
frame of
reference
We advise:
give counsel
based on our
experience
We interpret:
try to figure people
out, explain their
motives, based on
our own paradigm
Barriers to Listening
Source: The 7 habits of highly effective people by Stephen Covey
59
60. " Pair up with someone and
talk to them for 30 seconds
about anything that comes
to mind. (The person who is
doing the listening should
keep listening without
interrupting)
" After 30 seconds, Switch
roles
" Be prepared to report your
observations to the whole
group
Exercise
60
Timebox: 2 minutes
63. • Knowl.edge
: information,
understanding, or skill
that you get from
experience or
education
: awareness of
something : the state
of being aware of
something
Definition
Merriam-webster dictionary
63
64. Types of Knowledge
Explicit
Tacit
(Example: learning how to speak a language)
(Example: learning the rules of grammar)
Difficult
to
transfer
to
another
person
by
means
of
wri,ng
it
down
or
verbalizing
it
Knowledge
that
has
been
ar,culated,
codified,
and
stored
and
can
be
readily
transmiRed
to
others
90-95%
5-10%
Percentages are hypothetical
64
65. Explicit vs. Tacit
Explicit Tacit
Documents Experience
Data Thinking
Information Competence
Records Commitment
" What are the different characteristics of explicit vs. tacit knowledge?
" Is Tacit knowledge transferrable? Why or why not?
65
Timebox: 3 minutes
66. Osmotic communication
means that information
flows into the
background hearing of
the team, so that they
pick up relevant
information as though
by osmosis.
Osmotic Communication
Credit: Dr. Alistair Cockburn
66
67. " Pairing team
members to
enhance
knowledge sharing
" Reduce errors and
maintain
consistency
" Promote learning
Pairing
67
71. Collaborate: to work
together especially in
some literacy, artistic or
scientific undertaking [1]; to
work jointly with others or
together especially in an
intellectual endeavor. [2]
[1] Webster’s New World Dictionary of the American Language
[2] Merriam Webster Online Dictionary
Collaboration
Source:
Jean
Tabaka.
Collabora,on
Explained
71
73. Source:
Christopher
Avery.
The
Responsibility
Process
Owning
your
ability
and
power
to
create,
choose
and
aRract
Doing
what
you
have
to
instead
of
what
you
want
to
Laying
blame
onto
oneself
(oKen
felt
as
guilt)
Using
excuses
for
things
being
the
way
they
are
Holding
others
at
fault
for
causing
something
Giving
up
to
avoid
the
pain
of
Shame
and
Obliga,on
Giving
up
to
avoid
the
pain
of
Shame
and
Obliga,on
73
74. " Think of a high
performing team you
worked with or you
would like to work with.
" What were the qualities
that made it a high
performing team?
" How did they
collaborate?
Exercise
74
Timebox: 3 minutes
75. " What are the most
important values to us
as individuals and as a
team?
" What do we need to
do to succeed as a
team?
" How do we want to
resolve conflicts?
" How do we create a
safe space for
everyone?
Working Agreement
75
76. " If you were on a
team, what would
the working
agreement look
like?
" Write it down
Exercise
76
Timebox: 3 minutes
79. " Define a clear
vision for the team.
" Reiterate vision
often and
communicate
change in direction.
" Make it visible for
everyone to see.
Vision
79
80. " Establish SMART
goals (Specific,
Measurable, Attainable,
Realistic and Time bound)
" Review goals on a
regular basis
" Make it visible for
everyone to see
SMART Goals
80
81. " An Information Radiator
is a display posted in a
place where people can
see it as they work or
walk by.
" Radiators show
information the team
cares about without
asking anyone a question.
" This means more
communication with fewer
interruptions.
Information Radiators
Source: Alistair Cockburn
81
82. " Is large and
easily visible
" Is understood
at a glance
" Is kept up to
date
A good Information Radiator
82
83. Regular Touchpoints
Identify our goal for the
day and agree on what
will be done (serves as a
daily planning meeting)
Raise any impediments
and ensure someone
will follow through to
resolve them for the
team
Image credit: Jason Yip
83
84. 84
Shifts in Roles
Self-organizing teams aren’t characterized by a lack of leadership, but by a style of leadership.
-Jim Highsmith
85. Agile Principles
" Agile Principle #5: Build
projects around motivated
individuals. Give them the
environment and support
they need, and trust them to
get the job done.
" Agile Principle #11: The
best architecture,
requirements, and designs
emerge from self-
organizing teams.
Source: agilemanifesto.org/principles.html
85
86. Daniel Pink in his book ‘Drive:
the surprising truth about
what motivates us’ explains
that we are motivated by 3
simple things:
– Autonomy (wanting to direct our
own lives)
– Mastery (wanting to be good at
something)
– Purpose (wanting to make a
difference)
What motivates us?
Source:
youtube.com/watch?v=u6XAPnuFjJc
86
87. Self-organizing teams
Creating a self-organizing
team entails:
" Getting the right people
" Articulating the product
vision, boundaries and
team roles
" Encouraging collaboration
" Insisting on
accountability
" Fostering self-discipline
" Steering rather than
control
Source: Jim Highsmith
87
88. Roles
Generalist Specialist Generalizing Specialist
Pro: Has one or more
technical specialties
(Java, Project
Management, Business
analysis)
Con: Lack of
knowledge in a
specific area may
create an impediment
Pro: Has a deep
knowledge in one
domain area
Con: True specialists
may create
bottlenecks by
focusing too much on
their area and missing
the bigger picture
Pro: has a dispersed
knowledge over a
wide array of areas
Con: May not be able
to help the team in a
specific area
Where does Agile teams fall?
88
89. " Think of how you
would use agile in
your current role
" Pair up with
someone and
discuss
Exercise
89
Timebox: 3 minutes
91. 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
91
93. Plan vs. Value driven delivery
Value
Time
Plan driven delivery
Value driven delivery
Time is up
There is value that
can be delivered to
the customer.
There is no value to
be delivered to the
customer.
93
96. When can
we deliver
the
product?
Building a bit at a time “Incrementing”
We build to finish
Build a rough version, validates it, bit at a time “Iterating”
We build to learn
Throughout
Where do
we deliver
value
faster?
Where
does the
maximum
value
happen?
Source: Jeff Patton
Here
96
Incremental vs. Iterative
97. Slicing value
Vision
Desired
Outcomes
Product Backlog
Feature 1
Feature 1
Feature 1
Feature 1
Feature 1
Feature 1
Feature 1
has to satisfy
who has
pay
Goals and Needs
User Story 1
Iteration Backlog
User Story 4 User Story 5 User Story 6
User Story 3User Story 2
to buyrealized by
broken into
97
98. Slices of Value
98
Each slice of the
product provides
that can be
delivered to the
customer
value
99. All we doing is looking at
the time line, from the
moment the
customer gives us an
order to the point
when we collect the
cash. And we are
reducing the time line
by reducing the non-
value adding wastes. –
Taiichi Ohno. Father of TPS
99
Receiving Value
Idea
Usage
100. Waste
In Manufacturing In Software
In-‐Process
Inventory Par,ally
Done
Work
Extra
Processing Extra
Processes
Overproduc,on Extra
Features
Transporta,on Handoffs
Wai,ng Delays
Mo,on Task
Switching
Defects Defects
Source:
7
wastes
in
soKware.
Mary
and
Tom
Poppendieck
100
102. Work in Progress (WIP)
Inventory
Manufacturing
Software
Ideas/Inputs Value
Is WIP good, Bad or Necessary?
102
103. ‘Waste’ in Software Development
Waste Description Example
Partially done work Work started but not complete % Code waiting for quality
assurance (QA)
% Specs waiting for dev.
Extra processes Extra work that does not add value % Unused documentation
% Unnecessary approvals
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
Source:
7
wastes
in
soKware.
Mary
and
Tom
Poppendieck
103
104. Backlog Ready
for
Dev.
Development
(5)
Tes:ng
(3)
Accepted
(2)
To
be
Deployed
In Done In Done In Done
Cycle time
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
,me?
Limit WIP
Limiting WIP helps the team see the bottlenecks and “swarm” (collaborate) to alleviate it.
104
105. Why limit WIP?
105
The aim of WIP limits is
NOT to optimize
resource utilization
But to optimize
THROUHGPUT
107. " CI is a software
development practice
where members of a team
integrate their work
frequently (at least daily).
" Each integration is
verified by an automated
build (including test) to
detect integration errors
as quickly as possible.
What is CI?
107
Source: Martin Fowler
108. " Discuss how this
apply to your
environment.
" Identify 3 ways to
reduce integration
issues on your
projects.
" Write them down.
Why is CI important?
108
Timebox: 3 minutes
109. Scenario 1: Wait until the end
Team
A
Team
B
Team
C
Code Integrate
109
112. " Release at
anytime (on
demand)
" Team can deploy
to production
throughout the
cycle
" Automated tests
are essential
112
Continuous Delivery
Deploy
Test
Build
115. " Who are our
stakeholders?
" What is their level
of interest and
influence?
" What are their
personas?
(Demographics
and
Psychographics)
Stakeholders
115
116. " Who is our target
audience?
(Demographics)
" Why would they buy
our product?
(Psychographics)
" What are their goals?
Personas
Name: Joe
Role: Student
Profile: Joe is a freshman in
college who is curious about
learning. He likes to spend time
reading and share new articles
with friends on social media.
Goals:
- Learn online and share
interesting information with his
friends
- Rate classes
116
120. " Identify the right users
(High interest/high
influence)
" Establish a user group
with a point of contact
" Build a team culture with
a defined purpose
" Ask for their input/
feedback
Increasing User Involvement
120
122. Feedback Loop Defined
A process has a
feedback loop when
the results of running
the process are
allowed to influence
how the process itself
works in the future.
122
124. " Where do you
see the feedback
loops in Agile
practices?
" What are the
benefits of
shorter feedback
loops vs. longer
feedback loops?
Exercise
Timebox: 3 minutes 124
125. Feedback Loops
125
Customer
Are we there yet?
Need more work
Agile Principle #4: Business people and developers must work
together daily throughout the project.
Team
Iteration Planning and
throughout the iteration
Daily Standups
Iteration Reviews (The
most feedback)
130. " How much it will cost?
" When will we be done?
" What resources do we
need?
" When can we release
our product?
Why do we plan?
130
131. Levels of Planning
Credit: Mike Cohn
What do we plan to do as a team to fulfill
our iteration commitments? What is
preventing us from getting there?
What slice of value will we deliver over the
next 2-4 weeks?
Strategy
Product Vision
Product
Roadmap
Release
Plan
Iteration
Plan
Daily
Plan
What features will we deliver over the next
6-12 weeks?
What are we trying to accomplish by
building this product?
How does this align with the overall
organization goals?
What will be build when over the next 6-12
months?
131
132. During the product
vision session, we
address the following
question:
" What are we trying to
accomplish by
building this product?
" What problem are we
trying to solve?
Product Vision
132
133. " Understand ‘what we are
trying to accomplish?’
" Define who the team
members are and how
they will work together
" Establish roles and
responsibilities and level
set the expectations
" Decide if the project is a
‘go’ or ‘no-go’
Project Charter
133
134. During the product
roadmap session, we
address the following
questions:
" What gets build
first? (Priorities)
" What are the
desired outcomes?
Product Roadmap
134
135. During the release planning,
we address the following
questions:
" What features will be
delivered in this release?
(Priorities)
" What is our success
criteria? (Outcomes)
" When can we release?
(Timeline)
" What can prevent us from
delivering? (Risk)
Release Plan
135
136. Iteration Plan
During the Iteration plan,
we address the
following questions:
" What stories will be
delivered this iteration?
(Priorities)
" What is our iteration
goal? (Outcomes)
" What’s preventing us
from reaching our
goal?
" Is this getting us closer
to our release? (Risk)
136
137. During the daily standup,
we address the
following questions:
" What is our goal for
today? (Priority)
" What will we work on to
reach the goal?
(Outcomes)
" What’s in our way of
achieving our goal or
making making
progress? (Risk)
Daily Plan
Timebox: 15 minutes
137
139. User Stories
As a <role>, I want to
<goal> so that I can
<benefit>
" User Stories has 3 main
elements:
& Card: written on an
index card as a
placeholder for
future…
& Conversation:
exchange of thoughts,
opinions and feelings
& Confirmation: what are
the acceptance tests
139
140. Attributes of a User Story
Source:
Bill
Wake
INVEST
Independent
(can
be
scheduled
and
implemented
in
any
order)
Nego,able
(capture
the
essence
not
the
details)
Valuable
(needs
to
add
value
to
the
customer)
Independent
(can
be
scheduled
and
implemented
in
any
order)
Es,matable
(just
enough
es,mate
to
help
the
customer
rank
and
schedule)
Small
(can
be
planned
and
fit
into
an
itera,on)
Testable
(The
story
can
be
verified
and
tested)
140
141. Write user stories in the format of ‘As a
<role>, I want to <goal> so that I can get
<benefit>’ for the learning game
Exercise
WHAT
• User stories
• Check the stories against the INVEST model
OUTCOMES
141
Timebox: 15 minutes
142. " Also called ‘Conditions of
Satisfaction’ by Mike Cohn
" Are specific to a given product
backlog item and define what
must be true for that product
backlog item to be
considered done
" Example of Acceptance
criteria:
& User is logged in only when
proper credentials are
provided
& User can request a password
reminder
& User is locked out after three
failed attempts
Acceptance Criteria
142
143. " Is an agreed upon set of
things that must be true
before any product backlog
item is considered
complete
" Example of Definition of
Done:
& The code is well written
& The code is checked in
& The code has been
inspected
& The feature the code
implements has been
documented as needed
Definition of Done
Source: Mike Cohn
143
145. " How much effort
do we put into
estimation to
increase accuracy
" An estimate is just
an estimate
Law of Diminishing Returns
145
146. Absolute vs. Relative Estimating
How tall is this building in feet?
How did you come up with the estimate?
Assume this building is 350 ft, what’s your
estimate of the tall building?
146
147. " Estimate items
(tasks or user
stories) relative
to other items
rather than
separately.
" Estimate size,
derive duration.
Relative Estimating
Fibonacci sequence
147
148. Ideal time vs. elapsed time
Ideal time Elapsed time
How long does
an activity take
without any
interruptions?
How long does
an activity take
from start to
finish?
Football game: 1
hour (4x 15
minutes quarters)
Football game: 4
hours (including
commercials)
Source:
Mike
Cohn
148
149. " Velocity is a
measure of a team’s
rate of progress
" Velocity is a
predictability
measure NOT a
productivity
measure
Velocity
149
150. Estimate the stories you came up with
during the story writing exercise
Exercise
WHAT
• Estimated stories in points using 0,1,2,3,5,8
OUTCOMES
150
Timebox: 10 minutes
152. " How are we doing?
(Project, team and
process health)
" What’s preventing us
from making progress?
" What’s our planned vs.
estimated pace?
(velocity)
Agile Metrics
152
153. Burn Up charts
Burn Up charts give an indicator whether the team will deliver the functionality
or need to add more iterations.
Storypoints
Iteration
Expected velocity: 10 points/iteration
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
Velocity
Forecasted
Addi:onal
itera:ons:
2
153
154. Burn down charts shows the points remaining at the beginning of each iteration
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
Velocity
Addi:onal
itera:ons:
2
Forecasted
154
155. " A cumulative flow
diagram (CFD)
shows the status of
work in different
queues (Analysis,
Development,
Testing,
Deployment)
" It also shows if there
is a bottleneck that
needs to be
addressed
Cumulative Flow Diagram
The widening area may
be an indication of
bottlenecks (work items
are not being moved to
the next queue
This area hasn’t
changed and it
may indicate a
bottleneck with
Dev tasks
155
156. Bug Tracking
Source: Scrumage.com
Bug tracking give team
indicators such as:
1. Escaped defects (Bugs
that were not caught in
testing)
2. How long does it take
to fix bugs?
Most importantly, investigate why bugs are getting through and what
can we do to catch them early in the process
156
157. Team Assessment Radar Chart
" A good tool for the
team to assess their
practices.
" It is a participatory
indicator on how the
team are following
their own practices.
" This may be
subjective
Itera:on
157
158. 158
Process Adaptation
The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn,
unlearn and relearn.
–Alvin Toffler
159. " A series of actions or
steps taken in order to
achieve a particular
end.
" In our context, the
Process is the way the
project is delivered to
build a product or
service.
Process
What’s the problem with our processes today?
159
160. " Identify 3 ways on
how we change our
process today.
" Are these ways
participatory or
mandatory?
" Identify 2 approaches
to make it
participatory
Exercise
160
161. Inspect & Adapt
Agile Principle # 12:
At regular intervals, the
team reflects on how
to become more
effective, then tunes
and adjusts its
behavior accordingly.
Image
credit:
growingagile.co.za
161
162. Adapting over Conforming
Jim Highsmith explains that:
" Delivering great products
requires exploration, not
tracking against a plan.
" Have the courage to
explore into the unknown
and the humility to
recognize mistakes and
adapt to the situation.
162
163. When:
At regular
intervals
(Usually at the
end of each
sprint)
Retrospectives
Who:
The team
Why:
Reflect on how to
become more
effective, then tune
and adjusts its
behavior accordingly
Regardless of what we discover, we understand and truly believe that
everyone did the best job they could, given what they knew at the time,
their skills and abilities, the resources available, and the situation at hand.
- Retrospective Prime Directive. Norm Kerth
163
164. Conducting a Retro
• Establish purpose/focus of the retrospective.
• Share the plan for the meeting.Set the stage
• Create a shared pool of data (based on the focus/purpose).
• Ground the retrospective in facts, not opinions.Gather data
• Observe patterns.
• Build shared awareness.Generate insights
• Move from discussion to ACTION.
• Focus on what the team can accomplish not what’s important
(1-2 actions)
Decide what to
do
• Reiterate actions and follow up.
• Appreciate contributions.
Close the
retrospective
Source: Esther Derby
164
165. A Good Retrospective
" Discuss any personal, team or
process issues openly.
" Discuss what worked and what
needs to change.
" Agree on top action items to be
addressed and fixed.
" Review these action items at the
beginning of the next retrospective.
" Change it up (Innovation games).
" Add the “Appreciation” game every
now and then.
165
166. 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.)
How
long
has
the
system
been
around?
(evolu,on
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.
Context Matters
166
168. " Think about a
time where you
had to learn a new
skill (Pick one)
" Write down what
it took to master it
(The steps)
168
Exercise
Timebox: 3 minutes
169. Stages of Learning
SHU
Follow
the
Rule
“Obey”
HA
Break
the
Rule
“Detach”
RI
Be
the
Rule
“Separate”
169
