O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Why Does Agile Work?

1.536 visualizações

Publicada em

We all know, given the right mindset, that Agile approaches are a great way to get results and for people to go home feeling that they have contributed.

But no one really asks why. Why does it work?

This presentation, given at the Agile Business Conference in London in 2013 provides a collection of Agile-independant thoughts and ideas to make people think.

Above all, it provides some take aways to help judge if the team has a solid understanding of purpose and if the team is just well, how can on say, "dysfunctional".

Publicada em: Tecnologia, Negócios
  • Seja o primeiro a comentar

Why Does Agile Work?

  1. 1. Why  Does  Agile  Work?   October  9-­‐10th  2013   Agile  Business  Conference  2013     MaAhew  Caine  
  2. 2. AGILE     Some  people  call  it  a   method  or  an  approach     above  all     It  is  about  PEOPLE  and  RESULTS    
  3. 3. AssumpOons   •  •  •  •    Heard  something  about  “Agile”   May  have  seen  teams  working  in  this  way   You  like  it…  but  not  sure  why  it  works   Expect  some  quick-­‐win  “take-­‐aways”  
  4. 4. Who  am  I?   •  •  •  •  •  •  English   Come  from  near  Liverpool  /  Manchester   I.T.  background   Lived  in  CH  since  1994   Worked  in  London,  NY,  Berlin,  Geneva  and  ZH   Discovered  “Agile”  in  2009   August  2011   Setup  M.C.  Partners  &  Associates   September  2012   Launched  the  Agile  Academy  
  5. 5. Community  
  6. 6. A  Rollercoaster  Journey  
  7. 7. Let’s  Look  at  MoOvaOon   OUR  projects  are   Soooo  Complex  –   we  need  moOvated   people!  
  8. 8. Are  We  MoOvated?   How  many  people  are  truly  moOvated  in  their   work?   1  in  5   2  in  5   3  in  5   4  in  5   5  in  5  
  9. 9. MoOvaOon   Today  people  are  just  not  moOvated.   •  Only  1-­‐in-­‐5  are  truly  moOvated   •  Fear  prevails  in  the  work-­‐place     Let’s  not  menOon  these…    
  10. 10. 20th  Century  Management   Kills  MoOvaOon   (enough  said)  
  11. 11. Denning  Discovered  MoOvated  Geeks   They  were  doing  this  “Agile  thing”  
  12. 12. MoOvaOon   The  golden  quesOon  for  many  including  Denning   was:  “WHY?”     To  answer  this  we  need  to  understand  what   moOvates  us,  as  Human  Beings.    
  13. 13. Humans  Need  Three  Things   Autonomy   Mastery   Purpose   Daniel  Pink  “Drive”  
  14. 14. Let’s  Look  at  Complexity   OUR  complex   projects  need  to  be   planned  up  front  
  15. 15. Cynefin   hAp://en.wikipedia.org/wiki/Cynefin  
  16. 16. Cynefin  –  A  Complicated  Problem   Calculate  the  SHORTEST  route:     Hardbrücke  to  Frankenstrasse   Given  enough  data  &  Ome  we  can   PREDICT  the  outcome  of  a   COMPLICATED  problem  
  17. 17. Cynefin  –  A  Complex  Problem   Calculate  the  FASTEST  route   based  on  traffic  NOW:     Hardbrücke  to  Frankenstrasse   We  cannot  PREDICT  the  outcome  of   a  COMPLEX  problem  
  18. 18. Mapping  Methods  to  Cynefin     Agile hAp://en.wikipedia.org/wiki/Cynefin  
  19. 19. MoOvaOon  &  Complexity   Why  does   Agile   MoOvate?  
  20. 20. Agile  (Complex  Emergent)  Projects   The  Problem:  We  Love  to  Plan!   •  All  the  detail  “up  front”   •  Be  in  control   •  Resist  “change”  
  21. 21. BUT   The  World  is  changing  faster…        Those  plans  we  love,  have  to  change            If  not,  what  happens?    
  22. 22. Example   Road  trip  from  LA  to  Grand  Canyon   Spend  Ome  “upfront”  planning  route  in  detail.   As  soon  as  you  are  on  the  road…  
  23. 23. Details  ALWAYS  Emerge   We  always  discover  new  stuff        How  do  we  embrace  this  EMERGENT  stuff?              How  do  we  structure  our  work?    
  24. 24. Some  Key  Concepts   Fixed   Scope   Time   Cost   Quality   Quality   MoSCoW  Prio   Time   1   Time  Boxes   Variable   Cost   2   3   4   2-­‐6  weeks  in  length,  with  a  preference  for  the  shorter   Client  feedback  arer  every  Omebox:  “FAIL-­‐FAST”   Demo  at  the  end  of  each  Omebox   Scope   5   M  –  Must  (60%)   S  –  Should  (20%)   C  –  Could  (20%)   W  -­‐  Wont   6  
  25. 25. What  Makes  us  Agile?   Ability  to  re-­‐evaluate  what  the  most  important  thing  to  do  is,   at  the  start  of  each  Omebox,  including:     1.  New  emergent  “stuff”   2.  Things  that  did  not  get  done   3.  Change  in  priority   2   1   2   3   1   4   3   5   6  
  26. 26. The  Four  Agile  Ceremonies   Timebox  Planning  (1-­‐2  days)   Daily  Standup  (15  mins)   Review  /  Demo  (1-­‐2  hours)   RetrospecOves  (1-­‐2  hours)   Week  2   Review   Week  3   Daily  Standups   Retro   Week  1   Planning   1.  2.  3.  4. 
  27. 27. Timebox  Planning   Goal   To  produce  a  list  of  TASKS  that  the  team  are  commisng  too   with  their  plan,  with  the  priority     Ø Must  (60%)   Ø Should  (20%)   Ø Could  (20%)   Ø Wont  
  28. 28. Daily  Standup  
  29. 29. Review   Goal   To  get  assurance  that  the  right  things  are  being  done,  correctly.     Ø  The  ONLY  way  to  get  feedback  from  clients   Ø  Get  approval  that  things  are  right  (or  wrong!)  
  30. 30. RetrospecOves   Goal   To  allow  the  team  to  improve  on  HOW  they   work.     To  conOnuously  improve.  
  31. 31. Complex  Emergent  Agile   Products  &  Projects   ✓   Autonomy   ✓   Mastery   ✓   Purpose  
  32. 32. Denning’s  MoOvated  Geeks   Worked  with   Autonomy,  Mastery  and  Purpose  
  33. 33. Lean  Knowledge  Processes   Compare  this  type  of  tradiOonal  manufacturing…             With  knowledge  work  “manufacturing”  …  
  34. 34. Cannot  See  “Work-­‐in-­‐Progress”   Do  we  have…   •  BoAlenecks?   •  Idle  resources?   •  Burn-­‐out?   •  Focus?   All  result  in   •  No  mastery   •  No  sense  of  purpose   •  No  autonomy  
  35. 35. Need  to  Remove  “Waste”   #   Waste   DescripSon   1   Transport   Product  moving  from  A  to  B   2   Movement   MoOon  of  people  or  equipment  to  perform  processing   3   Idle  Time   WaiOng  for  the  next  step   4   Over  processing   ResulOng  from  poor  tool  or  product  design  creaOng  acOvity   5   Delivery  before  being  needed   Over  producOon   6   Defects   The  effort  involved  in  inspecOng  for  and  fixing  defects   7   Inventory   All  things  not  being  processed   8   Producing  things  that  don’t   fulfill  client  needs   Adding  things  that  are  not  needed   9   Unused  Human  Talent   No  duplicaOon  of  roles,  no  gaps,  the  right  people  
  36. 36. “Lean”  Purpose   •  Helping  others,  either  side   –  Before  me   –  Arer  me     •  Understand  the  big  picture   Purpose  
  37. 37. Lean   ✓   Autonomy   ✓   Mastery   ✓   Purpose  
  38. 38. All  of  this  Requires  Teamwork   My  team  is   GREAT  !!  
  39. 39. But  not  DysfuncOonal  Teamwork   In  the  last  month,  have  you  WITNESSED…     1.  Someone  admit  a  mistake   2.  Someone  ask  for  help   3.  Someone  point  out  to  a  colleague  that  they   were  lesng  the  team  down  by  their  acOons   4.  Someone  did  something  outside  of  their   personal  objecOves,  for  the  good  of  the  group.  
  40. 40. The  Five  DysfuncOons  of  a  Team   InaAenOon  to   Results   Avoidance  of   Accountability   Lack  of   Commitment   Fear  of   Conflict   Absence  of   Trust   Status  &  Ego:  Individuals  put  own  or  team’s   needs  before  that  of  the  collecOve  team’s  goal.   Low  Standards:  Don’t  challenge  colleagues  when   their  acOons  appear  wrong.   Ambiguity:  Rarely,  if  ever,  buy-­‐in  and   commit  but  “pretend”  to  agree.   ArSficial  Harmony:  Don’t  have   open  and  passionate  debate.   Invulnerable:  Don’t  admit   mistakes  and  weaknesses.   “The  Five  DysfuncOons  of  a  Team”,  P.  Lencioni  
  41. 41. Examples  –  What  does  it  look  like?   DysfuncSon   Symptom   Good  Example?   InaAenOon  to  Results   Individuals  put  own  or  team’s   a)  PM:  Sure  I  can  test  that.   needs  before  that  of  the  collecOve   b)  BA:  I  can  cover  Support.   team’s  goal.   Avoidance  of   Accountability   Don’t  challenge  colleagues  when   their  acOons  appear  wrong   a)  You  said  you  would  do  it,   you  haven’t.   b)  Stop  thinking  about  just   Dev…  we  need  to  think   beyond  just  dev   Lack  of  Commitment   Rarely,  if  ever,  buy-­‐in  and   commit  but  “pretend”  to  agree.   a)  I  understand  that  this  is   what  we  are  doing,  I  agree,  I   think  it  is  good.   Fear  of  Conflict   Don’t  have  open  and  passionate   debate   a)  I  don’t  agree…  because…   b)  But  X  will  not  like  it,  we   need  to  think  about  them…   Absence  of  Trust   Don’t  admit  mistakes  and   weaknesses   a)  I  have  a  problem…   b)  Sorry  I  screwed  up…   45  
  42. 42. From  a  PosiOve  Point-­‐of-­‐View   A  truly  cohesive  team…     •  •  •  •  •  Trusts  one  another     Engages  in  unfiltered  conflict  around  ideas   Commits  to  decisions  and  plans  of  acOon   Holds  one  another  accountable  for  delivering  against  those  plans   Focus’  on  the  achievement  of  collecOve  results  
  43. 43. Be  Aware  –  Look  Out  for  Clues   Behavior   Sprint   Planning   Trust  one  another   Standup   Grooming   Sprint   Review   ✓ •  Open  about  mistakes  &  weakness   Engage  in  unfiltered  conflict   around  ideas   ✓ Commit  to  decisions  and  plans  of   acOon   ✓ ✓ •  Passionate  debate  occurs   •  Real  buy-­‐in  with  emoOon   ✓ Hold  one  another  accountable   for  delivering  against  those  plans   ✓ ✓ Focus  on  the  achievement  of   collecOve  results   ✓ ✓ •  Challenge  colleagues   •  Ego  &  status  don’t  maAer   Sprint   Retro  
  44. 44. Even  Remote  Teamwork   Agile  Requires   Co-­‐locaOon  
  45. 45. Most  Teams  are  Remote   Remote  means:     •  on  another  conOnent     •  in  another  country     •  in  another  company     •  in  another  building     •  on  another  floor     •  in  another  room     •  more  than  25m  away...       ...  outside  of  passive  hearing.      
  46. 46. “Community  Decay”   Trust   MoOvaOon   Face-­‐to-­‐face   event   Face-­‐to-­‐face   event   Time  
  47. 47. “Community  Decay”   Trust   MoOvaOon   Face-­‐to-­‐face   event   Face-­‐to-­‐face   event   Need  to   communicate  to   prevent  “decay”   Time  
  48. 48. How  Does  Agile  Help?   Trust   MoOvaOon   Face-­‐to-­‐face   event   Face-­‐to-­‐face   event   Time  
  49. 49. How  Does  Agile  Help?   Trust   MoOvaOon   Face-­‐to-­‐face   event   Face-­‐to-­‐face   event   Time   Constant  communicaOon  (hard!)     In  a  remote  team,  Agile  is  beAer   than  tradiOonal  anyway!  
  50. 50. But  there  is  only  one  Purpose   $  profit,  please  
  51. 51. Your  Hardest  Job   What?   What?   How?   Why?   Most  groups  know  WHAT  and  HOW  but  oren  fail  to  say  WHY!   Simon  Sinek  –  Golden  Circle  
  52. 52. Example  
  53. 53. Why  is  this  one  beAer?   A  greater  sense  of  purpose  is  achieved  when  it  relates  to  “people”,   not  things,  least  of  all  money!  
  54. 54. Bringing  it  all  Together   And  Agile  Lean  approaches  support  this  
  55. 55. QuesOons?  
  56. 56. Further  Reading   The  Stoos  Movement   www.stoosnetwork.org     Holacracy   www.holacracy.org    
  57. 57. Contact   PlaYorm   Link   Telephone   +41  79  936  7060   Email   maAhew.caine@mcpa.biz   Homepage   www.mcpa.biz  |  www.agileacademy.ch   Library   www.mcpa.biz/blog   Xing   hAps://www.xing.com/profile/MaAhew_Caine   LinkedIn   hAp://ch.linkedin.com/in/maAhewcaine   TwiAer   mc_mcpa   Skype   mc_mcpa   YouTube   hAp://www.youtube.com/MCPartnersAssociates  
  58. 58. What  moOvates  MaAhew  is  simple:  “When  done  well,  Agile  approaches  make  a   difference  to  people’s  lives,  for  the  beAer  because  Agile  organisaOons  allow  their   people  to  go  home  saOsfied,  fulfilled  having  contributed”.   MaAhew  brings  20+  years  of  experience  from  across  the  IT  sector.  He  has  worked  at   sorware  companies  such  as  Avaloq  and  Infonic.   He  was  also  a  senior  consultant  for  10  years  at  Logica,  based  in  London,  Zürich,  Berlin  and  Geneva.  In  between   he  was  also  worked  at  Swiss  Re  in  Zurich  and  New  York.     Arer  introducing  Infonic  to  Agile  methods,  MaAhew  founded  M.C.  Partners  &  Associates  and  is  the  Managing   Director  of  the  Agile  Academy  Switzerland.  In  addiOon,  he  is  a  founding  member  of  the  Swiss  Agile  Leaders   Circle.     He  holds  a  Bachelors  of  Science  degree,  with  Honors,  in  Computer  Science  from  the  University  of  Staffordshire  in   England.  He  is  a  member  of  the  DSDM  ConsorOum,  Scrum  Alliance  and  is  a  volunteer  in  the  PMI  Swiss-­‐Chapter.   He  is  also  core  team  member  of  both  the  SwissICT’s  “Lean,  Agile  &  Scrum”  team  and  “Stoos  Network  Zurich”   movements.     When  he  is  not  public  speaking  on  the  theme  of  people  and  agility,  he  can  be  found  in  a  wild  remote  corner  of   Scotland  following  his  life-­‐long  passion  of  fishing.