Bringing the Pivotal Process to an Early Startup

Former Pivot Lee Edwards talks about bringing the Pivotal process to an early startup and how some of those ideas have changed over the last year and a couple months. Many ideas from Pivotal have worked well, many have required tweaking, a couple got thrown out the window, a few ideas are new, and a few we still haven't made up our minds about. Lee would love to hear your thoughts on how the team has evolved, and would love to give some perspective about how at least one early startup has learned from and reacted to a very Pivotal-style of working.

Transcript

1. Bringing the Pivotal Process
 to an Early Startup" Lee Edwards neé Newlee
 SideTour neé Pivotal Labs"
3. TOOLBOX  VS.  TOOL  
4. •  One  big  difference  I’ve  seen  is  that  not  all  of  the   tools  are  applicable,  and  not  always  in  the  same  way   •  I  tried  bringing  all  of  the  Pivotal  tools  to  SideTour  at   once,  and  it  worked  okay   •  But  when  I  pulled  back  and  started  only  using  the   tools  that  solved  pain  points  we  were  actually   happening,  everyone  was  happier  and  more   producAve  
5. OWNERSHIP  
6. •  Another  difference  comes  from  how  ownership   changes  at  your  own  startup   •  Everyone  owns  part  of  the  startup  and  has  ideas   about  how  to  impact  the  product  (and  other  aspects   of  the  business)   •  Pivotal  is  opAmized  for  producAvity  and  execuAon   •  Our  process  is  opAmized  for  exploraAon  (in  this   phase  of  the  company)  
7. KANBAN  BOARD   VALIDATE IMPLEMENT MONITOR
8. •  We  use  a  Kanban  board  to  keep  track  of  tests  and   iniAaAves  through  the  company   •  Our  Kanban  board  is  a  business  process,  not  a   product  process  (markeAng,  partnerships,  etc.)   •  We  are  less  concerned  about  process  boKlenecks   (the  tradiAonal  goal  of  Kanban)  and  more  concerned   with  always  tesAng   •  We  do  a  weekly  company-­‐wide  standup  that   revolves  around  the  Kanban  board   •  Everyone  is  encouraged  to  contribute  to  and  own   cards  on  the  Kanban  board  
9. COMPANY  OFFSITE  
10. •  Most  company  offsites  suck  and  are  a  waste  of  Ame   •  We  had  an  awesome  offsite  in  January  that  set  the   primary  goal  for  the  year.   •  That  metric  drives  our  Kanban  process  –  we  are   always  working  on  stories  that  affect  that  metric.   •  We  also  spent  a  lot  of  Ame  geAtng  to  know  each   other  and  sharing  personal  stories.   •  The  impact  the  bonding  has  had  on  our  team   dynamics  was  tremendous.  
11. TEST-­‐DRIVEN  DEVELOPMENT  
12. •  We  preKy  much  test  all  the  Ame   •  We  very  occasionally  compromise  on  wriAng  tests   when  the  effort  to  write  the  test  greatly  outweighs   its  added  value.   •  Our  code  has  about  3:1  test:code  coverage  
13. CONTINUOUS  INTEGRATION  
14. •  We  use  CI  to  run  our  tests  against  the  master  branch   •  It  automaAcally  deploys  to  staging  and  delivers   Tracker  stories   •  We  deploy  2-­‐3  Ames  a  week,  and  would  like  to  do   more  
15. BACKLOG  
16. •  We  use  Tracker  preKy  much  the  same  way  Pivotal   does   •  Stories  enter  Tracker  through  the  Kanban  board   •  Bugs  get  reported  various  ways  –  emails,   conversaAons    
17. ESTIMATION  
18. •  We  esAmate  the  same  way  Pivotal  does   •  1/2/4/8  if  anybody  cares   •  Stories  get  added  all  the  Ame,  all  day,  any  day,  so  we   hold  2-­‐5  minute  esAmaAon  parAes  whenever  the   next  story  in  the  backlog  needs  an  esAmate   •  We  don’t  pay  too  much  aKenAon  to  velocity.  We   tend  to  just  work  unAl  things  are  finished   •  EsAmaAon  helps  us  plan  iteraAons  though    
19. FULL-­‐STACK  DEVELOPMENT  
20. •  All  our  developers  are  full  stack   •  We  will  probably  keep  it  this  way  for  awhile   •  We  keep  preKy  true  to  collecAve  ownership   •  Though  the  code  base  is  big  enough  now  that  there   are  some  things  I  don’t  know  very  much  about  any   more    :-­‐(  
21. DAILY/WEEKLY  STANDUP  
22. •  We  do  daily  standups,  but  it’s  usually  only   developers  (10  am)   •  Because  we  tend  to  finish  work  before  we  leave  at   night  (regardless  of  what  Ame  it  is),  we  tend  to  start   the  day  with  new  stories   •  The  “unblock  me”  aspect  of  standup  is  therefor   minimized   •  I  can  act  as  product  owner  occasionally  
23. PRODUCT  OWNERSHIP  
24. •  Product  ownership  is  shared  across  several  people   •  Primarily  Mark  –  a  cofounder  who  does  PM   •  Also  someAmes  me  –  wriAng  stories  and  doing   acceptance  occasionally   •  JusAn  –  our  designer  o^en  owns  stories  he  designed   •  Carl  –  our  data/analyAcs  guy  usually  owns  stories   related  to  analyAcs  and  tracking  
25. SUSTAINABLE  PACE  
26. •  We  all  get  in  at  10  am  for  standup,  and  tend  to  stay   unAl  around  7-­‐9   •  Late  nights  are  preKy  rare   •  Our  key  to  sustainable  pace  is  recognizing  when  we   have  more  producAve  work  le^  in  us  at  the  end  of   the  day  and  staying  later  without  contribuAng  to   burnout   •  (Except  when  we  launched  the  Rails  app  in  6  weeks   working  mostly  12  hour  days  –  that  was  preKy   unsustainable)  
27. PAIR  PROGRAMMING  
28. •  We  pair  program  maybe  50-­‐100%  of  the  Ame,   depending  on  the  week   •  Some  weeks  look  closer  to  100%,  some  closer  to  0%   •  We  don’t  pair  on  copy  changes.  We  don’t  pair  on   most  chores.  We  don’t  pair  on  simple  bugs  or  simple   features.   •  We  like  to  pair  on  new,  complex,  or  high  risk  features   •  We’ve  found  out  the  hard  way  that  splieng  up  pairs   to  meet  deadlines  does  not  result  in  double   producAvity  (duh!)   •  SomeAmes  when  we  don’t  pair,  we  do  code  reviews  
29. ITERATION  PLANNING  MEETINGS  
30. •  We  don’t  really  do  IPMs  right  now   •  Weekly  Kanban  standup  replaces  IPM   •  Backlog  also  gets  filled  throughout  the  week   •  We  do  weekly  sprints,  and  try  to  commit  to  a   reasonable  amount  of  work  that  also  has  a  big   impact   •  The  esAmaAon  and  detail-­‐filling  that  o^en  happens   at  Pivotal  IPMs  happens  a  lot  more  ad-­‐hoc  for  us  
31. BREAKFAST  
32. •  No  breakfast  
33. INCEPTION  
34. •  Our  first  incepAon  helped  us  build  out  the  iniAal   feature  set  for  the  MVP   •  Since  then,  our  re-­‐incepAons  have  had  mixed  results   •  We’ve  goKen  most  of  our  good  ideas  ad-­‐hoc  from   various  members  of  the  team   •  IncepAons  that  resemble  group  brain-­‐storming   sessions  have  been  less  fruiiul  for  us   •  Would  be  open  to  learn  how  to  run  beKer  re-­‐ incepAons  
35. RETROS  
36. •  A  lot  of  team  members  felt  like  they  didn’t  get  much   out  of  Retros   •  We  do  a  lot  of  our  personal  airing  of  grievances  one-­‐ on-­‐one  or  in  a  group,  because  we  have  a  close   working  relaAonship   •  SomeAmes  short  15  minute  retros  come  out  of   standups  to  fix  process  problems   •  I’ll  sAll  hold  a  retro  any  Ame  someone  asks  for  one