Collaboration Driven Development - Agile City BRS

Transcript

1. Hello  I’m  Jenny  
    
   It’s  taken  me  25  years  to  realise  that  what  makes  me  6ck  and  get’s  me  out  of  bed  in  
   the  morning  isn’t  so=ware  development  as  such,  not  even  agile  tes6ng  or  BDD,  it’s  
   about  helping  teams  flourish  and  thrive  and  be  themselves.    So  I’m  all  about  
   collabora6on.  But  collabora6on  is  hard.  When  you  come  out  of  your  Scrum  
   cer6fica6on  training  you  kind  of  come  out  thinking  “OK  –  now  I’ve  got  this  post-­‐it  
   note  I  need  to  go  and  have  conversa6ons  and  collaborate”.      I  work  with  teams  who  
   find  that  difficult,  which  poses  problems  -­‐  because  effec6ve  collabora6on  is  
   absolutely  crucial  to  the  success  of  our  projects.  
    
   As  well  as  collabora6on,  I’m  also  convinced  that  one  of  the  biggest  challenges  that  
   organisa6ons  face  when  implemen6ng  Agile,  is  how  to  do  the  right  amount  of  
   analysis  and  design,  &  knowing  when  to  do  it.    
    
   So  today  we’re  going  to  examine  and  discuss  how  much  is  the  right  amount  of  
   upfront  work,  and  when  to  do  it,    &  how  taking  a  collabora6on-­‐driven  approach  can  
   help  you  get  the  balance  right  in  your  own  team.    I’d  like  to  introduce  you  to  a  couple  
   of  characters  you  might  have  met  before….  
   1  
   

   View Slide

2. So  Here’s  Umberto    
      
   As  in  his  name,    
      
   Umberto  likes  to  do  all  the  work  up  front.      
   He  likes  all  sorts  of  diagrams  and  massive  data  models.      
   Umberto  loves  work  in  the  solu6on  domain  and  he  likes  to  decompose  a  solu6on  in  
   its  en6rety  before  a  single  line  of  code  is  wriUen.    
      
   So  let’s  now  take  a  look  at  Umberto  Upfront’s  nemesis.    Nancy  Nimble  
    
   2  
   

   View Slide

3. Nancy  is  always  smiling  and  happy.  She’s  definitely  leaping  because  she  just  can’t  
   wait  to  get  the  next  task  off  the  backlog.  
      
   Nancy  nimble  is  super-­‐agile  and  her  team  works  with  really  small  units  of  work  and  
   limited  documenta6on.      
   She’s  a  great  team  player    -­‐  She’s  always  on  6me  for  stand  up  mee6ngs,  always  keeps  
   her  update  to  45  seconds  and  makes  great  notes  on  her  Jira  6ckets.        
   She  doesn’t  really  do  analysis  or  design,  she  just  focuses  on  building  so=ware  and  
   defers  technical  decisions  as  long  as  she  can.    
      
   So  as  you  have  probably  gathered,  Umberto  Upfront  and  Nancy  Nimble  both  have  
   issues.  
    
   3  
   

   View Slide

4. Umberto  likes  to  work  with  lots  of  heavyweight  documenta6on  
        
   The  Business  some6mes  get  cross  with  Umberto  Upfront  because  they  find  some  of  
   his  documenta6on  difficult  to  digest  and  they  don’t  always  understand  the  
   terminology  he  is  using.    So  they  miss  stuff  when  they  review  it  &  by  the  6me  they  
   see  it  working  there’s  load  of  costly  rework  to  do.    
   Another  issue  Umberto  has  is  that  all  of  his  technical  vision  needs  to  be  delivered  for  
   the  Business  to  get  any  of  the  value.    And  he  doesn’t  really  know  where  the  value  lies  
   in  his  solu6on  because  he  hasn’t  spent  any  6me  understanding  the  real  business  
   domain  and  the  issues  they  face.      
   And  even  though  his  solu6ons  are  carefully  architected,  a  small  business  change  
   some6mes  leads  to  a  massive  technical  change  with  a  huge  lead-­‐6me  for  delivery.      
    
   4  
   

   View Slide

