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  
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  
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  
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  
5. Poor  Umberto  is  having  a  hard  6me     5  
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  
7. Poor  Nancy  is  drowning  in  user  stories.     Let’s  look  a  bit  more  at  how  these  folks  work…     7  
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  
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  
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  
11. What  does  delivery  look  like  for  her?       11  
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  
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  
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  
15. Umberto  Up  front,  has  to  break  down  and  examine  the  whole  boulder  and  he  doesn’t   know  where  the  value  is.       15  
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  
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  
19. -­‐  So  how  does  this  help  with  gefng  the  balance  right?     19  
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  
21. Over  6me  it  might  look  like  this     Compared  to  Umberto’s  experience     Does  everyone  understand  what  I’m  on  about?   21  
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  
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  
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  
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  
26. Shout  out  different  types  of  tes6ng     26  
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  
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  
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  
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