Developer to Developer Accountability

By: Tim Rayburn

Transcript

1. Developer  to  Developer   Accountability   Tim  Rayburn  –  AgileDotNet  Dallas  2013  
2. Accountability   Should  not  be  scary!  
6. What  can  cause  a  failure  of   Accountability?  
7. 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  
8. 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  
9. 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  
10. 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  
11. Conquering  the  Problems  
12. 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.  
13. 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.  
14. 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.  
16. 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.  
17. 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…  
18. 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.  
19. 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.  
20. 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.  
21. But  wait,  there’s  more  …  
22. *  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…  
23. *  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