Agile Planning, Inspection & Adaption
   8+ yrs as Software Developer
   6+ yrs as Scrum Master and Coach
   1 year as Product Owner
   Internal Coach @ Rally Software
   Servant leader to the agile community
   Passionate about agile teams, metrics and using
    agile/lean concepts in everyday life

   Contact Info:
     tsheridan@rallydev.com
   10+ years in Software & Hardware Industries
   Certified Project Management Professional
   Certified Scrum Master and Professional
   External Agile Coach (to many)
   Internal Agile Coach at RightNow Technologies
   Agile Community Contributor and Teacher

   Contact Info:
     erin@skipstoneconsulting.com
     @coachatplay
   Name
   Company
   Position
   Experience with Agile
   Introductions
   Approaches and Value
   Agile Planning
   Inspecting
   Adapting
   Q&A
What do you want to learn? What seems the hard or impossible?




http://josvoskuil.files.wordpress.com/2009/02/think.png
EVM and Agile, how each determines value
• Agile approach
   EVM approach              – Value: Decided and
     Value = Amount            prioritized by the
                                PO/Customer/Business,
      Budgeted. Guided by       guided by Vision
      project plan            – Asks 3 Questions
                                 • Delivering highest value
     Asks 2 Questions             features?
      ▪ On Schedule?             • On Schedule?
                                 • Delivering Quality?
      ▪ On Budget?
                              – Focused on planning
     Focus on “The Plan”     – Rearrange how we work
                                (vertical slices)
Triple Constraints


 Fixed           Requirements     Resources          Time


                                          Value
                                          Driven

                    Plan
                   Driven

Estimated   Resources           Time      Features
Daily
                       Standup




                       2 Week
          Iteration   Iteration
          Planning                Demo, Review &
          Meeting                  Retrospective




Product    Tasks                      Potentially Shippable
Backlog                                Product Increment
   PO acting as proxy of the customer /
    stakeholders
   Fast feedback by delivering working software
   Prioritizing a backlog of features /
    requirements
   Guided by product vision
   Value vs. Risk decisions
Translating into the agile world
   For military folks: “Commanders Intent”
     To make people understand why they are doing
     stuff
 High level themes/initiatives (“broad strokes”)
 Annual or Quarterly
 NOT architectural
  layers                  Story 1 Story 2
 Deliver value quickly
 Use this feedback to              GUI
  deliver more value
                               Business Logic



                                  Database
Ball Point Game
Metrics and what the data is telling us
   EVM Approach
   Agile Metric: velocity
     Stabilize, then use for forecasting
   Burndowns
   Burnups
   Real
     Good decisions based on real data
     Constantly updated
     No surprises! (no “let’s see what happens?”)
   Fake
     Bad decisions
     “The optimism of hope above experience”
   Shippable product EVERY iteration
   Designed, Developed and Tested
   Fast Feedback!
   Not leaving stuff until the end
   Metric: # of defects escaping the iteration
   Metric: Code/Unit test coverage?
   Measurement = working software delivered
    (value!)
Retros to help your teams become more effective
Discuss and     Confirm
Gather Data
                Refine      Action Items
   Silent Brainstorming (w/ post its)
   Time boxed (15-30min)
   3-4 categories
     Start, Stop, Continue, Shouts
     Strong, Weak, Improving




                                http://www.selfishprogramming.com/2009/12/08/agile-winter-school
 Time boxed
 Walk through each comment in the Data
  Gathering exercise
 Find common themes and categories
 Brainstorm actionable
items for each categories




                        http://fabiopereira.me/blog/tag/thoughtworks/
   Time boxed
   Voting
   Give everyone 5-10 dot stickers
   Ask them to spend their dots on their favorite
    actionable items




                              http://www.innovationtools.com/Articles/ArticleDetails.asp?a=141
   Plus/delta
   Start/Stop/Continue
   4 Quadrants
   Timeline
   Many more
   Running them Locally:
     Whiteboard and Post-Its
   Remote Folks
     corkboard.me
     googledocs
     Whatever allows the voice of remote folks to be
     heard
Review parking lot backlog
This Workshop

Pmi agile planning, inspection and adaption

  • 1.
  • 2.
    8+ yrs as Software Developer  6+ yrs as Scrum Master and Coach  1 year as Product Owner  Internal Coach @ Rally Software  Servant leader to the agile community  Passionate about agile teams, metrics and using agile/lean concepts in everyday life  Contact Info:  tsheridan@rallydev.com
  • 3.
    10+ years in Software & Hardware Industries  Certified Project Management Professional  Certified Scrum Master and Professional  External Agile Coach (to many)  Internal Agile Coach at RightNow Technologies  Agile Community Contributor and Teacher  Contact Info:  erin@skipstoneconsulting.com  @coachatplay
  • 4.
    Name  Company  Position  Experience with Agile
  • 5.
    Introductions  Approaches and Value  Agile Planning  Inspecting  Adapting  Q&A
  • 6.
    What do youwant to learn? What seems the hard or impossible? http://josvoskuil.files.wordpress.com/2009/02/think.png
  • 8.
    EVM and Agile,how each determines value
  • 9.
    • Agile approach  EVM approach – Value: Decided and  Value = Amount prioritized by the PO/Customer/Business, Budgeted. Guided by guided by Vision project plan – Asks 3 Questions • Delivering highest value  Asks 2 Questions features? ▪ On Schedule? • On Schedule? • Delivering Quality? ▪ On Budget? – Focused on planning  Focus on “The Plan” – Rearrange how we work (vertical slices)
  • 10.
    Triple Constraints Fixed Requirements Resources Time Value Driven Plan Driven Estimated Resources Time Features
  • 11.
    Daily Standup 2 Week Iteration Iteration Planning Demo, Review & Meeting Retrospective Product Tasks Potentially Shippable Backlog Product Increment
  • 12.
    PO acting as proxy of the customer / stakeholders  Fast feedback by delivering working software  Prioritizing a backlog of features / requirements  Guided by product vision  Value vs. Risk decisions
  • 13.
  • 15.
    For military folks: “Commanders Intent”  To make people understand why they are doing stuff
  • 16.
     High levelthemes/initiatives (“broad strokes”)  Annual or Quarterly
  • 19.
     NOT architectural layers Story 1 Story 2  Deliver value quickly  Use this feedback to GUI deliver more value Business Logic Database
  • 24.
  • 25.
    Metrics and whatthe data is telling us
  • 26.
    EVM Approach
  • 28.
    Agile Metric: velocity  Stabilize, then use for forecasting
  • 30.
    Burndowns  Burnups
  • 31.
    Real  Good decisions based on real data  Constantly updated  No surprises! (no “let’s see what happens?”)  Fake  Bad decisions  “The optimism of hope above experience”
  • 32.
    Shippable product EVERY iteration  Designed, Developed and Tested  Fast Feedback!  Not leaving stuff until the end  Metric: # of defects escaping the iteration  Metric: Code/Unit test coverage?  Measurement = working software delivered (value!)
  • 33.
    Retros to helpyour teams become more effective
  • 34.
    Discuss and Confirm Gather Data Refine Action Items
  • 35.
    Silent Brainstorming (w/ post its)  Time boxed (15-30min)  3-4 categories  Start, Stop, Continue, Shouts  Strong, Weak, Improving http://www.selfishprogramming.com/2009/12/08/agile-winter-school
  • 36.
     Time boxed Walk through each comment in the Data Gathering exercise  Find common themes and categories  Brainstorm actionable items for each categories http://fabiopereira.me/blog/tag/thoughtworks/
  • 37.
    Time boxed  Voting  Give everyone 5-10 dot stickers  Ask them to spend their dots on their favorite actionable items http://www.innovationtools.com/Articles/ArticleDetails.asp?a=141
  • 38.
    Plus/delta  Start/Stop/Continue  4 Quadrants  Timeline  Many more
  • 39.
    Running them Locally:  Whiteboard and Post-Its  Remote Folks  corkboard.me  googledocs  Whatever allows the voice of remote folks to be heard
  • 41.
  • 43.

Editor's Notes

  • #8 http://toolsforagile.com/blog/wp-content/uploads/2008/07/word_cloud.pngSince Scrum has the highest adoption rate among agile practices, we’ll be focusing on this framework(not XP, Kanban, etc.)
  • #10 Quality: also focused on what the customer expected
  • #11 Have to mention dedicated teams doing the work
  • #13 Image: http://www.etftrends.com/wp-content/uploads/2011/03/ETF-Spotlight1.jpg
  • #15 Image: http://lh6.ggpht.com/sritsqldotnet/SGBLTDURKtI/AAAAAAAAADw/CGJ5OhfS3VE/Five%20Levels%20of%20Planning%5B2%5D.png
  • #17 http://farm1.static.flickr.com/198/466161899_339852d2a3_o.pngYou‘llhave a more realisticroadmapusingthisapproach ...
  • #18 Dean Leffingwell: Scaling Software Agility
  • #19 http://www.archives.gov/records-mgmt/toolkit/fbi/rma_transition/image5_3.gifBacklog contains the requirements– same as WBS -- we just don’t plan them out until we are sure we are going to deliver themAssume: 6 month project
  • #21 http://scalingsoftwareagility.files.wordpress.com/2008/03/draft-release-plan.jpgRelease plan is a little closer to what a WBS is, but still less planning than is necessary for this far outCone of uncertaintyIntegrated and tested at EVERY iteration boundary
  • #23 http://sandersconsulting.com/wp-content/uploads/2011/06/bigvssmall.jpgSprint plan is a WBS, just on a smaller scale we are sure we can deliver
  • #24 http://www.pensionriskmatters.com/uploads/image/Risk%20Cubes.jpgWhich reduces riskPotentiallyshippable product every sprint
  • #25 Use estimates, relative sizing, velocityFocus on velocity, allowing a team to understand what they can accomplish in a certain timeBreak after activity
  • #27 Problem:Only answers the questions: Are we on time? Are we on budget? (based on the original plan)Doesn’t answer: Are we delivering the right thing, right now?Not changing our approach, asking people to work longer == less qualityDoesn’t account for unknown integration, testing work (defects, etc.)
  • #28 Is it truly controllable?Invite change from the business, a collaboration not a contract
  • #29 Better velocity charts here!
  • #30 http://scalingsoftwareagility.files.wordpress.com/2008/03/draft-release-plan.jpg
  • #31 Split this into multiple slidesOn-Budget: Fixed cost of teamAdd an iteration, more costRemove an iteration, less cost
  • #32 Things that are marked as done are ACTUALLY Done, Done!not in progress on a featureNot waiting on QA/testingNot waiting on integration, etc.Cite quote
  • #33 Don’t allow your tech debt to growQuality metrics: Look at the system and how it’s incentivized (to find defects, or to add value?)Check-In on deep dives into any topics!Break!
  • #43 http://cfconference.files.wordpress.com/2011/05/thank-you-rocks.jpg