Agile Way of Dealing with Uncertainty in a Complex Adaptive World

Naresh Jain naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comSaturday 1 September 2012 1

Agile Way of dealing with Uncertainty in a Complex Adaptive World Naresh Jain naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comSaturday 1 September 2012 1

Video on Selective Attention http://www.youtube.com/watch?v=vJG698U2MvoSaturday 1 September 2012 2

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

Which line is the longest? 1 2 3Saturday 1 September 2012 4

Which line is the longest? 1 2 3 Müller-Lyer optical illusionSaturday 1 September 2012 4

Which Orange Circle is bigger?Saturday 1 September 2012 5

Which Orange Circle is bigger? Ebbinghaus optical illusionSaturday 1 September 2012 5

Saturday 1 September 2012 6

Pet Plant Research @ an elderly Nursing HomeSaturday 1 September 2012 7

Student Volunteers @ Nursing HomeSaturday 1 September 2012 8

Why?Saturday 1 September 2012 9

What would you prefer? A lo)ery %cket with a random number or a number you’ve picked?Saturday 1 September 2012 10

What would you prefer? In the Casino, if you toss the dice or someone else tosses the dice?Saturday 1 September 2012 11

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

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

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 intervalSaturday 1 September 2012 13

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

UncertaintySaturday 1 September 2012 14

Uncertainty Why? Our desire to ControlSaturday 1 September 2012 14

How do we deal with Uncertainty?Saturday 1 September 2012 15

Predictability ParadoxSaturday 1 September 2012 16

How to Organize a Childrens Party? A video by Dave Snowden http://www.youtube.com/watch?v=Miwb92eZaJgSaturday 1 September 2012 17

Why is there only ONE Toyota or Apple today?Saturday 1 September 2012 20

Products & Processes are like haircuts Copying someone else’s rarely worksSaturday 1 September 2012 21

Retrospec%ve CoherenceSaturday 1 September 2012 22

Retrospec%ve Coherence Hindsight does not lead to foresight!Saturday 1 September 2012 22

MESaturday 1 September 2012 23

Tech Talks!Saturday 1 September 2012 25

Taking ownership of a simple process Adapted from Jeff PattonSaturday 1 September 2012 27

The Ball Point GameSaturday 1 September 2012 28

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 canSaturday 1 September 2012 28

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 strategySaturday 1 September 2012 28

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 membersSaturday 1 September 2012 28

Core Agile concepts learned? Adapted from Jeff PattonSaturday 1 September 2012 29

Core Agile concepts learned?  Ideal processes use a simple framework -‐ like a game Adapted from Jeff PattonSaturday 1 September 2012 29

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 PattonSaturday 1 September 2012 29

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 PattonSaturday 1 September 2012 29

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 PattonSaturday 1 September 2012 29

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 PattonSaturday 1 September 2012 29

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 PattonSaturday 1 September 2012 29

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 PattonSaturday 1 September 2012 29

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  Reﬂec7on: observing, measuring & changing is the means for process improvement Adapted from Jeff PattonSaturday 1 September 2012 29

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  Reﬂec7on: observing, measuring & changing is the means for process improvement  Team work is an individual skill Adapted from Jeff PattonSaturday 1 September 2012 29

“Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.” Dee HockSaturday 1 September 2012 30

Your SoLware Development Game? What would be:  Your goal  Simple structure  Simple rulesSaturday 1 September 2012 31

The Agile Game Adapted from Jeff PattonSaturday 1 September 2012 32

The Agile Game Your goal:  As a team, predictably deliver max value to users & stakeholders Adapted from Jeff PattonSaturday 1 September 2012 32

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 ﬁxed cycle  Reﬂect & improve your Product, Plan, People and Process Adapted from Jeff PattonSaturday 1 September 2012 32

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 ﬁxed cycle  Reﬂect & 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 PattonSaturday 1 September 2012 32

Agile OriginsSaturday 1 September 2012 33

SoLware Engineering?Saturday 1 September 2012 34

SoLware Engineering? Crea%ng SoLware is a CraL. Conver%ng source code to executable is the engineering bit.Saturday 1 September 2012 34

IEEE deﬁnes 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, 1990Saturday 1 September 2012 35

Who used SoLware Engineering?Saturday 1 September 2012 36

For the space shuttle’s operating systemSaturday 1 September 2012 37

Some Sta%s%cs NASA’s Defect DensitySaturday 1 September 2012 38

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

