SlideShare a Scribd company logo
1 of 40
Download to read offline
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, including
requirements of all value. Nothing can be
used 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 value
iterations that                                                                                 The same work, but
                                                  Analyze	
  
deliver valuable,                                 Design	
                                      processed differently
                                       Plan	
  
                                       Plan	
  




opportunistic                                      Code	
  
                                                   Test	
  
                                                                                                and on fewer
pieces 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 value
iterations 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 Survey


29	
  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	
  setup


Situa<on:	
  You	
  are	
  in	
  charge	
  of	
  keeping	
  a	
  20	
  x	
                               8:00	
  -­‐	
  9:00   50          Breakfast,	
  ConLnental	
  buffet	
  
                                                                                                                                           style,	
  Lyzure	
  Amalgamated
40	
  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	
  break
At	
  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	
  
                                                                                                                                           Amalgamated
they	
  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	
  break
into	
  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 is
Patterns
Weather




                                                                                 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)




                                                             Time




29	
  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                                                          Release



Actual!
The release candidates were presentation of partially working functionality from the
code 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 Work


Product                Perceived
Backlog
                         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           0




29	
  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 Quality


29	
  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	
  

More Related Content

What's hot

Beyond Scrum: Scaling Agile with Continuous Delivery and Subversion
Beyond Scrum: Scaling Agile with Continuous Delivery and SubversionBeyond Scrum: Scaling Agile with Continuous Delivery and Subversion
Beyond Scrum: Scaling Agile with Continuous Delivery and SubversionProduct Marketing Services
 
Selected Aspects of Software Development
Selected Aspects of Software DevelopmentSelected Aspects of Software Development
Selected Aspects of Software DevelopmentHaitham El-Ghareeb
 
Private Clouds for Developers: Make Your Infrastructure Agile
Private Clouds for Developers: Make Your Infrastructure AgilePrivate Clouds for Developers: Make Your Infrastructure Agile
Private Clouds for Developers: Make Your Infrastructure AgileAbiquo, Inc.
 
Scrum Introduction Vietnam
Scrum Introduction VietnamScrum Introduction Vietnam
Scrum Introduction VietnamAgile Vietnam
 
Passing internal and external audits with reporting and dashboards nov 2011
Passing internal and external audits with reporting and dashboards   nov 2011Passing internal and external audits with reporting and dashboards   nov 2011
Passing internal and external audits with reporting and dashboards nov 2011Scott Althouse
 
How to make_it_real-hayden_lindsey
How to make_it_real-hayden_lindseyHow to make_it_real-hayden_lindsey
How to make_it_real-hayden_lindseyIBM
 
Verteilte SoftwareEntwicklung 2011 - von klassischen Modellen bis Scrum und S...
Verteilte SoftwareEntwicklung 2011 - von klassischen Modellen bis Scrum und S...Verteilte SoftwareEntwicklung 2011 - von klassischen Modellen bis Scrum und S...
Verteilte SoftwareEntwicklung 2011 - von klassischen Modellen bis Scrum und S...Intland Software GmbH
 
110605=holy grail cmmi_scrum
110605=holy grail cmmi_scrum110605=holy grail cmmi_scrum
110605=holy grail cmmi_scrumIsabel Ferreira
 
Building Mobile (app) Masterpiece with Distributed Agile
Building Mobile (app) Masterpiece with Distributed AgileBuilding Mobile (app) Masterpiece with Distributed Agile
Building Mobile (app) Masterpiece with Distributed AgileWee Witthawaskul
 
EM overview- - Hayden lindsey
EM overview- - Hayden lindseyEM overview- - Hayden lindsey
EM overview- - Hayden lindseyRoopa Nadkarni
 
3 hang on_a_minute-ankur_goyal
3 hang on_a_minute-ankur_goyal3 hang on_a_minute-ankur_goyal
3 hang on_a_minute-ankur_goyalIBM
 
The Manager's Dilemma
The Manager's DilemmaThe Manager's Dilemma
The Manager's DilemmaOla Sundin
 
Flexibility in Software Development Methodologies: Needs and Benefits
Flexibility in Software Development Methodologies: Needs and BenefitsFlexibility in Software Development Methodologies: Needs and Benefits
Flexibility in Software Development Methodologies: Needs and BenefitsCognizant
 
