20 Matching Annotations
  1. Jan 2018
    1. Douglas  Hofstadterobserved  that,  no  matter  how  much  work  went  into  developing  computer  programs  to  play  chess  against  Grand  Masters,  the  winning  program  always  seemed  to  be  10  years  away

      I didn't know this came from chess games

    2. Slicing  Features  into  separate  functional  parts  helps  us  actively  manage  the  scope  by  creating  different  implementation  options  45that  are  often  implicit  and  non-­negotiable  when  we  have  larger  Features  in  the  backlog

      On a second read through, this appears to be a key thing for this to work - decomposing larger units of work into smaller things, but not diving into the deliver-in-a-day scale of wehat he's referring to as user stories here

    3.  At  the  heart  of  the  rolling  wave  forecast  is  the  acceptance  of  uncertainty.  This,  in  turn,  allows  us  to  keep  our  options  open.  To  be  flexible  and  able  to  respond  to  change  –just  like  the  Agile  Manifesto  says.  

      okay, this is a nice way to present it

    4. what did you say about rolling wave forecast

      Moar new terminilogy for me…

      okay, so it feels a bit like a weird cross between a release plan and a roadmap

    5. By  forecasting  and  showing  progress  (or  the  lack  thereof)  very  early  on,  Carmen  is  bringing  the  scope  discussion  to  the  first  few  days  of  the  project.  

      So basically, acknowledge self-deception both parties played along with to get here as soon as you can, because it will come up either way

    6. Move  to  Story  Points.  Even  if  this  is  just  another  way  of  estimating,  getting  rid  of  ‘hours’  and  ‘days’  has  too  many  benefits  to  ignore  them.  We  already  discussed  previously  in  this  book  the  problems  of  using  time-­based  metrics,  which  are  an  indication  of  cost,  to  measure  project  progress.  Even  if  it’s  just  another  proxy  metric  for  productivity,  Story  Point-­based  estimation  gives  a  better  understanding  of  how  things  like  risk,  complexity,  expected  dependencies  for  each   Story,   etc.   Given   that   a   large   amount   of   time   it   takes   to   deliver   one   Story   is   spent  waiting,  Story  Point  estimation  is  more  likely  to  help  you  assess  the  true  impact  of  one  Story  in  your  project.

      Surely when you have story points it's now really hard to compare across teams and projects though, right? A 3 pointer for one team is not a 3 pointer for another.

    7. Mandating   the   maximum   calendar   duration   for   an   item   is   also   used   for   User   Stories.   In   my  practice  I  advise  teams  to  have  1-­day  User  Stories.  The  reason  is  simple.  If  you  were  wrong  about  the  time  it  takes  to  develop  your  User  Story  you  will  know  it  already  to

      So this is similar to the idea in Reinertsen's book, when he describes the round robin approach if you can't reliably estimate work

    8. Both  these  metrics  will  help  you  forecast  the  progress  for  your  project.  While  the  User  Story  velocity  metric  will  help  you  assess  when  a  certain  Feature  might  be  ready;;  the  Feature  velocity  will  help  you  assess  when  the  project  might  be  ready.

      This seems to assume that Carmen understands all the technology and the problem domain well enough to split a big feature into meaningful stories of more or less uniform size for devs to deliver. This feels like a different skill set to project management

    9. In  my  research  I’ve  normally  used  the  progress  data  from  3  to  5  iterations  (or  weeks  if  you  are  using   Kanban/flow   based   software   development)   in   order   to   define   the   initial   progress   rate.  Many  expect  that  you  need  many  more  data  points  before  you  can  make  a  useful  prediction,  but  that  is  not  the  case.  Three  to  5  iterations  are  typically  enough

      The German tank problem referenced as a justification for this is fascinating

    10. “Absolutely correct! In fact you will not know how long the whole project will take until you have either the whole backlog of INVEST Stories sliced up (a bad idea) or until you have enough historical information that you can infer the cycle time for every backlog item, independently of size,” Herman explained
    11. Early  in  each  project,  your  top  priority  is  not  to  ship  something  meaningful  to  your  customer,  but  to  obtain  information  on  capacity,  throughput,  and  bac

      Okay, this is an interesting, and there's lots around about optimising for learning, but this is the first time I've seen it explicitly phrased like this

    12. Even  if  each  Story  may  not  be  “sellable”,  it  must  be  testable  and  final,  i.e.  the  team  can  make  sure  that  aparticular  User  Story  has  been  successfully  completed  according  to  a  Definition  of  Done.  This  Definition  of  Done  is  a  litmus  test  that  will  allow  you  to  classify  tiny  parts  of  the  whole  project  as  completed,  before  the  whole  project  is  done.
    13. Each  Story  can  be  dropped  from  the  project  without  affecting  the  overall  project  delivery.

      This seems to contradict the earlier point about E meaning 'essential'. If I can drop a story then surely, it wasn't essential, right?

    14. Essential,  meaning  that  every  story  is  absolutely  required  for  the  product  to  be  viable.  To  be  Essential,  a  story  must  not  only  be  valuable,  but  it’s  removal  must  make  the  product  unusable  or  unsellable.  Earlier  INVEST  definitions  included  ‘Estimatable’  in  the  sense  that  there  would  be  some  understanding  and  specific  definition  of  the  story  that  allowed  us  to  cast  an  estimate  if  we  wanted  to.  #NoEstimates  focuses  on  value  instead.  The  goal  is  to  do  only  what  is  essential  to  the  project’s  success.

      I'm struggling with this, as when you're making trade-offs between stories to work on in a given timebox, you'd be deliberately deciding not to have certain things that you've just deemed essential.

    15. Gedanken  or  Gedankenexperiment.  Ángel  Medinilla,  this  book’s  fantastic  illustrator,  

      Ah, THAT'S where they came from

    16. At  Toyota,  the  production  engineers  would  simultaneously  start  to  design  the  production  line  and  prepare  manufacturing  long  before  the  new  car  designs  were  finished  (hence,  concurrent  engineering),  instead  of  waiting  until  all  decisions  about  the  design  were  closed.  This,  in  the  end,  provided  Japanese  manufacturers  with  an  astonishing  competitive  advantage  that  let  them  design  and  produce  the  Toyota  Prius  in  about  3  years27,  from  idea  to  first  sale!

      Only 3 years? Cripes

    17.  Project  Management  Body  of  Knowledge  (PMBO

      AH, this is the PM Book he was mentioning last night

    18. But   for   complex   environments,   where   estimates   come   mostly   from   personal   experience   and  knowledge,   these   estimates   will   be   different   for   every   person.   Experts   might   estimate   some  work  as  easy  and  fast,  while  novices  might  estimate  the  same  work  as  difficult  and  long  lasting.  Some  team  members  may  see  risks  and  estimate  the  impact  on  the  schedule,  while  others  may  ignore  those  risks.Hence,  in  most  environments  estimates  are  personal.  

      And presumably not comparable across teams then, if you're managing a portfolio of projects or products, and trying to work out where to focus your efforts?

    19. So,  if  h(a)  is  much  larger  than  g(e)  the  cost  of  a  feature  cannot  be  determined  by  relative  estimation.In  turn,this  means  that  the  most  common  estimation  approach,  Story  Point  estimation,  cannot  work  reliably.

      If this is the second 'social' complexity analysis, and it's a much larger factor, then I missed this part in the talk. Then again telling people to factor in how dysfunctional their org is might be a hard sell in an evening

    20. Some  researchers  have  alreadyproposedwhat  a  “good”estimate  should  be.  In  19861,  they  proposed  thata  good  estimation  approach  would  provide  estimates  “within  25%  of  the  actual  result,  75%  of  the  time”.

      Okay, this figure is what we need to beat, with Reinertsen's cost of delay question, tracking the cost of the project being 60 days late