Skip to main content
Dollars	
  and	
  Dates	
  Are	
  Killing	
  Agile




Wednesday, November 2, 2011
Chris	
  Sterling
           Co-­‐founder	
  of	
  Agile	
  Advantage	
  and	
  
           VP	
  of	
  Engineering	
  (www.AgileAdvantage.com)	
  
           Author	
  of	
  Book	
  “Managing	
  SoBware	
  
           Debt:	
  Building	
  for	
  Inevitable	
  Change”
           Consults	
  on	
  soBware	
  technology,	
  
           Agile	
  technical	
  pracKces,	
  Scrum,	
  and	
  
           effecKve	
  management	
  techniques
           CerKfied	
  Scrum	
  Trainer
           InnovaKon	
  Games®	
  Trained	
                          Email:	
  chris@sterlingbarton.com	
  
                                                                     Web:	
  hWp://www.agileadvantage.com
           Facilitator                                               Blog:	
  hWp://www.geYngagile.com
                                                                     Follow	
  me	
  on	
  TwiWer:	
  @csterwa
           Open	
  Source	
  Developer


                                                                                                           2
Wednesday, November 2, 2011
Agenda
               Business	
  Value	
  and	
  Agility
             • How	
  AdapKve	
  Planning	
  Stresses	
  Strategic	
  Planning
               Balancing	
  Signal	
  to	
  Noise	
  at	
  Scale
               The	
  Agile	
  Business	
  Roadmap
             • Year	
  1:	
  Reduce	
  Carryover
             • Year	
  2:	
  OpKmize	
  Por_olio
             • Year	
  3:	
  Incremental	
  Funding
             • What	
  we	
  can	
  do	
  to	
  help	
  all	
  along	
  the	
  way
               Ques:ons	
  &	
  Answers

                                                                                     3
Wednesday, November 2, 2011
Value
Wednesday, November 2, 2011
What	
  is	
  Value?




                              5
Wednesday, November 2, 2011
What	
  is	
  Value?




                              5
Wednesday, November 2, 2011
Agile
Wednesday, November 2, 2011
Wednesday, November 2, 2011
Value




                              Agile
Wednesday, November 2, 2011
Value

                                   What’s
                              In-­‐Between?

                                 Agile
Wednesday, November 2, 2011
Wednesday, November 2, 2011
Value
                              Demand




Wednesday, November 2, 2011
Value
                                      Demand

                              Rhythm	
  of	
  the	
  Business




Wednesday, November 2, 2011
Value
                                             Demand

                                  Rhythm	
  of	
  the	
  Business
                                                    Human	
  
                              CFO                   Resources
                              Cost	
  Constraints
                                                    People	
  Constraints




Wednesday, November 2, 2011
Value
                                             Demand

                                  Rhythm	
  of	
  the	
  Business
                                                    Human	
  
                              CFO                   Resources
                              Cost	
  Constraints
                                                    People	
  Constraints

                              PorEolio/Budget
Wednesday, November 2, 2011
Wednesday, November 2, 2011
Value
                              Demand
                         PorEolio/Budget



Wednesday, November 2, 2011
Value
                              Demand
                         PorEolio/Budget


                              Agile
Wednesday, November 2, 2011
Value
                              Demand
                         PorEolio/Budget
                              Perfec&on	
  
                              Goes	
  Here


                              Agile
Wednesday, November 2, 2011
10
Wednesday, November 2, 2011
?
                                  10
Wednesday, November 2, 2011
Conclusion:
                          AdapKve	
  Planning	
  Stresses	
  
                          Strategic	
  Planning
                          (Fine	
  Print:	
  **	
  Except	
  in	
  cases	
  of	
  PerfecKon	
  **)




                                                                                                     10
Wednesday, November 2, 2011
Typical	
  Outcomes
            Business	
  can’t	
  take	
  advantage	
  of	
  Adap:ve	
  
           Planning	
  methods
            It	
  is	
  decided	
  that	
  Agile	
  can’t	
  scale
            Subop:mal	
  results
            Restarted	
  several	
  :mes




                                                                          11
Wednesday, November 2, 2011
Balancing	
  Signal	
  to	
  Noise	
  at	
  Scale




Wednesday, November 2, 2011
Balancing	
  Signal	
  Indicators	
  

                                   Value




                 Quality                                    Constraints
                              Source:	
  Jim	
  Highsmith   (Schedule,	
  Cost,	
  Scope)




                                                                                            13
Wednesday, November 2, 2011
The	
  Agile	
  Business	
  Roadmap




Wednesday, November 2, 2011
Agile	
  Business	
  Roadmap
        Year 1:	
  Reduce carryover
               Iden:fy	
  issues	
  sooner
               Make	
  decisions	
  earlier
               Demonstrate	
  progress	
  frequently
               Focus	
  on	
  quality




                                                       15
Wednesday, November 2, 2011
PaMerns	
  for	
  Scaling	
  Agile	
  delivery