Applying 'Kanban' in Enterprise-Class Products Sustaining Engineering - An Ex...
Applying 'Kanban' in Enterprise-Class Products Sustaining Engineering - An Ex...Applying 'Kanban' in Enterprise-Class Products Sustaining Engineering - An Ex...
Applying 'Kanban' in Enterprise-Class Products Sustaining Engineering - An Ex...Tathagat Varma
 
SAP BPM Jump Start to Value Package
SAP BPM Jump Start to Value PackageSAP BPM Jump Start to Value Package
SAP BPM Jump Start to Value PackageIncture Technologies
 

What's hot (19)

88908872 scrum
88908872 scrum88908872 scrum
88908872 scrum
 
Beyond manifestos
Beyond manifestosBeyond manifestos
Beyond manifestos
 
Beyond Scrum: Scaling Agile with Continuous Delivery and Subversion
Beyond Scrum: Scaling Agile with Continuous Delivery and SubversionBeyond Scrum: Scaling Agile with Continuous Delivery and Subversion
Beyond Scrum: Scaling Agile with Continuous Delivery and Subversion
 
Selected Aspects of Software Development
Selected Aspects of Software DevelopmentSelected Aspects of Software Development
Selected Aspects of Software Development
 
Lesson2 software process_contd2
Lesson2 software process_contd2Lesson2 software process_contd2
Lesson2 software process_contd2
 
Private Clouds for Developers: Make Your Infrastructure Agile
Private Clouds for Developers: Make Your Infrastructure AgilePrivate Clouds for Developers: Make Your Infrastructure Agile
Private Clouds for Developers: Make Your Infrastructure Agile
 
03 - Continuous Integration
03 - Continuous Integration03 - Continuous Integration
03 - Continuous Integration
 
Scrum Introduction Vietnam
Scrum Introduction VietnamScrum Introduction Vietnam
Scrum Introduction Vietnam
 
Passing internal and external audits with reporting and dashboards nov 2011
Passing internal and external audits with reporting and dashboards   nov 2011Passing internal and external audits with reporting and dashboards   nov 2011
Passing internal and external audits with reporting and dashboards nov 2011
 
How to make_it_real-hayden_lindsey
How to make_it_real-hayden_lindseyHow to make_it_real-hayden_lindsey
How to make_it_real-hayden_lindsey
 
Verteilte SoftwareEntwicklung 2011 - von klassischen Modellen bis Scrum und S...
Verteilte SoftwareEntwicklung 2011 - von klassischen Modellen bis Scrum und S...Verteilte SoftwareEntwicklung 2011 - von klassischen Modellen bis Scrum und S...
Verteilte SoftwareEntwicklung 2011 - von klassischen Modellen bis Scrum und S...
 
110605=holy grail cmmi_scrum
110605=holy grail cmmi_scrum110605=holy grail cmmi_scrum
110605=holy grail cmmi_scrum
 
Building Mobile (app) Masterpiece with Distributed Agile
Building Mobile (app) Masterpiece with Distributed AgileBuilding Mobile (app) Masterpiece with Distributed Agile
Building Mobile (app) Masterpiece with Distributed Agile
 
EM overview- - Hayden lindsey
EM overview- - Hayden lindseyEM overview- - Hayden lindsey
EM overview- - Hayden lindsey
 
3 hang on_a_minute-ankur_goyal
3 hang on_a_minute-ankur_goyal3 hang on_a_minute-ankur_goyal
3 hang on_a_minute-ankur_goyal
 
The Manager's Dilemma
The Manager's DilemmaThe Manager's Dilemma
The Manager's Dilemma
 
Flexibility in Software Development Methodologies: Needs and Benefits
Flexibility in Software Development Methodologies: Needs and BenefitsFlexibility in Software Development Methodologies: Needs and Benefits
Flexibility in Software Development Methodologies: Needs and Benefits
 
Applying 'Kanban' in Enterprise-Class Products Sustaining Engineering - An Ex...
Applying 'Kanban' in Enterprise-Class Products Sustaining Engineering - An Ex...Applying 'Kanban' in Enterprise-Class Products Sustaining Engineering - An Ex...
Applying 'Kanban' in Enterprise-Class Products Sustaining Engineering - An Ex...
 
SAP BPM Jump Start to Value Package
SAP BPM Jump Start to Value PackageSAP BPM Jump Start to Value Package
SAP BPM Jump Start to Value Package
 

Similar to Path to agility, Ken Schwaber