One More Data PointSaturday 1 September 2012 39

Another real soLware engineering projectSaturday 1 September 2012 40

Another real soLware engineering project Safeguard - Ballistic Missile Defense SystemSaturday 1 September 2012 40

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 % 42Saturday 1 September 2012 40

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

Safeguard Ballis%c Missile Defense System…Saturday 1 September 2012 41

Safeguard Ballis%c Missile Defense System… Revised Project StatisticsSaturday 1 September 2012 41

Safeguard Ballis%c Missile Defense System… Revised Project Statistics The project was delivered according to speciﬁca%ons Saturday 1 September 2012 41

Safeguard Ballis%c Missile Defense System… Revised Project Statistics The project was delivered according to speciﬁca%ons Cost: $25 Billion (not adjusted)Saturday 1 September 2012 41

Safeguard Ballis%c Missile Defense System… Revised Project Statistics The project was delivered according to speciﬁca%ons Cost: $25 Billion (not adjusted) 1969-‐1975, 5407 person yearsSaturday 1 September 2012 41

Safeguard Ballis%c Missile Defense System… Revised Project Statistics The project was delivered according to speciﬁca%ons Cost: $25 Billion (not adjusted) 1969-‐1975, 5407 person years Operational for 133 days - Project terminated in 1978Saturday 1 September 2012 41

Safeguard Ballis%c Missile Defense System… Revised Project Statistics The project was delivered according to speciﬁca%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

Where do things go wrong?Saturday 1 September 2012 42

Requirements are stableSaturday 1 September 2012 43

Technology is well known and matureSaturday 1 September 2012 44

Everything goes as expected/plannedSaturday 1 September 2012 45

We’ve a great deal of expertise having done the same thing many times beforeSaturday 1 September 2012 46

Heavy weight methods work well when the previous points are validSaturday 1 September 2012 47

Projects with those characteristics are few and far between.Saturday 1 September 2012 48

Heavy Weight MethodologiesSaturday 1 September 2012 49

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

The Business Case for Agile Development We need to do be)er than this …. IT Projects Succeeded Failed Challenged Chaos Report 2006. Standish GroupSaturday 1 September 2012 50

Project Overruns….Saturday 1 September 2012 51

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, ChairmanSaturday 1 September 2012 52

Can We Predict What We Need ? How signiﬁcant is requirements change on a project? “The average project has 30% requirements change”Saturday 1 September 2012 53

Why Agile?Saturday 1 September 2012 54

Albert EinsteinSaturday 1 September 2012 55

A perfection of means, and confusion of aims, seems to be our main problem. Albert EinsteinSaturday 1 September 2012 55

Process is a placebo 56Saturday 1 September 2012 56

Process is a placebo Jared spool’s tricks to Dogma conAnuum arranges terminology from improvisaAon to atrophy 56Saturday 1 September 2012 56

Process is built on values and principles and tailored to ﬁt its context Src: Jeff PattonSaturday 1 September 2012 57

Src: Jeff PattonSaturday 1 September 2012 58

Lower cost of change curve Traditional cost profileSaturday 1 September 2012 59

Lower cost of change curve Traditional cost profile Agile system cost profileSaturday 1 September 2012 59

Clear communica%on is the founda%on “I’m glad we’re all agreed then.”Saturday 1 September 2012 60

Get mental models out on the table “Ah...”Saturday 1 September 2012 61

Convergence through itera%on “Ah!”Saturday 1 September 2012 62

A genuinely shared understanding “I’m glad we’re all agreed then.”Saturday 1 September 2012 63

Tradi%onal soLware development ﬁxes scope then es%mates to ﬁgure out %me and cost Traditional software development Src: Jeff PattonSaturday 1 September 2012 64

Tradi%onal soLware development ﬁxes scope then es%mates to ﬁgure out %me and cost Scope Traditional software development Time Cost (resources) Src: Jeff PattonSaturday 1 September 2012 64

Agile development ﬁxes %me and cost, then leverages itera%on and incremen%ng to maximize scope Scope Traditional software development Time Cost (resources) Src: Jeff PattonSaturday 1 September 2012 65

Agile development ﬁxes %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 PattonSaturday 1 September 2012 65

Agile development ﬁxes %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 PattonSaturday 1 September 2012 65

Agile development ﬁxes %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 PattonSaturday 1 September 2012 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) Src: Jeff PattonSaturday 1 September 2012 66

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 outcomesSaturday 1 September 2012 66

Building Quality into the Process Toyoda LoomSaturday 1 September 2012 67

Focus on Throughput Utilization (%) Source: Beyond Agile Software Development Becoming Lean, Mary Poppendieck, Poppendieck.llcSaturday 1 September 2012 68

Tradi%onal ProcessSaturday 1 September 2012 69

Applying Lean Principles to SoLware DevelopmentSaturday 1 September 2012 70

Applying Lean Principles to SoLware Development End-to-End small slices of workSaturday 1 September 2012 70

Applying Lean Principles to SoLware Development End-to-End small slices 20 % done = 100 % usable of workSaturday 1 September 2012 70

Lean Principles applied to SoLware Development Project Plan/Estimation Requirements Gathering Use Cases / Functional Specs Design Specifications Code Test Fix / Integrate $ Inception $ $ $ $Saturday 1 September 2012 71

Itera%ve Adapted from Jeff PattonSaturday 1 September 2012 72

Incremental Adapted from Jeff PattonSaturday 1 September 2012 73

Itera%ve AND Incremental Adapted from Jeff PattonSaturday 1 September 2012 74

Itera%ve AND Incremental • Mix the strategies: –Iterate to ﬁnd and improve soluAons –Increment to add funcAonality Adapted from Jeff PattonSaturday 1 September 2012 74

Agile Birth of a new Software Movement!Saturday 1 September 2012 75

Agile has evolved over many years Src: Jeff PattonSaturday 1 September 2012 76

2000Saturday 1 September 2012 77

2000 XP | Extreme Programming (Kent Beck) DSDM | Dynamic System Development Method (Dane Faulkner) FDD | Feature Driven Development (Jeff DeLuca) SCRUM (Ken Schwaber) Crystal (Alistair Cockburn) Adaptive Software Development (Jim Highsmith) Lean Software Development (Mary Poppendieck)Saturday 1 September 2012 77

Agile Umbrella Agile XP Scrum DSDM FDD Adaptive Pragmatic Crystal LeanSaturday 1 September 2012 78

Agile ManifestoSaturday 1 September 2012 79

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

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

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

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

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

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.orgSaturday 1 September 2012 79

Agile Manifesto PrinciplesSaturday 1 September 2012 80

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Saturday 1 September 2012 81

Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage.Saturday 1 September 2012 82

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

Business people and developers must work together daily throughout the project.Saturday 1 September 2012 84

Build projects around motivated individuals. Givethem the environment and support they need, and trust them to get the job done.Saturday 1 September 2012 85

The most efﬁcient and effective method of conveying information to and within a development team is face-to-face conversation.Saturday 1 September 2012 86

Working software is the primary measure of progress.Saturday 1 September 2012 87

Agile processes promote sustainable development. Thesponsors, developers, and users should be able to maintain a constant pace indeﬁnitely.Saturday 1 September 2012 88

Simplicity the art of maximizing the amount of work not done is essential.Saturday 1 September 2012 89

Continuous attention to technical excellence and good design enhances agility.Saturday 1 September 2012 90

The best architectures, requirements, and designs emerge from self-organizing teams.Saturday 1 September 2012 91

At regular intervals, the teamreﬂects on how to become moreeffective, then tunes and adjusts its behavior accordingly.Saturday 1 September 2012 92

It turns out...Saturday 1 September 2012 93

It turns out... Zivs law -‐ speciﬁca%ons will never be fully understood.Saturday 1 September 2012 93

It turns out... Zivs law -‐ speciﬁca%ons will never be fully understood. Humphreys 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

It turns out... Zivs law -‐ speciﬁca%ons will never be fully understood. Humphreys law -‐ the user will never know what they want un%l aLer the system is in produc%on (maybe not even then) Wegners lemma -‐ an interac%ve system can never be fully speciﬁed nor can it ever be fully tested. Saturday 1 September 2012 93

It turns out... Zivs law -‐ speciﬁca%ons will never be fully understood. Humphreys law -‐ the user will never know what they want un%l aLer the system is in produc%on (maybe not even then) Wegners lemma -‐ an interac%ve system can never be fully speciﬁed nor can it ever be fully tested. Langdons lemma -‐ soLware evolves more rapidly as it approaches chao%c regions (taking care not to spill over into chaos)Saturday 1 September 2012 93

