An introductory presentation by Naresh Jain on the essence of Being Agile vs. Following Agile and why being Agile is important? Naresh also shows an evolution of Agile methods over the last 11 years and the future of Agile. Also take a sneak preview into what challenges an organizations may face when trying to be agile?
29. The
Ball
Point
Game
Your
goal:
As
a
team
predictably
"process"
the
most
number
of
balls
in
a
round
by
passing
a
ball
to
each
member
You
have
3
rounds
to
get
the
best
score
you
can
Friday 15 June 2012 24
30. The
Ball
Point
Game
Your
goal:
As
a
team
predictably
"process"
the
most
number
of
balls
in
a
round
by
passing
a
ball
to
each
member
You
have
3
rounds
to
get
the
best
score
you
can
Simple
structure:
Predict
the
number
of
balls
you
can
process
Pass
balls
for
2
minutes
(no
more,
no
less)
Take
2
minute
to
discuss
and
improve
your
strategy
Friday 15 June 2012 24
31. The
Ball
Point
Game
Your
goal:
As
a
team
predictably
"process"
the
most
number
of
balls
in
a
round
by
passing
a
ball
to
each
member
You
have
3
rounds
to
get
the
best
score
you
can
Simple
structure:
Predict
the
number
of
balls
you
can
process
Pass
balls
for
2
minutes
(no
more,
no
less)
Take
2
minute
to
discuss
and
improve
your
strategy
Simple
rules:
Everyone
must
touch
the
ball
for
it
to
be
“done”
The
ball
must
have
“air
)me”
-‐
it
must
be
tossed
or
dropped
between
team
members
Friday 15 June 2012 24
32. Core
Agile
concepts
learned?
Adapted from Jeff Patton
Friday 15 June 2012 25
33. Core
Agile
concepts
learned?
Ideal
processes
use
a
simple
framework
-‐
like
a
game
Adapted from Jeff Patton
Friday 15 June 2012 25
34. Core
Agile
concepts
learned?
Ideal
processes
use
a
simple
framework
-‐
like
a
game
Changing
your
strategies
&
tac7cs,
not
the
framework,
allow
you
to
improve
Adapted from Jeff Patton
Friday 15 June 2012 25
35. Core
Agile
concepts
learned?
Ideal
processes
use
a
simple
framework
-‐
like
a
game
Changing
your
strategies
&
tac7cs,
not
the
framework,
allow
you
to
improve
Process
improvement
comes
from
change
Adapted from Jeff Patton
Friday 15 June 2012 25
36. Core
Agile
concepts
learned?
Ideal
processes
use
a
simple
framework
-‐
like
a
game
Changing
your
strategies
&
tac7cs,
not
the
framework,
allow
you
to
improve
Process
improvement
comes
from
change
Skill
improvement
come
from
prac7ce
Adapted from Jeff Patton
Friday 15 June 2012 25
37. Core
Agile
concepts
learned?
Ideal
processes
use
a
simple
framework
-‐
like
a
game
Changing
your
strategies
&
tac7cs,
not
the
framework,
allow
you
to
improve
Process
improvement
comes
from
change
Skill
improvement
come
from
prac7ce
Certain
kind
of
es=mates
improves
with
frequent
measurement
Adapted from Jeff Patton
Friday 15 June 2012 25
38. Core
Agile
concepts
learned?
Ideal
processes
use
a
simple
framework
-‐
like
a
game
Changing
your
strategies
&
tac7cs,
not
the
framework,
allow
you
to
improve
Process
improvement
comes
from
change
Skill
improvement
come
from
prac7ce
Certain
kind
of
es=mates
improves
with
frequent
measurement
Velocity
is
agile’s
language
for
measuring
throughput
Adapted from Jeff Patton
Friday 15 June 2012 25
39. Core
Agile
concepts
learned?
Ideal
processes
use
a
simple
framework
-‐
like
a
game
Changing
your
strategies
&
tac7cs,
not
the
framework,
allow
you
to
improve
Process
improvement
comes
from
change
Skill
improvement
come
from
prac7ce
Certain
kind
of
es=mates
improves
with
frequent
measurement
Velocity
is
agile’s
language
for
measuring
throughput
Visibility
of
work
helps
us
make
improvement
decisions
Adapted from Jeff Patton
Friday 15 June 2012 25
40. Core
Agile
concepts
learned?
Ideal
processes
use
a
simple
framework
-‐
like
a
game
Changing
your
strategies
&
tac7cs,
not
the
framework,
allow
you
to
improve
Process
improvement
comes
from
change
Skill
improvement
come
from
prac7ce
Certain
kind
of
es=mates
improves
with
frequent
measurement
Velocity
is
agile’s
language
for
measuring
throughput
Visibility
of
work
helps
us
make
improvement
decisions
Reflec7on:
observing,
measuring
&
changing
is
the
means
for
process
improvement
Adapted from Jeff Patton
Friday 15 June 2012 25
41. Core
Agile
concepts
learned?
Ideal
processes
use
a
simple
framework
-‐
like
a
game
Changing
your
strategies
&
tac7cs,
not
the
framework,
allow
you
to
improve
Process
improvement
comes
from
change
Skill
improvement
come
from
prac7ce
Certain
kind
of
es=mates
improves
with
frequent
measurement
Velocity
is
agile’s
language
for
measuring
throughput
Visibility
of
work
helps
us
make
improvement
decisions
Reflec7on:
observing,
measuring
&
changing
is
the
means
for
process
improvement
Team
work
is
an
individual
skill
Adapted from Jeff Patton
Friday 15 June 2012 25
42. “Simple, clear purpose and
principles give rise to complex
and intelligent behavior.
Complex rules and
regulations give rise to simple
and stupid behavior.”
Dee Hock
Friday 15 June 2012 26
43. Your
SoNware
Development
Game?
What
would
be:
Your
goal
Simple
structure
Simple
rules
Friday 15 June 2012 27
44. The
Agile
Game
Adapted from Jeff Patton
Friday 15 June 2012 28
45. The
Agile
Game
Your
goal:
As
a
team,
predictably
deliver
max
value
to
users
&
stakeholders
Adapted from Jeff Patton
Friday 15 June 2012 28
46. The
Agile
Game
Your
goal:
As
a
team,
predictably
deliver
max
value
to
users
&
stakeholders
Simple
structure:
As
a
team,
set
a
goal
&
plan
to
accomplish
the
work
Deliver
working
solu=on
by
the
end
of
a
fixed
cycle
Reflect
&
improve
your
Product,
Plan,
People
and
Process
Adapted from Jeff Patton
Friday 15 June 2012 28
47. The
Agile
Game
Your
goal:
As
a
team,
predictably
deliver
max
value
to
users
&
stakeholders
Simple
structure:
As
a
team,
set
a
goal
&
plan
to
accomplish
the
work
Deliver
working
solu=on
by
the
end
of
a
fixed
cycle
Reflect
&
improve
your
Product,
Plan,
People
and
Process
Simple
rules:
Whole
team
works
together
&
takes
responsibility
for
the
outcome
Progress
and
quality
must
be
kept
visible
Finished
work
(working
solu=on)
is
the
only
measure
of
progress
Adapted from Jeff Patton
Friday 15 June 2012 28
54. A
genuinely
shared
understanding
“I’m glad we’re all agreed then.”
Friday 15 June 2012 34
55. Tradi7onal
so>ware
development
fixes
scope
then
es7mates
to
figure
out
7me
and
cost
Traditional
software
development
Src: Jeff Patton
Friday 15 June 2012 35
56. Tradi7onal
so>ware
development
fixes
scope
then
es7mates
to
figure
out
7me
and
cost
Scope
Traditional
software
development
Time Cost
(resources)
Src: Jeff Patton
Friday 15 June 2012 35
57. Tradi7onal
so>ware
development
fixes
scope
then
es7mates
to
figure
out
7me
and
cost
Scope
Traditional
software
development
Time Cost
(resources)
Src: Jeff Patton
Friday 15 June 2012 35
58. Tradi7onal
so>ware
development
fixes
scope
then
es7mates
to
figure
out
7me
and
cost
Scope
Traditional
software
development
Time Cost
(resources)
Src: Jeff Patton
Friday 15 June 2012 35
59. Agile
development
fixes
7me
and
cost,
then
leverages
itera7on
and
incremen7ng
to
maximize
scope
Scope
Traditional
software
development
Time Cost
(resources)
Src: Jeff Patton
Friday 15 June 2012 36
60. Agile
development
fixes
7me
and
cost,
then
leverages
itera7on
and
incremen7ng
to
maximize
scope
Scope
Traditional
software
development
Time Cost
(resources)
Src: Jeff Patton
Friday 15 June 2012 36
61. Agile
development
fixes
7me
and
cost,
then
leverages
itera7on
and
incremen7ng
to
maximize
scope
Scope
Agile software
development
Traditional
software
development
Time Cost
(resources)
Src: Jeff Patton
Friday 15 June 2012 36
62. Agile
development
fixes
7me
and
cost,
then
leverages
itera7on
and
incremen7ng
to
maximize
scope
Cost
Scope Time (resources)
Agile software
development
Traditional
software
development
Time Cost
(resources)
Src: Jeff Patton
Friday 15 June 2012 36
63. Agile
development
fixes
7me
and
cost,
then
leverages
itera7on
and
incremen7ng
to
maximize
scope
Cost
Scope Time (resources)
Agile software
development
Traditional
software
development
Time Cost Scope
(resources)
Src: Jeff Patton
Friday 15 June 2012 36
64. Leverage
a
shared
understanding
of
desired
product
goals
to
minimize
scope
while
maximizing
value
Cost
Scope Time (resources)
Agile software
development
Traditional
software
development
Time Cost Scope
(resources)
Src: Jeff Patton
Friday 15 June 2012 37
65. Leverage
a
shared
understanding
of
desired
product
goals
to
minimize
scope
while
maximizing
value
Cost
Scope Time (resources)
Agile software
development
Traditional
software
development
Time Cost Scope
(resources)
Target business goals &
Src: Jeff Patton outcomes
Friday 15 June 2012 37
83. Itera)ve
AND
Incremental
• Mix
the
strategies:
–Iterate to
find
and
improve
solu6ons
–Increment to
add
func6onality
Adapted from Jeff Patton
Friday 15 June 2012 45
84. Itera)ve
AND
Incremental
• Mix
the
strategies:
–Iterate to
find
and
improve
solu6ons
–Increment to
add
func6onality
Adapted from Jeff Patton
Friday 15 June 2012 45
85. Itera)ve
AND
Incremental
• Mix
the
strategies:
–Iterate to
find
and
improve
solu6ons
–Increment to
add
func6onality
Adapted from Jeff Patton
Friday 15 June 2012 45
86. Itera)ve
AND
Incremental
• Mix
the
strategies:
–Iterate to
find
and
improve
solu6ons
–Increment to
add
func6onality
Adapted from Jeff Patton
Friday 15 June 2012 45
87. Itera)ve
AND
Incremental
• Mix
the
strategies:
–Iterate to
find
and
improve
solu6ons
–Increment to
add
func6onality
Adapted from Jeff Patton
Friday 15 June 2012 45
88. Agile
Birth of a new Software Movement!
Friday 15 June 2012 46
89. Agile
has
evolved
over
many
years
Src: Jeff Patton
Friday 15 June 2012 47
90. Agile
Umbrella
Agile
XP Scrum
DSDM FDD
Adaptive Pragmatic
Crystal Lean
Friday 15 June 2012 48
92. Agile Manifesto
“We are uncovering better ways of developing software by doing it and helping others do
it. Through this work we have come to value:
Friday 15 June 2012 49
93. Agile Manifesto
“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 OVER processes and tools.
Friday 15 June 2012 49
94. Agile Manifesto
“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 OVER processes and tools.
– Working software OVER comprehensive documentation.
Friday 15 June 2012 49
95. Agile Manifesto
“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 OVER processes and tools.
– Working software OVER comprehensive documentation.
– Customer collaboration OVER contract negotiation.
Friday 15 June 2012 49
96. Agile Manifesto
“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 OVER processes and tools.
– Working software OVER comprehensive documentation.
– Customer collaboration OVER contract negotiation.
– Responding to change OVER following a plan.
Friday 15 June 2012 49
99. Our highest priority is to satisfy
the customer through early and
continuous delivery of
valuable software.
Friday 15 June 2012 51
100. Welcome changing
requirements, even late in
development. Agile processes
harness change for the customer's
competitive advantage.
Friday 15 June 2012 52
101. Deliver working software
frequently, from a couple of
weeks to a couple of months, with a
preference to the shorter
timescale.
Friday 15 June 2012 53
102. Business people and developers
must work together daily
throughout the project.
Friday 15 June 2012 54
103. Build projects around
motivated
individuals. Give
them the environment
and support they
need, and trust them
to get the job done.
Friday 15 June 2012 55
104. The most efficient and effective
method of conveying information to
and within a development team is
face-to-face conversation.
Friday 15 June 2012 56
105. Working software is the primary
measure of progress.
Friday 15 June 2012 57
106. Agile processes promote
sustainable development. The
sponsors, developers, and users should
be able to maintain a constant pace
indefinitely.
Friday 15 June 2012 58
107. Simplicity
the art of maximizing the amount of
work not done
is essential.
Friday 15 June 2012 59
108. Continuous attention to technical
excellence and good design
enhances agility.
Friday 15 June 2012 60
109. The best architectures,
requirements, and designs emerge
from self-organizing teams.
Friday 15 June 2012 61
110. At regular intervals, the team
reflects on how to become more
effective, then tunes and adjusts
its behavior accordingly.
Friday 15 June 2012 62
112. It
turns
out...
Ziv's
law
-‐
specifica=ons
will
never
be
fully
understood.
Friday 15 June 2012 63
113. It
turns
out...
Ziv's
law
-‐
specifica=ons
will
never
be
fully
understood.
Humphrey's
law
-‐
the
user
will
never
know
what
they
want
un=l
aOer
the
system
is
in
produc=on
(maybe
not
even
then)
Friday 15 June 2012 63
114. It
turns
out...
Ziv's
law
-‐
specifica=ons
will
never
be
fully
understood.
Humphrey's
law
-‐
the
user
will
never
know
what
they
want
un=l
aOer
the
system
is
in
produc=on
(maybe
not
even
then)
Wegner's
lemma
-‐
an
interac=ve
system
can
never
be
fully
specified
nor
can
it
ever
be
fully
tested.
Friday 15 June 2012 63
115. It
turns
out...
Ziv's
law
-‐
specifica=ons
will
never
be
fully
understood.
Humphrey's
law
-‐
the
user
will
never
know
what
they
want
un=l
aOer
the
system
is
in
produc=on
(maybe
not
even
then)
Wegner's
lemma
-‐
an
interac=ve
system
can
never
be
fully
specified
nor
can
it
ever
be
fully
tested.
Langdon's
lemma
-‐
soOware
evolves
more
rapidly
as
it
approaches
chao=c
regions
(taking
care
not
to
spill
over
into
chaos)
Friday 15 June 2012 63
116. It
turns
out...
Ziv's
law
-‐
specifica=ons
will
never
be
fully
understood.
Humphrey's
law
-‐
the
user
will
never
know
what
they
want
un=l
aOer
the
system
is
in
produc=on
(maybe
not
even
then)
Wegner's
lemma
-‐
an
interac=ve
system
can
never
be
fully
specified
nor
can
it
ever
be
fully
tested.
Langdon's
lemma
-‐
soOware
evolves
more
rapidly
as
it
approaches
chao=c
regions
(taking
care
not
to
spill
over
into
chaos)
Any association of predictive or defined processes
with Agile is an exercise in futility. - Jeff
Friday 15 June 2012 63
117. Treat
agile
principles
as
“proper)es”
you
use
to
assess
process
health
Performing
a
simple
process
health
checkup:
hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
Friday 15 June 2012 64
118. Treat
agile
principles
as
“proper)es”
you
use
to
assess
process
health
1. Frequent
delivery
Performing
a
simple
process
health
checkup:
hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
Friday 15 June 2012 64
119. Treat
agile
principles
as
“proper)es”
you
use
to
assess
process
health
1. Frequent
delivery
2. Reflec6ve
improvement
Performing
a
simple
process
health
checkup:
hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
Friday 15 June 2012 64
120. Treat
agile
principles
as
“proper)es”
you
use
to
assess
process
health
1. Frequent
delivery
2. Reflec6ve
improvement
3. Close
communica6on
Performing
a
simple
process
health
checkup:
hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
Friday 15 June 2012 64
121. Treat
agile
principles
as
“proper)es”
you
use
to
assess
process
health
1. Frequent
delivery
2. Reflec6ve
improvement
3. Close
communica6on
4. Focus
Performing
a
simple
process
health
checkup:
hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
Friday 15 June 2012 64
122. Treat
agile
principles
as
“proper)es”
you
use
to
assess
process
health
1. Frequent
delivery
2. Reflec6ve
improvement
3. Close
communica6on
4. Focus
5. Personal
safety
Performing
a
simple
process
health
checkup:
hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
Friday 15 June 2012 64
123. Treat
agile
principles
as
“proper)es”
you
use
to
assess
process
health
1. Frequent
delivery
2. Reflec6ve
improvement
3. Close
communica6on
4. Focus
5. Personal
safety
6. Easy
access
to
experts
Performing
a
simple
process
health
checkup:
hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
Friday 15 June 2012 64
124. Treat
agile
principles
as
“proper)es”
you
use
to
assess
process
health
1. Frequent
delivery 7. Strong
technical
environment
2. Reflec6ve
improvement
3. Close
communica6on
4. Focus
5. Personal
safety
6. Easy
access
to
experts
Performing
a
simple
process
health
checkup:
hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
Friday 15 June 2012 64
125. Treat
agile
principles
as
“proper)es”
you
use
to
assess
process
health
1. Frequent
delivery 7. Strong
technical
environment
2. Reflec6ve
improvement 8. Sunny
day
visibility
3. Close
communica6on
4. Focus
5. Personal
safety
6. Easy
access
to
experts
Performing
a
simple
process
health
checkup:
hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
Friday 15 June 2012 64
126. Treat
agile
principles
as
“proper)es”
you
use
to
assess
process
health
1. Frequent
delivery 7. Strong
technical
environment
2. Reflec6ve
improvement 8. Sunny
day
visibility
3. Close
communica6on 9. Regular
cadence
4. Focus
5. Personal
safety
6. Easy
access
to
experts
Performing
a
simple
process
health
checkup:
hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
Friday 15 June 2012 64
127. Treat
agile
principles
as
“proper)es”
you
use
to
assess
process
health
1. Frequent
delivery 7. Strong
technical
environment
2. Reflec6ve
improvement 8. Sunny
day
visibility
3. Close
communica6on 9. Regular
cadence
4. Focus 10.High
energy
5. Personal
safety
6. Easy
access
to
experts
Performing
a
simple
process
health
checkup:
hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
Friday 15 June 2012 64
128. Treat
agile
principles
as
“proper)es”
you
use
to
assess
process
health
1. Frequent
delivery 7. Strong
technical
environment
2. Reflec6ve
improvement 8. Sunny
day
visibility
3. Close
communica6on 9. Regular
cadence
4. Focus 10.High
energy
5. Personal
safety 11.Empowered
teams
6. Easy
access
to
experts
Performing
a
simple
process
health
checkup:
hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
Friday 15 June 2012 64
129. Treat
agile
principles
as
“proper)es”
you
use
to
assess
process
health
1. Frequent
delivery 7. Strong
technical
environment
2. Reflec6ve
improvement 8. Sunny
day
visibility
3. Close
communica6on 9. Regular
cadence
4. Focus 10.High
energy
5. Personal
safety 11.Empowered
teams
6. Easy
access
to
experts 12.Disrup6ve
change
Performing
a
simple
process
health
checkup:
hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
Friday 15 June 2012 64
139. Balance discovery with delivery
Discovery:
understanding the
right product to
build
Delivery: building
product right
Src: Jeff Patton
Friday 15 June 2012 73
140. Then
came
along...
Agile Ecosystem
Agile
Agile-UX XP
Lean
Scrum
Product
Discovery
Friday 15 June 2012 74
141. High Level View of an Agile Process
Src: Jeff Patton
Friday 15 June 2012 75
142. Then
came
along...
Agile Ecosystem
Agile
Agile-UX
XP
Lean
Scrum
Kanban
Product
Discovery
Friday 15 June 2012 76
143. Where did Agile Originate?
Src: Jeff Patton
Friday 15 June 2012 77
144. Where
Agile
appears
to
work
best?
Unknown
Solution
Known
Known Unknown
Problem
Src: Eric Ries
Friday 15 June 2012 78
145. Where
Agile
appears
to
work
best?
Unknown
le
Solution
gi
Known
A
Known Unknown
Problem
Src: Eric Ries
Friday 15 June 2012 78
146. Where
Agile
appears
to
work
best?
Unknown
??
le
Solution
gi
Known
A
Known Unknown
Problem
Src: Eric Ries
Friday 15 June 2012 78
148. Currently...
Agile
Ecosystem
Lean
Agile Startup
Agile-UX XP
Lean
Scrum Kanban
Dev-OPs
Product
Discovery
Friday 15 June 2012 80
149. The
Future
Lean Startup
CD Pivot
Costumer
Development CD
Agile Continuous
Delivery
XP
Agile-UX
Scrum Lean
Kanban
Dev-OPs MVP
Product
Discovery
Friday 15 June 2012 81
151. Organizations have habits, and
they will stick to their habits
even at the risk of their own
survival.
Brad Anderson, CEO, Best Buy
Friday 15 June 2012 83
152. Organizational structures have a short life...
Nobody likes to reorganize, and you
always run the risk that you distract your
employees and lose focus on customers.
But if you don't do it, you lose your
competitive edge.
Nancy McKinstry, CEO, Wolters Kluwer
Friday 15 June 2012 84