It is human nature to look for patterns while solving new problems. We have a dangerous tendency to reuse what we already know to solve the next problem. We rarely discard what we've learned; we simply build on top of it. Sometimes this is a useful tactic, but often new problems and their context are slightly (if not vastly) different than the previous ones. And applying our previous way of doing things, will not be best suited for tackling the new problem.
In the software world, we've seen a similar desire to find the "one true way", "the BEST method", "the silver bullet" to solve all software development problems. Alas, after decades of trying we've not found one.
In this workshop, I'll let you discover why this is not possible and possibly explain how best to deal with this problem. This ideas in this workshop are based on my experience backed by latest research from Cognitive Science, Complex Adaptive System’s Theory and Evolutionary Psychology.
2. Agile Way of dealing with
Uncertainty in a
Complex Adaptive World
Naresh Jain
naresh@agilefaqs.com
twitter: @nashjain
http://nareshjain.com
Saturday 1 September 2012 1
3. Video on Selective Attention
http://www.youtube.com/watch?v=vJG698U2Mvo
Saturday 1 September 2012 2
4. Selec%ve
A)en%on
The
process
by
which
a
person
can
selec%vely
pick
out
one
s%mulus
from
a
mixture
of
s%muli
occurring
simultaneously.
Saturday 1 September 2012 3
5. Which
line
is
the
longest?
1
2
3
Saturday 1 September 2012 4
6. Which
line
is
the
longest?
1
2
3
Müller-Lyer optical illusion
Saturday 1 September 2012 4
15. What
would
you
prefer?
A
lo)ery
%cket
with
a
random
number
or
a
number
you’ve
picked?
Saturday 1 September 2012 10
16. What
would
you
prefer?
In
the
Casino,
if
you
toss
the
dice
or
someone
else
tosses
the
dice?
Saturday 1 September 2012 11
17. What
would
you
prefer?
In
the
Casino,
if
you
toss
the
dice
or
someone
else
tosses
the
dice?
Do you think it will
make any difference?
Saturday 1 September 2012 11
18. Illusion
of
Control
Our
desire
to
control
is
so
powerful
that
the
feeling
of
being
in
control
is
so
rewarding
that
people
oLen
act
as
though
they
can
control
the
uncontrollable.
Saturday 1 September 2012 12
19. Electrical
Shock
Research
High
Volts
Shock
Group
vs.
Low
Volts
Shock
Group
5
shocks
of
5
volts
each
vs.
3
shocks
of
2-‐4
volts
each
Every
10
seconds
vs.
Random
%me
interval
Saturday 1 September 2012 13
20. Electrical
Shock
Research
High
Volts
Shock
Group
vs.
Low
Volts
Shock
Group
5
shocks
of
5
volts
each
vs.
3
shocks
of
2-‐4
volts
each
Which Group would have
Every
10
seconds
vs.
Random
%me
interval
sweated more, whose heart beats
would be faster and who claimed
to be more afraid?
Saturday 1 September 2012 13
42. 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
Saturday 1 September 2012 28
43. 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
Saturday 1 September 2012 28
44. 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
Saturday 1 September 2012 28
45. Core
Agile
concepts
learned?
Adapted from Jeff Patton
Saturday 1 September 2012 29
46. Core
Agile
concepts
learned?
Ideal
processes
use
a
simple
framework
-‐
like
a
game
Adapted from Jeff Patton
Saturday 1 September 2012 29
47. 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
Saturday 1 September 2012 29
48. 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
Saturday 1 September 2012 29
49. 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
Saturday 1 September 2012 29
50. 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
Saturday 1 September 2012 29
51. 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
Saturday 1 September 2012 29
52. 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
Saturday 1 September 2012 29
53. 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
Saturday 1 September 2012 29
54. 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
Saturday 1 September 2012 29
55. “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
Saturday 1 September 2012 30
56. Your
SoLware
Development
Game?
What
would
be:
Your
goal
Simple
structure
Simple
rules
Saturday 1 September 2012 31
57. The
Agile
Game
Adapted from Jeff Patton
Saturday 1 September 2012 32
58. The
Agile
Game
Your
goal:
As
a
team,
predictably
deliver
max
value
to
users
&
stakeholders
Adapted from Jeff Patton
Saturday 1 September 2012 32
59. 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
Saturday 1 September 2012 32
60. 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
Saturday 1 September 2012 32
64. SoLware
Engineering?
Crea%ng
SoLware
is
a
CraL.
Conver%ng
source
code
to
executable
is
the
engineering
bit.
Saturday 1 September 2012 34
65. IEEE
defines
SoLware
Engineering
as...
“Software Engineering is the application of
a systematic, disciplined, quantifiable
approach to development, operation and
maintenance of software: that is, the
application of engineering to software.”
IEEE Standard Computer Dictionary,
ISBN 1-55937-079-3, 1990
Saturday 1 September 2012 35
68. For the space shuttle’s operating system
Saturday 1 September 2012 37
69. Some
Sta%s%cs
NASA’s
Defect
Density
Saturday 1 September 2012 38
70. Some
Sta%s%cs
NASA’s
Defect
Density
The
last
11
versions
of
the
space
shu)le’s
420,000
line
systems
had
a
total
of
17
defects.
Saturday 1 September 2012 38
71. Some
Sta%s%cs
NASA’s
Defect
Density
The
last
11
versions
of
the
space
shu)le’s
420,000
line
systems
had
a
total
of
17
defects.
Saturday 1 September 2012 38
74. Another
real
soLware
engineering
project
Saturday 1 September 2012 40
75. Another
real
soLware
engineering
project
Safeguard - Ballistic Missile Defense System
Saturday 1 September 2012 40
76. Another
real
soLware
engineering
project
Safeguard - Ballistic Missile Defense System 18
20
1969-‐1975,
5407
person
years code &
unit test
Hardware
designed
at
the
same
design
18 %
20 %
Ame
as
soBware
specs
being
wriDen
reqmts
Late
changes
in
requirements
not
20 %
20 integration
an
opAon
testing
42 %
42
Saturday 1 September 2012 40
77. Another
real
soLware
engineering
project
Safeguard - Ballistic Missile Defense System 18
20
1969-‐1975,
5407
person
years code &
unit test
Hardware
designed
at
the
same
design
18 %
20 %
Ame
as
soBware
specs
being
wriDen
reqmts
Late
changes
in
requirements
not
20 %
20 integration
an
opAon
testing
42 %
42
Did it Succeed?
Saturday 1 September 2012 40
80. Safeguard
Ballis%c
Missile
Defense
System…
Revised Project Statistics
The
project
was
delivered
according
to
specifica%ons
Saturday 1 September 2012 41
81. Safeguard
Ballis%c
Missile
Defense
System…
Revised Project Statistics
The
project
was
delivered
according
to
specifica%ons
Cost:
$25
Billion
(not
adjusted)
Saturday 1 September 2012 41
82. Safeguard
Ballis%c
Missile
Defense
System…
Revised Project Statistics
The
project
was
delivered
according
to
specifica%ons
Cost:
$25
Billion
(not
adjusted)
1969-‐1975,
5407
person
years
Saturday 1 September 2012 41
83. Safeguard
Ballis%c
Missile
Defense
System…
Revised Project Statistics
The
project
was
delivered
according
to
specifica%ons
Cost:
$25
Billion
(not
adjusted)
1969-‐1975,
5407
person
years
Operational for 133 days - Project terminated in 1978
Saturday 1 September 2012 41
84. Safeguard
Ballis%c
Missile
Defense
System…
Revised Project Statistics
The
project
was
delivered
according
to
specifica%ons
Cost:
$25
Billion
(not
adjusted)
1969-‐1975,
5407
person
years
Operational for 133 days - Project terminated in 1978
‘By the time the 6-year anti-missile system project was
completed, the new missiles were faster than the anti-
missile missiles’
Saturday 1 September 2012 41
93. Heavy
Weight
Methodologies
Heavy weight methodologies
work in some instances, but
there are high costs, and the
risk in using them in dynamic
environments is high.
Saturday 1 September 2012 49
94. The
Business
Case
for
Agile
Development
We
need
to
do
be)er
than
this
….
IT Projects
Succeeded
Failed
Challenged
Chaos
Report
2006.
Standish
Group
Saturday 1 September 2012 50
96. Feature
Use
O@en
or
Always
Used:
20%
Rarely
Some%mes 19%
16%
Never
45%
OLen
13%
Always
7% Rarely
or
Never
Used:
64%
Standish
Group
study
reported
at
XP2002
by
Jim
Johnson,
Chairman
Saturday 1 September 2012 52
97. Can
We
Predict
What
We
Need
?
How
significant
is
requirements
change
on
a
project?
“The
average
project
has
30%
requirements
change”
Saturday 1 September 2012 53
110. A
genuinely
shared
understanding
“I’m glad we’re all agreed then.”
Saturday 1 September 2012 63
111. Tradi%onal
soLware
development
fixes
scope
then
es%mates
to
figure
out
%me
and
cost
Traditional
software
development
Src: Jeff Patton
Saturday 1 September 2012 64
112. Tradi%onal
soLware
development
fixes
scope
then
es%mates
to
figure
out
%me
and
cost
Scope
Traditional
software
development
Time Cost
(resources)
Src: Jeff Patton
Saturday 1 September 2012 64
113. Tradi%onal
soLware
development
fixes
scope
then
es%mates
to
figure
out
%me
and
cost
Scope
Traditional
software
development
Time Cost
(resources)
Src: Jeff Patton
Saturday 1 September 2012 64
114. Tradi%onal
soLware
development
fixes
scope
then
es%mates
to
figure
out
%me
and
cost
Scope
Traditional
software
development
Time Cost
(resources)
Src: Jeff Patton
Saturday 1 September 2012 64
115. Agile
development
fixes
%me
and
cost,
then
leverages
itera%on
and
incremen%ng
to
maximize
scope
Scope
Traditional
software
development
Time Cost
(resources)
Src: Jeff Patton
Saturday 1 September 2012 65
116. Agile
development
fixes
%me
and
cost,
then
leverages
itera%on
and
incremen%ng
to
maximize
scope
Scope
Traditional
software
development
Time Cost
(resources)
Src: Jeff Patton
Saturday 1 September 2012 65
117. Agile
development
fixes
%me
and
cost,
then
leverages
itera%on
and
incremen%ng
to
maximize
scope
Scope
Agile software
development
Traditional
software
development
Time Cost
(resources)
Src: Jeff Patton
Saturday 1 September 2012 65
118. Agile
development
fixes
%me
and
cost,
then
leverages
itera%on
and
incremen%ng
to
maximize
scope
Cost
Scope Time (resources)
Agile software
development
Traditional
software
development
Time Cost
(resources)
Src: Jeff Patton
Saturday 1 September 2012 65
119. Agile
development
fixes
%me
and
cost,
then
leverages
itera%on
and
incremen%ng
to
maximize
scope
Cost
Scope Time (resources)
Agile software
development
Traditional
software
development
Time Cost Scope
(resources)
Src: Jeff Patton
Saturday 1 September 2012 65
120. 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
Saturday 1 September 2012 66
121. 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
Saturday 1 September 2012 66
139. Itera%ve
AND
Incremental
• Mix
the
strategies:
–Iterate to
find
and
improve
soluAons
–Increment to
add
funcAonality
Adapted from Jeff Patton
Saturday 1 September 2012 74
140. Itera%ve
AND
Incremental
• Mix
the
strategies:
–Iterate to
find
and
improve
soluAons
–Increment to
add
funcAonality
Adapted from Jeff Patton
Saturday 1 September 2012 74
141. Itera%ve
AND
Incremental
• Mix
the
strategies:
–Iterate to
find
and
improve
soluAons
–Increment to
add
funcAonality
Adapted from Jeff Patton
Saturday 1 September 2012 74
142. Itera%ve
AND
Incremental
• Mix
the
strategies:
–Iterate to
find
and
improve
soluAons
–Increment to
add
funcAonality
Adapted from Jeff Patton
Saturday 1 September 2012 74
143. Itera%ve
AND
Incremental
• Mix
the
strategies:
–Iterate to
find
and
improve
soluAons
–Increment to
add
funcAonality
Adapted from Jeff Patton
Saturday 1 September 2012 74
144. Agile
Birth of a new Software Movement!
Saturday 1 September 2012 75
145. Agile
has
evolved
over
many
years
Src: Jeff Patton
Saturday 1 September 2012 76
150. 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:
Saturday 1 September 2012 79
151. 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.
Saturday 1 September 2012 79
152. 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.
Saturday 1 September 2012 79
153. 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.
Saturday 1 September 2012 79
154. 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.
Saturday 1 September 2012 79
157. Our highest priority is to satisfy
the customer through early and
continuous delivery of
valuable software.
Saturday 1 September 2012 81
158. Welcome changing
requirements, even late in
development. Agile processes
harness change for the customer's
competitive advantage.
Saturday 1 September 2012 82
159. Deliver working software
frequently, from a couple of
weeks to a couple of months, with a
preference to the shorter
timescale.
Saturday 1 September 2012 83
160. Business people and developers
must work together daily
throughout the project.
Saturday 1 September 2012 84
161. Build projects around
motivated
individuals. Give
them the environment
and support they
need, and trust them
to get the job done.
Saturday 1 September 2012 85
162. The most efficient and effective
method of conveying information to
and within a development team is
face-to-face conversation.
Saturday 1 September 2012 86
163. Working software is the primary
measure of progress.
Saturday 1 September 2012 87
164. Agile processes promote
sustainable development. The
sponsors, developers, and users should
be able to maintain a constant pace
indefinitely.
Saturday 1 September 2012 88
165. Simplicity
the art of maximizing the amount of
work not done
is essential.
Saturday 1 September 2012 89
166. Continuous attention to technical
excellence and good design
enhances agility.
Saturday 1 September 2012 90
167. The best architectures,
requirements, and designs emerge
from self-organizing teams.
Saturday 1 September 2012 91
168. At regular intervals, the team
reflects on how to become more
effective, then tunes and adjusts
its behavior accordingly.
Saturday 1 September 2012 92
170. It
turns
out...
Ziv's
law
-‐
specifica%ons
will
never
be
fully
understood.
Saturday 1 September 2012 93
171. 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
aLer
the
system
is
in
produc%on
(maybe
not
even
then)
Saturday 1 September 2012 93
172. 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
aLer
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.
Saturday 1 September 2012 93
173. 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
aLer
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
-‐
soLware
evolves
more
rapidly
as
it
approaches
chao%c
regions
(taking
care
not
to
spill
over
into
chaos)
Saturday 1 September 2012 93
174. 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
aLer
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
-‐
soLware
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
Saturday 1 September 2012 93
175. Treat
agile
principles
as
“proper%es”
you
use
to
assess
process
health
Performing
a
simple
process
health
checkup:
h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
Saturday 1 September 2012 94
176. Treat
agile
principles
as
“proper%es”
you
use
to
assess
process
health
1. Frequent
delivery
Performing
a
simple
process
health
checkup:
h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
Saturday 1 September 2012 94
177. Treat
agile
principles
as
“proper%es”
you
use
to
assess
process
health
1. Frequent
delivery
2. ReflecAve
improvement
Performing
a
simple
process
health
checkup:
h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
Saturday 1 September 2012 94
178. Treat
agile
principles
as
“proper%es”
you
use
to
assess
process
health
1. Frequent
delivery
2. ReflecAve
improvement
3. Close
communicaAon
Performing
a
simple
process
health
checkup:
h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
Saturday 1 September 2012 94
179. Treat
agile
principles
as
“proper%es”
you
use
to
assess
process
health
1. Frequent
delivery
2. ReflecAve
improvement
3. Close
communicaAon
4. Focus
Performing
a
simple
process
health
checkup:
h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
Saturday 1 September 2012 94
180. Treat
agile
principles
as
“proper%es”
you
use
to
assess
process
health
1. Frequent
delivery
2. ReflecAve
improvement
3. Close
communicaAon
4. Focus
5. Personal
safety
Performing
a
simple
process
health
checkup:
h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
Saturday 1 September 2012 94
181. Treat
agile
principles
as
“proper%es”
you
use
to
assess
process
health
1. Frequent
delivery
2. ReflecAve
improvement
3. Close
communicaAon
4. Focus
5. Personal
safety
6. Easy
access
to
experts
Performing
a
simple
process
health
checkup:
h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
Saturday 1 September 2012 94
182. Treat
agile
principles
as
“proper%es”
you
use
to
assess
process
health
1. Frequent
delivery 7. Strong
technical
environment
2. ReflecAve
improvement
3. Close
communicaAon
4. Focus
5. Personal
safety
6. Easy
access
to
experts
Performing
a
simple
process
health
checkup:
h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
Saturday 1 September 2012 94
183. Treat
agile
principles
as
“proper%es”
you
use
to
assess
process
health
1. Frequent
delivery 7. Strong
technical
environment
2. ReflecAve
improvement 8. Sunny
day
visibility
3. Close
communicaAon
4. Focus
5. Personal
safety
6. Easy
access
to
experts
Performing
a
simple
process
health
checkup:
h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
Saturday 1 September 2012 94
184. Treat
agile
principles
as
“proper%es”
you
use
to
assess
process
health
1. Frequent
delivery 7. Strong
technical
environment
2. ReflecAve
improvement 8. Sunny
day
visibility
3. Close
communicaAon 9. Regular
cadence
4. Focus
5. Personal
safety
6. Easy
access
to
experts
Performing
a
simple
process
health
checkup:
h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
Saturday 1 September 2012 94
185. Treat
agile
principles
as
“proper%es”
you
use
to
assess
process
health
1. Frequent
delivery 7. Strong
technical
environment
2. ReflecAve
improvement 8. Sunny
day
visibility
3. Close
communicaAon 9. Regular
cadence
4. Focus 10.High
energy
5. Personal
safety
6. Easy
access
to
experts
Performing
a
simple
process
health
checkup:
h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
Saturday 1 September 2012 94
186. Treat
agile
principles
as
“proper%es”
you
use
to
assess
process
health
1. Frequent
delivery 7. Strong
technical
environment
2. ReflecAve
improvement 8. Sunny
day
visibility
3. Close
communicaAon 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:
h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
Saturday 1 September 2012 94
187. Treat
agile
principles
as
“proper%es”
you
use
to
assess
process
health
1. Frequent
delivery 7. Strong
technical
environment
2. ReflecAve
improvement 8. Sunny
day
visibility
3. Close
communicaAon 9. Regular
cadence
4. Focus 10.High
energy
5. Personal
safety 11.Empowered
teams
6. Easy
access
to
experts 12.DisrupAve
change
Performing
a
simple
process
health
checkup:
h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
Saturday 1 September 2012 94
198. Balance discovery with delivery
Discovery:
understanding the
right product to
build
Delivery: building
product right
Src: Jeff Patton
Saturday 1 September 2012 104
199. Then
came
along...
Agile Ecosystem
Agile
Agile-UX XP
Lean
Scrum
Product
Discovery
Saturday 1 September 2012 105
200. High Level View of an Agile Process
Src: Jeff Patton
Saturday 1 September 2012 106
201. Then
came
along...
Agile Ecosystem
Agile
Agile-UX
XP
Lean
Scrum
Kanban
Product
Discovery
Saturday 1 September 2012 107
202. Where did Agile Originate?
Src: Jeff Patton
Saturday 1 September 2012 108
203. Where
Agile
appears
to
work
best?
Unknown
Solution
Known
Known Unknown
Problem
Src: Eric Ries
Saturday 1 September 2012 109
204. Where
Agile
appears
to
work
best?
Unknown
le
Solution
gi
Known
A
Known Unknown
Problem
Src: Eric Ries
Saturday 1 September 2012 109
205. Where
Agile
appears
to
work
best?
Unknown
??
le
Solution
gi
Known
A
Known Unknown
Problem
Src: Eric Ries
Saturday 1 September 2012 109
207. Currently...
Agile
Ecosystem
Lean
Agile Startup
Agile-UX XP
Lean
Scrum Kanban
Dev-OPs
Product
Discovery
Saturday 1 September 2012 111
208. The
Future
Lean Startup
CD Pivot
Costumer
Development CD
Agile Continuous
Delivery
XP
Agile-UX
Scrum Lean
Kanban
Dev-OPs MVP
Product
Discovery
Saturday 1 September 2012 112
210. Organizations have habits, and
they will stick to their habits
even at the risk of their own
survival.
Brad Anderson, CEO, Best Buy
Saturday 1 September 2012 114
211. 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
Saturday 1 September 2012 115