It’s  not  Agile  without   Retrospectives   KEYS  TO  PRODUCTIVE  RETROSPECTIVES  AND     CONTINUOUS  TEAM  IMPROVEMENT   

It’s  not  Agile  without  Retrospectives   Too  often,  retrospectives  are  the  least  valuable  activities  in  Scrum.   However,  if  you  do  them  properly,  retrospectives  could  be  the  only   activity  you  really  need.     Come  find  out  why  in  this  interactive  session  about  how  we  can   truly  learn  from  our  experiences  and  take  real  action.  We  will   explore  several  variations  of  retrospective  techniques  for   inspecting  a  team’s  process,  product,  teamwork,  and  technical   practices.     Participants  will  leave  with  a  set  of  tools  they  can  put  to  use  in   their  very  next  retrospective.   

Speaker:  Todd  Girvin   [email protected]   Cofounder,  Improving  Enterprises   SVP,  Microsoft  Technology  Practice   former  Microsoft  MVP  for  C#   creator  of  the  AgileDotNet  conference   @tmgirvin   http://www.linkedin.com/in/tmgirvin     http://tmgirvin.com     

Speaker:  Todd  Girvin   •  10  years  of  agile  development  experience   •  Cofounder,  Jef  Newsom,  was  my  Scrum  Mentor  &  first  Scrum  Master   •  Started  Improving  to  bring  agile  methods  to  IT   •  Consultant  and  mentor  to  agile  teams     •  Worked  with  teams  of  all  sizes  and  growth  phases   

Agile  =  ?   Build   Measure   Learn   ?   Burn  down,   Velocity,     Quality,     Course  Correction   Backlog  >>  Product   

Agile  Principle  #  12   At  regular  intervals,     the  team  reflects  on  how  to   become  more  effective,     then  tunes  and  adjusts  its   behavior  accordingly.   

Scrum  Guide:   The  Sprint  Retrospective  is  an   opportunity  for  the  Scrum  Team   to  inspect  itself  and  create  a  plan   for  improvements  to  be  enacted   during  the  next  Sprint.     

Purpose  of  Retrospectives   1.  Inspect  the  last  Sprint   2.  Identify  improvements   3.  Create  a  plan   

Purpose  of  Retrospectives   1.  Inspect  how  the  last  Sprint  went  with  regards  to   people,  relationships,  process,  and  tools.     Ask  Questions:       Less  Valuable                          More  Valuable   Yes/No          Who      Where          When   What    How  Why   

Purpose  of  Retrospectives   1.  Inspect  how  the  last  Sprint  went  with  regards  to   people,  relationships,  process,  and  tools.   Example  Questions:   •  Did  we  meet  the  Sprint  goal?   •  Was  the  PO  engaged  in  the  Sprint  and  Demo?   •  How  do  you  feel  about  the  Sprint?   •  What  did  we  learn  in  this  Sprint?   

Purpose  of  Retrospectives   2.  Identify  and  order  the  major  items  that  went  well   and  potential  improvements.   Keep  doing  this:   1.  ~~~~~~~~~~~~~~~~   2.  ~~~~~~~~~~~~~~~~   3.  ~~~~~~~~~~~~~~~~   4.  ~~~~~~~~~~~~~~~~   5.  ~~~~~~~~~~~~~~~~   Start  doing  this:   1.  ~~~~~~~~~~~~~~~~   2.  ~~~~~~~~~~~~~~~~   3.  ~~~~~~~~~~~~~~~~   4.  ~~~~~~~~~~~~~~~~   5.  ~~~~~~~~~~~~~~~~   

Example:  What  did  you  like  about  Sprint  2?   •  Mnp:  Having  the  online  tool  (onTime)  tool  to  have  a  limited  list  of  work  items  to  select  from   •  LS:  likes  ability  to  see  documented  tasks  visible  and  assigned  so  we  know  what  everyone  is  working  on.    Can  share  product   knowledge,  but  also  communicate  with  others  on  priority   •  Sbab.  Liked  the  transparency  and  how  much  effort  remaining  on  each  story/issue.   •  Sb:  online  tool  helped  offsite  developers  plug  in.  Also  they  have  advanced  in  their  product  knowledge  to  create  their  own  test   files.    Like  the  burndown  chart.   •  Jacob:  online  tool  really  helped.   •  Cathy  (production  implementation/development);  was  very  helpful  now  seeing  what  is  going  on  in  development.  How  my  items   as  field  rep  is  prioritized.   •  Davito:  likes  daily  scrums  driven  by  Jacob.  Likes  “minute  16”  concept  which  takes  items  offline.  Likes  online.   •  Marcelo:  likes  scrums  and  ontime  software.   •  Chris:  like  tool   •  Ned:  liked  ontime  better  than  past  products.     