5. Poor  Umberto  is  having  a  hard  6me  
    
   5  
   

   View Slide

6. Nancy  nimble  works  with  much  smaller  units  of  work  than  Umberto,  more  like  gravel  
   than  a  great  big  boulder.  She’s  confident  working  with  minimal  documenta6on  and  
   she  can  let  the  design  kind  of  take  care  of  itself.    
    
   There  are  hundreds  of  user  stories  on  the  backlog,  but  she  can’t  see  the  big  picture  
   and  she  doesn’t  understand  the  technical  vision.        
   Nancy’s  team  deliver  at  high  velocity  but  they  have  no  idea  if  their  solu6ons  are  
   actually  delivering  any  value  to  the  business    
   Some6mes  Nancy  feels  like  she’s  building  a  great  big  ball  of  mud  and  she’s  spending  
   more  and  more  6me  trying  to  refactor  her  way  out  of  it.    She’s  beginning  to  feel  
   overwhelmed.  
    
   6  
   

   View Slide

7. Poor  Nancy  is  drowning  in  user  stories.  
    
   Let’s  look  a  bit  more  at  how  these  folks  work…  
    
   7  
   

   View Slide

8. So  this  graph  represents  a  project  6meline.    And  the  red  is  the  amount  of  analysis  and  
   design  effort.      As  you  can  see  from  this  Umberto  does  all  of  his  at  the  beginning  of  a  
   project  and  releases  in  one  big  bang.  
   8  
   

   View Slide

9. Nancy  however  has  really  regular  releases  &  she’s  really  not  even  aware  of  doing  any  
   “analysis”    She  just  picks  up  a  story,  has  a  conversa6on,  and  gets  on  with  some  
   implementa6on.  
   9  
   

   View Slide

10. So  here’s  where  I  need  your  help,  Imagine  for  a  minute  that  Umberto  and  Nancy  
    came  to  Agile  in  the  City  and  began  discussing  their  differences.      One  thing  led  to  
    another  and  they  had  a  love-­‐child  ’Agile  Angelina’  
    She  s  inherited  Nancy  and  Umberto’s  best  quali6es.      
     
    10  
    

    View Slide

11. What  does  delivery  look  like  for  her?      
    11  
    

    View Slide

12.  
    When  does  the  thinking  happen?  
     
    It  used  to  be  easier  to  know  this  in  the  waterfall  days.    You  had  a  requirements  
    document  and  then  specifica6on  and  design  documents,  and  this  process  of  analysis  
    and  synthesis  happened  in  between.  
       
    We  need  to  do  enough  up  front  work  to  be  able  to  see  the  big  picture  and  make  good  
    decisions,  but  be  able  to  start  really  small  so  that  we  can  get  to  market  quickly.      
       
       
       
     
     
    12  
    

    View Slide

13. So  we’ve  talked  about  Umberto  Upfront  and  Nancy  Nimble,  the  big  boulder  and  the  
    gravel.    A  huge  project  versus  a  6ny  story.    But  changing  from  waterfall  working  to  
    itera6ve  delivery  is  not  as  simple  as  turning  everything  into  fortnightly  sprints  
    delivering  user  stories.  There  are  many  other  heartbeats  and  itera6ons  that  we  need  
    to  consider.    
     
    13  
    

    View Slide

14. This  is  based  on  a  model  called  the  feedback  onion  which  I  developed  with  a  
    colleague  Pete  Buckney  a  few  years  ago.    
    It  represents  Collabora6on  driven  development.    
           
    We  have  different  layers  of  collabora6on  in  our  organisa6ons  
       
    At  each  layer  there  are  different  ques6ons  to  answer  and  different  challenges.    There  
    are  different  audiences  working  with  different  levels  of  detail,  and  the  audiences  are  
    different  sizes.    In  our  Umberto  and  Nancy  example,  the  project  is  the  great  big  
    boulder,  delivered  in  one  big  bang  with  lots  of  people  involved  and  the  feature  in  the  
    middle  is  the  6ny  piece  of  gravel  where  only  a  few  people  understand  the  details.  
     
    14  
    

    View Slide