Towards Agile Scalability: From Component To Feature Teams
Towards Agile Scalability: From Component To Feature TeamsTowards Agile Scalability: From Component To Feature Teams
Towards Agile Scalability: From Component To Feature TeamsDmitriyViktorov
 
Lean & agile 101 for Astute Entrepreneurs
Lean & agile 101 for Astute EntrepreneursLean & agile 101 for Astute Entrepreneurs
Lean & agile 101 for Astute EntrepreneursClaudio Perrone
 
Microsoft ALM Platform Overview
Microsoft ALM Platform OverviewMicrosoft ALM Platform Overview
Microsoft ALM Platform OverviewSteve Lange
 
Top 7 Myths of Agile Testing - Busted!
Top 7 Myths of Agile Testing - Busted!Top 7 Myths of Agile Testing - Busted!
Top 7 Myths of Agile Testing - Busted!Aricent
 
Redistributable introtoscrum
Redistributable introtoscrumRedistributable introtoscrum
Redistributable introtoscrumCiklum Ukraine
 
Avantica presentacion scrum
Avantica presentacion scrumAvantica presentacion scrum
Avantica presentacion scrumJl Ballon V
 
Enterprise Dev Ops At Scale
Enterprise Dev Ops At ScaleEnterprise Dev Ops At Scale
Enterprise Dev Ops At ScaleWesley Pullen
 
Agile- To Infinity and Beyond
Agile- To Infinity and BeyondAgile- To Infinity and Beyond
Agile- To Infinity and BeyondInnoTech
 
Agile and Lean Software Development
Agile and Lean Software DevelopmentAgile and Lean Software Development
Agile and Lean Software DevelopmentTathagat Varma
 
Agile product development and management
Agile product development and managementAgile product development and management
Agile product development and managementAshwinee Kumar
 
Agileproductdevelopmentandmanagement 120420040535-phpapp02
Agileproductdevelopmentandmanagement 120420040535-phpapp02Agileproductdevelopmentandmanagement 120420040535-phpapp02
Agileproductdevelopmentandmanagement 120420040535-phpapp02Cognizant
 
Arena product presentation
Arena product presentationArena product presentation
Arena product presentationjhjsmits
 
From Waterfall to Agile - from predictive to adaptive methods
From Waterfall to Agile - from predictive to adaptive methodsFrom Waterfall to Agile - from predictive to adaptive methods
From Waterfall to Agile - from predictive to adaptive methodsBjörn Jónsson
 
Agile Estimation And Planning Part I
Agile Estimation And Planning Part IAgile Estimation And Planning Part I
Agile Estimation And Planning Part IKevin Zamora
 
Standardization and strategy in agile
Standardization and strategy in agileStandardization and strategy in agile
Standardization and strategy in agileNaveen Gupta
 
Going agile with scrum
Going agile with scrumGoing agile with scrum
Going agile with scrumMayur Sand
 
Collaborative Lifecycle Managmenent - an Introduction
Collaborative Lifecycle Managmenent - an IntroductionCollaborative Lifecycle Managmenent - an Introduction
Collaborative Lifecycle Managmenent - an IntroductionStrongback Consulting
 
Agile software development for startups
Agile software development for startupsAgile software development for startups
Agile software development for startupsHemant Elhence
 
Agile Fundamental Skill Set
Agile Fundamental Skill SetAgile Fundamental Skill Set
Agile Fundamental Skill SetTsuyoshi Ushio
 

Similar to Path to agility, Ken Schwaber (20)

Towards Agile Scalability: From Component To Feature Teams
Towards Agile Scalability: From Component To Feature TeamsTowards Agile Scalability: From Component To Feature Teams
Towards Agile Scalability: From Component To Feature Teams
 
Lean & agile 101 for Astute Entrepreneurs
Lean & agile 101 for Astute EntrepreneursLean & agile 101 for Astute Entrepreneurs
Lean & agile 101 for Astute Entrepreneurs
 
Microsoft ALM Platform Overview
Microsoft ALM Platform OverviewMicrosoft ALM Platform Overview
Microsoft ALM Platform Overview
 
Top 7 Myths of Agile Testing - Busted!
Top 7 Myths of Agile Testing - Busted!Top 7 Myths of Agile Testing - Busted!
Top 7 Myths of Agile Testing - Busted!
 
Redistributable introtoscrum
Redistributable introtoscrumRedistributable introtoscrum
Redistributable introtoscrum
 
Agile marries itil
Agile marries itilAgile marries itil
Agile marries itil
 
