• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile Way of Dealing with Uncertainty in a Complex Adaptive World
 

Agile Way of Dealing with Uncertainty in a Complex Adaptive World

on

  • 5,168 views

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 ...

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.

Statistics

Views

Total Views
5,168
Views on SlideShare
4,097
Embed Views
1,071

Actions

Likes
6
Downloads
129
Comments
2

16 Embeds 1,071

http://blogs.agilefaqs.com 704
http://www.thoughtworks.com 159
http://agilefaqs.com 94
http://www.linkedin.com 31
http://localhost 22
http://blogs.thoughtworks.com 21
http://nareshjain.com 17
http://feeds.feedburner.com 7
https://twitter.com 5
http://ranksit.com 3
http://translate.googleusercontent.com 2
https://twimg0-a.akamaihd.net 2
http://161.27.27.33 1
https://si0.twimg.com 1
http://www.onlydoo.com 1
https://www.linkedin.com 1
More...

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Great job.. very inspiring
    Are you sure you want to
    Your message goes here
    Processing…
  • thank you naresh, for your thoughtful presentation. i see great merit in applying agile methodology to my own field of instructional design and your presentation has given me great food for thought.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Agile Way of Dealing with Uncertainty in a Complex Adaptive World Agile Way of Dealing with Uncertainty in a Complex Adaptive World Presentation Transcript

    • 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
    • Pet  Plant  Research  @  an  elderly  Nursing  HomeSaturday 1 September 2012 7
    • Student  Volunteers  @  Nursing  HomeSaturday 1 September 2012 8
    • 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
    • How  do  we  deal  with  Uncertainty?Saturday 1 September 2012 15
    • How  do  we  deal  with  Uncertainty?Saturday 1 September 2012 15
    • How  do  we  deal  with  Uncertainty?Saturday 1 September 2012 15
    • 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
    • Saturday 1 September 2012 18
    • Saturday 1 September 2012 19
    • 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
    • Saturday 1 September 2012 24
    • Tech Talks!Saturday 1 September 2012 25
    • Saturday 1 September 2012 26
    • 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    Reflec7on:  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    Reflec7on:  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  fixed  cycle    Reflect  &  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  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 PattonSaturday 1 September 2012 32
    • Saturday 1 September 2012 33
    • 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  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, 1990Saturday 1 September 2012 35
    • Who  used  SoLware  Engineering?Saturday 1 September 2012 36
    • 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
    • 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
    • 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  specifica%ons  Saturday 1 September 2012 41
    • 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
    • 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  yearsSaturday 1 September 2012 41
    • 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 1978Saturday 1 September 2012 41
    • 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
    • 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  significant  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 fit 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  fixes  scope   then  es%mates  to  figure  out  %me  and  cost Traditional software development Src: Jeff PattonSaturday 1 September 2012 64
    • Tradi%onal  soLware  development  fixes  scope   then  es%mates  to  figure  out  %me  and  cost Scope Traditional software development Time Cost (resources) Src: Jeff PattonSaturday 1 September 2012 64
    • Tradi%onal  soLware  development  fixes  scope   then  es%mates  to  figure  out  %me  and  cost Scope Traditional software development Time Cost (resources) Src: Jeff PattonSaturday 1 September 2012 64
    • Tradi%onal  soLware  development  fixes  scope   then  es%mates  to  figure  out  %me  and  cost Scope Traditional software development Time Cost (resources) Src: Jeff PattonSaturday 1 September 2012 64
    • 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 PattonSaturday 1 September 2012 65
    • 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 PattonSaturday 1 September 2012 65
    • 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 PattonSaturday 1 September 2012 65
    • 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 PattonSaturday 1 September 2012 65
    • 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 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
    • 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
    • Itera%ve Adapted from Jeff PattonSaturday 1 September 2012 72
    • Itera%ve Adapted from Jeff PattonSaturday 1 September 2012 72
    • Itera%ve Adapted from Jeff PattonSaturday 1 September 2012 72
    • Incremental Adapted from Jeff PattonSaturday 1 September 2012 73
    • Incremental Adapted from Jeff PattonSaturday 1 September 2012 73
    • Incremental Adapted from Jeff PattonSaturday 1 September 2012 73
    • 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  find  and  improve  soluAons –Increment to  add  funcAonality   Adapted from Jeff PattonSaturday 1 September 2012 74
    • Itera%ve  AND  Incremental • Mix  the  strategies: –Iterate to  find  and  improve  soluAons –Increment to  add  funcAonality   Adapted from Jeff PattonSaturday 1 September 2012 74
    • Itera%ve  AND  Incremental • Mix  the  strategies: –Iterate to  find  and  improve  soluAons –Increment to  add  funcAonality   Adapted from Jeff PattonSaturday 1 September 2012 74
    • Itera%ve  AND  Incremental • Mix  the  strategies: –Iterate to  find  and  improve  soluAons –Increment to  add  funcAonality   Adapted from Jeff PattonSaturday 1 September 2012 74
    • Itera%ve  AND  Incremental • Mix  the  strategies: –Iterate to  find  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 efficient 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 indefinitely.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 teamreflects 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  -­‐  specifica%ons  will  never  be  fully  understood.Saturday 1 September 2012 93
    • It  turns  out...  Zivs  law  -­‐  specifica%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  -­‐  specifica%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   specified  nor  can  it  ever  be  fully  tested.  Saturday 1 September 2012 93
    • It  turns  out...  Zivs  law  -­‐  specifica%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   specified  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  -­‐  specifica%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   specified  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. 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Saturday 1 September 2012 103
    • 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
    • Saturday 1 September 2012 113
    • 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
    • Saturday 1 September 2012 116
    • Saturday 1 September 2012 117
    • InnovationSaturday 1 September 2012 118
    • Metrics MessSaturday 1 September 2012 119
    • Saturday 1 September 2012 120
    • Knowledge Islands Metrics MessSaturday 1 September 2012 121
    • Saturday 1 September 2012 122
    • 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
    • Be  careful  not  to… Naresh Jain Ques%ons? naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comSaturday 1 September 2012 123