It turns out... Zivs law -‐ speciﬁca%ons will never be fully understood. Humphreys law -‐ the user will never know what they want un%l aLer the system is in produc%on (maybe not even then) Wegners lemma -‐ an interac%ve system can never be fully speciﬁed nor can it ever be fully tested. Langdons 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. - JeffSaturday 1 September 2012 93

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

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

Treat agile principles as “proper%es” you use to assess process health 1. Frequent delivery 2. ReﬂecAve improvement Performing a simple process health checkup: h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2 Saturday 1 September 2012 94

Treat agile principles as “proper%es” you use to assess process health 1. Frequent delivery 2. ReﬂecAve 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

Treat agile principles as “proper%es” you use to assess process health 1. Frequent delivery 2. ReﬂecAve 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

Treat agile principles as “proper%es” you use to assess process health 1. Frequent delivery 2. ReﬂecAve 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

Treat agile principles as “proper%es” you use to assess process health 1. Frequent delivery 2. ReﬂecAve 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

Treat agile principles as “proper%es” you use to assess process health 1. Frequent delivery 7. Strong technical environment 2. ReﬂecAve 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

Treat agile principles as “proper%es” you use to assess process health 1. Frequent delivery 7. Strong technical environment 2. ReﬂecAve 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

Treat agile principles as “proper%es” you use to assess process health 1. Frequent delivery 7. Strong technical environment 2. ReﬂecAve 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

Treat agile principles as “proper%es” you use to assess process health 1. Frequent delivery 7. Strong technical environment 2. ReﬂecAve 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

Treat agile principles as “proper%es” you use to assess process health 1. Frequent delivery 7. Strong technical environment 2. ReﬂecAve 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

Treat agile principles as “proper%es” you use to assess process health 1. Frequent delivery 7. Strong technical environment 2. ReﬂecAve 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

Our Team RoomsSaturday 1 September 2012 95

Our plans looks like this Source : ThoughtWorksSaturday 1 September 2012 96

some more plans…Saturday 1 September 2012 97

src: ThoughtWorks IndiaSaturday 1 September 2012 98

Work or Fun or Both? src: ThoughtWorks IndiaSaturday 1 September 2012 99

Agile EvolutionSaturday 1 September 2012 100

Agile Umbrella Agile XP Scrum DSDM FDD Adaptive Pragmatic Crystal LeanSaturday 1 September 2012 101

Agile become... Agile XP ScrumSaturday 1 September 2012 102

Balance discovery with delivery Discovery:understanding theright product to build Delivery: building product right Src: Jeff PattonSaturday 1 September 2012 104

Then came along... Agile Ecosystem Agile Agile-UX XP Lean Scrum Product DiscoverySaturday 1 September 2012 105

High Level View of an Agile Process Src: Jeff PattonSaturday 1 September 2012 106

Then came along... Agile Ecosystem Agile Agile-UX XP Lean Scrum Kanban Product DiscoverySaturday 1 September 2012 107

Where did Agile Originate? Src: Jeff PattonSaturday 1 September 2012 108

Where Agile appears to work best? Unknown Solution Known Known Unknown Problem Src: Eric RiesSaturday 1 September 2012 109

Where Agile appears to work best? Unknown le Solution gi Known A Known Unknown Problem Src: Eric RiesSaturday 1 September 2012 109

Where Agile appears to work best? Unknown ?? le Solution gi Known A Known Unknown Problem Src: Eric RiesSaturday 1 September 2012 109

Kaizen vs. KaikakuSaturday 1 September 2012 110

Currently... Agile Ecosystem Lean Agile Startup Agile-UX XP Lean Scrum Kanban Dev-OPs Product DiscoverySaturday 1 September 2012 111

The Future Lean Startup CD Pivot Costumer Development CD Agile Continuous Delivery XP Agile-UX Scrum Lean Kanban Dev-OPs MVP Product DiscoverySaturday 1 September 2012 112

Organizations have habits, and they will stick to their habits even at the risk of their own survival. Brad Anderson, CEO, Best BuySaturday 1 September 2012 114

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 dont do it, you lose your competitive edge. Nancy McKinstry, CEO, Wolters KluwerSaturday 1 September 2012 115

InnovationSaturday 1 September 2012 118

Metrics MessSaturday 1 September 2012 119

Knowledge Islands Metrics MessSaturday 1 September 2012 121

Be careful not to… Naresh Jain naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comSaturday 1 September 2012 123

Be careful not to… Naresh Jain Ques%ons? naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comSaturday 1 September 2012 123