Scrum! for
  Paris User Group!                      1	  
Agility	  (a·∙gil·∙i·∙ty)	  –noun	  1. flexibility, the capacity and capability of    rapidly and efficiently adapting to ...
Why	  is	  Agility	  important?	                                                                          •  More	  global...
What	  are	  some	  specific	  reasons	  to	  “be	  Agile?”	  •       Improved	  relaLonship	  with	  customers,	  regainin...
But,	  many	  organizaLons	  instead	  have	  …	  •       Releases	  take	  longer	  and	  longer.	  •       Release	  sch...
TradiLonal	  Development	  Processes	  Are	  Not	  Agile	                              Plan	            Analyze	   Design	...
Scrum	  Is	  Just	  TradiLonal	  More	  Quickly	  Waterfall!                                              Plan	           ...
Scrum	  Is	  a	  Tool	  You	  Use	  To	  Become	  Agile	  Scrum!Short, high valueiterations that                          ...
May	  I	  recommend	  Scrum?	  Scrum	  (n):	  	  	  (1)	  framework	  within	  which	  people	  can	  address	  complex	  ...
Agile	  Overtakes	  Waterfall	                                      Waterfall %                          Agile %          ...
Improve	  things	  with	  Scrum	  Remove	  waste	                                                   Improve	  producLvity	...
The	  first	  thing	  that	  Agility	  requires	  is	  empiricism	  Empirical (adjective) 1) Derived from or guided by expe...
A	  thermostat	  for	  soEware	  development	                                                                             ...
Controlling	  temperature	  isn’t	  that	  complex,	  but	        there	  are	  a	  lot	  of	  things	  to	  plan	  for!	 ...
Dimensions	  Of	  Complexity	                                                                                  Simple: Eve...
Empirical	  processes	  adapt	  to	  the	  future	  •  Variables	  are	  ignored.	     Actual	  temperature	  drives	     ...
The	  first	  thing	  empiricism	  needs	  is	  transparency	  Transparency (adjective) 1) Easily seen through, recognized,...
Quality:	  A	  Developer’s	  POV	  •  I	  can	  readily	  understand	  the	  soEware	  and	  where	  &	  how	  things	    ...
Green	  Field	  SoEware	                            Product                          Backlog                              ...
Exercise	  The	  SituaLon:	                                                             The	  Assignment:	  •  You	  are	 ...
Exercise	  (Cont.)	  Did	  your	  definiLon	  of	  “done”	  include	  these?	  Why	  not?	  •       	  Performance	  tesLng...
StabilizaLon:	  What	  Undone	  Gets	  You	           Plan	            Plan	       Develop	                Plan	          ...
Case	  Study:	  TransCanada	  Pipelines	  •  After three Sprints, Product Owner was delighted.   She wanted us to continue...
StabilizaLon:	  Plan	  Vs.	  Reality	  Plan!9 Sprints, 3 release candidates and then release.!800-person development organ...
Impact	  Of	  Integrated	  “Done”	  • 120 people, 18 teams!• Release 1: !                                                 ...
New	  Baseline	  Of	  “Undone”	  Work	      Actual	  Baseline	                                                            ...
Work Item                                                                                             Usual               ...
SoEware	  W/Low	  Value	  To	  Developers	                                                                            Core...
Gradual	  Impact	  Of	  Reduced	  Quality	                            NPQ - Normal Product Quality                        ...
Reduced	  Velocity	  Puts	  OrganizaLon	  In	  Corner	                                          Release 10                ...
Exercise	   •  Your	  CEO	  comes	  to	  your	  development	  group.	  She	  tells	  you	  it	  is	      mandatory	  to	  ...
How	  Does	  Design-­‐Dead	  SoEware	  Smell?	                                         35	                                ...
Maintenance/Velocity/Features	  CorrelaLon	  29	  March	  2011	     ©	  ADM	  1983-­‐2010	  All	  Rights	  Reserved	  v2.0...
29	  March	  2011	     ©	  ADM	  1983-­‐2010	  All	  Rights	  Reserved	  v2.0	     34	  
Filling	  In	  Scrum’s	  Holes	                                                 Successful	                               ...
Professional	  Scrum	  Product	  Owner	  course	  Agenda	                                                          •  Teac...
Next	  Step	  for	  You!	  When	                        Course	  April	                       Professional	  Scrum	  Produ...
29	  March	  2011	     ©	  ADM	  1983-­‐2010	  All	  Rights	  Reserved	  v2.0	     38	  
QuesLons?	                            ©	  ADM	  1983-­‐2010	  All	  Rights	  Reserved	  v2.0	  29	  March	  2011	         ...
Thank	  you!	  Ken	  Schwaber	  •  ken.schwaber@scrum.org	  •  www.scrum.org	                            ©	  ADM	  1983-­‐...
Upcoming SlideShare
Loading in...5
×

Path to agility, Ken Schwaber

2,094

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,094
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
50
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Path to agility, Ken Schwaber

  1. 1. Scrum! for
 Paris User Group! 1  
  2. 2. 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  
  3. 3. 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  
  4. 4. 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  
  5. 5. 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  
  6. 6. 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  
  7. 7. 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  
  8. 8. 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  
  9. 9. 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  
  10. 10. Agile  Overtakes  Waterfall   Waterfall % Agile % Source: December 2008 Global Agile Company Online Survey29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   10  
  11. 11. 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  
  12. 12. 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  
  13. 13. 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  
  14. 14. 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  
  15. 15. 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  
  16. 16. 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  
  17. 17. 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  
  18. 18. 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  
  19. 19. Green  Field  SoEware   Product Backlog Velocity (done work over time) (work) Time29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   19  
  20. 20. 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  
  21. 21. 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  
  22. 22. 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  
  23. 23. 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  
  24. 24. 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  
  25. 25. 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  
  26. 26. 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  
  27. 27. 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  
  28. 28. 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  
  29. 29. Gradual  Impact  Of  Reduced  Quality   NPQ - Normal Product Quality RPQ - Reduced Product Quality29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   29  
  30. 30. Reduced  Velocity  Puts  OrganizaLon  In  Corner   Release 10 5 6 7 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   30  
  31. 31. 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  
  32. 32. 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  
  33. 33. Maintenance/Velocity/Features  CorrelaLon  29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   33  
  34. 34. 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   34  
  35. 35. 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  
  36. 36. 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  
  37. 37. 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  
  38. 38. 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   38  
  39. 39. QuesLons?   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0  29  March  2011   39  
  40. 40. Thank  you!  Ken  Schwaber  •  ken.schwaber@scrum.org  •  www.scrum.org   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0  29  March  2011   40  
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×