Avantica presentacion scrum
Avantica presentacion scrumAvantica presentacion scrum
Avantica presentacion scrum
 
Enterprise Dev Ops At Scale
Enterprise Dev Ops At ScaleEnterprise Dev Ops At Scale
Enterprise Dev Ops At Scale
 
Agile- To Infinity and Beyond
Agile- To Infinity and BeyondAgile- To Infinity and Beyond
Agile- To Infinity and Beyond
 
Agile and Lean Software Development
Agile and Lean Software DevelopmentAgile and Lean Software Development
Agile and Lean Software Development
 
Agile product development and management
Agile product development and managementAgile product development and management
Agile product development and management
 
Agileproductdevelopmentandmanagement 120420040535-phpapp02
Agileproductdevelopmentandmanagement 120420040535-phpapp02Agileproductdevelopmentandmanagement 120420040535-phpapp02
Agileproductdevelopmentandmanagement 120420040535-phpapp02
 
Arena product presentation
Arena product presentationArena product presentation
Arena product presentation
 
From Waterfall to Agile - from predictive to adaptive methods
From Waterfall to Agile - from predictive to adaptive methodsFrom Waterfall to Agile - from predictive to adaptive methods
From Waterfall to Agile - from predictive to adaptive methods
 
Agile Estimation And Planning Part I
Agile Estimation And Planning Part IAgile Estimation And Planning Part I
Agile Estimation And Planning Part I
 
Standardization and strategy in agile
Standardization and strategy in agileStandardization and strategy in agile
Standardization and strategy in agile
 
Going agile with scrum
Going agile with scrumGoing agile with scrum
Going agile with scrum
 
Collaborative Lifecycle Managmenent - an Introduction
Collaborative Lifecycle Managmenent - an IntroductionCollaborative Lifecycle Managmenent - an Introduction
Collaborative Lifecycle Managmenent - an Introduction
 
Agile software development for startups
Agile software development for startupsAgile software development for startups
Agile software development for startups
 
Agile Fundamental Skill Set
Agile Fundamental Skill SetAgile Fundamental Skill Set
Agile Fundamental Skill Set
 

More from Xavier Warzee

SOS TITANIC - Be a highly performant team to save your life!
SOS TITANIC - Be a highly performant team to save your life!SOS TITANIC - Be a highly performant team to save your life!
SOS TITANIC - Be a highly performant team to save your life!Xavier Warzee
 
Le Management à l'ère des organisations Agiles
Le Management à l'ère des organisations AgilesLe Management à l'ère des organisations Agiles
Le Management à l'ère des organisations AgilesXavier Warzee
 
Be very efficient and innovative thanks to disorder!
Be very efficient and innovative thanks to disorder!Be very efficient and innovative thanks to disorder!
Be very efficient and innovative thanks to disorder!Xavier Warzee
 
L'Agilité - breakfast IDC devops, 18 septembre 2014
L'Agilité  - breakfast IDC devops, 18 septembre 2014L'Agilité  - breakfast IDC devops, 18 septembre 2014
L'Agilité - breakfast IDC devops, 18 septembre 2014Xavier Warzee
 
Advanced infrastructure for pan european collaborative engineering - E-colleg
Advanced infrastructure for pan european collaborative engineering - E-collegAdvanced infrastructure for pan european collaborative engineering - E-colleg
Advanced infrastructure for pan european collaborative engineering - E-collegXavier Warzee
 
Retour expérience Agilité & Données fonction finances risques - Agile Tour ...
Retour expérience Agilité & Données fonction finances risques - Agile Tour ...Retour expérience Agilité & Données fonction finances risques - Agile Tour ...
Retour expérience Agilité & Données fonction finances risques - Agile Tour ...Xavier Warzee
 
Atelier "SOS du Titanic, perdu dans l'Atlantique" - leadership des talents
Atelier "SOS du Titanic, perdu dans l'Atlantique" - leadership des talentsAtelier "SOS du Titanic, perdu dans l'Atlantique" - leadership des talents
Atelier "SOS du Titanic, perdu dans l'Atlantique" - leadership des talentsXavier Warzee
 
Faciliter une transformation agile avec les Innovation Games dans une banque ...
Faciliter une transformation agile avec les Innovation Games dans une banque ...Faciliter une transformation agile avec les Innovation Games dans une banque ...
Faciliter une transformation agile avec les Innovation Games dans une banque ...Xavier Warzee
 
