Upload
others
View
11
Download
0
Embed Size (px)
Citation preview
Traditional Project Management Meets Agile:Management Meets Agile:
Can’t We All Get Along
Dr. Harry KoehnemannDirector of TechnologyRocket Gangh @ k t
Mark CoatsChief Software EngineerGeneral Dynamics C4SM k C t @ d [email protected] [email protected]
Copyright © 2011 Rocket Gang 1
Report Documentation Page Form ApprovedOMB No. 0704-0188
Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering andmaintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, ArlingtonVA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if itdoes not display a currently valid OMB control number.
1. REPORT DATE MAY 2011 2. REPORT TYPE
3. DATES COVERED 00-00-2011 to 00-00-2011
4. TITLE AND SUBTITLE Traditional Project Management Meets Agile: Can’t We All Get Along
5a. CONTRACT NUMBER
5b. GRANT NUMBER
5c. PROGRAM ELEMENT NUMBER
6. AUTHOR(S) 5d. PROJECT NUMBER
5e. TASK NUMBER
5f. WORK UNIT NUMBER
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) Rocket Gang,14362 N. Frank Lloyd Wright Blvd,Scottsdale,AZ,85260
8. PERFORMING ORGANIZATIONREPORT NUMBER
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)
11. SPONSOR/MONITOR’S REPORT NUMBER(S)
12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES Presented at the 23rd Systems and Software Technology Conference (SSTC), 16-19 May 2011, Salt LakeCity, UT. Sponsored in part by the USAF. U.S. Government or Federal Rights License
14. ABSTRACT
15. SUBJECT TERMS
16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF ABSTRACT Same as
Report (SAR)
18. NUMBEROF PAGES
14
19a. NAME OFRESPONSIBLE PERSON
a. REPORT unclassified
b. ABSTRACT unclassified
c. THIS PAGE unclassified
Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18
Agenda
• Traditional planning and it’s challenges
Focus on team organization, planning, requirements, and architecture
• Making traditional planning agile• Making traditional planning agile
• Transitioning from traditional to agile
Copyright © 2011 Rocket Gang 2
Traditional Development
Schedule
Earned Value Management
DevelopmentBDUF
g
PDR CDR xRR
Value
No value until end
Everyone responsible for everything; no one responsible for anything
Copyright © 2011 Rocket Gang 3
Agile DevelopmentStory
Story
IBR PDR CDR xRR
DevelopmentBDUFStory
Story
StoryStory
StoryStory
Story
StoryStory
Release/
ProductBacklog
ReleaseBacklog
IBRPDRCDRxRR IBRPDRCDRxRREnvisioning
Release/Milestone/
WaveSprintStory
StoryStory
Story BSD-JIT* BSD-JIT*
ac og
Value Value Value Value
IPT
IPT Lead (Gov)…Cross-Functional Teams
Product Owner
SprintBacklog A
Copyright © 2011 Rocket Gang 4
( )
Scrum MasterSprint
Backlog B * Barely Sufficient Design(Architecture Runway)
Agile Value Points
• Defines success as delivering business value, vs. meeting schedule
• Continuous, frequent collaboration points between dev and business
E f t f db k d l i• Encourages frequent feedback and learning
Allows projects to fail fast
Quickly adapts to changesQuickly adapts to changes
• Accommodates uncertainty, risk, change
• Plans work and organizes teams around system behavior
• Details requirements, design, schedule at right time
Copyright © 2011 Rocket Gang 5
Transitioning to Agile
• Addresses team organization, planning, requirements, architecture• Continually define barely-sufficient requirements and architecture runway for
feature teams
• Envision/Speculate (vs. Initiate/Plan)
Brainstorm on product vision and promising implementation approach
• Explore (vs. Execute)
Use iterations to explore solution and adapt to new discoveries
Vs preserve original baselines at all costsVs. preserve original baselines at all costs
Envision/
Release/Milestone/
Wave“Sprint 0”Envision/Speculate
• Vision• Business Goals• Significant features
• Architecture infrastructure• Development infrastructure
Envision/Speculate
Copyright © 2011 Rocket Gang 6
Significant features• Architecture models• Constraints• Risks
p(test automation, etc.)
• Risk mitigation plans
Transitioning to Agile Team Organization
• Organize around behavior, not structure or domain
• Teams self-manageCommit to features, decompose work, assign tasks , p , g
Desire to keep co-located!!
• Strive to push decisions out to feature teamsS i lt t ibl f b d t i d d i iSpecialty teams responsible for broader system issues and decisions
• Coupled features may require high collaboration between teams
Feature Team A Feature Team B
Feature TeamsFeature Team C
ArchitectureBuild/Test “Specialty Teams”,
possibly ad-hocProduct Owner …
Copyright © 2011 Rocket Gang 7
Project Leadership
Transition to Agile Planning
• Plans (WBS) define behavior
Releases plan features (20-100 day effort)
Decompose into stories (2 10 day)
Feature
Story
StorySystems
Test
Decompose into stories (2-10 day)
• Items become more detailed closer to scheduling
• Use milestones/waves as synchronization points
Story
Use milestones/waves as synchronization points
Each iteration we learn more about team’s ability to meet schedule
MilestoneFeature
Feature
Feature
Feature
Feature
FeatureFeature
FeatureStory
StoryStory
Backlog
…
yStory
StoryStory
StoryStory
StoryStory
StoryStSt
Story
Story
StoryStory
Story
Story
StoryStSt
Story
Story
Story
Copyright © 2011 Rocket Gang 8
Milestone ReleaseSprint
…StoryStoryStoryStory
Story
StoryStoryStoryStory
Story
Transitioning to Agile Requirements
• Envisioning defines constraints, significant features
• Exploring plans and details requirements at right time
N d dditi l t t t t l l t• Need additional story types to support large, complex systems
Storyboarding
Process Modeling
Storyboarding
Structured (Formal)UML UML
UI SketchUser StorySupport Non-customer Facing Stories• Constraints (security, performance)• Infrastructure building
Copyright © 2011 Rocket Gang 9
Infrastructure building • Prototyping for risk mitigation• Inter-team commitments• Technical tasks
Transitioning to Agile Architecture
• Complex systems also develop their infrastructure
Responsible for significant functionality below the waterline
• Prioritize stories that extend and validate infrastructure• Prioritize stories that extend and validate infrastructure
Includes rich set of automated tests
Similar in spirit to the “Sprint 0” agile practice (“Milestone 0”)p p g p ( )
FeatureFeature
Application Server
Feature Feature
System Layers
Virtualization
Database, Persistence
Operating System
Application Server
?
Copyright © 2011 Rocket Gang 10
Caution on Organizational Change
• Great process cannot make up for having the wrong people
• Need capable people with self-discipline
S lf ti t d i t b t l i blSelf-motivated, passionate about solving problems
Multi-skilled, adaptive, continuous improvers
Proactive, sense of ownership, p
Communicate, collaborate
• Coaching/modeling is key to organizational change
“Most organizations build their bureaucratic rules to manage the few wrong people on the bus, which drives away the right people on the bus, which in turn increases the need for more b ti l d ” Ji C lli (2001)
Copyright © 2011 Rocket Gang 11
bureaucratic rules, and so on” -- Jim Collins (2001)
Recommendations
• Blend strengths
Agile: continuous feedback, learning, adaptive planning, behavior focus
Traditional: up-front assumptionsp p
• Consider agility principles
Knowledge and running system are the goals, not documents and schedules
F f db k d l i bl l ti d l tFocus on feedback and learning – problem, solution, development process
Use continuous, inspect-adapt cycles
Plan, track, execute small work
Organize teams around features
Lead teams, let teams manage themselves
• Repeatable wants to schedule reliable wants to deliver valueRepeatable wants to schedule, reliable wants to deliver value
Focus more on execution, less on management/control
Copyright © 2011 Rocket Gang 12
Conclusions
• Fill the gap between project plans and developer tasks
Ensure plans are based on reality
Automate progress from development work to project level plansAutomate progress from development work to project-level plans
• Agile changes how we:
Plan Behavior-focused vs. structure/document-focused
Measure Business value vs. percent complete
Manage Self-managed teams vs. Project Manager
Track Feature-centric vs. plan-centric
Build & Test Continuously vs. at end
Define success Make business smile (value ☺) vs execute the planDefine success Make business smile (value ☺) vs. execute the plan
Copyright © 2011 Rocket Gang 13
Dr. Harry KoehnemannDirector of TechnologyRocket Gangh @ k t
Mark CoatsChief Software EngineerGeneral Dynamics C4SM k C t @ d [email protected] [email protected]
Copyright © 2011 Rocket Gang 14