We  said  it  was  simple  

Andy  Longshaw  Advanced  Legal  @andylongshaw  

A  wise  man  once  said  

It’s  simple  

Individuals  and  interac/ons  over  processes  and  tools  Working  so4ware  over  comprehensive  documenta;on  

Customer  collabora/on  over  contract  nego;a;on  Responding  to  change  over  following  a  plan  

Agile  manifesto    

Courage  Simplicity  Feedback  Communica/on  Respect  

XP  values  

Well,  reasonably  simple  Working  so@ware  is  the  primary  measure  of  progress.    Agile  processes  promote  sustainable  development.  The  sponsors,  developers,  and  users  should  be  able  to  maintain  a  constant  pace  indefinitely.    Con;nuous  aEen;on  to  technical  excellence  and  good  design  enhances  agility.    Simplicity-­‐-­‐the  art  of  maximizing  the  amount    of  work  not  done-­‐-­‐is  essen;al.    The  best  architectures,  requirements,  and  designs  emerge  from  self-­‐organizing  teams.    At  regular  intervals,  the  team  reflects  on  how  to  become  more  effec;ve,  then  tunes  and  adjusts  its  behavior  accordingly.  

Our  highest  priority  is  to  sa;sfy  the  customer  through  early  and  con;nuous  delivery  of  valuable  so@ware.    

Welcome  changing  requirements,  even  late  in  development.  Agile  processes  harness  change  for  the  customer's  compe;;ve  advantage.    

Deliver  working  so@ware  frequently,  from  a  couple  of  weeks  to  a  couple  of  months,  with  a  preference  to  the  shorter  ;mescale.    Business  people  and  developers  must  work  together  daily  throughout  the  project.    Build  projects  around  mo;vated  individuals.  Give  them  the  environment  and  support  they  need,  and  trust  them  to  get  the  job  done.    The  most  efficient  and  effec;ve  method  of  conveying  informa;on  to  and  within  a  development  team  is  face-­‐to-­‐face  conversa;on.  

How  hard  can  it  be?  

Developers  •  It’s  not  easy  for  them  

because  they  need  to…  

 •  take  responsibility  •  have  the  discipline  to  follow  their  process  under  

pressure  •  say  “no”  when  things  can’t  be  done  •  have  the  judgment  and  courage  to  ask  for  help  

when  they  need  it  •  follow  through  on  their  retrospec;ve  ac;ons  •  seek  feedback  and  keep  improving  •  keep  refactoring  un;l  it’s  simple!  

Tes;ng  specialists  •  It’s  not  easy  for  her  

because  she  needs  to…  

•  be  more  proac;ve  •  get  really  good  at  (business)  analysis  

skills  •  learn  some  coding  •  get  really  good  at  exploratory  tes;ng  •  spend  a  lot  of  ;me  teaching  people  

about  what  makes  good  tests  

•  oh,  and  see  “Developers”  

Devops  specialists  •  It’s  not  easy  for  them  

because  they  need  to…  

•  automate  all  the  things  •  master  the  different  

tools  for  deployment,  tools  for  build,  tools  for  test  and  containers  

•  refactor  the  pipeline  again  to  include  a  new  technology  

•  oh,  and  see  “Developers”  

The  product  owner  •  It’s  not  easy  for  her  because  she  has  to…  

•  spend  a  lot  of  ;me  out  of  the  building,  visi;ng  customers  and  understanding  the  market  

•  be  available  to  answer  ques;ons  when  the  team  needs  her  to  &  take  part  in  3  Amigos  sessions  

•  find  ;me  to  do  enough  work  on  the  backlog  so  that  it’s  coherent  and  ready  for  the  team  

•  deal  with  various  bits  of  the  organisa;onal  square  on  behalf  of  the  team,  like  communica;ng  “bad  news”  (honesty)  about  changes  in  delivery  ;mescales  or  the  features  (not)  in  a  release  

The  organisa;on’s  technical  leadership  

•  It’s  not  easy  for  them  because  they  have  to…  

•  recruit  good  people  who  can  fulfill  all  of  this    •  trust  them  to  make  good  decisions  and  

priori;se  and  to  ask  for  help  when  they  need  it  •  deal  with  the  other  bits  of  the  organisa;onal  

square  on  behalf  of  the  team  that  the  product  owner  doesn’t  deal  with  

•  let  people  get  on  with  making  mistakes  and  learning  as  they  do  some  stuff  that  you  can  probably  already  do  &  that  you  would  probably  rather  be  doing  than  all  this  management  crap    

I  know,  we’ll  get  a  coach  in…  •  It’s  not  easy  for  them  because  they  have  to…  

•  try  to  influence  the  team  culture  and  codebase  in  a  couple  of  days  a  week    

•  set  a  consistent  example  of  how  to  be  a  good  agile  developer  

•  teach  people  the  same  stuff  over  and  over  in  different  ways  without  going  postal    

It’s  not  easy,  because…  •  You  need  discipline  to  avoid  a  cynefin-­‐style  slide  into  chaos  

•  Most  of  the  challenges  are  around  so@  skills  -­‐  not  a  techie  strong  point  

•  You  have  to  change  yourself  •  You  have  to  learn  when  to  have  iron  discipline  and  when  it’s  OK  to  improvise  

•  Your  organiza;on  is  square  and  you  are  a  circle  

But  mostly…  

•  It’s  not  easy  because…  

•  …nobody  has  sold  the  wider  business  on  working  in  an  agile  way  and  agile  so@ware  development  doesn’t  deliver  the  benefits  unless  the  wider  business  works  with  the  grain  

We  ain’t  gonna  take  it  

•  This  is  why  most  organisa;ons  end  up  in  Tommy  mode  –  "We  ain't  gonna  take  it"    hEps://www.youtube.com/watch?v=sKDO19Y0KWg  

–  flaccid  scrum,  cargo  cult,  etc.  

•  But  XP  (and  other  agile  approaches)  only  work  when  they  have  the  dials  turned  up  to  10  

So  remember…  

•  We  didn’t  say  it  was  easy.      We  said  it  was  SIMPLE  

•  If  you’re  finding  agile  so@ware  development  easy,  you’re  probably  doing  it  wrong