Agile Methods Workshop - Center for Software Engineering

Document Sample
Agile Methods Workshop - Center for Software Engineering Powered By Docstoc
					Injecting Agile Methods into a
“Disciplined” Context
An Experience Report from Motorola

John May
USC CSE ARR - Agile Methods Workshop
April 3, 2013
    Our domain is not a “home
    ground” for agile methods
                                                                                                  Master Site

• Public safety            Subsite
                                        Subsite                                ATIA

• Infrastructure
                                                                     Third Party
                                                                    ATIA Analyzer                                     ZCSNetwork
                                                                                  Zone Controller                      Management


equipment                 Conv. Analog
                           Station #1
                                       Conv. Analog
                                        Station #1

• Wide-area radio                                                                                               WAN

communications                        4W
                                            Router w/ E&M        Switch

                                                                                                                                    Router w/ E&M     Switch
                                                                                                                                                               Conventional Site Controller
                                                                                                                                                                Located at Console Site

• “Soft” real-time
                         Comparator                                                                                        e              4W

                                                  4W                        Site

• Many proprietary
                                                                          Controller                                                                           Console #1
                                                                                                                      Conv. Analog                                                  Logging
                                Conv. Analog      Conv. Analog                         Trunking                                              Non-Vortex 2
                                                                                                                       Station #1                                                    Server
                                 Station #1        Station #2                           Station                                                Console
                                                                                                                                                                       Console #2

protocols              Analog
                                                   RF Site (Trunking & Conventional)                                                      Console Site (w/ Conventional)

• Off-the-shelf OS                                                              4W
                                                                                       Router w/ E&M

                                    Conventional Only Site
                                                                          Conv. Analog      Conv. Analog
                                                                           Station #1        Station #2

                                                                                                                                                                             Page 2
                 The project

 This is a “typical” project for our group
    Part of a larger program (systems release)
    Adding features to existing call controller
    Estimates: 20 KSLOC; 200+ SM; 15 CM
 The team:
      12 developers (most w/ < 2 years C++)
      2 chief architects (w/ 4 years OOD/C+)
      2 project managers (w/ 10 years on product)
      SEI Level 3 organization (at L4 by Sept...?)
 Project status:
    Starting Iteration 4 (of 9 planned)
                                               Page 3
       Our hybrid approach

 Our “middle ground”:
   Time-bound design model created up front
    for estimation purposes
   Functional requirements are 80% completed
    before iterations even start
      Iterations really only cover design/code/unit-test
   We settled on 5-week iterations:
      3 weeks of UML design specification and TDD
      1 week of formal peer reviews
      1 week of “slack” between iterations
          Iteration Postmortem, CI roles, Iteration Kickoff
   Wait for last iteration to complete before
    starting box-level “acceptance” testing
                                                           Page 4
 Organizational characteristics

 Criticality: Safety-critical communication
 Personnel: Above avg; very few “gurus”
 Dynamism: We’ve chosen to keep it low
   at expense of cycle-time, responsiveness
   requirements are written by developers
 Culture: Balance between chaos/order
 Size: Full projects peak at 25-30
   “architecture component” teams: up to 10-15
   agile teams within component: more like 4-5

                                           Page 5
