PAM Summit Cracow, The goes Agile Story


Published on

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

PAM Summit Cracow, The goes Agile Story

  1. 1. Workshop   The  OneABB  Team  Goes  Agile       The  Tricks  Used  for  Crea8ng  Awareness  and  Desire  for  Change   and  Actually  Doing  the  Change       Ma?hew  Caine  
  2. 2. AGILE     Some  people  call  it  a   method  or  an  approach     above  all     It  is  about  PEOPLE  and  RESULTS    
  3. 3. Assump8ons   •  You  are  looking  for  real  challenges  of  “Agile”   •  Expect  some  quick-­‐win  “take-­‐aways”   •  You  are  not  here  to  fine-­‐tune  your  Standups    
  4. 4. Who  am  I?   •  •  •  •  •  •  English   Come  from  near  Liverpool  /  Manchester   I.T.  background   Lived  in  Zurich  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. OneABB’s Purpose: “An Awesome Website”
  7. 7. 2000  content  editors 80  country  sites   over  1  million  urls     10  million   views  /  month  
  8. 8. ABB’s website is a key customer connection Facebook and LinkedIn are the top sources of traffic after direct visits, search, and visits from the intranet
  9. 9. The  Real  Story   •  •  •  •  •  •  •  •  No  transparency  on  status,  people  or  ac8vi8es   50  people  in  four  countries   40  people  in  Krakow  organized  by  skill   Culture  of  maintenance   “Hero  culture”  with  Prima  Donnas   Agile,  but  not  really   Constant  “firefigh8ng”   Stuff  was  late,  not  as  expected,  poor  quality  
  10. 10. This  Workshop  is  about   the  changes  above  and  beyond  Agile  skills.   It  is  about  some  of  the  things  we     had  to  do   con8nue  to  do   and  s8ll  need  to  do     to  give  Agile  a  chance!  
  11. 11. How  the  Workshop  will  Work   •  9  topics…  The  first  5-­‐6:   –  Examine  the  Scenario  /  Theory   –  You  get  5  minutes  at  your  table  to  discuss   –  I  then  chose  2  groups  for  feedback   –  We  then  look  at  what  was  actually  done   •  At  the  end  we’ll  scan  the  remaining  topics.  
  12. 12. Managing  Prima  Donnas   /   Gold  Pla8ng  =  Quality   Remote  Teamwork   Performance  Reviews   The  Gan?  Lie  Chart  vs  “Agile  Planning”   Crea8ng  Awareness  &  Desire   Remote  Team  Percep8on   Be?er  Transparency  on  Work   Looking  for  &  Building  Trust  
  13. 13. Crea8ng  Awareness  &  Desire  
  14. 14. Crea8ng  Awareness  &  Desire   The  Scenario   It  is  May  2012.    You  are  in  a  room  with  the  key  people  from  Krakow  and  Zurich.    They   know  things  have  to  improve.    But  don’t  know  where  to  start.   Your  Task   Discuss  how  you  would  get  them  to:     1.  Share  &  agree  on  their  pains   2.  Want  to  address  the  pains   3.  Agree  on  the  most  important  changes?  
  15. 15. Crea8ng  Awareness  &  Desire   Step  1:  Brainstorm  to  Visualise  “Tensions”  
  16. 16. Crea8ng  Awareness  &  Desire   Step  2:  Run  a  Normal  Retrospec8ves  Session   Categories   What  went  well?   What  do  we  need  to  start?   What  do  we  need  to  stop?   What  do  we  need  to  improve?   Out-­‐of-­‐the-­‐box  innova8ve  ideas  
  17. 17. Crea8ng  Awareness  &  Desire   Step  3:  Which  Tensions  could  be  Resolved  and  Examine  Lem-­‐overs   3b)  Re-­‐examine  any  lem-­‐overs   3a)  Place  “tensions”  on  top  
  18. 18. Crea8ng  Awareness  &  Desire   Step  4:  Group  &  Name   B   C   A   D   F   E  
  19. 19. Crea8ng  Awareness  &  Desire   Step  5:  Priori8se   B   Priority   C   A   B   E   C   F   D   F   1.  2.  3.  4.  E   Each  Team-­‐member  has  3  votes.   Take  5  minutes  to  vote.   Facilitator  checks  and  summarizes  the  vo8ng.     Debate  results.   D   A  
  20. 20. Crea8ng  Awareness  &  Desire   Step  6:  Assign  Owner     B   Priority   Owner   C   B   John   E   Mary   C   Mark   F   A   Paul   D   D   F   A   Don’t  do  low  prio  stuff!   E   As  a  peer-­‐group  they  have  iden8fied  their  tensions,  priori8zed  and  assigned  owners.   By  default  they  are  aware  and  have  the  focus  and  desire  to  change.  
  21. 21. Crea8ng  Awareness  &  Desire   Project  Methodology   Stop   Classic  BA  process   Start   Have  a  board   with  projects  and   priori8es  visible   to  everyone.   Stop   Having  every  task   a  top  priority   Start   Regular   structured   standups   Stop   Making  promises   without   consul8ng   execu8ng  party   Start   Get  the  UX  –  BA  –   DEV  process   working   Everything  is  a   priority  to   everyone  in   GWM   Maintenance   burden  of  “old”   vs  developing   new   Improve   Set  up  common   rules  for  running   a  project   Improve   Intera8ve:  Get   feedback  more   omen,  earlier   Improve   Priori8za8on  and   deadline  serng   Improve   Be  persistant  with   things  we  have   started.  Do  not   abandon  things.   Well   Projects  where   we  have  a  clear   deliverables   schedule   Improve   Planning  and   Priori8za8on   Improve   Working  on   deadlines   together   Well   Projects  with   weekly  mee8ngs   to  followup  on   overall  status   Improve   PM  ISDC  GWH   Well   Doing  the  scope   planning  together   Well   Structuring  the   Work  (Basecamp)  
  22. 22. Managing  Prima  Donnas  
  23. 23. Managing  Prima  Donnas   The  Scenario   Krakow  has  a  number  of  Individuals  that  are   “prima-­‐donnas”…   Your  Task   Discuss  and  list  your  thoughts  on  :     •  The  risks  of  prima-­‐donnas  to  the  teams,  department  &  company.   •  How  you  could  get  the  knowledge  of  the  individual  prima-­‐donnas  shared.    
  24. 24. Managing  Prima  Donnas   Ø  Ø  Ø  Ø  Ø  Ø  Ø  Ø  Bo?leneck  for  the  teams   Difficult  to  plan   Create  dependencies  in  a  sprint   Burn  out   Cause  resentment   “Under  a  bus”  syndrome   Like  to  keep  know-­‐how   Poor  team  members  
  25. 25. Managing  Prima  Donnas   Typical  Solu8on   Alterna8vely   Two  or  more  teams  share:   50%     But  s8ll:     •  Bo?leneck   •  Difficult  to  plan   •  Create  dependencies  in  a  sprint   •  Burn  out   •  Cause  resentment   •  “Under  a  bus”  syndrome   •  Insecure  –  like  to  keep  know-­‐how   •  Poor  team  members   •  Make  them  free-­‐agents   •  No  longer  responsible  for  deliverables   •  Now  responsible  for  coaching  &   suppor8ng  team  members  who  deliver   Thus   •  Know-­‐how  transfer  happens   •  Can  support  many  people   •  Ego  is  not  damaged  ;-­‐)    
  26. 26. Be?er  Transparency  on  Work  
  27. 27. Be?er  Transparency  on  Work   The  Scenario   •  Zurich  has  no  idea  who  is  working  on  what  or  why  people  are  working  on  things.   •  Krakow  does  not  understand  the  priori8es,  as  they  constantly  change.   •  Krakow  do  not  know  what  to  work  on  or  why  it  is  suddenly  “important”.   Your  Task   List  your  thoughts  on  how  to  gain  transparency  on:     1.  Why  work  is  important  (Purpose)?   2.  What  is  coming  (Future  stuff)?   3.  Who  is  working  now  on  what?     It  is  important  that  both  Krakow  and  Zurich  see  the  same  informa8on.    
  28. 28. Be?er  Transparency  on  Work   Step  1:  Define  Phases  that  Projects  are  “in”   Based  on  DSDM:  Pre-­‐Project,  Feasibility,  Founda8ons,  Explora8on  &  Engineering   Idea   OpAons   High  Level  Plan   Features   A  long  10m  Wall  will  help!   Maintenance  
  29. 29. Be?er  Transparency  on  Work   Step  2:  Map  Projects  to  the  Phases  and  the  Projects  to  Teams   Teams  can  start  to  PULL  work…  
  30. 30. Be?er  Transparency  on  Work   Step  3:  Assign  People  to  Teams  &  Iterate  (Ac8on  Gaps!)  
  31. 31. Be?er  Transparency  on  Work   Step  4:  Make  it  All  Accessible  to  All  (Zurich  &  Krakow)  All  the  Time  e.g.  Google  Drive  Docs  
  32. 32. /   Gold  Pla8ng  =  Quality  
  33. 33. /   Gold  Pla8ng  =  Quality   The  Scenario   Krakow  development  speed  is  slowed  due  to:     •  Developers  gold-­‐pla8ng   •  Poor  quality     Yet  developers  want  to  work  on  the  next  latest  sexiest  work.   Your  Task   What  do  developers  need  to  understand  to:     •  reduce  gold-­‐pla8ng     •  deliver  quality   •  get  developer  working  on  the  next  sexy  project?      
  34. 34. /   Gold  Pla8ng  =  Quality   ü  Build  the  absolute  minimum.   ü  Don’t  be  tempted  to  do  what  is  interes8ng.   ü  Build  it  well.     ü  Make  it  from  simple  stuff.     Ø  Frees  developers  from  future  maintenance.   Ø  Gives  8me  to  start  the  next  sexiest  job.    
  35. 35. Remote  Team  Percep8on  
  36. 36. Remote  Team  Percep8on   The  Scenario   •  There  is  miscommunica8on  in  the  team  split  across  Zurich  &  Krakow.   •  People  are  by-­‐passed  and  feel  unappreciated   •  Others  have  to  much  to  do.   Business   Sponsor   Your  Task   Two  groups  will:     1.  Read  their  team  descrip8ons   2.  Put  names  to  the  Roles   (based  on  DSDM)  –  Flipchart   Provided   3.  Reveal  the  results     “Spot  the  Difference”.       Business   Visionary   Project   Manager   Technical   Coordinator   “Expert  user”   Team   Leader   Business   Advisors   “End  user”   Solu8on   Developers   Business   Ambassadors   Business   Analysts   Solu8on   Testers  
  37. 37. Remote  Team  Percep8on   SPOT  THE  DIFFERENCE  
  38. 38. Remote  Team  Percep8on   Zurich’s  Percep8on   Mike   Mike   Business   Sponsor   ????   Krakow’s  Percep8on     Business   Sponsor   Piotr   Nolan   Business   Visionary   Project   Manager   ????   Technical   Coordinator   Nolan   Business   Visionary   Casper   Project   Manager   Technical   Coordinator   ????   ????   Team   Leader   Team   Leader   Business   Advisors   Casper   Casper   Solu8on   Developers   Lukas   Casper   Pawel   Business   Advisors   Business   Ambassadors   Claire   Solu8on   Developers   ????   Lukas   Piotr   Pawel   Business   Ambassadors   Anna   Business   Analysts   Eloise   Solu8on   Testers   Business   Analysts   Eloise   SPOT  THE  DIFFERENCE   Solu8on   Testers  
  39. 39. The  Gan?  Lie  Chart  vs  “Agile  Planning”  
  40. 40. The  Gan?  Lie  Chart  vs  “Agile  Planning”   The  Scenario   •  Scrum  &  sprints  are  perfect  for  systems  that  are  already  live.   •  Zurich  however,  occasionally  want  to  launch  new  products.   •  Some8mes  for  things  that  we  don’t  even  know  if  they  are  possible.     DSDM  is  great  for  star8ng  a  new  product…     •  Take  an  idea   •  Test  op8ons  and  feasibility   •  Set  up  a  high-­‐level  plan  and  context  (JEDUF)     •  Finally  to  launch  into  regular  sprints  /  Timeboxes.   Your  Task   What  could  the  context  be?  What  makes  sense  to  agree  before  development   starts,  especially  in  large  corporate  IT  environments?  
  41. 41. •  •  •  •  •  •  •  “Agile  Planning”   Business  case,  vision,  assump8ons   Op8ons  considered   Recommended  op8on   Highlevel  plan  (ext  deadlines)   Indictor  of  poten8al  cost   Plan  +  cost  to  deliver  “High  level  planning”   Key  resources   AT  THIS  POINT  STILL   NO  DETAILED  SPEC  or  DESIGN  (JEDUF)   Idea!   •  •  •  •  High  Level   Planning   Op8ons   1-­‐Pager   Business  driver   V.  Highlevel  Objec8ves   Request  to  invest  $x  in   “Op8ons”   Increment   E   J,  A   Increment   H   G   Maintenance  strategy   Tes8ng  strategy   Non-­‐func8onal  needs   Audit  requirements   Regulatory  needs   Hardware,  somware,  middleware   •  •  •  •  •  •  Priori8sed  Highlevel  Requirements   Timebox  Plans  with  MoSCoW’d  requirements   Financial  cost  for  en8re  plan.   Repor8ng   Resources   Delivery  plan  (training  etc)   I   B   Deploy   •  •  •  •  •  •  •  ROI,  Business  Case   •  Risks,  assump8ons   C   Increment   D   Deploy   Assess   Benefits   F   Deploy   Decision  Point   (Go  on,  Stop)   PrioriAsed  Requirements   A  m   B  s   C  s   D  c   E  m   F  c   G  m   H  m   I  s   J  m   Timebox   Deploy   Into  produc8on   (Not  necessarily  switch-­‐on)  
  42. 42. Looking  for  &  Building  Trust  
  43. 43. Looking  for  &  Building  Trust   The  Theory:  The  Five  Dysfunc8ons  of  a  Team  (P.  Lencioni,  2002)     Ina?en8on  to   Results   Avoidance  of   Accountability   Lack  of   Commitment   Fear  of   Conflict   Absence  of   Trust   Status  &  Ego:  Individuals  put  own  or  department’s   needs  before  that  of  the  collec8ve  team’s  goal.   Low  Standards:  Don’t  challenge  peers  when   their  ac8ons  appear  counterproduc8ve.   Ambiguity:  Rarely,  if  ever,  buy-­‐in  and   commit  but  “pretend”  to  agree.   ArAficial  Harmony:  Incapable   of  unfiltered  and  passionate  debate.   Invulnerable:  Don’t  admit   mistakes  and  weaknesses.  
  44. 44. Looking  for  &  Building  Trust   The  Scenario   •  People  in  Zurich  have  started  to  distrust  those  in  Krakow.   •  People  in  Krakow  have  started  to  distrust  those  in  Zurich.   •  “Finger  poin8ng”  &  blame  has  started.   •  There  is  an  absence  of  trust!   Your  Task   Agile  teams  have  perfect  moments  to  admit  mistakes  and  weaknesses.     Ø  When  are  they?   Ø  If  team-­‐members  do  trust  each  other,  what  do  you  hear  when  they  talk?  
  45. 45. Looking  for  &  Building  Trust   ü  Sprint  Planning   ü  “I  need  help”   ü  Standups   ü  “I  made  a  mistake”   ü  Review   ü  “I  found  an  issue,  can  we  look  together”   ü  Retrospec8ve   ü  “Your  work  was  great”   ü  Backlog  Grooming   ü  “This  is  taking  longer  than  I  thought”   ü  “Sorry,  my  assump8on  was  wrong”   ü  “I  am  not  familiar  with  this  code,  who   can  help  me?”   ü  “You  said  you’d  work  on  this…   why  have  you  not  done  so?”  
  46. 46. Remote  Teamwork  
  47. 47. Remote  Teamwork   The  Theory   Top-­‐Down   Control   from  ZH   Freedom  in  a   Framework   “Agile”  is  the  framework   Them  and  Us!   Bo?om  Up   Krakow   Autonomy  
  48. 48. Remote  Teamwork   The  Scenario   Like  85%  of  teamwork,  this  team  is  remote  (Zurich  and  Krakow).     People  think  that  only  co-­‐located  teams  can  be  Agile.     Your  Task   Discuss  the  reality  that  85%  of  teams  are  not  co-­‐located.  Then  think  about:     Ø  How  far  away  do  you  have  to  be,  to  be  “remote”?   Ø  Why  is  being  Agile  actually  be?er  for  a  remote  team?  
  49. 49. Remote  Teamwork   ü  In  the  next  room   ü  When  you  cannot  hear  a  conversa8on  
  50. 50. Remote  Teamwork   Community  Decay   Trust   Mo8va8on   Face-­‐to-­‐face   event   Face-­‐to-­‐face   event   Time   50  
  51. 51. Remote  Teamwork   Community  Decay   Trust   Mo8va8on   Face-­‐to-­‐face   event   Face-­‐to-­‐face   event   “Communica8on  Decay”   Time   51  
  52. 52. Remote  Teamwork   How  Does  Agile  Help?   Trust   Mo8va8on   Face-­‐to-­‐face   event   Face-­‐to-­‐face   event   Time   Through  Frequent   Planning,  Standups,  Reviews,  Grooming  and  Retrospec8ves   52  
  53. 53. Performance  Reviews  
  54. 54. Performance  Reviews   The  Scenario   You  are  now  “Agile”  your  teams  are  working  well.     However,  people  s8ll  have  personal  goals  based  on  SMART  deliverables.     Your  Task   Discuss  the  reality  that  the  teams  cannot  “predict”  their  deliverables:     Ø  What  could  be  reviewed  instead?   Ø  Who  should  review  it?   Ø  Do  we  s8ll  match  performance  to  bonus?  
  55. 55. Performance  Reviews   ü  Reward  good  “Agile”  behavior   ü  Never  8e  performance  to  a  bonus   ü  Manager  should  never  evaluate   Jurgen  Apello:   h?p://­‐money/  
  56. 56. Managing  Prima  Donnas   /   Gold  Pla8ng  =  Quality   Remote  Teamwork   Performance  Reviews   The  Gan?  Lie  Chart  vs  “Agile  Planning”   Crea8ng  Awareness  &  Desire   Remote  Team  Percep8on   Be?er  Transparency  on  Work   Looking  for  &  Building  Trust  
  57. 57. /   Gold  Pla8ng  =  Quality   Managing  Prima  Donnas   Con8nuously   Review   Remote  Teamwork   Next  Week:  ATDD,   “Hardening”,   Planning   Performance  Reviews   Crea8ng  Awareness  &  Desire   Improve   Everything   The  Gan?  Lie  Chart  vs  “Agile  Planning”   We  are  S8ll   Improving…   Remote  Team  Percep8on   Be?er  Transparency  on  Work   Looking  for  &  Building  Trust  
  58. 58. An  awesome  Website   needs  PEOPLE   to  deliver  RESULTS     Any  Ques8ons?  
  59. 59. Stay  in  Contact   PlaNorm          Telephone     Link   +41  79  936  7060   Email   ma?   Homepage   Library   Xing   h?ps://   LinkedIn   h?p://   Twi?er   mc_mcpa   Skype   mc_mcpa   YouTube   h?p://  
  60. 60. Support  Material  
  61. 61. Remote  Team  Perspec8ves   •  Team  1  –  Zurich’s  View   Mike  is  paying  for  the  work.    We  know  that  Nolan  is  responsible  for  the  whole   thing  with  lots  of  help  from  Claire  who  works  with  the  users.     Piotr  helped  to  define  the  architecture  together  with  Lukas,  Casper  and  Pawel   who  are  developers.     Claire  tests  and  Eloise  is  looking  amer  the  backlog.  Nolan  organises  the   retrospec8ves  and  Casper  is  running  the  daily  sprints  in  Krakow.  
  62. 62. Remote  Team  Perspec8ves   •  Team  2  –  Krakow’s  View   Mike  is  paying  for  the  work.    We  know  that  Nolan  is  responsible  for  the  whole   thing  and  gives  us  our  sprint  backlog.     Casper  is  our  team  leader  with  Lukas,  Piotr  and  Pawel  who  are  developers.    We   also  ask  Casper  for  help  with  the  technology.     Anna  tests  and  Eloise  is  our  BA.  Nolan  organises  the  retrospec8ves  and  Casper   is  running  the  daily  sprints  in  Krakow.