Help, the hippies have taken my team to play games... or let’s get real we have a business to run - Richard Bailey

  • 1,030 views
Uploaded on

This talk was given at the recent South African Scrum Gathering

This talk was given at the recent South African Scrum Gathering

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,030
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 1  
  • 2. Scrum  Sponsor  Rela0vely  successful  at  Scrum  and  Agile  -­‐  Visa  are  excited  about  agile  -­‐  Responsible  for  a  product  that  Visa  acquired  -­‐  Built  it  by  being  painfully  rigorous  about  scrum  –  playing  by  the  rules    Defender  of  the  Realm  -­‐  Hired  a  CST  in  training    Agile  adventurer  -­‐  Never  done  it  -­‐  Never  proved  it  -­‐  Didn’t  believe  in  it  -­‐  But  now  my  dad’s  even  a  believer  J  And  yes  oHen  to  my  team  –  I  am  “The  Business”  and  I  am  conflicted  -­‐  I  am  a  senior  exec  at  Fundamo  (strategic  role  player)  -­‐  I  ac0vely  par0cipated  in  the  bid  and  acquisi0on  by  Visa  -­‐  I  ac0vely  sell  our  product  -­‐  I  work  with  partners  (in  the  channel  and  technology)  -­‐  I  chair  product  investment  commiQee  (yes  –  the  one  the  product  managers  come     2  
  • 3. Product  SteerCo  Clue  #1Go  tell  those  people  to  stop  playing  games  Every  0me  I  come  to  a  demo  you  show  me  new  tooling,  new  infrastructure  Don’t  those  people  know  we  have  a  business  to  run  –  some0mes  I  think  they  just  come  to  work  to  play  games     3  
  • 4. Embraced  agile  Allowed  me  the  space  to  introduce  scrum  Watched  us  develop  a  commercial  product  in  less  than  a  year  Allowed  me  to  defend  the  team  But  –  he’s  driving  revenues,  and  he  is  the  consummate  entrepreneur  –  innova0on  above  process  And…he  has  a  business  to  run     4  
  • 5. •  What’s  this  about  gatherings?    [conference  or  a  mee0ng]  •  Lightning  spot  •  Stand  up  •  Open  space?  [  •  Retrospec0ves  [  •  Value  the  items  on  the  right  vs  the  leH  •  What  mind  altering  trip  are  these  people  on?  •  Calm  steadiness  to  our  teams  •  NO  sense  of  urgency??  I  am  encouraging  us  all  to  think  like  business  leaders  –  like  managers   5  
  • 6. -­‐  S0cky  notes  (of  different  colours)  -­‐  FedEx  day  -­‐  (all  these  I  sponsor)  -­‐  Poker  cards  -­‐  Chickens,  Pigs  -­‐  New  tooling  -­‐  New  frameworks  -­‐  This  trust  thing  –  hey  man,  we  trust  the  team  -­‐  How  can  you  trust  these  people?     6  
  • 7. To  all  you  scrumdamentalists  out  there  (with  your  games,  your  gatherings,  your  retrospec0ves,  your  s0cky  notes  and  your  fancy  marker  pens    We  are  in  the  business  of  soHware  because  we  are  capitalists  –  not  because  we  want  you  to  feel  comfortable  at  your  R20,000  chair,  your  chill  room,  the  blackjack  table  in  the  corner  of  the  dev  room,  your  two  21”  screens,  sifng  on  your  beanbag,  scribbling  on  a  random  post  it  note!      Do  you  understand  we  need  to  sell  this  stuff  to  people  who  want  to  use  it,  like  to  use  it  and  want  to  buy  more  of  it?  You  know  what  –  I  think  the  teams  do  –  most  developers  know  why.      And  the  business  grudgingly  accepts  we  know  how  to  develop  soHware.    This  is  a  tough  one:  -­‐  They  want  scope,  features  -­‐  Commit  to  less  work  that  expected  Now  of  course  these  are  all  valid  reasons  why  we  adopted  agile  and  scrum  (BUT  SOMETIMES  WE  SUCK  AT  COMMUNICATING  THAT)  -­‐  We  know  that  there  are  many  unknowns  -­‐  We  know  that  if  we  priori0se  we  will  do  the  most  valuable  stuff  first  -­‐  We  know  that  the  team  will  work  as  hard  as  they  can   7  
  • 8. See  we  come  to  our  gatherings  We  priori0se  our  workload  We  con0nually  improve  We  need  to  remember  why  we  do  this  –  the  challenge  is  to  remind  the  business  (ME)  We  are  changing  the  world  –  from  Africa  –  for  real  people  The  why  we  do  things  –  is  known  to  us  in  the  detail  of  the  business  And  you  know  what  bugs  me  -­‐  We  always  have  an  answer  -­‐  The  team  will  know  -­‐  We’ll  drop  some  scope  -­‐  The  Product  Owner  understands  -­‐  We’ll  just  ask  the  Steering  CommiQee  for  more  0me  -­‐  We  do  a  spike  (spike  –  what’s  that?  –  oh  yes  –  we’ll  experiment,  play  games)     8  
  • 9. Is  this  a  lifestyle  thing  rather  than  a  business  thing?              How  can  I  respond?  Is  our  business  more  profitable  because  of  scrum?    What  do  those  games  mean  Is  this  some  way  we  aQract  the  underworld  (hidden  community  of  geeks)  Are  they  games?          Business  value?    Scrum  rituals  Gatherings  Retrospec0ves  Ceremonies  (what  happened  to  mee0ngs)    A  fantasy  world  for  geeks?  Are  the  metrics  right?  How  do  I  jus0fy  using  scrum?    Did  I  really  have  to  say  that?       9  
  • 10. -­‐  Do  we  have?  -­‐  Unhappy  clients,  bugs,  more  demand  than  supply  –  normal  business  pressure  -­‐  Also  a  company  divided  in  some  senses  –  and  I  think  you  will  find  this  common  -­‐  A  voracious  appe0te  for  more  features  (hey  –  that’s  why  we  do  this  Scrum  thing,   right?)  We  also  have  -­‐  Teams  organised  -­‐  Scrum  masters,  PO  per  team  -­‐  Regular  cadence  -­‐  Some-­‐what  groomed  backlog  -­‐  Regular  releases  -­‐  Happy  clients    So  YES     10  
  • 11. License  sales  growing  Content  of  product  –  is  relevant  Ongoing  support  is  gefng  beQer  For  all  of  you  the  same  is  probably  true       11  
  • 12. -­‐  TDD  -­‐  Design  experience  -­‐  Extreme  Automa0on  -­‐  Story  grooming  -­‐  Granularity  of  stories  -­‐  Assign  a  PO  to  each  team  -­‐  Kanban  for  support   12  
  • 13. Like  hippies  –  pursuing  love  –  not  meaning  for  the  customer    We  can  become  too  inwardly  focussed  –  on  the  good  things  -­‐  Improving  our  quality  -­‐  Predictability  -­‐  Stories  -­‐  Epics  -­‐  Features  -­‐  And  for  Fundamo  Visa  teams  –  we  are  far  from  the  end  user:  -­‐  Dev  -­‐>  BD  -­‐>  SI  -­‐>  Customer  -­‐>  Consumer  -­‐  That’s  tough  to  be  sure  we  are  doing  the  right  things     13  
  • 14. I  cannot  emphasise  the  importance  of  on-­‐going  communica0on  –talking  the  language  of  the  business  When  I  am  most  successful  I  reflect  the  business  picture  of  our  roadmap  (not  a  burndown  –  a  roadmap)  Yes  –  it’s  up  there  in  the  agile  manifesto  We  favour  conversa0on  over  documenta0on  But  –  there  are  many  stakeholders  out  there    -­‐  be  sure  your  PO  or  PM  is  having  those  conversa0ons    -­‐  be  sure  the  conversa0ons  are  consistent    -­‐  be  sure  the  context  is  always  there    -­‐  return  to  the  beginning,  refine  the  picture,  show  how  it  changed    -­‐  in  the  heat  of  the  sprint  or  release,  we  some  0mes  forgot  how  we  re-­‐priori0sed    -­‐  If  we  did  our  stakeholders  certainly  did  (moving  priori0es  of  stories)     14  
  • 15. 15  
  • 16. The  prac0ces  of  scrum  help  us  -­‐  that’s  where  the  games  come  in  -­‐  That’s  where  the  discipline  comes  -­‐  It’s  management  Don’t  think  it  will  solve  your  basic  stakeholder  management  issues  –  it  will  only  expose  them  -­‐  Status  repor0ng  -­‐  Change  management  -­‐  Infrastructure  management  -­‐  Some0mes  documenta0on  is  necessary  -­‐  We  neglected  our  roadmap  –what  stuck  was  the  12  month  old  roadmap  (what   about  x  y  z)     16  
  • 17. Projects  became  the  enemy  They  needed  project  managers,  and  they  do  waterfall  They  needed  scope,  and  signing  in  blood  And  so  we  have  this  backlog  thing  -­‐  A  hiding  place  for  many  evils  (a  joke)  I  suggest  the  structure  of  a  project  is  not  evil  -­‐  It  gives  execu0ves  big  chunks  to  decide  on  -­‐  A  simple  project  charter  confirms  value  and  cost  -­‐  It  defines  priori0es  -­‐  It  defines  scope  boundaries  -­‐  It  defines  terminology  -­‐  It  reduces  complexity  -­‐  It  integrates  with  the  rest  of  the  business  (charge  codes,  status  reports,   investment  themes,  stakeholders)  -­‐  It  is  not  waterfall  Instead  of  a  great  big  backlog  –  an  ordered  grouping  of  projects     17  
  • 18. 18  
  • 19. It’s  so  temp0ng  We  have  two  areas  of  the  business    -­‐  1  scrum,  one  not    -­‐  very  different  pressures    I  honestly  observe    -­‐  the  team  could  work  harder    -­‐  the  team  does  work  hard    -­‐  we  do  not  burn  people  out  (this  is  the  development  mindset  I  started  in)    Yes  the  team  can  work  beQer  –  that’s  why  we  adopt  agile    -­‐  when  they  have,  the  bugs  go  up  and  I  measure  that  in  ZAR  Make  sure  you  have  a  response  –  mine  is  NO  –  they  are  working  harder.  Judge  that  on:  -­‐  Commitment  -­‐  Quality  -­‐  Stability  (aQri0on)   19  
  • 20. Responsible  –  actually  doing  the  work  Accountable  –  approve  or  disapprove  it  –  this  is  not  the  team    -­‐  and  some0mes  it  is  not  the  PO,  who  is  already  under  a  ton  of  pressure    -­‐  be  sure  you  define  in  your  business  who  is  accountable  (a  single  wringable  neck  –  the  manager)    -­‐  for  my  business  that  is  the  product  manager    -­‐  make  sure  the  V-­‐Model  is  defined  for  your  organisa0on  (we  lost  our  way  a  liQle)  Let  the  team  take  resonsibility  –  trust  them,  remind  them  [I  trust  you  to  commit,  improve,  add  value  è  you  trust  me  to  protect  you  and  give  you  a  great  place  to  work]   20  
  • 21. Agile  coach  Scrum  coach  As  a  business  leader  –  reality  check    -­‐  why  are  you  saying  that  Double  check    -­‐  are  we  too  theore0cal    -­‐  can  I  inspect  and  adapt    I  have  had  a  couple    -­‐  some  on  the  team    -­‐  some  external    -­‐  keep  checking  yourself  as  an  execu0ve   21  
  • 22. 22  
  • 23. Think  about  growing  in  teams  (one  team  at  a  0me)  Grow  the  whole  team  (PO  -­‐>  Dev  -­‐>  Tester)  Think  abut  the  overheads  -­‐  Architecture  -­‐  Code  complexity  Don’t  think  it  will  solve  your  basic  stakeholder  management  issues  –  it  will  only  expose  them  -­‐  Tes0ng  -­‐  Code  quality  -­‐  Secure  coding  prac0ce  -­‐  Status  repor0ng  -­‐  Engineering  prac0ce  (XP)  -­‐  Infrastructure  management     23  
  • 24. Yes  –  because  we  have  order    -­‐  higher  engagement    -­‐  flexibility  (my  boss  even  thinks  so)    -­‐  reality  (we  build  what  we  can)    -­‐  predictability    -­‐  honesty    -­‐  reliability  –  release  plan  PLAYING  GAMES?    NO!   24  
  • 25. We  have  to  be  clear  abut  common  measures  with  the  business  This  needs  a  lot  of  work  That  the  business  understands  -­‐  Not  just  our  internal  scrum  measures  (RTF)  Measure  the  roadmap    -­‐  how  did  you  s0ck  to  it  (so  I  suggest  using  RTF,  but  call  it  roadmap  execu0on)  Measure  how  well  the  priori0sa0on  works    -­‐  a  simple  c-­‐sat  with  your  customers  (Sales,  Execu0on)    -­‐  How  oHen  did  you  get  what  you  needed  just  in  0me  Quality    -­‐  use  bug  trends  Cost    -­‐  show  the  cost  of  support    -­‐  show  the  cost  of  a  team  Revenue    -­‐  the  toughest  of  all    -­‐  I  use  this  for  the  team     25  
  • 26. A  toothless  wimp?  I  think  he  needs  to  give  more  direc0on  We  need  to  balance  this  servant  leader  with  real  deliverables  If  your  scrum  master  does  not  have  clear  responsibili0es  -­‐  Give  them  deliverables  (metrics,  improvement,  goals)  The  SM  role  is  not  a  hiding  place  The  SM  needs  to  in0mately  know  what  the  team  is  doing,  understand  it,  test  it   26  
  • 27. -­‐  talking,  gathering,  s0cky  notes,  marker  pens  -­‐  All  is  good.    We  do  play  games…  -­‐  Some0mes  I  think  the  success  of  scrum  is  gefng  started  and  then  doing  –  report   on  success,  keep  shou0ng  out,  keep  communica0ng  -­‐  So  use  your  gatherings,  your  retrospec0ves  -­‐  Remember  to  get  real  –  talk  to  business  people  like  business  people  -­‐  All  important  stuff  we  do  -­‐  But  we  need  to  ground  ourselves  in  the  reality  of  running  a  business   -­‐  Revenue   -­‐  Quality   -­‐  Communic0on         27