Boehm/Turner spider chart

                        Page 6
 Motivations for agile methods

 Desire to use an iterative lifecycle
    Iterative development = OO best practice
    Agile methods = set of best practices for
     iterative development
 Needed to do on-the-job training
    Over half of team was new to OOD/C++
       skills gained in an iteration are re-applied quickly
    Better information flow “amplifies learning”
 Lack of good historical data for planning
    Only a handful of pilots to draw data from
    Yet there is “zero tolerance” for missed dates

                                                         Page 7
   Motivations we didn’t have

 Intense time-to-market pressure
   Why not? ... Because of our unique market:
      Customers think: high-quality = long cycle times
      Our large systems are almost “built-to-order”
 Changing requirements
   Why not? ... Because project plans allow:
      Developers to decide when documents are “done”
      For all the requirements to get defined “up front”
 Need for “hands-on” customer input
   Why not? ... Because systems development:
      Puts distance between software and end-user
      Non-functional needs drive much of our “box reqs”

                                                     Page 8
           Other Influences

 We had no other training options
   Little investment in training for developers
   Little investment in external consulting
 Much resistance to working iteratively
   Senior engineers and managers skeptical
      They have good track record (“if it ain’t broke...”)
      “Going iterative” is very disruptive to organization
      Lean principles vs. culture of “heavy” process
   Tight, loose feedback loops vs. “formal CI”
      Recent SEI CMM focus (moving to levels 4-5)
      Re-emphasis of Six Sigma techniques

                                                       Page 9
      Valuable Agile Practices

    Developer-oriented practices:
    1. Test-Driven Development
          w/ automated regression
          this was the “foot in the door” for mgmt buy-in
    2. Collective Ownership
          closely coupled with Frequent Integration
    3. Pair Programming
          intense mentoring and domain cross-training
    4. Refactoring
          a cultural shift: it’s OK to change
    5. Wiki
          unleashing the promise of the intranet

                                                       Page 10
      Valuable Agile Practices

   Management-oriented practices
    1. Project Planning
          Backlog Burndown Chart - using velocity to
           predict completion dates
          FDD-style feature definitions (“slices and steps”)
          Iterations as ~30-day “sprints”
          Iteration Postmortem, Kickoff, Daily Standup
    2. Iteration Planning
          Held weekly Planning Game with each subteam
          Velocity tracked w/ estimation in “ideal hours”
    3. On-site “customer team”
          Created a dedicated “customer proxy” role
          Interface to Systems Engineering
          Drove the completion, formal review of reqs
                                                         Page 11
Agile Practices we’re not using

   Things that don’t match our needs:
    1. LDUF
          We create a costing model as baseline design
          Valuable “metaphors” emerge from this model
    2. User stories
          Formal requirements are created instead
    3. “Strict” Pair Programming
          Rotation frequency is monthly not daily
          Pairs don’t always choose their assignments
          In a 40-hour week, we’re seeing 20-25 pair hours
          We supplement pairing with formal peer reviews

                                                     Page 12
               The Role of Roles

   We’ve gotten specific about some roles
    1. Redundant Leadership
          For 12 staff across 3 subteams we established:
              redundant pair of lead designers (chief architects)
              redundant pair of project managers
          Leadership responsibilities span all subteams
          A smaller project might not need this...
    2. Designated Experts for Functional Areas
          Within the overall set of functional requirements
          Individual accountability in collective ownership
          Individual can impact the quality through:
              day-to-day development activities
              added focus during peer reviews
              manual test execution (for acceptance testing)
                                                            Page 13
       Additional Practices

3. Dedicated Auxiliary Roles
      To insure that infrastructure/support needs of the
       development environment will be met
      Also offers chance for individual achievement
4. Managers Conduct Pair “Interviews”
      Using agile methods makes it more challenging
       for personnel managers to get feedback on
       individual performance/achievement
          More collaboration than in existing practices
          How do we determine whether stronger members
           of the team are “carrying” the weaker ones?
      Project Lead keeps record of “key creative
       contributions” for each developer across project
      Developers volunteer this info at one-on-one
       “interview” sessions with project leads conducted
       after each iteration
                                                   Page 14
              Future Work

 Finding an optimal balance between
  productivity and quality in iteration sizing
 Scaling agile practices to larger teams
 Finding the “customer” in a large
  systems development organization
 Restructuring the value proposition of
  agility as personnel characteristics
 Using financial metrics to make a strong
  business case for agile methods
                                          Page 15
               Contact Info

 John May
   Principal Staff Engineer

 Motorola, Inc. Schaumburg, Illinois
   Commercial, Government, Industrial Systems Sector
      Worldwide Systems Solutions Division
         Private Radio Network Engineering
             Trunking Controller Products

                                                 Page 16

Shared By: