Collaboration Driven Development

How do we get the balance right between lots of up front work and not enough analysis and design?
How do we build collaboration into our delivery cycles?
This talk explores looks at the heartbeats of collaboration we have in our organisations and how to plan effective collaboration to get the balance just right.

Transcript

1. Hello  I’m  Jenny     I’ve  been  in  so0ware  delivery  for  20  years  and  I  work  with  teams  to  help  them   collaborate  be=er  and  be  more  effec?ve.  It’s  taken  me  quite  a  long  ?me  to  realise   that  what  makes  me  ?ck  and  get’s  me  out  of  bed  in  the  morning  isn’t  so0ware   development  as  such,  not  even  agile  tes?ng  or  BDD,  it’s  about  helping  teams  flourish   and  thrive  and  be  themselves.    So  I’m  all  about  collabora?on.  But  collabora?on  is   hard.  When  you  come  out  of  your  Scrum  cer?fica?on  training  you  kind  of  come  out   thinking  “OK  –  now  I’ve  got  this  post-­‐it  note  I  need  to  go  and  have  conversa?ons  and   collaborate”.      I  work  with  teams  who  find  that  difficult,  which  poses  problems  -­‐   because  effec?ve  collabora?on  is  absolutely  crucial  to  the  success  of  our  projects.     As  well  as  collabora?on,  I’m  also  convinced  that  one  of  the  biggest  challenges  that   organisa?ons  face  when  implemen?ng  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  collabora?on-­‐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  diagrams  and  massive  data  models.       Umberto  loves  work  in  the  solu?on  domain  and  he  likes  to  decompose  a  solu?on  in   its  en?rety  before  a  single  line  of  code  is  wri=en.         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  documenta?on.       She’s  a  great  team  player    -­‐  She’s  always  on  ?me  for  stand  up  mee?ngs,  always  keeps   her  update  to  45  seconds  and  makes  great  notes  on  her  Jira  ?ckets.         She  doesn’t  really  do  analysis  or  design,  she  just  focuses  on  building  so0ware  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  documenta?on         The  Business  some?mes  get  cross  with  Umberto  Upfront  because  they  find  some  of   his  documenta?on  difficult  to  digest  and  they  don’t  always  understand  the   terminology  he  is  using.    So  they  miss  stuff  when  they  review  it  &  by  the  ?me  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  solu?on  because  he  hasn’t  spent  any  ?me  understanding  the  real  business   domain  and  the  issues  they  face.       And  even  though  his  solu?ons  are  carefully  architected,  a  small  business  change   some?mes  leads  to  a  massive  technical  change  with  a  huge  lead-­‐?me  for  delivery.         4  
5. Poor  Umberto  is  having  a  hard  ?me     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  documenta?on  and   she  can  let  the  design  kind  of  take  care  of  itself.         But  she’s  drowning  in  user  stories  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  solu?ons  are   actually  delivering  any  value  to  the  business     Some?mes  Nancy  feels  like  she’s  building  a  great  big  ball  of  mud  and  she’s  spending   more  and  more  ?me  trying  to  refactor  her  way  out  of  it.    She’s  beginning  to  feel   overwhelmed.     6  
7. Poor  Nancy.     Let’s  look  a  bit  more  at  how  these  folks  work…     7  
8. So  this  graph  represents  a  project  ?meline.    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  conversa?on,  and  gets  on  with  some   implementa?on.   9  
10. So  here’s  where  I  need  your  help,  Imagine  for  a  minute  that  Umberto  and  Nancy   came  to  Lean  Agile  Scotland  and  began  discussing  their  differences.      One  thing  led  to   another  and  they  had  a  love-­‐child  ’Lean  Agile  Angelina’   She  s  inherited  Nancy  and  Umberto’s  best  quali?es.         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  specifica?on  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  ?ny  story.    But  changing  from  waterfall  working  to   itera?ve  delivery  is  not  as  simple  as  turning  everything  into  fortnightly  sprints   delivering  user  stories.  There  are  many  other  heartbeats  and  itera?ons  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  Collabora?on  driven  development.    We’ve  got  BDD  and  DDD  and  I   thought  we  needed  CDD  to  help  bring  those  things  together           I  see  it  like  this.    This  is  a  model  for  collabora?on       We  have  different  layers  of  collabora?on  in  our  organisa?ons       At  each  layer  there  are  different  ques?ons  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  ?ny  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  naviga?ng  through  the  other  layers  skillfully.     These  layers  represent  the  process  of  decomposi?on  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  a0er  the  value  in  a  much  more  deliberate   way.        If  you  pay  more  a=en?on  to  these  different  itera?ons  and  heartbeats,  these   layers  of  decomposi?on  and  collabora?on  you  can  be  more  effec?ve  and  accelerate   delivery.     18  
19. -­‐  So  how  does  this  help  with  gefng  the  balance  right?     19  
20. Whenever  we  go  through  that  process  of  decomposi?on  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  direc?on   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  ?me  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  op?ons,    crea?ng  choices  and  then  convergent   thinking,  where  you  make  choices.    These  2  sec?ons  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   rela?onship  here  between  looking  at  the  problem  domain  and  then  moving  into  the   solu?on  domain.         In  the  olden  days  we  went  through  this  process  in  silos  –  Umberto  would  have  done   it  all  by  himself  before  wri?ng  his  987  page  document….       But    if  we  do  this  collabora?vely,  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  solu?on,  with  risk  mi?ga?ng  ac?ons  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  (par?cularly  in  the  DDD  community)  the  benefits  of  collabora?ng  –   domain  experts  and  technical  experts.    Raising  the  level  of  shared  understanding,   avoiding  costly  misunderstandings  and  making  good  decisions.         22  
23. So  each  ?me  we  move  through  our  collabora?on  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  itera?on  and  at  the  beginning  of  each  feature.    The  audiences   might  be  different  and  the  techniques  we  use  might  be  different.    For  each  of  the   collabora?on  layers  we  need  to  understand  the  high  level  landscape,  the  goals,  the   risks  etc  before  agreeing  on  a  concrete  ar?cula?on  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  collabora?on   and  par?cularly  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   Specifica?on  By  Example   24  
25. Here’s  how  this  might  look  on  a  ?meline.       So  can  you  see  how  if  you  understood  the  itera?ons  and  heartbeats  in  your  own   organisa?on,  you  might  be  able  to  plan  specific  collabora?ve  ac?vi?es  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  tes?ng     26  
27. In  Agile  We  talk  too  much  about  ‘Agile  Acceptance  Tes?ng)  –  what  about  all  the  other   types  of  tes?ng?       This  model  also  reflects  different  levels  of  tes?ng  and  how  different  techniques  and   tools  might  be  appropriate  at  different  levels.    How  does  that  look  on  the  ?meline  for   Lean  -­‐  Agile  Angelina?       27  
29. Our  objec?ve  for  itera?ve  tes?ng  is  for  it  to  be  as  con?nuous  and  collabora?ve  as   possible,  by  using  techniques  like  specifica?on  by  example  we’re  trying  to  eliminate   handovers  to  that  there  is  no  specific  acceptance  tes?ng  needed,  it  just  works  as   expected.   But  depending  on  your  context  and  heartbeats  in  your  organisa?on  there  might  be   specific  ac?vi?es  required  that  ?e  to  the  end  of  an  itera?on.    Where  you  need  things   to  be  stable.    For  example  to  run  representa?ve  performance  tes?ng  or  lock  down   regression  tests.   29  
30.  So  these  collabora?on  layers  are  like  different  levels  of  decomposi?on  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  tes?ng  pyramid  in  here  –  Anyone  heard  of  Mike  Cohns   Automated  tes?ng  pyramid?     If  we  understand  more  about  what  ques?ons  we  are  trying  to  answer  and  what  level   of  decomposi?on  we  are  at,  maybe  we’d  be  be=er  at  choosing  appropriate   collabora?on  and  tes?ng  techniques  to  help  us  answer  those  ques?ons.    And  we   might  even  be  able  to  structure  our  projects  around  these  heartbeats  and   collabora?ons  rather  than  trying  to  force  a  one-­‐model  fits  all  approach.     30  
31. So  that  was  Collabora?on  Driven  Development  Model.    So  I’m  hoping  you  might  try  a   collabora?on  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-­‐itera?on  work.    It  might  help  you   deliver  value  faster  like    Lean  –  Agile  Angelina  and  stop  you  gefng  squished  like   Umberto  or  Nancy   31