Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Basic Agile for Being Agile

Basic Agile for Being Agile

Understanding the basics of Agile software development. 2nd master class @U_tad @telefonicaid

Ruben Gonzalez Blanco

September 18, 2014
Tweet

More Decks by Ruben Gonzalez Blanco

Other Decks in Technology

Transcript

  1. Dealing  with  So,ware  -­‐  EvoluHon   So,ware  Crisis   So#ware

     Engineering   No  Silver  Bullet   Agile  Manifesto   Cra#smanship   Manifesto   Cra,ing   Incremental   1960   1970   1980   1950   1990   2000   2010   Waterfall   IteraHve   Rapid  Prototyping   CMM   Cra,ing   PredicHve  Processes   IteraHve  Processes   Agile  Methods   Scrum,  XP,  FDD,  DSDM,  OpenUP…   Spiral,  RAD,  Objectory,    RUP   Waterfall,  CMM,  ISO9000   EvoluHonary  
  2. Inherent  complexity  and  uncertainty   •  Machines  are  complex  

    •  Machines  are  faster  and  can  process  more  data  than  human  brain   (consciously)   •  Although  Machines  are  predictable  (based  on  math  and  logic),  the  level   of  parallelism,  speed  and  volume  of  data  and  instrucHons  processed  per   second    makes  dealing  with  machines  a  complex  and  uncertain  task   •  Modern  mathemaHcal/logical  formulas  =  so,ware  programs    needs   TesHng  to  make  sure  we  have  instructed  the  machine  properly.  Can  not   be  predicted  upfront   •  Uncertain  and  Changing  Requirements,  FuncHonal,  non  FuncHonal     created  by  Machines  and  the  Problem  to  solve  
  3. Accidental  complexity  and  uncertainty   created  by  Humans   So,ware

     Development  depends  on  humans  creaHvity,  knowledge,  passion,  talent   desires  …  but  also  in  their  collaboraHons  and  interacHons     So,ware  is  “so,”  or  flexible,  it  is  possible  to  express  almost  any  kind  of  abstracHon     Managing  de  Development  Process  is  complex      
  4. Since  the  outcome  is  uncertain  we   need    a

     ConHnuous  CreaHve  ISRF  Cycle   IntenHon   RealizaHon   Feedback   Synthesis  
  5. That  is  based  on  human  creaHvity,   talent  and  knowledge

     that  is  acquired   along  the    synthesis  process   knowledge   Time   Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Learning  by  doing   Deliberate  pracHce  
  6. Difficulty:  understand  the  Problem  (What)     and  figure  out

     possible  SoluHon  (How)   Problem   SoluHon   At  the  same  Hme  
  7. at  mulHple  levels  of  detail…   What   How  

    What   How   What   How   User    System   Component   What   How   What   How   What   How    Domain  
  8. …concurrently  ,  in  mulHple  brains  and   within  different  Hme

     frames     Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis'
  9. Till  the  Desired  Working  So#ware   Emerges   Inten%on' Realiza%on'

    Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Compile  Failed   Run  Failed   Test  Failed   Test  Passed   Enhance  Idea/Design   Test  Failed   Inten%on' Realiza%on' Feedback' Synthesis' Test  Passed   Emergence  is  the  key  characterisHc  of  complex  systems.     WORKING  SOFTWARE   IntenHonal   Emergent  
  10. …  in  both  the  So,ware  SpecificaHon  and  the   So,ware

     RealizaHon   Both  SpecificaHons  and  Architecture  Emerge  and  Grow  along  the  process     System  “Specs”   Architecture   So#ware  System   Idea   Need   Problem   IntenHonal   Emergent   Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis'
  11. All  depends  on  Talented  Individuals     inspired   creaHve

      passionate   team  player   Knowledge     Mastery   Talent   MoLvaLon     CreaLvity   InspiraLon   Passion   Genius  
  12. Requires  MulHple  Disciplines  in  a   Team  CollaboraHng  together  

    Domain  Experts   Ux  Designers   Business  Analysts   Product  Managers   So#ware  Developers   Testers   System  Engineers   Deployment  Engineers   So,ware  Architects   Human  Factors   Users   Project  Managers  
  13. Agile  So,ware  Development  is  just  a   set  of  Principles,

     Values,  and  PracHces   for  dealing  with  so,ware  complexity   and  uncertainty   The  purpose  :  Effec3ve  So6ware  Development  
  14. Agile  Manifesto   We  are  uncovering  bemer  ways  of  developing

     so,ware  by  doing  it  and  helping  others  do  it.   Through  this  work  we  have  come  to  value:     Individuals  and  interacLons  over  processes  and  tools     Working  so#ware  over  comprehensive  documentaHon     Customer  collaboraLon  over  contract  negoHaHon     Responding  to  change  over  following  a  plan     That  is,  while  there  is  value  in  the  items  on  the  right,  we  value  the  items  on  the  le,  more   hmp://agilemanifesto.org/  
  15. Our  highest  priority  is  to  saLsfy  the  customer   through

     early  and  conLnuous  delivery  of   valuable  so#ware.   Welcome  changing  requirements,  even  late  in   development.  Agile  processes  harness  change   for  the  customer’s  compeHHve  advantage.   Deliver  working  so#ware  frequently,  from  a   couple  of  weeks  to  a  couple  of  months,  with  a   preference  to  the  shorter  Hmescale.   Business  people  and  developers  must  work   together  daily  throughout  the  project.   Build  projects  around  moLvated  individuals.   Give  them  the  environment  and  support  they   need,  and  trust  them  to  get  the  job  done.   The  most  efficient  and  effecHve  method  of   conveying  informaHon  to  and  within  a   development  team  is  face-­‐to-­‐face   conversaLon.   1 2 3 4 5 6 7 8 9 10 11 12 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.   ConHnuous  amenHon  to  technical  excellence   and  good  design  enhances  agility.   Simplicity—the  art  of  maximizing  the  amount   of  work  not  done—is  essenHal.   The  best  architectures,  requirements,  and   designs  emerge  from  self-­‐organizing  teams.   At  regular  intervals,  the  team  reflects  on  how   to  become  more  effecHve,  then  tunes  and   adjusts  its  behaviour  accordingly.   12  Agile  Principles  
  16. Copyright 2007 Dean Leffingwell What  Paradigms  Is  Agile  Breaking?  

    Culture   Measure     of  Success   Waterfall   Development   IteraLve  Development   IteraLve  and   Incremental   Development   Parallel   Development   Acceptance   Test  Driven     Development   Command-­‐and-­‐Control   Leadership  /CollaboraLve   Conformance    to  Plan   Response  to  Change   Design   QA   Process   Big  Design  Up  Front   ConLnuous/Emergent   Big  Test  on  Backend   ConLnuous   Agile  Development   Tool  Support   Highly  specific   Fully  Integrated  
  17. IteraHve  vs  Waterfall  Development   So,-­‐NOT-­‐aware   So,ware   Waterfall

      Requirements   Analysis&Design   ImplementaHon   TesHng   Deployment   SpecificsHons   Architecture   So,ware   So,ware   Paperware   Itera3on1   Itera3on2   Itera3on3   Release1   Working  So,ware   Release2   Release3   Focus In Executable Software You  can't  know   everything  at  the   beginning   You  learn  as  you   work  
  18. Why  IteraHve   •  It  accommodates  changing  requirements   • 

    IntegraHon  is  not  one  "big  bang"  at  the  end  of  a  project   •  Risks  are  usually  discovered  or  addressed  during  early  integraHons   •  Reuse  is  facilitated   •  Management  has  a  means  of  making  tacHcal  changes  to  the  product   •  Defects  can  be  found  and  corrected  over  several  iteraHons,     •  It  is  a  bemer  use  of  project  personnel.     •  Team  members  learn  along  the  way.   •  The  development  process  itself  is  improved  and  refined  along  the  way  
  19. IteraHon  general  pamern   PLANNING   REVIEW   ITERATION  N

      PLANNING   REVIEW   ITERATION  N+1   Product  Backlog   •  User  Stories   •  Features   •  Architecture  Stories   •  Issues/Bugs   new  reqs   Working  So,ware   PLANNING   REVIEW   ITERATION  N+2  
  20. IteraHon  a  la  mini-­‐waterfall   Requirements   Analysis&Design   ImplementaHon

      TesHng   Deployment   PLANNING   REVIEW   ITERATION  N   Product  Backlog   Working  So,ware  
  21. Requirements   Analysis&Design   ImplementaHon   TesHng   Deployment  

    IteraHon  a  la  agile   PLANNING   REVIEW   ITERATION  N   Product  Backlog   Working  So,ware   Concurrent  &  Blended   around  people  collaboraHon   2-­‐4  weeks  
  22. IteraHon  a  la  agile  example  :    D/B/T  teams  

        User  Story1   UserStory2   UserStory3   Feature1   Feature2   …   define   build   test   define   build   test   define   build   test   ITERATION  <n>   DBT  user  story  1   DBT  component  2   DBT  Feature1   Backlog  n       UserStory2   UserStory3   NewUserStory4   Feature2   NewFeature3   …   Backlog  n+1   PLANNING   REVIEW   Working  So,ware   D/B/T  :   •  User  story   •  Feature   •  Technical/Architecture   •  Bug  
  23. IteraHons  a  la  ¿agile?  Example   interleaved  “waterfalls”   PLANNING

      REVIEW   ITERATION  N-­‐1   PLANNING   REVIEW   ITERATION  N   Product  Backlog   •  User  Stories   •  Features   •  Architecture  Stories   •  Issues/Bugs   PLANNING   REVIEW   ITERATION  N+1   Requirements  N   Analysis&Design  N   ImplementaHon    N   TesHng  N   PLANNING   REVIEW   ITERATION  N+2   Deployment  N   Acceptance  N   Acceptance  N-­‐3   Requirements  N+1   Requirements  N+2   Deployment  N-­‐1   Acceptance  N-­‐1   Deployment  N-­‐2   Acceptance  N-­‐2   Requirements  N+3   TesHng  N-­‐1   TesHng  N-­‐2   Analysis&Design  N-­‐1   ImplementaHon  N-­‐1   Analysis&Design  N+1   ImplementaHon  N+1   Analysis&Design  N+2   ImplementaHon  N+2   TesHng  N+1   Deployment  N-­‐3  
  24. “iteraHng”  builds  a  rough  version,   validates  it,  then  slowly

     builds  up  quality   1 2 3 IteraHng  allows  you  to   move  from  vague  idea   to  realizaHon   From  Jeff  Pamon  :  hmp://www.agileproductdesign.com/blog/dont_know_what_i_want.html  
  25. “incremenHng”  builds  a  bit  at  a  Hme     1

    2 3 But,  incremenHng  calls   for  a  fully  formed  idea   ©  2006-­‐2009  Jeff  Pamon:  hmp://www.agileproductdesign.com/blog/dont_know_what_i_want.html  
  26. In  so,ware,  iteraHons  combine  iteraHve   and  incremental  development  

    •  To  find  out  “what”  and  “how”   •  To  improve  the  System   •  To  release  funcHonality  incrementally   •  To  gradually  add  parts  to  the  System  when  “what”  and  “how”  are  known   ITERATIVE   INCREMENTAL   ©  2006-­‐2009  Jeff  Pamon:  hmp://www.agileproductdesign.com/blog/dont_know_what_i_want.html  
  27. Value  Driven   SOURCE  :  DSDM   Based  on  Dean

     Leffingwell  scaling  agile  blog   Fixed   Scope   Time   Resources   Time   Scope   Plan     Driven   Value   Driven   The  Plan  creates  cost/ schedule  es1mates   feature  intent  &  commitment  to   deliver  the  max  value   Resources   Fixed   EsLmated   IntenLonal  &   Max  Possible  
  28. The  happy  IteraHve  project   •  User  Stories   • 

    Features   •  Architecture  Stories   •  Issues/Bugs   ITERATION1   ITERATION2   ITERATION3   ITERATION4   Final   RELEASE   Backlog   Fixed  Time  
  29. The  unhappy  IteraHve  project   •  User  Stories   • 

    Features   •  Architecture  Stories   •  Issues/Bugs   ITERATION1   ITERATION2   ITERATION3   ITERATION4   Final   RELEASE   Backlog   New  Req   “Embracing  the  Change”   Fixed  Time  
  30. Value  Driven  Strategies   •  PrioriLze  and  reduce  goals  to

     hit  the  release  date   –  Less  goals  =>  less  So,ware   •  Do  not  commit  to  early:     –  Decide  what  to  deliver  by  experimenHng  in  the   iteraHons.     –  Remember  that  both  Specs  and  Architecture  emerge   •  Avoid  Big  UpFront  Designs  and  Specs  (BUFDS)   •  Grow  Features  quality  iteraHon  by  iteraHon   –  Start  with  simplest,  minimal  feature  soluHon  and  add   more  quality  iteraHon  by  iteraHon   Based  on  Jeff  Pamon:  hmp://www.agileproductdesign.com  Embrace  Uncertainty  presentaHon  
  31. RUP  Process  Framework   Overview  of  Processes/Methods   Low  Ceremony

        Limle  documentaHon   Light  process   High  Ceremony     Well  documented   Traceability   CCB   CMM-­‐I   CMM   IteraHve   Risk  Driven   ConHnuous  integraHon  and  tesHng     Waterfall   SequenHal,  Few  risks   Late  IntegraHon  and  tesHng   Open  UP   DSDM   XP   SCRUM   Agile   Source:  Per  Kroll/  Philippe  Krutchen  
  32. The  Agile  Methods   •  Each  IteraLon  delivers  working  so#ware:

     Ready  to  be  demonstrated  to   Business  Customer  and  deployed  in  producHon  environment   •  All  development  disciplines  (requirements,  analysis  and  design,   implementaHon,  test…)    are  nearly  concurrent  :  FiDng  all  ac3vi3es  in  a   short  3me  itera3on   •  Teams  are  self  managing  :  Bomom-­‐up    vs  Top-­‐down  management   •  Use  of  specific  pracLces  that  keep  the  code  base  fresh  and    flexible:  Pair   programming,  code  refactoring,  test  driven  development,  conHnuous   integraHon   •  Lean  principles  and  techniques  eliminate  waste  whenever  possible  
  33. Agile  Methods   DSDM   FDD   Crystal   PragmaHc

     Programming   AdapHve  So,ware  Development   The most extended methods under the Agile umbrella are Scrum and XP  
  34. Embrace  Change   Embrace  Uncertainty   Be  Value  Driven  

    Use  AdapLve  Management   Agile  AdopHon  
  35. In  any  case    Remember  that  in  so,ware   development

     there  is  not  silver  bullet   Fred  Brooks  
  36. ….and  you  must  Adapt  Methods  to  the   Team,  not

     the  opposite   DSDM   FDD   Crystal   PragmaHc  Programming   AdapHve  So,ware  Development  
  37. Books: Scaling Software Agility: Best Practices for Large Enterprises, Dean

    Leffingwell Agile Estimating and Planning, Mike Cohn Agile Project Management with Scrum, Ken Schwaber The Enterprise and Scrum, Ken Schwaber Scrum And XP from the trenches, Henrik Kniberg Succeeding with Agile. Software Development using Scrum. Mike Cohn Specification by Example. Gojko Adzic Agile References (II)
  38. Presentations: Building Better Products Using User Story Mapping – Jeff

    Patton Embrace Uncertainty – Jeff Pattong http://www.agileproductdesign.com/presentations/index.html Websites: Agile Community: https://agile.telefonica.com Agile Alliance http://www.agilealliance.org Scrum Alliance http://www.scrumalliance.org Mountain Goat Software http://www.mountaingoatsoftware.com/scrum http://www.scrumalliance.org/articles/46 http://www.leadingagile.com/2009/08/scrum-of-scrums.html (how to handle dependencies) http://geekoff.blogspot.com/2008/12/big-org-small-bandwidth.html Agile References (III)
  39. Kanban  in  a  nusthell   •  Visualize  the  workflow  

      –  Split  the  work  into  pieces,  write  each  item  on  a  card  and  put  on   the  wall     –  Use  named  columns  to  illustrate  where  each  item  is  in  the   workflow.     •  Limit  WIP  (work  in  progress)  –  assign  explicit  limits  to  how   many  items  may  be  in  progress  at  each  workflow  state.     •  Measure  the  lead  Hme  (average  Hme  to  complete  one   item,  someHmes  called  “cycle”),  opHmize  the  process  to   make  lead  Lme  as  small  and  predictable  as  possible.    
  40. Cra,smanship  Manifesto   As   aspiring   So,ware   Cra,smen

      we   are   raising   the   bar   of   professional   so,ware     development   by   pracHcing  it  and  helping  others  learn  the  cra,.    Through  this  work  we  have  come  to  value:                                     That  is,  in  pursuit  of  the  items  on  the  le,  we  have  found  the  items  on  the  right  to  be  indispensable.   Not  only  working  so,ware,    but  also  well-­‐cra#ed  so#ware     Not  only  responding  to  change,    but  also  steadily  adding  value     Not  only  individuals  and  interacHons,    but  also  a  community  of  professionals     Not  only  customer  collaboraHon,     but  also  producLve  partnerships   hmp://manifesto.so,warecra,smanship.org/