15. Umberto  Up  front,  has  to  break  down  and  examine  the  whole  boulder  and  he  doesn’t  
    know  where  the  value  is.      
    15  
    

    View Slide

16. We  saw  that  Nancy  nimble  starts  with  all  this  gravel,  and  there’s  value  in  there  
    somewhere,  but  she  might  miss  it  because  she  doesn’t  have  the  big  picture    
     
    16  
    

    View Slide

17. View Slide

18. That  means  naviga6ng  through  the  other  layers  skillfully.  
     
    These  layers  represent  the  process  of  decomposi6on  that  Umberto  went  through  as  
    he  broke  down  the  boulder  into  smaller  bits.    But  instead  of  smashing  at  the  boulder  
    with  a  great  big  hammer  you  need  to  go  a=er  the  value  in  a  much  more  deliberate  
    way.        If  you  pay  more  aUen6on  to  these  different  itera6ons  and  heartbeats,  these  
    layers  of  decomposi6on  and  collabora6on  you  can  be  more  effec6ve  and  accelerate  
    delivery.  
     
    18  
    

    View Slide

19. -­‐  So  how  does  this  help  with  gefng  the  balance  right?  
     
    19  
    

    View Slide

20. Whenever  we  go  through  that  process  of  decomposi6on  and    move  from  one  layer  to  
    the  next  we  have  some  up  front  work  to  do.    
       
    We  need  to  pause  at  each  of  these  layers  to  make  sure  we  know  which  direc6on  
    we’re  going  in  and  why.    We  need  to  be  aligned  on  our  technical  vision  and  to  
    understand  the  scope  and  risks  of  what  we’re  taking  on  
     
    20  
    

    View Slide

21. Over  6me  it  might  look  like  this  
     
    Compared  to  Umberto’s  experience  
     
    Does  everyone  understand  what  I’m  on  about?  
    21  
    

    View Slide

22. Here  it  is  –  in  design  thinking  .      Design  thinking  is  made  up  of  2  parts,  divergent  
    thinking  where  you  start  by  examining  op6ons,    crea6ng  choices  and  then  convergent  
    thinking,  where  you  make  choices.    These  2  sec6ons  are  also  synonymous  with  
    analysis  and  synthesis.    So  analysis  is  where  you  break  down  the  whole  and  examine  
    it  and  then  synthesis  is  where  you  turn  that  into  a  way  forward.    I  also  think  there’s  a  
    rela6onship  here  between  looking  at  the  problem  domain  and  then  moving  into  the  
    solu6on  domain.      
     
    In  the  olden  days  we  went  through  this  process  in  silos  –  Umberto  would  have  done  
    it  all  by  himself  before  wri6ng  his  987  page  document….  
       
    But    if  we  do  this  collabora6vely,  this  is  where  the  magic  happens.  
       
    as  we  collaborate  and  explore  the  as  is,  look  at  customer  goals  and  examine  risks,  
    we’re  able  to  come  up  with  a  to  be  solu6on,  with  risk  mi6ga6ng  ac6ons  and  with  a  
    clear  technical  vision  as  to  how  to  proceed.    Which  is  really  important  if  we’re  trying  
    to  extract  the  value  in  the  leanest  way.  
    We  all  know  now  (par6cularly  in  the  DDD  community)  the  benefits  of  collabora6ng  –  
    domain  experts  and  technical  experts.    Raising  the  level  of  shared  understanding,  
    avoiding  costly  misunderstandings  and  making  good  decisions.  
       
     
    22  
    

    View Slide

23. So  each  6me  we  move  through  our  collabora6on  layers  we  need  to  do  some  design  
    thinking.    At  the  beginning  of  each  project,  at  the  beginning  of  each  release  at  the  
    beginning  of  each  itera6on  and  at  the  beginning  of  each  feature.    The  audiences  
    might  be  different  and  the  techniques  we  use  might  be  different.    For  each  of  the  
    collabora6on  layers  we  need  to  understand  the  high  level  landscape,  the  goals,  the  
    risks  etc  before  agreeing  on  a  concrete  ar6cula6on  of  what  success  looks  like,  and  a  
    target  for  delivery.  
     
    23  
    

    View Slide

