agile way of dealing with uncertainty in a complex adaptive world
DESCRIPTION
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.TRANSCRIPT
Agile Way of dealing with Uncertainty in a
Complex Adaptive World
Naresh [email protected]
twitter: @nashjain
http://nareshjain.com
1Saturday 1 September 2012
Video on Selective Attention http://www.youtube.com/watch?v=vJG698U2Mvo
2Saturday 1 September 2012
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.
3Saturday 1 September 2012
Which line is the longest?
1
2
3
4Saturday 1 September 2012
Which line is the longest?
1
2
3
Müller-Lyer optical illusion
4Saturday 1 September 2012
Which Orange Circle is bigger?
5Saturday 1 September 2012
Which Orange Circle is bigger?
Ebbinghaus optical illusion
5Saturday 1 September 2012
6Saturday 1 September 2012
Pet Plant Research @ an elderly Nursing Home
7Saturday 1 September 2012
Pet Plant Research @ an elderly Nursing Home
7Saturday 1 September 2012
Student Volunteers @ Nursing Home
8Saturday 1 September 2012
Student Volunteers @ Nursing Home
8Saturday 1 September 2012
Why?
9Saturday 1 September 2012
What would you prefer?
A lo)ery %cket with a random number
or a number you’ve picked?
10Saturday 1 September 2012
What would you prefer?
In the Casino, if you toss the dice
or someone else tosses the dice?
11Saturday 1 September 2012
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?
11Saturday 1 September 2012
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.
12Saturday 1 September 2012
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
13Saturday 1 September 2012
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 intervalWhich Group would have sweated more, whose heart beats would be faster and who claimed
to be more afraid?
13Saturday 1 September 2012
Uncertainty
14Saturday 1 September 2012
Uncertainty
Why?Our desire to Control
14Saturday 1 September 2012
How do we deal with Uncertainty?
15Saturday 1 September 2012
How do we deal with Uncertainty?
15Saturday 1 September 2012
How do we deal with Uncertainty?
15Saturday 1 September 2012
How do we deal with Uncertainty?
15Saturday 1 September 2012
How do we deal with Uncertainty?
15Saturday 1 September 2012
Predictability Paradox
16Saturday 1 September 2012
How to Organize a Children's Party?
A video by Dave Snowdenhttp://www.youtube.com/watch?v=Miwb92eZaJg
17Saturday 1 September 2012
18Saturday 1 September 2012
19Saturday 1 September 2012
Why is there only ONE Toyota or Apple today?
20Saturday 1 September 2012
Products & Processes are like haircutsCopying someone else’s rarely works
21Saturday 1 September 2012
Retrospec%ve Coherence
22Saturday 1 September 2012
Retrospec%ve Coherence
Hindsight does not lead to foresight!
22Saturday 1 September 2012
ME
23Saturday 1 September 2012
24Saturday 1 September 2012
Tech Talks!
25Saturday 1 September 2012
26Saturday 1 September 2012
Taking ownership of a simple process
Adapted from Jeff Patton
27Saturday 1 September 2012
The Ball Point Game
28Saturday 1 September 2012
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
28Saturday 1 September 2012
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
28Saturday 1 September 2012
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
28Saturday 1 September 2012
Core Agile concepts learned?
Adapted from Jeff Patton29Saturday 1 September 2012
Core Agile concepts learned?
Ideal processes use a simple framework -‐ like a game
Adapted from Jeff Patton29Saturday 1 September 2012
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 Patton29Saturday 1 September 2012
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 Patton29Saturday 1 September 2012
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 Patton29Saturday 1 September 2012
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 Patton29Saturday 1 September 2012
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 Patton29Saturday 1 September 2012
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 Patton29Saturday 1 September 2012
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 Patton29Saturday 1 September 2012
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 Patton29Saturday 1 September 2012
“Simple, clear purpose and principles give rise to complex
and intelligent behavior.
Complex rules and regulations give rise to simple
and stupid behavior.”
Dee Hock30Saturday 1 September 2012
Your SoLware Development Game?
What would be:
Your goal
Simple structure
Simple rules
31Saturday 1 September 2012
The Agile Game
Adapted from Jeff Patton32Saturday 1 September 2012
The Agile Game
Your goal: As a team, predictably deliver max value to users & stakeholders
Adapted from Jeff Patton32Saturday 1 September 2012
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 Patton32Saturday 1 September 2012
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 Patton32Saturday 1 September 2012
33Saturday 1 September 2012
Agile Origins
33Saturday 1 September 2012
SoLware Engineering?
34Saturday 1 September 2012
SoLware Engineering?
Crea%ng SoLware is a CraL.
Conver%ng source code to executable is the engineering bit.
34Saturday 1 September 2012
“Software Engineering is the application ofa systematic, disciplined, quantifiableapproach to development, operation andmaintenance of software: that is, theapplication of engineering to software.”
IEEE Standard Computer Dictionary,
ISBN 1-55937-079-3, 1990
IEEE defines SoLware Engineering as...
35Saturday 1 September 2012
Who used SoLware Engineering?
36Saturday 1 September 2012
Who used SoLware Engineering?
36Saturday 1 September 2012
For the space shuttle’s operating system37Saturday 1 September 2012
Some Sta%s%csNASA’s Defect Density
38Saturday 1 September 2012
The last 11 versions of the space shu)le’s 420,000 line systems had a total of 17
defects.
Some Sta%s%csNASA’s Defect Density
38Saturday 1 September 2012
The last 11 versions of the space shu)le’s 420,000 line systems had a total of 17
defects.
Some Sta%s%csNASA’s Defect Density
38Saturday 1 September 2012
One More Data Point
39Saturday 1 September 2012
One More Data Point
39Saturday 1 September 2012
Another real soLware engineering project
40Saturday 1 September 2012
Safeguard - Ballistic Missile Defense System
Another real soLware engineering project
40Saturday 1 September 2012
1969-‐1975, 5407 person years
Hardware designed at the same Ame as soBware specs being wriDen
Late changes in requirements not an opAon
42
1820
20
reqmts20 %
design20 %
code &unit test
18 %
integrationtesting42 %
Safeguard - Ballistic Missile Defense System
Another real soLware engineering project
40Saturday 1 September 2012
1969-‐1975, 5407 person years
Hardware designed at the same Ame as soBware specs being wriDen
Late changes in requirements not an opAon
42
1820
20
reqmts20 %
design20 %
code &unit test
18 %
integrationtesting42 %
Safeguard - Ballistic Missile Defense System
Did it Succeed?
Another real soLware engineering project
40Saturday 1 September 2012
Safeguard Ballis%c Missile Defense System…
41Saturday 1 September 2012
Revised Project Statistics
Safeguard Ballis%c Missile Defense System…
41Saturday 1 September 2012
Revised Project StatisticsThe project was delivered according to specifica%ons
Safeguard Ballis%c Missile Defense System…
41Saturday 1 September 2012
Revised Project StatisticsThe project was delivered according to specifica%ons
Cost: $25 Billion (not adjusted)
Safeguard Ballis%c Missile Defense System…
41Saturday 1 September 2012
Revised Project StatisticsThe project was delivered according to specifica%ons
Cost: $25 Billion (not adjusted)
1969-‐1975, 5407 person years
Safeguard Ballis%c Missile Defense System…
41Saturday 1 September 2012
Revised Project StatisticsThe 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
Safeguard Ballis%c Missile Defense System…
41Saturday 1 September 2012
Revised Project StatisticsThe project was delivered according to specifica%ons
Cost: $25 Billion (not adjusted)
1969-‐1975, 5407 person years
‘By the time the 6-year anti-missile system project was completed, the new missiles were faster than the anti-
missile missiles’
Operational for 133 days - Project terminated in 1978
Safeguard Ballis%c Missile Defense System…
41Saturday 1 September 2012
Where do things go wrong?
42Saturday 1 September 2012
Requirements are stable
43Saturday 1 September 2012
Technology is well known and mature
44Saturday 1 September 2012
Everything goes as expected/planned
45Saturday 1 September 2012
We’ve a great deal of expertise having
done the same thing many times before
46Saturday 1 September 2012
Heavy weight methods work well when the previous
points are valid
47Saturday 1 September 2012
Projects with those characteristics are few
and far between.
48Saturday 1 September 2012
Heavy Weight Methodologies
49Saturday 1 September 2012
Heavy weight methodologies work in some instances, but there are high costs, and the risk in using them in dynamic environments is high.
Heavy Weight Methodologies
49Saturday 1 September 2012
The Business Case for Agile Development
SucceededFailedChallenged
Chaos Report 2006. Standish Group
We need to do be)er than this ….
IT Projects
50Saturday 1 September 2012
Project Overruns….
51Saturday 1 September 2012
Always7%
OLen13%
Some%mes16%
Rarely19%
Never45%
Standish Group study reported at XP2002 by Jim Johnson, Chairman
O@en or Always Used: 20%
Rarely or NeverUsed: 64%
Feature Use
52Saturday 1 September 2012
How significant is requirements change on a project? “The average project has 30% requirements change”
Can We Predict What We Need ?
53Saturday 1 September 2012
Why Agile?
54Saturday 1 September 2012
Albert Einstein55Saturday 1 September 2012
Albert Einstein
A perfection of means, and confusion of aims, seems to be
our main problem.
55Saturday 1 September 2012
\ 56
Process is a placebo
56Saturday 1 September 2012
\
Jared spool’s tricks to Dogma conAnuum arranges terminology from improvisaAon to atrophy
56
Process is a placebo
56Saturday 1 September 2012
Process is built on values and principles and tailored to fit its
context
Src: Jeff Patton57Saturday 1 September 2012
Src: Jeff Patton58Saturday 1 September 2012
Traditional cost profile
Lower cost of change curve
59Saturday 1 September 2012
Agile system cost profile
Traditional cost profile
Lower cost of change curve
59Saturday 1 September 2012
“I’m glad we’re all agreed then.”
Clear communica%on is the founda%on
60Saturday 1 September 2012
“Ah...”
Get mental models out on the table
61Saturday 1 September 2012
“Ah!”
Convergence through itera%on
62Saturday 1 September 2012
“I’m glad we’re all agreed then.”
A genuinely shared understanding
63Saturday 1 September 2012
Tradi%onal soLware development fixes scope then es%mates to figure out %me and cost
Traditional software
development
Src: Jeff Patton64Saturday 1 September 2012
Tradi%onal soLware development fixes scope then es%mates to figure out %me and cost
Traditional software
development
Scope
Time Cost(resources)
Src: Jeff Patton64Saturday 1 September 2012
Tradi%onal soLware development fixes scope then es%mates to figure out %me and cost
Traditional software
development
Scope
Time Cost(resources)
Src: Jeff Patton64Saturday 1 September 2012
Tradi%onal soLware development fixes scope then es%mates to figure out %me and cost
Traditional software
development
Scope
Time Cost(resources)
Src: Jeff Patton64Saturday 1 September 2012
Agile development fixes %me and cost, then leverages itera%on and incremen%ng to maximize scope
Traditional software
development
Scope
Time Cost(resources)
Src: Jeff Patton65Saturday 1 September 2012
Agile development fixes %me and cost, then leverages itera%on and incremen%ng to maximize scope
Traditional software
development
Scope
Time Cost(resources)
Src: Jeff Patton65Saturday 1 September 2012
Agile development fixes %me and cost, then leverages itera%on and incremen%ng to maximize scope
Traditional software
development
Scope
Time Cost(resources)
Agile software development
Src: Jeff Patton65Saturday 1 September 2012
Agile development fixes %me and cost, then leverages itera%on and incremen%ng to maximize scope
Traditional software
development
Scope
Time Cost(resources)
TimeCost
(resources)
Agile software development
Src: Jeff Patton65Saturday 1 September 2012
Agile development fixes %me and cost, then leverages itera%on and incremen%ng to maximize scope
Traditional software
development
Scope
Time Cost(resources)
Scope
TimeCost
(resources)
Agile software development
Src: Jeff Patton65Saturday 1 September 2012
Leverage a shared understanding of desired product goals to minimize scope while maximizing value
Traditional software
development
Scope
Time Cost(resources)
Scope
TimeCost
(resources)
Agile software development
Src: Jeff Patton66Saturday 1 September 2012
Leverage a shared understanding of desired product goals to minimize scope while maximizing value
Traditional software
development
Scope
Time Cost(resources)
Scope
TimeCost
(resources)
Agile software development
Target business goals & outcomesSrc: Jeff Patton
66Saturday 1 September 2012
Building Quality into the Process
Toyoda Loom
67Saturday 1 September 2012
Source: Beyond Agile Software Development Becoming Lean, Mary Poppendieck, Poppendieck.llc
Utilization (%)
Focus on Throughput
68Saturday 1 September 2012
Tradi%onal Process
69Saturday 1 September 2012
Tradi%onal Process
69Saturday 1 September 2012
Applying Lean Principles to SoLware Development
70Saturday 1 September 2012
End-to-End small slices of work
Applying Lean Principles to SoLware Development
70Saturday 1 September 2012
End-to-End small slices of work 20 % done = 100 % usable
Applying Lean Principles to SoLware Development
70Saturday 1 September 2012
Fix / Integrate $
Test
Code
DesignSpecifications
Use Cases / Functional Specs
Requirements Gathering
Project Plan/Estimation
$
Inception
$
$
$
Lean Principles applied to SoLware Development
71Saturday 1 September 2012
Itera%ve
Adapted from Jeff Patton
72Saturday 1 September 2012
Itera%ve
Adapted from Jeff Patton
72Saturday 1 September 2012
Itera%ve
Adapted from Jeff Patton
72Saturday 1 September 2012
Itera%ve
Adapted from Jeff Patton
72Saturday 1 September 2012
Incremental
Adapted from Jeff Patton
73Saturday 1 September 2012
Incremental
Adapted from Jeff Patton
73Saturday 1 September 2012
Incremental
Adapted from Jeff Patton
73Saturday 1 September 2012
Incremental
Adapted from Jeff Patton
73Saturday 1 September 2012
Itera%ve AND Incremental
Adapted from Jeff Patton
74Saturday 1 September 2012
Itera%ve AND Incremental
• Mix the strategies:–Iterate to find and improve soluAons
–Increment to add funcAonality
Adapted from Jeff Patton
74Saturday 1 September 2012
Itera%ve AND Incremental
• Mix the strategies:–Iterate to find and improve soluAons
–Increment to add funcAonality
Adapted from Jeff Patton
74Saturday 1 September 2012
Itera%ve AND Incremental
• Mix the strategies:–Iterate to find and improve soluAons
–Increment to add funcAonality
Adapted from Jeff Patton
74Saturday 1 September 2012
Itera%ve AND Incremental
• Mix the strategies:–Iterate to find and improve soluAons
–Increment to add funcAonality
Adapted from Jeff Patton
74Saturday 1 September 2012
Itera%ve AND Incremental
• Mix the strategies:–Iterate to find and improve soluAons
–Increment to add funcAonality
Adapted from Jeff Patton
74Saturday 1 September 2012
AgileBirth of a new Software Movement!
75Saturday 1 September 2012
Agile has evolved over many years
Src: Jeff Patton
76Saturday 1 September 2012
2000
77Saturday 1 September 2012
FDD | Feature Driven Development (Jeff DeLuca)
DSDM | Dynamic System Development Method (Dane Faulkner)
Adaptive Software Development (Jim Highsmith)
Crystal (Alistair Cockburn)
SCRUM (Ken Schwaber)
XP | Extreme Programming (Kent Beck)
Lean Software Development (Mary Poppendieck)
2000
77Saturday 1 September 2012
XP
Pragmatic
DSDM
Crystal Lean
Adaptive
Scrum
FDD
Agile
Agile Umbrella
78Saturday 1 September 2012
Agile Manifesto
79Saturday 1 September 2012
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:
79Saturday 1 September 2012
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.
79Saturday 1 September 2012
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.
79Saturday 1 September 2012
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.
79Saturday 1 September 2012
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.
79Saturday 1 September 2012
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.
That is, while there is value in the items on the right, we value the items on the left more.”
© 2001 Agile Alliance. http://www.agilemanifesto.org
79Saturday 1 September 2012
Agile Manifesto Principles
80Saturday 1 September 2012
Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
81Saturday 1 September 2012
Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
82Saturday 1 September 2012
Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the shorter
timescale.
83Saturday 1 September 2012
Business people and developers must work together daily
throughout the project.
84Saturday 1 September 2012
Build projects around motivated
individuals. Give them the environment
and support they need, and trust them to get the job done.
85Saturday 1 September 2012
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
86Saturday 1 September 2012
Working software is the primary measure of progress.
87Saturday 1 September 2012
Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a constant pace
indefinitely.
88Saturday 1 September 2012
Simplicitythe art of maximizing the amount of
work not doneis essential.
89Saturday 1 September 2012
Continuous attention to technical excellence and good design
enhances agility.
90Saturday 1 September 2012
The best architectures, requirements, and designs emerge
from self-organizing teams.
91Saturday 1 September 2012
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.
92Saturday 1 September 2012
It turns out...
93Saturday 1 September 2012
It turns out...
Ziv's law -‐ specifica%ons will never be fully understood.
93Saturday 1 September 2012
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)
93Saturday 1 September 2012
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.
93Saturday 1 September 2012
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)
93Saturday 1 September 2012
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
93Saturday 1 September 2012
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
94Saturday 1 September 2012
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
94Saturday 1 September 2012
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
94Saturday 1 September 2012
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
94Saturday 1 September 2012
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
94Saturday 1 September 2012
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
94Saturday 1 September 2012
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
94Saturday 1 September 2012
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
7. Strong technical environment
Performing a simple process health checkup: h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
94Saturday 1 September 2012
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
7. Strong technical environment
8. Sunny day visibility
Performing a simple process health checkup: h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
94Saturday 1 September 2012
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
7. Strong technical environment
8. Sunny day visibility
9. Regular cadence
Performing a simple process health checkup: h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
94Saturday 1 September 2012
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
7. Strong technical environment
8. Sunny day visibility
9. Regular cadence
10.High energy
Performing a simple process health checkup: h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
94Saturday 1 September 2012
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
7. Strong technical environment
8. Sunny day visibility
9. Regular cadence
10.High energy
11.Empowered teams
Performing a simple process health checkup: h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
94Saturday 1 September 2012
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
7. Strong technical environment
8. Sunny day visibility
9. Regular cadence
10.High energy
11.Empowered teams
12.DisrupAve change
Performing a simple process health checkup: h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2
94Saturday 1 September 2012
Our Team Rooms
95Saturday 1 September 2012
Our plans looks like this
Source : ThoughtWorks
96Saturday 1 September 2012
some more plans…
97Saturday 1 September 2012
src: ThoughtWorks India98Saturday 1 September 2012
src: ThoughtWorks India
Work or Fun or Both?
99Saturday 1 September 2012
src: ThoughtWorks India
Work or Fun or Both?
99Saturday 1 September 2012
Agile Evolution
100Saturday 1 September 2012
XP
Pragmatic
DSDM
Crystal Lean
Adaptive
Scrum
FDD
Agile
Agile Umbrella
101Saturday 1 September 2012
Agile become...
XP
Agile
Scrum
102Saturday 1 September 2012
103Saturday 1 September 2012
Balance discovery with delivery
Delivery: building product right
Discovery: understanding the right product to
build
Src: Jeff Patton104Saturday 1 September 2012
Then came along...
XP
Agile
LeanAgile-UX
ProductDiscovery
Agile Ecosystem
Scrum
105Saturday 1 September 2012
High Level View of an Agile Process
Src: Jeff Patton106Saturday 1 September 2012
Then came along...
XP
Agile
Agile-UX
ProductDiscovery
Agile Ecosystem
ScrumLean
Kanban
107Saturday 1 September 2012
Where did Agile Originate?
Src: Jeff Patton108Saturday 1 September 2012
Problem
Solu
tion
Known Unknown
Kno
wn
Unk
now
n
Src: Eric Ries
Where Agile appears to work best?
109Saturday 1 September 2012
Problem
Solu
tion
Known Unknown
Kno
wn
Unk
now
n
A g i
l e
Src: Eric Ries
Where Agile appears to work best?
109Saturday 1 September 2012
Problem
Solu
tion
Known Unknown
Kno
wn
Unk
now
n
A g i
l e ??
Src: Eric Ries
Where Agile appears to work best?
109Saturday 1 September 2012
Kaizen vs. Kaikaku
110Saturday 1 September 2012
Currently...
XP
Agile
LeanAgile-UX
ProductDiscovery
Dev-OPs
LeanStartup
AgileEcosystem
KanbanScrum
111Saturday 1 September 2012
The Future
XPAgile
Agile-UX
ProductDiscovery
Dev-OPs
Lean Startup
Costumer Development
CDCD
ContinuousDelivery
MVP
Pivot
KanbanScrum Lean
112Saturday 1 September 2012
113Saturday 1 September 2012
Organizations have habits, and they will stick to their habits even at the risk of their own
survival.Brad Anderson, CEO, Best Buy
114Saturday 1 September 2012
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
115Saturday 1 September 2012
116Saturday 1 September 2012
117Saturday 1 September 2012
Innovation
118Saturday 1 September 2012
Metrics Mess
119Saturday 1 September 2012
120Saturday 1 September 2012
Metrics MessKnowledge Islands
121Saturday 1 September 2012
122Saturday 1 September 2012
Be careful not to…
Naresh [email protected]
twitter: @nashjain
http://nareshjain.com
123Saturday 1 September 2012
Be careful not to…
Naresh [email protected]
twitter: @nashjain
http://nareshjain.com
Ques%ons?123Saturday 1 September 2012
Be careful not to…
Naresh [email protected]
twitter: @nashjain
http://nareshjain.com
Ques%ons?123Saturday 1 September 2012