Wednesday, November 2, 2011
Component	
  Teams

                               “Component	
  Team”	
  structure
                               Separate	
  Product	
  Backlog
                               Managing	
  dependencies	
  is	
  oBen	
  
                              serialized
                               ProblemaKc	
  integraKon	
  issues	
  are	
  
                              typically	
  faced	
  if	
  mulKple	
  
                              components	
  are	
  required	
  to	
  release
                               Use	
  an	
  “IntegraKon	
  Team”	
  to	
  pull	
  
                              components	
  together
                               Causes	
  more	
  rework	
  than	
  “Feature	
  
                              Team”	
  structure



                                                                             17
Wednesday, November 2, 2011
Feature	
  Teams
                               “Feature	
  Team”	
  structure
                               Uses	
  common	
  Product	
  Backlog
                               IntegraKon	
  is	
  done	
  in	
  parallel
                               Requires	
  high	
  levels	
  of	
  
                              communicaKon	
  across	
  teams	
  to	
  
                              resolve	
  integraKon	
  issues
                               Forces	
  Product	
  Owners	
  to	
  
                              be	
  more	
  coordinated	
  
                               Sprints	
  should	
  be	
  synchronized
                               Cross	
  team	
  ferKlizaKon	
  is	
  a
                              requirement	
  to	
  successfully	
  
                              deliver	
  in	
  parallel


                                                                            18
Wednesday, November 2, 2011
Story	
  Map
              Areas	
  of	
  func:onality/capabili:es	
  on	
  top
              Place	
  associated	
  user	
  stories	
  ver:cally




                                                                     19
Wednesday, November 2, 2011
Story	
  Map	
  -­‐	
  Next	
  Release
               Draw	
  line	
  that	
  represents	
  viable	
  release
             • Customer	
  features	
  above	
  the	
  line	
  are	
  “in”
             • DoMed	
  line	
  represents	
  nego:ability




                                                                                  !"
                                                                             20
Wednesday, November 2, 2011
Forming	
  the	
  Meta-­‐Scrum




                                 21
Wednesday, November 2, 2011
DefiniKon	
  of	
  Done	
  -­‐	
  Assert	
  Quality
              Acceptance defined criteria for each    Code checked in with reference to
              user story                             US#/Task#
              Unit tests written and passed          Tested on FE
              Code compiles with no errors and no    Integration test written & passes
              warnings
                                                     Test code reviewed
              New code doesn’t break existing code
                                                     Environment requirements documented
              Test case review (Dev to review test
                                                     Interface document updated/added
              case written)
                                                     and checked in to SVN
              Architectural impact assessed and
                                                     Acceptance criteria verified complete
              artifacts updated if necessary
                                                     All P1-P3 bugs for the story are
              Comments in code
                                                     closed
              Error codes added
                                                     Test approves user story
              Code reviewed by peer
                                                     Story demonstrated to product owner
                                                     and accepted on Target Platform




                                                                                            22
Wednesday, November 2, 2011
Release	
  DefiniKon	
  of	
  Done
            Every	
  release	
  should	
  have	
  clear	
  quality	
  criteria
            With	
  a	
  “Release	
  Defini:on	
  of	
  Done”	
  you	
  can	
  
           understand	
  targets	
  beMer
            Measure	
  the	
  gap	
  between	
  the	
  teams’	
  Defini:on	
  
           of	
  Done	
  and	
  a	
  Release	
  Defini:on	
  of	
  Done.
             • This	
  gap	
  is	
  a	
  source	
  of	
  quality	
  issues	
  and	
  represents	
  
               significant	
  risk	
  to	
  schedule




Wednesday, November 2, 2011
Release	
  DefiniKon	
  of	
  Done
            Every	
  release	
  should	
  have	
  clear	
  quality	
  criteria
            With	
  a	
  “Release	
  Defini:on	
  of	
  Done”	
  you	
  can	
  
           understand	
  targets	
  beMer
            Measure	
  the	
  gap	
  between	
  the	
  teams’	
  Defini:on	
  
           of	
  Done	
  and	
  a	
  Release	
  Defini:on	
  of	
  Done.
             • This	
  gap	
  is	
  a	
  source	
  of	
  quality	
  issues	
  and	
  represents	
  
               significant	
  risk	
  to	
  schedule




Wednesday, November 2, 2011
Agile	
  Business	
  Roadmap
         Year 2:	
  Optimize Project Portfolio
               Iden:fy	
  emergent	
  value
               Compare	
  performance	
  across	
  porRolio
               Increase	
  overall	
  value/cost	
  ra:o
               Lower	
  cost	
  of	
  compliance
               Deliver	
  smaller	
  batches
               Reduce	
  stabiliza:on	
  periods
               Coordinate	
  across	
  groups


                                                              24
Wednesday, November 2, 2011
Process	
  AutomaOon	
  &	
  OpOmizaOon	
  
                          with	
  AddiOon	
  of	
  Appropriate	
  “Slack”