Example:  What  would  you  like  to  change   about  how  we  conducted  Sprint  2?   •  Team  Commitment   •  Jacob:  done  is  done  seems  like  too  much  of  a  stretch.  Plan  to  review  later.  (1)     •  Chris:  feel  like  we  did  not  make  the  committed  release  as  part  of  our  initial  commitment  to  the  stakeholders.  (2)   •  Ned:  lack  of  time  to  fully  code  and  test  stories  at  end  of  same  sprint,  particularly  with  ACA  product.    Release  specific  stories  in  particular.       •  Mnp:  Task  list  grew  during  sprint  adding  sub-­‐items  on  the  fly  during  the  sprint  based  on  private  demos  to  PO  group.   •  Jacob:  trying  to  administrate  OnTime  tool.    Users  adding  stories/issues  during  the  week  for  assumed  behavior  that  is  not  a  part  of  a  story,  e.g.  2013  license  authorizing  2014  version!    How  should  we  address   in  scrum  meetings.    Bring  up  and  throw  on  the  backlog.    Have  team  discussion  to  review.  (1)   •  Jacob:  would  like  to  know  better  what  stories  are  demonstrable  and  will  need  to  be  reviewed  at  sprint  review.  Locking  down  builds  so  we  know  what  product  we  are  even  GOING  to  demo  from.  Too  many   moving  targets  for  what  is  expected.  (3)   •  Sbabin:  Acting  on  PO  behalf  caused  him  to  take  some  of  the  heat  for  working  on  things  not  necessarily  agreed  in  sprint  planning.   •  Self-­‐Organizing     •  Ned:  got  assigned  or  assumptions  were  made  that  I  would  pull  tickets  for  work  that  would  be  done  by  me.    (1)   •  Tooling  and  Automation   •  Mnp:  would  like  combined  backlog  (one  list)  with  both  Stories  and  Issues  on  combined  list.  (2)   •  LS:  would  like  to  not  have  tiny  tasks  have  to  be  written  if  they  are  minor  changes.  (1)   •  Davito:  need  build  number  for  each  of  the  two  components  in  the  combined  product.   •  Marcelo:  would  like  a  way  to  log  into  OnTime  that  he  has  coded  the  unit  testing  and  they  have  passed.    A  single  story  with  multiple    acceptance  criteria  might  require  multiple     •  Multiple  Roles  and  Responsibilities   •  Wearing  too  many  hats  (9)   

Purpose  of  Retrospectives   3.  Create  a  plan  for  implementing  improvements  to   the  way  the  Scrum  Team  does  its  work.     Previous  Sprint  Deltas:   1.  ~~~~~~~~~~~~~~~~   2.  ~~~~~~~~~~~~~~~~   3.  ~~~~~~~~~~~~~~~~   4.  ~~~~~~~~~~~~~~~~   5.  ~~~~~~~~~~~~~~~~   Recent  Sprint  Deltas:   1.  ~~~~~~~~~~~~~~~~   2.  ~~~~~~~~~~~~~~~~   3.  ~~~~~~~~~~~~~~~~   4.  ~~~~~~~~~~~~~~~~   5.  ~~~~~~~~~~~~~~~~   Committed  Next  Sprint:   1.  ~~~~~~~~~~~~~~~~   2.  ~~~~~~~~~~~~~~~~   3.  ~~~~~~~~~~~~~~~~   4.  ~~~~~~~~~~~~~~~~   5.  ~~~~~~~~~~~~~~~~   

Example:  Top  Items  to  Change     1.  Wearing  too  many  hats  (9)  Responsibilities  to  multiple  roles.   •  Define  how  much  time  is  available  for  the  role.   •  Share  with  management  the  conflicting  responsibilities  and  cost  to  the  team.   •  Hire  outside  help,  more  resources.   2.  Different  developers  have  specialty  areas,  TSL  only  or  Revit  only  expertise  and  no  crossover.    So  we  add  tasks  for  multiple   products  in  the  sprint.  Multiple  products  in  single  sprint.  (5)   •  Pairing  up  to  share  tasks.   •  Create  build  process  that  anyone  can  trigger  so  anyone  can  dev/test.   3.  Need  others  to  step  up  for  certain  jobs.  Domain  knowledge  challenge.  (4)  Learning  new  domains  (not  roles).   •  Expect  team  members  to  test  others’  code.   •  Expect  team  members  to  write  documentation  or  others’  features.   •  “Lunch  and  Learns”  to  share  knowledge  across  the  team.   4.  Would  like  to  know  better  what  stories  are  demonstrable  and  will  need  to  be  reviewed  at  sprint  review.  Locking  down  builds   so  we  know  what  product  we  are  even  GOING  to  demo  from.  Too  many  moving  targets  for  what  is  expected.  (3)   •  Work  on  highest  priorities  first  –  as  a  team.   •  Plan  the  demo  early.  Get  priorities  from  PO(s).   •  Setup  shared  VMs?   5.  Feel  like  we  did  not  make  the  committed  release  as  part  of  our  initial  commitment  to  the  stakeholders.  (2)   •  Make  better  estimates.   •  Need  finalized  sprint  plan  exiting  the  planning  meeting.   •  Better  communication  across  the  team  adding  significant  tasks.   

Tips  for  Effective  Retrospectives   •  Journaling  concerns  during  the  Sprint   •  Especially  SM   •  Team  member  can,  or  send  notes  to  SM   •  Look  for  signs  of  dysfunction  in  burn-­‐down,  story  board   •  Ask:  “What  can  we  do  to  be  more  productive?”   •  Come  prepared  for  the  Retro:      process  artifacts,  pictures/screen  shots,  questions,  observations   

Q?   Copyright  2013  Improving  Enterprises   www.ImprovingEnterprises.com