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

Bringing the Pivotal Process to an Early Startup

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.

Lee Edwards

April 09, 2013
Tweet

More Decks by Lee Edwards

Other Decks in Technology

Transcript

  1. Bringing the Pivotal Process

    to an Early Startup"
    Lee Edwards neé Newlee

    SideTour neé Pivotal Labs"

    View full-size slide

  2. TOOLBOX  VS.  TOOL  

    View full-size slide

  3. •  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  

    View full-size slide

  4. OWNERSHIP  

    View full-size slide

  5. •  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)  

    View full-size slide

  6. KANBAN  BOARD  
    VALIDATE IMPLEMENT MONITOR

    View full-size slide

  7. •  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  

    View full-size slide

  8. COMPANY  OFFSITE  

    View full-size slide

  9. •  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.  

    View full-size slide

  10. TEST-­‐DRIVEN  DEVELOPMENT  

    View full-size slide

  11. •  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  

    View full-size slide

  12. CONTINUOUS  INTEGRATION  

    View full-size slide

  13. •  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  

    View full-size slide

  14. •  We  use  Tracker  preKy  much  the  same  way  Pivotal  
    does  
    •  Stories  enter  Tracker  through  the  Kanban  board  
    •  Bugs  get  reported  various  ways  –  emails,  
    conversaAons  
     

    View full-size slide

  15. ESTIMATION  

    View full-size slide

  16. •  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  
     

    View full-size slide

  17. FULL-­‐STACK  DEVELOPMENT  

    View full-size slide

  18. •  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    :-­‐(  

    View full-size slide

  19. DAILY/WEEKLY  STANDUP  

    View full-size slide

  20. •  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  

    View full-size slide

  21. PRODUCT  OWNERSHIP  

    View full-size slide

  22. •  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  

    View full-size slide

  23. SUSTAINABLE  PACE  

    View full-size slide

  24. •  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)  

    View full-size slide

  25. PAIR  PROGRAMMING  

    View full-size slide

  26. •  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  

    View full-size slide

  27. ITERATION  PLANNING  MEETINGS  

    View full-size slide

  28. •  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  

    View full-size slide

  29. BREAKFAST  

    View full-size slide

  30. •  No  breakfast  

    View full-size slide

  31. INCEPTION  

    View full-size slide

  32. •  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  

    View full-size slide

  33. •  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  

    View full-size slide