24. Design  Thinking  toolkit  
    So  over  the  last  couple  of  years  I’ve  been  looking  a  lot  at  the  benefits  of  collabora6on  
    and  par6cularly  which  techniques  help  at  different  layers.  
       
    Here  are  some  techniques  you  might  be  familiar  with  Each  of  these  techniques  has  
    divergent  and  convergent  aspects  
       
    Lean  Canvas  
    Impact  Mapping  
    Story  Mapping  
    OOPSI  
    Specifica6on  By  Example  
    24  
    

    View Slide

25. Here’s  how  this  might  look  on  a  6meline.  
       
    So  can  you  see  how  if  you  understood  the  itera6ons  and  heartbeats  in  your  own  
    organisa6on,  you  might  be  able  to  plan  specific  collabora6ve  ac6vi6es  around  
    tailored  to  your  context.    So  it  would  depend  how  regularly  you  were  able  to  do  
    releases  and  how  greenfield  you  were  etc.  
     
    25  
    

    View Slide

26. Shout  out  different  types  of  tes6ng  
     
    26  
    

    View Slide

27. In  Agile  We  talk  too  much  about  ‘Agile  Acceptance  Tes6ng)  –  what  about  all  the  other  
    types  of  tes6ng?  
       
    This  model  also  reflects  different  levels  of  tes6ng  and  how  different  techniques  and  
    tools  might  be  appropriate  at  different  levels.    How  does  that  look  on  the  6meline  for  
    Lean  -­‐  Agile  Angelina?  
     
     
    27  
    

    View Slide

28. View Slide

29. Our  objec6ve  for  itera6ve  tes6ng  is  for  it  to  be  as  con6nuous  and  collabora6ve  as  
    possible,  by  using  techniques  like  specifica6on  by  example  we’re  trying  to  eliminate  
    handovers  to  that  there  is  no  specific  acceptance  tes6ng  needed,  it  just  works  as  
    expected.  
    But  depending  on  your  context  and  heartbeats  in  your  organisa6on  there  might  be  
    specific  ac6vi6es  required  that  6e  to  the  end  of  an  itera6on.    Where  you  need  things  
    to  be  stable.    For  example  to  run  representa6ve  performance  tes6ng  or  lock  down  
    regression  tests.  
    29  
    

    View Slide

30.  So  these  collabora6on  layers  are  like  different  levels  of  decomposi6on  of  detail  &  it  
    might  help  us  recognise  for  these  different  layers  what  appropriate  artefacts  we  want  
    to  keep,  and  who’d  interested  in  them.    
     
    There’s  also  a  kind  of  inverted  tes6ng  pyramid  in  here  –  Anyone  heard  of  Mike  Cohns  
    Automated  tes6ng  pyramid?  
     
    If  we  understand  more  about  what  ques6ons  we  are  trying  to  answer  and  what  level  
    of  decomposi6on  we  are  at,  maybe  we’d  be  beUer  at  choosing  appropriate  
    collabora6on  and  tes6ng  techniques  to  help  us  answer  those  ques6ons.    And  we  
    might  even  be  able  to  structure  our  projects  around  these  heartbeats  and  
    collabora6ons  rather  than  trying  to  force  a  one-­‐model  fits  all  approach.  
     
    30  
    

    View Slide

31. So  that  was  Collabora6on  Driven  Development  Model.    So  I’m  hoping  you  might  try  a  
    collabora6on  driven  approach  in  your  own  teams  and  I’m  keen  to  hear  if  it  helps  you  
    get  the  balance  right  between  up  front  work  and  in-­‐itera6on  work.    It  might  help  you  
    deliver  value  faster  like    Agile  Angelina  and  stop  you  gefng  squished  like  Umberto  or  
    Nancy  
    31  
    

    View Slide

32. View Slide