Path to agility, Ken Schwaber
Upcoming SlideShare
Loading in...5
×
 

Path to agility, Ken Schwaber

on

  • 2,274 views

 

Statistics

Views

Total Views
2,274
Slideshare-icon Views on SlideShare
1,487
Embed Views
787

Actions

Likes
1
Downloads
40
Comments
0

3 Embeds 787

http://www.frenchsug.org 785
http://translate.googleusercontent.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Path to agility, Ken Schwaber Path to agility, Ken Schwaber Presentation Transcript

    • Scrum! for
 Paris User Group! 1  
    • Agility  (a·∙gil·∙i·∙ty)  –noun  1. flexibility, the capacity and capability of rapidly and efficiently adapting to change.2.  ability  to  take  advantage  of  opportuni6es   while  controlling  risk. The  courage  to  be  honest  enough  to  admit  that  building  soEware  is   complex  and  it  can’t  be  perfectly  planned  since  requirements  change.  29  March  2011   ©  ADM  1993-­‐2011  All  Rights  Reserved  v2.0   Slide  2  
    • Why  is  Agility  important?   •  More  global  compeLtors   •  More  demanding   customers   •  More  complex  products   •  More  features  requested   In  other  words:  Because  your  customers  demand  it.  29  March  2011   ©  ADM  1993-­‐2011  All  Rights  Reserved  v2.0   Slide  3  
    • What  are  some  specific  reasons  to  “be  Agile?”  •  Improved  relaLonship  with  customers,  regaining  trust  •  Flexibility  to  turn  on  a  dime  •  Improved  producLvity  and  quality  •  Taking  advantage  of  opportuniLes  •  Early  eliminaLon  of  risk  •  Early  realizaLon  of  value  •  Always  knowing  exactly  where  you  are  in  a  development/deployment   cycle  •  Easier  to  make  changes  •  EliminaLon  of  waste  •  Lean  products  that  reach  market  faster  and  are  more  targeted  •  Increased  Return  on  Investment  •  Engaged,  empowered  workers  •  Reduced  Total  Cost  of  Ownership  29  March  2011   ©  ADM  1993-­‐2011  All  Rights  Reserved  v2.0   Slide  4  
    • But,  many  organizaLons  instead  have  …  •  Releases  take  longer  and  longer.  •  Release  schedules  slip.  •  StabilizaLon  at  end  of  release  takes  longer  and  longer.  •  While  a  release  is  being  worked  on,  it  is  very  hard  if  not  impossible   to  start  another  release.  •  Planning  seems  to  take  too  long.  •  Changes  are  hard  to  introduce  mid-­‐release,  even  though  they   consLtute  35%  of  the  total  work.  •  Quality  is  deterioraLng.  •  There  have  more  and  more  arLfacts,  documentaLon,  and  process  •  Death  marches  are  hurLng  morale.  •  More  than  60%  of  the  funcLonality  is  rarely  or  never  used,  yet   unfilled  needs  and  commitments  conLnue  to  build  up  while  the   current  release  is  being  delivered.   Source:  Advanced  Development  Methods,  Inc.  29  March  2011   ©  ADM  1993-­‐2011  All  Rights  Reserved  v2.0   Slide  5  
    • TradiLonal  Development  Processes  Are  Not  Agile   Plan   Analyze   Design   Code   Test   Release  Waterfall!Plan for the entire project up-front, includingrequirements of all value. Nothing can beused until project is over. 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   6  
    • Scrum  Is  Just  TradiLonal  More  Quickly  Waterfall! Plan   Analyze   Design   Code   Test   Release  Scrum!Short, high valueiterations that The same work, but Analyze  deliver valuable, Design   processed differently Plan   Plan  opportunistic Code   Test   and on fewerpieces of Release   requirements.!functionality.!29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   7  
    • Scrum  Is  a  Tool  You  Use  To  Become  Agile  Scrum!Short, high valueiterations that Analyze  deliver valuable, Design   Scrum  Team   Plan   Plan  opportunistic Code   Test  pieces of Release   Work done by self-organizing,functionality.! cross-functional teams that are highly productive, creative, and build high quality product.!29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   8  
    • May  I  recommend  Scrum?  Scrum  (n):      (1)  framework  within  which  people  can  address  complex  problems,  and  producLvely  and  creaLvely  develop  products  of  the  highest  possible  value;  (2)A  tool  you  can  use  to  become  Agile!   Image  source:  codecentric.de  29  March  2011   ©  ADM  1993-­‐2011  All  Rights  Reserved  v2.0   Slide  9  
    • Agile  Overtakes  Waterfall   Waterfall % Agile % Source: December 2008 Global Agile Company Online Survey29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   10  
    • Improve  things  with  Scrum  Remove  waste   Improve  producLvity  •  Technical  debt   •  Collocated,  self-­‐•  Unnecessary   organizing  teams   documentaLon   •  Cross-­‐funcLonal  teams  •  Unnecessary   •  FTF  communicaLons   requirements   •  Improved  decision  •  Unused  requirements   making  •  Architecture  that  must   be  reworked  29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   11  
    • The  first  thing  that  Agility  requires  is  empiricism  Empirical (adjective) 1) Derived from or guided by experience or experiment. The  modesty  to  admit  that  you  don’t  know  all  the  answers,  and  that  is   okay.  The  best  soluLon  emerges  from  collaboraLon  with  the  team.  29  March  2011   ©  ADM  1993-­‐2011  All  Rights  Reserved  v2.0   Slide  12  
    • A  thermostat  for  soEware  development   5  MINS   Time   People   Event  Purpose:  Understand  the  power  of  empiricism   7:00  -­‐  8:00 5 Room  setupSitua<on:  You  are  in  charge  of  keeping  a  20  x   8:00  -­‐  9:00 50 Breakfast,  ConLnental  buffet   style,  Lyzure  Amalgamated40  room  in  this  building  at  a  constant  22C  temperature  through  the  day.    The  room  does  not   9:00-­‐  10:30 55 MeeLng  -­‐  Lyzure  have  a  thermostat.   Amalgamated 10:30-­‐  11:00 55 Coffee  breakAt  the  start  of  the  day,  8:00  am,  you  have  to  set  the  heaLng,  air  condiLoning,  venLng,  and  blinds  so  that   11:00-­‐  12:30 55 MeeLng  -­‐  Lyzure   Amalgamatedthey  will  adjust  themselves  at  the  appropriate  Lmes   12:30-­‐  1:00 5-­‐20 Setup  and  next  meeLng  to  maintain  this  temperature  throughout  the  day.   arriving 1:00-­‐  3:00 50 MeeLng  -­‐  Rexxus  Ltd.Ques<on:  What  variables  will  you  have  to  take   3:00-­‐  3:30 50 Coffee  breakinto  account  to  know  the  senngs?  (hint:  number  of  people  in  the  room  will  be  one  variable).   3:30-­‐  5:30 70 MeeLng  -­‐  Rexxus  Ltd.29  March  2011   ©  ADM  1993-­‐2011  All  Rights  Reserved  v2.0   Slide  13  
    • Controlling  temperature  isn’t  that  complex,  but   there  are  a  lot  of  things  to  plan  for!  Variables  might  include,  for  any  Lme  during  the  day:  •  number  of  people  in  room  •  metabolism  of  each  person  •  acLvity  of  each  person  •  opening/closing  of  doors  •  weather:  including  sun,  clouds,  and  outside  temperature  •  temperature  of  adjoining  rooms  •  construcLon  material  of  the  building  •  floor  of  the  room  •  will  food  be  served,  when,  what  type,  and  how  much  •  temperature  of  food  brought  into  room  29  March  2011   ©  ADM  1993-­‐2011  All  Rights  Reserved  v2.0   Slide  14  
    • Dimensions  Of  Complexity   Simple: Everything is known Complicated: More isPatternsWeather known than unknown Complex: More is unknown than is known Chaotic: Very little is known Building Construction Source:  Ralph  Stacey,  University  of  Herfordshire   29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   15  
    • Empirical  processes  adapt  to  the  future  •  Variables  are  ignored.   Actual  temperature  drives   senng  of  air  condiLoning,   heaLng,  blinds.    •  Frequent  inspecLon  &   adaptaLon  (JIT)  rather  than   predicLve  planning    •  Based  on  “actuals”  rather   than  predicLons  •  Requires  transparency  29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   16  
    • The  first  thing  empiricism  needs  is  transparency  Transparency (adjective) 1) Easily seen through, recognized, or understood. 2) All aspects are equally and commonly understood by all observers Most  organizaLons  struggle  with  transparency.  It  requires  trust,   courage  and  a  lot  of  collaboraLon.  29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   17  
    • Quality:  A  Developer’s  POV  •  I  can  readily  understand  the  soEware  and  where  &  how  things   happen;  •  When  I  change  or  add  to  part  of  the  soEware,  there  are  no  unintended   or  poorly  designed  dependencies;  •  I  can  read  the  code  without  looking  for  tricks  or  poorly  defined  and   labeled  variables  or  data;  •  I  don’t  need  the  person(s)  that  wrote  the  code  to  explain  it  to  me;  •  There  are  a  full  set  of  (automated)  tests  to  check  that  the  funcLon   works  as  expected;  •  When  I  change  something  and  add  to  the  tests,  I  can  check  that  the   enLre  change  and  product  conLnues  to  work;  •  How  things  work  and  hang  together  is  tranparent;  and,  •  Standard,  well-­‐known  design  principles  have  been  adhered  to.  29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   18  
    • Green  Field  SoEware   Product Backlog Velocity (done work over time) (work) Time29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   19  
    • Exercise  The  SituaLon:   The  Assignment:  •  You  are  a  developer  at  xyz  co,   •   What  work  would  you  have  to  do   building  life-­‐criLcal  products.     to  turn  the  requirements  into  a  •  Your  Scrum  team  is  one  of  seven   “done”  increment?   working  on  a  new  release  of  one   •   If  you  were  developing  a  “done”,   product.   potenLally  shippable  increment,  •  Your  team  is  going  to  select   what  would  your  definiLon  of   product  backlog  to  turn  into   “done”  be?  Would  it  include,  for   something  done  (no  more  work   example,  refactoring?  What  else?   remains,  potenLally  shippable)   within  a  two-­‐week  iteraLon.  •  Each  team  has  all  the  skills  to  fully   develop  the  requirements  into  a   “done  increment.”  29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   20  
    • Exercise  (Cont.)  Did  your  definiLon  of  “done”  include  these?  Why  not?  •   Performance  tesLng  •   Stability  tesLng  •   Refactoring  •   Immunological  response  tesLng  •   IntegraLon  with  the  work  of  the  other  six  teams  •   IntegraLon  tesLng  with  the  work  of  the  other  six  teams  so  the  increment   is  the  totality  of  all  seven  teams  •   Release  notes  •   InternaLonalizaLon  to  the  six  cultures  where  the  product  will  be  sold  •   User  acceptance  tesLng  •   Regression  tesLng  •   Code  reviews  29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   21  
    • StabilizaLon:  What  Undone  Gets  You   Plan   Plan   Develop   Plan   Develop   Plan   Develop   Stabilize   Plan   Plan   Develop   Plan   Develop   Plan   Develop   Stabilize   Undone   Undone   Undone  29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   22  
    • Case  Study:  TransCanada  Pipelines  •  After three Sprints, Product Owner was delighted. She wanted us to continue, but she wanted us to implement the first three increments so her department could start using them.•  We told her that she couldn’t. She asked why not. We said that we weren’t done. She said that it looked done. We said, yes, but not that type of done. She asked how long it would take to go from our type of done to the done that would be usable by her.•  Transparency was not present and trust was lost.29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   23  
    • StabilizaLon:  Plan  Vs.  Reality  Plan!9 Sprints, 3 release candidates and then release.!800-person development organization.!P D P D P D RC P D P D P D RC P D P D P D RC ReleaseActual!The release candidates were presentation of partially working functionality from thecode branch for each team. A five+ month stabilization was required prior to release.!“Inadequate performance” was a bug logged in the first Sprint.!P D P D P D RC P D P D P D RC P D P D P D RC Stabilization!Release 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   24  
    • Impact  Of  Integrated  “Done”  • 120 people, 18 teams!• Release 1: ! Planned! Release! •  Each team produced Date! “done” increments each Sprint, but they were not Release 1! integrated or integration tested until “code complete.”! # Defects!• Release 2: ! Release 2! •  All teams produced an increment of integrated, Time! integration tested code every Sprint. !29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   25  
    • New  Baseline  Of  “Undone”  Work   Actual  Baseline   Perceived Work + Undone Work Perceived  Baseline   Actual Work Actual WorkProduct PerceivedBacklog Work Undone Work Time 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   26  
    • Work Item Usual Rec. start Done Requirements analysis 25 25 25 Design of architectural components (UI, System, Data 15 15 15 Design review 0 5 5 Design of tests (system, user acceptance, integration) 0 10 10 Design review 0 3 3 Design of documentation 0 2 2 Design Review 0 1 1 Refactoring of existing design 0 0 8 Design of unit tests for new code 0 3 3 Design of unit tests for code to be refactored 0 3 3 Writing new code 10 7 7 Writing refactored code 6 3 3 Code review (or pair programming) 0 4 4 Write functional tests 8 4 4 Write integration tests 0 4 4 Write documentation 4 4 4 Unit test code 0 2 2 Identify and rectify defects 0 2 2 Subsystem/team build 6 2 2 Identify and rectify defects 1 1 1 Unit test for subsystem/team code 0 2 2 Identify and rectify defects 0 2 2 System/integration build 1 1 1 Identify and rectify defects 0 2 2 System, functional tests 1 2 2 Identify and rectify defects 1 2 4 Integration tests 0 0 2 Identify and rectify defects 0 0 5 Performance tests 0 0 1 Identify and rectify defects 0 0 2 Security tests 0 0 1 Identify and rectify defects 0 0 2 Regression test 0 2 2 Identify and rectify defects 0 8 8 Documentation test 0 1 2 Identify and rectify defects 0 1 1 Total work expended requirement 78 118 148 Work remaining per requirement 65 30 029  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   27  
    • SoEware  W/Low  Value  To  Developers   Core  FuncLonality   •  Most  significant  new   Core funcLonality  builds  on  it;   Functionality •  Also  called  infrastructure   and  legacy  soEware;   •  Is  fragile,  doesn’t  have  Product New complete  test  harnesses,  Backlog Functionality and  few  people  sLll  know   how  to  or  are  willing  to   touch  it;  and,   •  Requires  more  Lme  to  work   on;  velocity  working  on  it  is   Time less  than  new  work.   29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   28  
    • Gradual  Impact  Of  Reduced  Quality   NPQ - Normal Product Quality RPQ - Reduced Product Quality29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   29  
    • Reduced  Velocity  Puts  OrganizaLon  In  Corner   Release 10 5 6 7 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   30  
    • Exercise   •  Your  CEO  comes  to  your  development  group.  She  tells  you  it  is   mandatory  to  deliver  three  new  pieces  of  funcLonality  within  three   Sprints.  Otherwise,  compeLtors  will  decimate  the  company.   •  Planned  work  consists  of:   –  FuncLon  1:  20  units  of  work,  15  new,  5  core   –  FuncLon  2:  40  units  of  work,  25  new,  15  core   –  FuncLon  3:  30  units  of  work,  20  new,  10  core   •  Velocity  for  new  funcLonality  is  15  units  of  work  per  Sprint  per   team.   •  Velocity  for  core  funcLonality  is  5  units  of  work  per  Sprint  total.   •  You  need  a  release  with  all  three  funcLons  in  three  months.   •  Can  do  you  do?  Can  you  save  the  company?  29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   31  
    • How  Does  Design-­‐Dead  SoEware  Smell?   35   30   25   Maintenance  Cost   20   15   10   5   0   1   2   3   4   5   Release  29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   32  
    • Maintenance/Velocity/Features  CorrelaLon  29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   33  
    • 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   34  
    • Filling  In  Scrum’s  Holes   Successful   SoAware  Development   PSM   PSPO   (Professional   (Professional   Scrum  Master)   Scrum  Product   Owner)   PSD     (Professional   PSTM   Scrum   Developer)   (Professional  Scrum  Team   Member)  29  March  2011   ©  1993-­‐2011  ADM,  All  Rights  Reserved   Slide  35  
    • Professional  Scrum  Product  Owner  course  Agenda   •  Teaches Product•  Basics  of  Agility   Owner how to achieve•  Value  Driven   Agility. Development   •  Complete course•  Product  Management   rewrite.•  Plan  a  Release   •  For product managers,•  Managing  Requirements   program managers, and development•  Planning  Releases   managers.•  Managing  Releases   •  Assessments and•  Managing  Products   certification. 29  March  2011   ©  ADM  1993-­‐2011  All  Rights  Reserved  v2.0   Slide  36  
    • Next  Step  for  You!  When   Course  April   Professional  Scrum  Product  Owner  course  11-­‐12   taught  by  ken  Schwaber  in  Amsterdam  April  6-­‐7   Professional  Scrum  Master  course  taught  by   Ken  Schwaber  in  Brussels   Register        hvp://courses.scrum.org/   Visit                      hvp://www.scrum.org/    29  March  2011   ©  ADM  1993-­‐2011  All  Rights  Reserved  v2.0   Slide  37  
    • 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   38  
    • QuesLons?   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0  29  March  2011   39  
    • Thank  you!  Ken  Schwaber  •  ken.schwaber@scrum.org  •  www.scrum.org   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0  29  March  2011   40