Innovation games + agile in retail banking
Innovation games + agile in retail bankingInnovation games + agile in retail banking
Innovation games + agile in retail bankingXavier Warzee
 
Scrum day 2013 sponsoring package
Scrum day 2013 sponsoring packageScrum day 2013 sponsoring package
Scrum day 2013 sponsoring packageXavier Warzee
 
Annonces du french scrum user group v1.2
Annonces du french scrum user group   v1.2Annonces du french scrum user group   v1.2
Annonces du french scrum user group v1.2Xavier Warzee
 
Annonces du french scrum user group - rencontre du 24 juin 2011
Annonces du french scrum user group - rencontre du 24 juin 2011Annonces du french scrum user group - rencontre du 24 juin 2011
Annonces du french scrum user group - rencontre du 24 juin 2011Xavier Warzee
 
Journées NEPTUNE - Keynote Modélisation chez Microsoft
Journées NEPTUNE - Keynote Modélisation chez MicrosoftJournées NEPTUNE - Keynote Modélisation chez Microsoft
Journées NEPTUNE - Keynote Modélisation chez MicrosoftXavier Warzee
 
Enquête 2011 - Vous, votre organisation et Agile
Enquête 2011 - Vous, votre organisation et Agile Enquête 2011 - Vous, votre organisation et Agile
Enquête 2011 - Vous, votre organisation et Agile Xavier Warzee
 
Scrum Day France 2011 : ouverture avec Xavier Warzee
Scrum Day France 2011 : ouverture avec Xavier WarzeeScrum Day France 2011 : ouverture avec Xavier Warzee
Scrum Day France 2011 : ouverture avec Xavier WarzeeXavier Warzee
 
Embedding a Scrum culture avec Harvey Wheaton, Scrum Alliance
Embedding a Scrum culture avec Harvey Wheaton, Scrum AllianceEmbedding a Scrum culture avec Harvey Wheaton, Scrum Alliance
Embedding a Scrum culture avec Harvey Wheaton, Scrum AllianceXavier Warzee
 
Bilan 2010-2011 du FSUG
Bilan 2010-2011 du FSUGBilan 2010-2011 du FSUG
Bilan 2010-2011 du FSUGXavier Warzee
 
Quand mon produit est un système d information
Quand mon produit est un système d informationQuand mon produit est un système d information
Quand mon produit est un système d informationXavier Warzee
 
Un format dynamique de rétrospective, Jean-Charles Meyrignac
Un format dynamique de rétrospective, Jean-Charles Meyrignac Un format dynamique de rétrospective, Jean-Charles Meyrignac
Un format dynamique de rétrospective, Jean-Charles Meyrignac Xavier Warzee
 
Le Product Owner proxy, Bertrand Dour
Le Product Owner proxy, Bertrand DourLe Product Owner proxy, Bertrand Dour
Le Product Owner proxy, Bertrand DourXavier Warzee
 

More from Xavier Warzee (20)

SOS TITANIC - Be a highly performant team to save your life!
SOS TITANIC - Be a highly performant team to save your life!SOS TITANIC - Be a highly performant team to save your life!
SOS TITANIC - Be a highly performant team to save your life!
 
Le Management à l'ère des organisations Agiles
Le Management à l'ère des organisations AgilesLe Management à l'ère des organisations Agiles
Le Management à l'ère des organisations Agiles
 
Be very efficient and innovative thanks to disorder!
Be very efficient and innovative thanks to disorder!Be very efficient and innovative thanks to disorder!
Be very efficient and innovative thanks to disorder!
 
L'Agilité - breakfast IDC devops, 18 septembre 2014
L'Agilité  - breakfast IDC devops, 18 septembre 2014L'Agilité  - breakfast IDC devops, 18 septembre 2014
L'Agilité - breakfast IDC devops, 18 septembre 2014
 
Advanced infrastructure for pan european collaborative engineering - E-colleg
Advanced infrastructure for pan european collaborative engineering - E-collegAdvanced infrastructure for pan european collaborative engineering - E-colleg
Advanced infrastructure for pan european collaborative engineering - E-colleg
 
Retour expérience Agilité & Données fonction finances risques - Agile Tour ...
Retour expérience Agilité & Données fonction finances risques - Agile Tour ...Retour expérience Agilité & Données fonction finances risques - Agile Tour ...
Retour expérience Agilité & Données fonction finances risques - Agile Tour ...
 
