Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Developer to Developer Accountability

Developer to Developer Accountability

By: Tim Rayburn

Improving

May 29, 2013
Tweet

More Decks by Improving

Other Decks in Technology

Transcript

  1. The  Hierarchy  of  Pains   *  True  technology   problems

     are  very  rare.     But  are  also  often   relatively  easy  to  solve.   *  The  good  news  is  that   there  are  lots  of  ways  to   approach  this  problem.   Tech   Process   Team   Character  
  2. The  Hierarchy  of  Pains   *  Process  problems  exist  

    when  a  process  does  not   serve  its  one  true   purpose,  to  guide  the   team  towards  value.   *  Process  can  and  should   be  flexible,  because  value   can  be  derived  in  so  many   different  ways.   Tech   Process   Team   Character  
  3. The  Hierarchy  of  Pains   *  A  team  of  great

     individual   contributors  does  not   guarantee  a  great  team.   *  Tools  such  as  the  DISC   profiles  can  help  you  put   together  strong  teams   Tech   Process   Team   Character  
  4. The  Hierarchy  of  Pains   *  These  are  the  tough

     ones.     You  need  to  provide  room   for  personal  growth,  but   one  bad  apple  can  and   will  spoil  the  bunch.   *  “The  good  of  the  many   out  weighs  the  good  of   the  few  …  or  the  one.”   Tech   Process   Team   Character  
  5. I  don’t  know  what  Tim’s  doing…   *  Task  boards

     aren’t  just  for   Project  Managers  or   SCRUM  Masters.   *  If  you  have  chronic   offenders,  have  everyone   touch  the  task  they  are   talking  about  during  your   morning  meeting.  
  6. I  don’t  know  what  Tim’s  doing…   *  If  your

     team  is   distributed,  then  a  tool   like  Team  Foundation   Server  2012’s  built  in  task   board  can  be  very  helpful.  
  7. Tim  gets  upset  when  you  critique…   *  This  is

     first  and  foremost   a  character  issue.    And   needs  to  be  addressed.   *  Using  comments  on  work   items,  and  not  having  to   “sit  through”  a  review   can  be  helpful.  
  8. Tim  checks  in  untested  code…   *  This,  again,  is

     a  character   issue  and  should  be   addressed.   *  Tools  can  help  here,   monitoring  code   coverage,  and  gated   check-­‐ins.  
  9. The  great  thing  about  Object   Oriented  code  is  that

     it  can   make  small,  simple  problems   look  like  large,  complex  ones.   #UnitTesting   Tim  checks  in  untested  code…  
  10. Tim  violates  “the  architecture”…   *  This  is  a  process

     smell,   but  if  it  provides  value   then  we  should  really  look   at  tools  to  automate  this.   *  Tools  like  FXCop  or  the   Architecture  Explorer  can   be  very  useful  in  this   regard.  
  11. Tim  claimed  something  is  done,  and  it   isn’t.  

    Whoo-­‐hoo-­‐hoo,  look  who   knows  so  much.  It  just  so   happens  that  your  friend   here  is  only  MOSTLY  dead.   There's  a  big  difference   between  mostly  dead  and   all  dead.  Mostly  dead  is   slightly  alive.  
  12. Tim  claimed  something  is  done,  and  it   isn’t.  

    *  We  want,  we  need,  tasks   which  are  all  dead,  aka  all   done.    Mostly  done,  is  not   done.   *  Tasks  will  take  as  long  as   they  will  take,  don’t  fudge   this.  
  13. *  Pushed  code  to  production  or  QA  without  approval.  

    *  “Fixed”  a  bug,  but  not  told  QA  it  was  fixed.   *  Didn’t  let  the  product  owner  know  that  a  release  was   complete.   *  And  oh  so  many  more…   Tim  might  have…  
  14. *  Drive  for  accountability  on  your  team,  person  to  

    person.    This  isn’t  a  management  thing,  it’s  a  team   dynamic  thing.   *  Encourage  teams  to  hold  each  other  accountable,   we’re  trying  to  achieve  value.   *  Remember  this  is  not  about  confrontation,  it’s  about   accountability.    Visibility  as  to  where  things  are  so  that   WE  can  achieve  our  goals.   Call  to  Action