• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile WTF
 

Agile WTF

on

  • 4,071 views

An introductory presentation by Naresh Jain on the essence of Being Agile vs. Following Agile and why being Agile is important? Naresh also shows an evolution of Agile methods over the last 11 years ...

An introductory presentation by Naresh Jain on the essence of Being Agile vs. Following Agile and why being Agile is important? Naresh also shows an evolution of Agile methods over the last 11 years and the future of Agile. Also take a sneak preview into what challenges an organizations may face when trying to be agile?

Statistics

Views

Total Views
4,071
Views on SlideShare
2,502
Embed Views
1,569

Actions

Likes
10
Downloads
93
Comments
0

16 Embeds 1,569

http://blogs.agilefaqs.com 1299
http://www.thoughtworks.com 172
http://www.linkedin.com 26
http://agilefaqs.com 21
http://nareshjain.com 17
http://feeds.feedburner.com 12
http://blogs.thoughtworks.com 7
http://127.0.0.1:8795 3
https://twitter.com 2
http://pinterest.com 2
http://translate.googleusercontent.com 2
https://si0.twimg.com 2
http://localhost 1
http://coderwall.com 1
https://twimg0-a.akamaihd.net 1
http://127.0.0.1 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
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Agile WTF Agile WTF Presentation Transcript

    • Agile WTF! Naresh Jain naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comFriday 15 June 2012 1
    • Agile WTF! Agile Way to Fail! Naresh Jain naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comFriday 15 June 2012 1
    • Being ‘agile’ OVERFollowing ‘Agile’ Naresh Jain naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comFriday 15 June 2012 2
    • Friday 15 June 2012 3
    • Friday 15 June 2012 4
    • Why is there only ONE Toyota or Apple today?Friday 15 June 2012 5
    • Processes are like haircuts Copying someone else’s rarely worksFriday 15 June 2012 6
    • Retrospec)ve  CoherenceFriday 15 June 2012 7
    • Retrospec)ve  Coherence Hindsight does not lead to foresight!Friday 15 June 2012 7
    • Albert EinsteinFriday 15 June 2012 8
    • A perfection of means, and confusion of aims, seems to be our main problem. Albert EinsteinFriday 15 June 2012 8
    • Process  is  a  placebo 9Friday 15 June 2012 9
    • Process  is  a  placebo Jared  spool’s  tricks  to  Dogma  con7nuum  arranges   terminology  from  improvisa7on  to  atrophy 9Friday 15 June 2012 9
    • Process is built on values and principles and tailored to fit its context Src: Jeff PattonFriday 15 June 2012 10
    • Src: Jeff PattonFriday 15 June 2012 11
    • MEFriday 15 June 2012 12
    • Friday 15 June 2012 13
    • MumbaiFriday 15 June 2012 14
    • Tech Talks!Friday 15 June 2012 15
    • FitNesse Panopticode ProTest DBFit FitDecorator ProFIT La"u Patang QWickFriday 15 June 2012 16
    • Friday 15 June 2012 17
    • Friday 15 June 2012 18
    • Friday 15 June 2012 19
    • Friday 15 June 2012 20
    • Friday 15 June 2012 21
    • Friday 15 June 2012 22
    • Taking ownership of a simple process Adapted from Jeff PattonFriday 15 June 2012 23
    • The  Ball  Point  GameFriday 15 June 2012 24
    • 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  canFriday 15 June 2012 24
    • 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  strategyFriday 15 June 2012 24
    • 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  membersFriday 15 June 2012 24
    • Core  Agile  concepts  learned? Adapted from Jeff PattonFriday 15 June 2012 25
    • Core  Agile  concepts  learned?  Ideal  processes  use  a  simple  framework  -­‐  like  a  game   Adapted from Jeff PattonFriday 15 June 2012 25
    • 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 PattonFriday 15 June 2012 25
    • 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 PattonFriday 15 June 2012 25
    • 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 PattonFriday 15 June 2012 25
    • 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 PattonFriday 15 June 2012 25
    • 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 PattonFriday 15 June 2012 25
    • 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 PattonFriday 15 June 2012 25
    • 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 PattonFriday 15 June 2012 25
    • 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 PattonFriday 15 June 2012 25
    • “Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.” Dee HockFriday 15 June 2012 26
    • Your  SoNware  Development  Game? What  would  be:  Your  goal  Simple  structure  Simple  rulesFriday 15 June 2012 27
    • The  Agile  Game Adapted from Jeff PattonFriday 15 June 2012 28
    • The  Agile  Game Your  goal:  As  a  team,  predictably  deliver  max  value  to  users  &  stakeholders Adapted from Jeff PattonFriday 15 June 2012 28
    • 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 PattonFriday 15 June 2012 28
    • 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 PattonFriday 15 June 2012 28
    • Why Agile?Friday 15 June 2012 29
    • Lower  cost  of  change  curve Traditional cost profileFriday 15 June 2012 30
    • Lower  cost  of  change  curve Traditional cost profile Agile system cost profileFriday 15 June 2012 30
    • Clear  communica)on  is  the  founda)on “I’m glad we’re all agreed then.”Friday 15 June 2012 31
    • Get  mental  models  out  on  the  table “Ah...”Friday 15 June 2012 32
    • Convergence  through  itera)on “Ah!”Friday 15 June 2012 33
    • A  genuinely  shared  understanding “I’m glad we’re all agreed then.”Friday 15 June 2012 34
    • Tradi7onal  so>ware  development  fixes  scope   then  es7mates  to  figure  out  7me  and  cost Traditional software development Src: Jeff PattonFriday 15 June 2012 35
    • Tradi7onal  so>ware  development  fixes  scope   then  es7mates  to  figure  out  7me  and  cost Scope Traditional software development Time Cost (resources) Src: Jeff PattonFriday 15 June 2012 35
    • Tradi7onal  so>ware  development  fixes  scope   then  es7mates  to  figure  out  7me  and  cost Scope Traditional software development Time Cost (resources) Src: Jeff PattonFriday 15 June 2012 35
    • Tradi7onal  so>ware  development  fixes  scope   then  es7mates  to  figure  out  7me  and  cost Scope Traditional software development Time Cost (resources) Src: Jeff PattonFriday 15 June 2012 35
    • Agile  development  fixes  7me  and  cost,  then  leverages   itera7on  and  incremen7ng  to  maximize  scope   Scope Traditional software development Time Cost (resources) Src: Jeff PattonFriday 15 June 2012 36
    • Agile  development  fixes  7me  and  cost,  then  leverages   itera7on  and  incremen7ng  to  maximize  scope   Scope Traditional software development Time Cost (resources) Src: Jeff PattonFriday 15 June 2012 36
    • Agile  development  fixes  7me  and  cost,  then  leverages   itera7on  and  incremen7ng  to  maximize  scope   Scope Agile software development Traditional software development Time Cost (resources) Src: Jeff PattonFriday 15 June 2012 36
    • Agile  development  fixes  7me  and  cost,  then  leverages   itera7on  and  incremen7ng  to  maximize  scope   Cost Scope Time (resources) Agile software development Traditional software development Time Cost (resources) Src: Jeff PattonFriday 15 June 2012 36
    • Agile  development  fixes  7me  and  cost,  then  leverages   itera7on  and  incremen7ng  to  maximize  scope   Cost Scope Time (resources) Agile software development Traditional software development Time Cost Scope (resources) Src: Jeff PattonFriday 15 June 2012 36
    • 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 PattonFriday 15 June 2012 37
    • 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 outcomesFriday 15 June 2012 37
    • Building  Quality  into  the  Process Toyoda LoomFriday 15 June 2012 38
    • Focus  on  Throughput Utilization (%) Source: Beyond Agile Software Development Becoming Lean, Mary Poppendieck, Poppendieck.llcFriday 15 June 2012 39
    • Tradi)onal  ProcessFriday 15 June 2012 40
    • Tradi)onal  ProcessFriday 15 June 2012 40
    • Applying  Lean  Principles   to  SoNware  DevelopmentFriday 15 June 2012 41
    • Applying  Lean  Principles   to  SoNware  Development End-to-End small slices of workFriday 15 June 2012 41
    • Applying  Lean  Principles   to  SoNware  Development End-to-End small slices 20 % done = 100 % usable of workFriday 15 June 2012 41
    • Lean  Principles  applied   to  SoNware  Development   Project Plan/Estimation Requirements Gathering Use Cases / Functional Specs Design Specifications Code Test Fix / Integrate $ Inception $ $ $ $Friday 15 June 2012 42
    • Itera)ve Adapted from Jeff PattonFriday 15 June 2012 43
    • Itera)ve Adapted from Jeff PattonFriday 15 June 2012 43
    • Itera)ve Adapted from Jeff PattonFriday 15 June 2012 43
    • Itera)ve Adapted from Jeff PattonFriday 15 June 2012 43
    • Incremental Adapted from Jeff PattonFriday 15 June 2012 44
    • Incremental Adapted from Jeff PattonFriday 15 June 2012 44
    • Incremental Adapted from Jeff PattonFriday 15 June 2012 44
    • Incremental Adapted from Jeff PattonFriday 15 June 2012 44
    • Itera)ve  AND  Incremental Adapted from Jeff PattonFriday 15 June 2012 45
    • Itera)ve  AND  Incremental • Mix  the  strategies: –Iterate to  find  and  improve  solu6ons –Increment to  add  func6onality   Adapted from Jeff PattonFriday 15 June 2012 45
    • Itera)ve  AND  Incremental • Mix  the  strategies: –Iterate to  find  and  improve  solu6ons –Increment to  add  func6onality   Adapted from Jeff PattonFriday 15 June 2012 45
    • Itera)ve  AND  Incremental • Mix  the  strategies: –Iterate to  find  and  improve  solu6ons –Increment to  add  func6onality   Adapted from Jeff PattonFriday 15 June 2012 45
    • Itera)ve  AND  Incremental • Mix  the  strategies: –Iterate to  find  and  improve  solu6ons –Increment to  add  func6onality   Adapted from Jeff PattonFriday 15 June 2012 45
    • Itera)ve  AND  Incremental • Mix  the  strategies: –Iterate to  find  and  improve  solu6ons –Increment to  add  func6onality   Adapted from Jeff PattonFriday 15 June 2012 45
    • Agile Birth of a new Software Movement!Friday 15 June 2012 46
    • Agile  has  evolved  over  many  years Src: Jeff PattonFriday 15 June 2012 47
    • Agile  Umbrella Agile XP Scrum DSDM FDD Adaptive Pragmatic Crystal LeanFriday 15 June 2012 48
    • Agile ManifestoFriday 15 June 2012 49
    • Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Friday 15 June 2012 49
    • Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: – Individuals and interactions OVER processes and tools.Friday 15 June 2012 49
    • Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: – Individuals and interactions OVER processes and tools. – Working software OVER comprehensive documentation.Friday 15 June 2012 49
    • Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: – Individuals and interactions OVER processes and tools. – Working software OVER comprehensive documentation. – Customer collaboration OVER contract negotiation.Friday 15 June 2012 49
    • Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: – Individuals and interactions OVER processes and tools. – Working software OVER comprehensive documentation. – Customer collaboration OVER contract negotiation. – Responding to change OVER following a plan.Friday 15 June 2012 49
    • 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.orgFriday 15 June 2012 49
    • Agile Manifesto PrinciplesFriday 15 June 2012 50
    • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Friday 15 June 2012 51
    • Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage.Friday 15 June 2012 52
    • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.Friday 15 June 2012 53
    • Business people and developers must work together daily throughout the project.Friday 15 June 2012 54
    • Build projects around motivated individuals. Givethem the environment and support they need, and trust them to get the job done.Friday 15 June 2012 55
    • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.Friday 15 June 2012 56
    • Working software is the primary measure of progress.Friday 15 June 2012 57
    • Agile processes promote sustainable development. Thesponsors, developers, and users should be able to maintain a constant pace indefinitely.Friday 15 June 2012 58
    • Simplicity the art of maximizing the amount of work not done is essential.Friday 15 June 2012 59
    • Continuous attention to technical excellence and good design enhances agility.Friday 15 June 2012 60
    • The best architectures, requirements, and designs emerge from self-organizing teams.Friday 15 June 2012 61
    • At regular intervals, the teamreflects on how to become moreeffective, then tunes and adjusts its behavior accordingly.Friday 15 June 2012 62
    • It  turns  out...Friday 15 June 2012 63
    • It  turns  out...  Zivs  law  -­‐  specifica=ons  will  never  be  fully  understood.Friday 15 June 2012 63
    • It  turns  out...  Zivs  law  -­‐  specifica=ons  will  never  be  fully  understood.  Humphreys  law  -­‐  the  user  will  never  know  what  they  want  un=l   aOer  the  system  is  in  produc=on  (maybe  not  even  then)Friday 15 June 2012 63
    • It  turns  out...  Zivs  law  -­‐  specifica=ons  will  never  be  fully  understood.  Humphreys  law  -­‐  the  user  will  never  know  what  they  want  un=l   aOer  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.  Friday 15 June 2012 63
    • It  turns  out...  Zivs  law  -­‐  specifica=ons  will  never  be  fully  understood.  Humphreys  law  -­‐  the  user  will  never  know  what  they  want  un=l   aOer  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  -­‐  soOware  evolves  more  rapidly  as  it   approaches  chao=c  regions  (taking  care  not  to  spill  over  into   chaos)Friday 15 June 2012 63
    • It  turns  out...  Zivs  law  -­‐  specifica=ons  will  never  be  fully  understood.  Humphreys  law  -­‐  the  user  will  never  know  what  they  want  un=l   aOer  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  -­‐  soOware  evolves  more  rapidly  as  it   approaches  chao=c  regions  (taking  care  not  to  spill  over  into   chaos) Any association of predictive or defined processes with Agile is an exercise in futility. - JeffFriday 15 June 2012 63
    • Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
    • Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
    • Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 2. Reflec6ve  improvement Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
    • Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 2. Reflec6ve  improvement 3. Close  communica6on Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
    • Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 2. Reflec6ve  improvement 3. Close  communica6on 4. Focus Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
    • Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 2. Reflec6ve  improvement 3. Close  communica6on 4. Focus 5. Personal  safety Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
    • Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 2. Reflec6ve  improvement 3. Close  communica6on 4. Focus 5. Personal  safety 6. Easy  access  to  experts Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
    • Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 7. Strong  technical  environment 2. Reflec6ve  improvement 3. Close  communica6on 4. Focus 5. Personal  safety 6. Easy  access  to  experts Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
    • Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 7. Strong  technical  environment 2. Reflec6ve  improvement 8. Sunny  day  visibility 3. Close  communica6on 4. Focus 5. Personal  safety 6. Easy  access  to  experts Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
    • Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 7. Strong  technical  environment 2. Reflec6ve  improvement 8. Sunny  day  visibility 3. Close  communica6on 9. Regular  cadence 4. Focus 5. Personal  safety 6. Easy  access  to  experts Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
    • Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 7. Strong  technical  environment 2. Reflec6ve  improvement 8. Sunny  day  visibility 3. Close  communica6on 9. Regular  cadence 4. Focus 10.High  energy 5. Personal  safety 6. Easy  access  to  experts Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
    • Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 7. Strong  technical  environment 2. Reflec6ve  improvement 8. Sunny  day  visibility 3. Close  communica6on 9. Regular  cadence 4. Focus 10.High  energy 5. Personal  safety 11.Empowered  teams 6. Easy  access  to  experts Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
    • Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 7. Strong  technical  environment 2. Reflec6ve  improvement 8. Sunny  day  visibility 3. Close  communica6on 9. Regular  cadence 4. Focus 10.High  energy 5. Personal  safety 11.Empowered  teams 6. Easy  access  to  experts 12.Disrup6ve  change Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
    • Our  Team  RoomsFriday 15 June 2012 65
    • some  more  plans…Friday 15 June 2012 66
    • src: ThoughtWorks IndiaFriday 15 June 2012 67
    • Work or Fun or Both? src: ThoughtWorks IndiaFriday 15 June 2012 68
    • Work or Fun or Both? src: ThoughtWorks IndiaFriday 15 June 2012 68
    • Agile EvolutionFriday 15 June 2012 69
    • Agile  Umbrella Agile XP Scrum DSDM FDD Adaptive Pragmatic Crystal LeanFriday 15 June 2012 70
    • Agile  become... Agile XP ScrumFriday 15 June 2012 71
    • Friday 15 June 2012 72
    • Balance discovery with delivery Discovery:understanding theright product to build Delivery: building product right Src: Jeff PattonFriday 15 June 2012 73
    • Then  came  along... Agile Ecosystem Agile Agile-UX XP Lean Scrum Product DiscoveryFriday 15 June 2012 74
    • High Level View of an Agile Process Src: Jeff PattonFriday 15 June 2012 75
    • Then  came  along... Agile Ecosystem Agile Agile-UX XP Lean Scrum Kanban Product DiscoveryFriday 15 June 2012 76
    • Where did Agile Originate? Src: Jeff PattonFriday 15 June 2012 77
    • Where  Agile  appears  to  work  best? Unknown Solution Known Known Unknown Problem Src: Eric RiesFriday 15 June 2012 78
    • Where  Agile  appears  to  work  best? Unknown le Solution gi Known A Known Unknown Problem Src: Eric RiesFriday 15 June 2012 78
    • Where  Agile  appears  to  work  best? Unknown ?? le Solution gi Known A Known Unknown Problem Src: Eric RiesFriday 15 June 2012 78
    • Kaizen vs. KaikakuFriday 15 June 2012 79
    • Currently... Agile Ecosystem Lean Agile Startup Agile-UX XP Lean Scrum Kanban Dev-OPs Product DiscoveryFriday 15 June 2012 80
    • The  Future Lean Startup CD Pivot Costumer Development CD Agile Continuous Delivery XP Agile-UX Scrum Lean Kanban Dev-OPs MVP Product DiscoveryFriday 15 June 2012 81
    • Friday 15 June 2012 82
    • Organizations have habits, and they will stick to their habits even at the risk of their own survival. Brad Anderson, CEO, Best BuyFriday 15 June 2012 83
    • 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 KluwerFriday 15 June 2012 84
    • Friday 15 June 2012 85
    • Friday 15 June 2012 86
    • InnovationFriday 15 June 2012 87
    • Metrics MessFriday 15 June 2012 88
    • Friday 15 June 2012 89
    • Knowledge Islands Metrics MessFriday 15 June 2012 90
    • Friday 15 June 2012 91
    • Be  careful  not  to… Naresh Jain naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comFriday 15 June 2012 92
    • Be  careful  not  to… Naresh Jain Ques7ons? naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comFriday 15 June 2012 92
    • Be  careful  not  to… Naresh Jain Ques7ons? naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comFriday 15 June 2012 92