Atelier "SOS du Titanic, perdu dans l'Atlantique" - leadership des talents
Atelier "SOS du Titanic, perdu dans l'Atlantique" - leadership des talentsAtelier "SOS du Titanic, perdu dans l'Atlantique" - leadership des talents
Atelier "SOS du Titanic, perdu dans l'Atlantique" - leadership des talents
 
Faciliter une transformation agile avec les Innovation Games dans une banque ...
Faciliter une transformation agile avec les Innovation Games dans une banque ...Faciliter une transformation agile avec les Innovation Games dans une banque ...
Faciliter une transformation agile avec les Innovation Games dans une banque ...
 
Innovation games + agile in retail banking
Innovation games + agile in retail bankingInnovation games + agile in retail banking
Innovation games + agile in retail banking
 
Scrum day 2013 sponsoring package
Scrum day 2013 sponsoring packageScrum day 2013 sponsoring package
Scrum day 2013 sponsoring package
 
Annonces du french scrum user group v1.2
Annonces du french scrum user group   v1.2Annonces du french scrum user group   v1.2
Annonces du french scrum user group v1.2
 
Annonces du french scrum user group - rencontre du 24 juin 2011
Annonces du french scrum user group - rencontre du 24 juin 2011Annonces du french scrum user group - rencontre du 24 juin 2011
Annonces du french scrum user group - rencontre du 24 juin 2011
 
Journées NEPTUNE - Keynote Modélisation chez Microsoft
Journées NEPTUNE - Keynote Modélisation chez MicrosoftJournées NEPTUNE - Keynote Modélisation chez Microsoft
Journées NEPTUNE - Keynote Modélisation chez Microsoft
 
Enquête 2011 - Vous, votre organisation et Agile
Enquête 2011 - Vous, votre organisation et Agile Enquête 2011 - Vous, votre organisation et Agile
Enquête 2011 - Vous, votre organisation et Agile
 
Scrum Day France 2011 : ouverture avec Xavier Warzee
Scrum Day France 2011 : ouverture avec Xavier WarzeeScrum Day France 2011 : ouverture avec Xavier Warzee
Scrum Day France 2011 : ouverture avec Xavier Warzee
 
Embedding a Scrum culture avec Harvey Wheaton, Scrum Alliance
Embedding a Scrum culture avec Harvey Wheaton, Scrum AllianceEmbedding a Scrum culture avec Harvey Wheaton, Scrum Alliance
Embedding a Scrum culture avec Harvey Wheaton, Scrum Alliance
 
Bilan 2010-2011 du FSUG
Bilan 2010-2011 du FSUGBilan 2010-2011 du FSUG
Bilan 2010-2011 du FSUG
 
Quand mon produit est un système d information
Quand mon produit est un système d informationQuand mon produit est un système d information
Quand mon produit est un système d information
 
Un format dynamique de rétrospective, Jean-Charles Meyrignac
Un format dynamique de rétrospective, Jean-Charles Meyrignac Un format dynamique de rétrospective, Jean-Charles Meyrignac
Un format dynamique de rétrospective, Jean-Charles Meyrignac
 
Le Product Owner proxy, Bertrand Dour
Le Product Owner proxy, Bertrand DourLe Product Owner proxy, Bertrand Dour
Le Product Owner proxy, Bertrand Dour
 

Recently uploaded

Design and Development of a Provenance Capture Platform for Data Science
Design and Development of a Provenance Capture Platform for Data ScienceDesign and Development of a Provenance Capture Platform for Data Science
Design and Development of a Provenance Capture Platform for Data SciencePaolo Missier
 
Frisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdf
Frisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdfFrisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdf
Frisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdfAnubhavMangla3
 
Event-Driven Architecture Masterclass: Engineering a Robust, High-performance...
Event-Driven Architecture Masterclass: Engineering a Robust, High-performance...Event-Driven Architecture Masterclass: Engineering a Robust, High-performance...
Event-Driven Architecture Masterclass: Engineering a Robust, High-performance...ScyllaDB
 
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)Paige Cruz
 
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptxHarnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptxFIDO Alliance
 
2024 May Patch Tuesday
2024 May Patch Tuesday2024 May Patch Tuesday
2024 May Patch TuesdayIvanti
 
Six Myths about Ontologies: The Basics of Formal Ontology
Six Myths about Ontologies: The Basics of Formal OntologySix Myths about Ontologies: The Basics of Formal Ontology
Six Myths about Ontologies: The Basics of Formal Ontologyjohnbeverley2021
 
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...ScyllaDB
 