Wednesday, November 2, 2011
TradiKonal	
  Source	
  Control	
  Management




                                          26
Wednesday, November 2, 2011
TradiKonal	
  Source	
  Control	
  Management



                                 Main	
  Branch




                                                  26
Wednesday, November 2, 2011
TradiKonal	
  Source	
  Control	
  Management

                              Code
                              Complete
               Version	
  1              Integrate	
  for
               Branch                    Version	
  2


                                                            Main	
  Branch




                                                                             26
Wednesday, November 2, 2011
TradiKonal	
  Source	
  Control	
  Management

                                           Code
                                           Complete
               Version	
  1                           Integrate	
  for
               Branch                                 Version	
  2


                                                 Debt                    Main	
  Branch

                              Death	
  March




                                                                                          26
Wednesday, November 2, 2011
TradiKonal	
  Source	
  Control	
  Management

                                                  Code
                                                  Complete
               Version	
  1                                        Integrate	
  for
               Branch                                              Version	
  2


                                                            Debt                        Main	
  Branch

                               Death	
  March



                                                    {
                              Debt	
  accrues	
  quickly	
  within	
  stabilizaCon	
  periods




                                                                                                         26
Wednesday, November 2, 2011
Flexible	
  Source	
  Control	
  Management




                                              27
Wednesday, November 2, 2011
Flexible	
  Source	
  Control	
  Management



                                Main Branch




                                              27
Wednesday, November 2, 2011
Flexible	
  Source	
  Control	
  Management


              Version 1

                                Main Branch




                                              27
Wednesday, November 2, 2011
Flexible	
  Source	
  Control	
  Management


              Version 1       Version 2

                                          Main Branch




                                                        27
Wednesday, November 2, 2011
Flexible	
  Source	
  Control	
  Management


              Version 1                     Version 2

                                                           Main Branch


                       {
            Not Easy! Must have proper infrastructure to do this.




                                                                         27
Wednesday, November 2, 2011
ConKnuous	
  IntegraKon




                              28
Wednesday, November 2, 2011
29
Wednesday, November 2, 2011
Agile	
  Business	
  Roadmap
     Year 3:	
  Incremental Funding
         Safe-­‐fail	
  environment	
  
         Use	
  experimenta:on	
  as	
  a	
  compe::ve	
  advantage
         Combat	
  compe::ve	
  threats
         Integrate	
  technical	
  &	
  customer	
  feedback	
  promptly
         Aggressively	
  use	
  commit/transform/kill	
  for	
  
       porRolio	
  op:miza:on
         Pull	
  ini:a:ves	
  through	
  teams	
  rather	
  than	
  pushing	
  
       resources	
  to	
  projects

                                                                             30
Wednesday, November 2, 2011
PorEolio	
  Management	
  Decisions:
                                  Commit,	
  Transform,	
  Kill
                                               Source:	
  Johanna	
  Rothman
                                             “Manage	
  Your	
  Project	
  PorLolio”
                                  hNp://www.amazon.com/Manage-­‐Your-­‐Project-­‐PorLolio-­‐first/dp/B004SMU0OW




Wednesday, November 2, 2011
EsKmates	
  are	
  Unreliable	
  but	
  Useful
               Es:mate	
  using	
  rela:ve	
  size
               Affinity	
  Es:ma:ng	
  technique*




                   Affinity	
  EsKmaKng	
  How-­‐To:	
  hWp://www.geYngagile.com/2008/07/04/affinity-­‐esKmaKng-­‐a-­‐how-­‐to/



                                                                                                                              32
Wednesday, November 2, 2011
Por_olio	
  Level	
  Project	
  Commitment




                                             33
Wednesday, November 2, 2011
Por_olio	
  Project	
  TransformaKon




                                       34
Wednesday, November 2, 2011
Early	
  Warning	
  Signs




       Early	
  Warnings:
       •Broken	
  Builds
       •Broken	
  Automated	
  Tests
       •Broken	
  Custom	
  Thresholds


                                         35
Wednesday, November 2, 2011
Early	
  Warnings:
                              •Design	
  Debt	
  in	
  DuplicaOon	
  (DRY)
                              •Technical	
  Debt	
  in	
  Code	
  Complexity
                              •Quality	
  Debt	
  in	
  Bug	
  DB	
  (Break/Fix)
                              •Other	
  Custom	
  Thresholds




                                                                                   36
Wednesday, November 2, 2011
Project	
  Por_olio	
  Kill?




                              Early	
  Warnings:
                              •When	
  transform	
  and	
  re-­‐”commit”	
  is	
  not	
  a	
  valid	
  opOon:
                                •“Kill”	
  should	
  be	
  an	
  opOon	
  on	
  the	
  table	
  MORE



                                                                                                                37
Wednesday, November 2, 2011
Thank	
  you!
                              QuesOons	
  &	
  Answers




Wednesday, November 2, 2011
Come	
  see	
  us	
  at	
  AgileAdvantage.com




                                                39
Wednesday, November 2, 2011