Intro to Passkeys and the State of Passwordless.pptx
Intro to Passkeys and the State of Passwordless.pptxIntro to Passkeys and the State of Passwordless.pptx
Intro to Passkeys and the State of Passwordless.pptxFIDO Alliance
 
CORS (Kitworks Team Study 양다윗 발표자료 240510)
CORS (Kitworks Team Study 양다윗 발표자료 240510)CORS (Kitworks Team Study 양다윗 발표자료 240510)
CORS (Kitworks Team Study 양다윗 발표자료 240510)Wonjun Hwang
 
الأمن السيبراني - ما لا يسع للمستخدم جهله
الأمن السيبراني - ما لا يسع للمستخدم جهلهالأمن السيبراني - ما لا يسع للمستخدم جهله
الأمن السيبراني - ما لا يسع للمستخدم جهلهMohamed Sweelam
 
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...TrustArc
 
JavaScript Usage Statistics 2024 - The Ultimate Guide
JavaScript Usage Statistics 2024 - The Ultimate GuideJavaScript Usage Statistics 2024 - The Ultimate Guide
JavaScript Usage Statistics 2024 - The Ultimate GuidePixlogix Infotech
 
Portal Kombat : extension du réseau de propagande russe
Portal Kombat : extension du réseau de propagande russePortal Kombat : extension du réseau de propagande russe
Portal Kombat : extension du réseau de propagande russe中 央社
 
Event-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream ProcessingEvent-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream ProcessingScyllaDB
 
State of the Smart Building Startup Landscape 2024!
State of the Smart Building Startup Landscape 2024!State of the Smart Building Startup Landscape 2024!
State of the Smart Building Startup Landscape 2024!Memoori
 
Oauth 2.0 Introduction and Flows with MuleSoft
Oauth 2.0 Introduction and Flows with MuleSoftOauth 2.0 Introduction and Flows with MuleSoft
Oauth 2.0 Introduction and Flows with MuleSoftshyamraj55
 
TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...
TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...
TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...marcuskenyatta275
 
Microsoft CSP Briefing Pre-Engagement - Questionnaire
Microsoft CSP Briefing Pre-Engagement - QuestionnaireMicrosoft CSP Briefing Pre-Engagement - Questionnaire
Microsoft CSP Briefing Pre-Engagement - QuestionnaireExakis Nelite
 
ChatGPT and Beyond - Elevating DevOps Productivity
ChatGPT and Beyond - Elevating DevOps ProductivityChatGPT and Beyond - Elevating DevOps Productivity
ChatGPT and Beyond - Elevating DevOps ProductivityVictorSzoltysek
 

Recently uploaded (20)

Design and Development of a Provenance Capture Platform for Data Science
Design and Development of a Provenance Capture Platform for Data ScienceDesign and Development of a Provenance Capture Platform for Data Science
Design and Development of a Provenance Capture Platform for Data Science
 
Frisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdf
Frisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdfFrisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdf
Frisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdf
 
Event-Driven Architecture Masterclass: Engineering a Robust, High-performance...
Event-Driven Architecture Masterclass: Engineering a Robust, High-performance...Event-Driven Architecture Masterclass: Engineering a Robust, High-performance...
Event-Driven Architecture Masterclass: Engineering a Robust, High-performance...
 
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
 
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptxHarnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
 
2024 May Patch Tuesday
2024 May Patch Tuesday2024 May Patch Tuesday
2024 May Patch Tuesday
 
Six Myths about Ontologies: The Basics of Formal Ontology
Six Myths about Ontologies: The Basics of Formal OntologySix Myths about Ontologies: The Basics of Formal Ontology
Six Myths about Ontologies: The Basics of Formal Ontology
 
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
 
Intro to Passkeys and the State of Passwordless.pptx
Intro to Passkeys and the State of Passwordless.pptxIntro to Passkeys and the State of Passwordless.pptx
Intro to Passkeys and the State of Passwordless.pptx
 
CORS (Kitworks Team Study 양다윗 발표자료 240510)
CORS (Kitworks Team Study 양다윗 발표자료 240510)CORS (Kitworks Team Study 양다윗 발표자료 240510)
CORS (Kitworks Team Study 양다윗 발표자료 240510)
 
الأمن السيبراني - ما لا يسع للمستخدم جهله
الأمن السيبراني - ما لا يسع للمستخدم جهلهالأمن السيبراني - ما لا يسع للمستخدم جهله
الأمن السيبراني - ما لا يسع للمستخدم جهله
 
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
 
JavaScript Usage Statistics 2024 - The Ultimate Guide
JavaScript Usage Statistics 2024 - The Ultimate GuideJavaScript Usage Statistics 2024 - The Ultimate Guide
JavaScript Usage Statistics 2024 - The Ultimate Guide
 
Portal Kombat : extension du réseau de propagande russe
Portal Kombat : extension du réseau de propagande russePortal Kombat : extension du réseau de propagande russe
Portal Kombat : extension du réseau de propagande russe
 
Event-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream ProcessingEvent-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream Processing
 
State of the Smart Building Startup Landscape 2024!
State of the Smart Building Startup Landscape 2024!State of the Smart Building Startup Landscape 2024!
State of the Smart Building Startup Landscape 2024!
 
Oauth 2.0 Introduction and Flows with MuleSoft
Oauth 2.0 Introduction and Flows with MuleSoftOauth 2.0 Introduction and Flows with MuleSoft
Oauth 2.0 Introduction and Flows with MuleSoft
 
TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...
TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...
TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...
 
Microsoft CSP Briefing Pre-Engagement - Questionnaire
Microsoft CSP Briefing Pre-Engagement - QuestionnaireMicrosoft CSP Briefing Pre-Engagement - Questionnaire
Microsoft CSP Briefing Pre-Engagement - Questionnaire
 
ChatGPT and Beyond - Elevating DevOps Productivity
ChatGPT and Beyond - Elevating DevOps ProductivityChatGPT and Beyond - Elevating DevOps Productivity
ChatGPT and Beyond - Elevating DevOps Productivity
 

Path to agility, Ken Schwaber

  • 1. Scrum! for
 Paris User Group! 1  
  • 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. 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. 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. 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. TradiLonal  Development  Processes  Are  Not  Agile   Plan   Analyze   Design   Code   Test   Release   Waterfall! Plan for the entire project up-front, including requirements of all value. Nothing can be used until project is over. 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   6  
  • 7. Scrum  Is  Just  TradiLonal  More  Quickly   Waterfall! Plan   Analyze   Design   Code   Test   Release   Scrum! Short, high value iterations that The same work, but Analyze   deliver valuable, Design   processed differently Plan   Plan   opportunistic Code   Test   and on fewer pieces of Release   requirements.! functionality.! 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   7  
  • 8. Scrum  Is  a  Tool  You  Use  To  Become  Agile   Scrum! Short, high value iterations 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. 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. Agile  Overtakes  Waterfall   Waterfall % Agile % Source: December 2008 Global Agile Company Online Survey 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   10  
  • 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. 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. A  thermostat  for  soEware  development   5  MINS   Time   People   Event   Purpose:  Understand  the  power  of  empiricism   7:00  -­‐  8:00 5 Room  setup Situa<on:  You  are  in  charge  of  keeping  a  20  x   8:00  -­‐  9:00 50 Breakfast,  ConLnental  buffet   style,  Lyzure  Amalgamated 40  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  break At  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   Amalgamated they  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  break into  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. 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. Dimensions  Of  Complexity   Simple: Everything is known Complicated: More is Patterns Weather 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. 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. 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. 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. Green  Field  SoEware   Product Backlog Velocity (done work over time) (work) Time 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   19  
  • 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. 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. 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. 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. 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 Release Actual! The release candidates were presentation of partially working functionality from the code 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. 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. New  Baseline  Of  “Undone”  Work   Actual  Baseline   Perceived Work + Undone Work Perceived  Baseline   Actual Work Actual Work Product Perceived Backlog Work Undone Work Time 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   26  
  • 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 0 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   27  
  • 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. Gradual  Impact  Of  Reduced  Quality   NPQ - Normal Product Quality RPQ - Reduced Product Quality 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   29  
  • 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. 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. 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. Maintenance/Velocity/Features  CorrelaLon   29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   33  
  • 34. 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   34  
  • 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. 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. 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. 29  March  2011   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   38  
  • 39. QuesLons?   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   29  March  2011   39  
  • 40. Thank  you!   Ken  Schwaber   •  ken.schwaber@scrum.org   •  www.scrum.org   ©  ADM  1983-­‐2010  All  Rights  Reserved  v2.0   29  March  2011   40