Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
Dr. David F. Rico, PMP, ACP, CSMTwitter: @dr_david_f_rico
Website: http://www.davidfrico.comLinkedIn: http://www.linkedin.com/in/davidfrico
Facebook: http://www.facebook.com/profile.php?id=1540017424
A 2-Day Introduction for Technical Leaders, Staff, and Engineers
2
DoD contractor with 28+ years of IT experience B.S. Comp. Sci., M.S. Soft. Eng., & D.M. Info. Sys. Large gov’t projects in U.S., Far/Mid-East, & Europe
Author Background
Published six books & numerous journal articlesAdjunct at George Washington, UMUC, & ArgosyAgile Program Management & Lean DevelopmentSpecializes in metrics, models, & cost engineeringSix Sigma, CMMI, ISO 9001, DoDAF, & DoD 5000Cloud Computing, SOA, Web Services, FOSS, etc.
3
Agenda
Agile Motivation
Agile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning
Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources
4
U.S. is no longer an industrial-age nation U.S. part of a group of post-industrial countries U.S. consists of information-age knowledge workers
Information Age
Bell, D. (1999). The coming of post industrial society. New York, NY: Basic Books.
0%
20%
40%
60%
80%
100%
1860 1870 1880 1890 1900 1910 1920 1930 1940 1950 1960 1970 1980 1990
Perc
ent o
f Eco
nom
y
Information
Service
Industry
Agriculture
5
21st century systems are becoming more complex Number of physical parts are becoming smaller Nano-circuitry and software hide complexity
System Complexity is Growing
Moody, J. A., et al. (1997). Metrics and case studies for evaluating engineering designs. Upper Saddle River, NJ: Prentice-Hall.
6
No. of software-intensive systems is growing 80% of US DoD functions performed in software Major driver of cost, schedule, & tech. performance
Software Century
Kennedy, M. P., & Umphress, D. A. (2011). An agile systems engineering process: The missing link. Crosstalk, 24(3), 16-20.
7
21st century systems are technology-intensive Technology is evolving at an exponential speed Technology is obsolete before project completion
Technology Change
Kurzweil, R. (2005). The singularity is near: When humans transcend biology. New York, NY: Penguin Group.
8
Big projects result in poor quality and scope changes Productivity declines with long queues/wait times Long projects are unsuccessful or canceled
Large, Traditional Projects
Jones, C. (1991). Applied software measurement: Assuring productivity and quality. New York, NY: McGraw-Hill.
Size vs. Quality
Def
ect
Den
sity
0.00
3.20
6.40
9.60
12.80
16.00
0 2 6 25 100 400
Lines of Code (Thousands)
Size vs. Productivity
Cod
e P
rodu
ctio
n R
ate
0.00
1.00
2.00
3.00
4.00
5.00
0 2 6 25 100 400
Lines of Code (Thousands)
Size vs. Requirements Growth
Per
cent
age
0%
8%
16%
24%
32%
40%
0 2 6 25 100 400
Lines of Code (Thousands)
Size vs. SuccessP
erce
ntag
e
0%
12%
24%
36%
48%
60%
0 2 6 25 100 400
Lines of Code (Thousands)
9
Challenged and failed projects hover at 67% Big projects fail more often, which is 5% to 10% Of $1.7T spent on IT projects, over $858B were lost
Global Project Failures
Standish Group. (2010). Chaos summary 2010. Boston, MA: Author.Sessions, R. (2009). The IT complexity crisis: Danger and opportunity. Houston, TX: Object Watch.
16% 53% 31%
27% 33% 40%
26% 46% 28%
28% 49% 23%
34% 51% 15%
29% 53% 18%
35% 46% 19%
32% 44% 24%
33% 41% 26%
0% 20% 40% 60% 80% 100%
1994
1996
1998
2000
2002
2004
2006
2008
2010
Year
Successful Challenged Failed
$0.0
$0.4
$0.7
$1.1
$1.4
$1.8
2002 2003 2004 2005 2006 2007 2008 2009 2010
Trill
ions
(US
Dolla
rs)
Expenditures Failed Investments
10
Requirements defects are #1 reason projects fail Traditional projects specify too many requirements More than 65% of requirements are never used at all
Requirements Defects & Waste
Sheldon, F. T. et al. (1992). Reliability measurement: From theory to practice. IEEE Software, 9(4), 13-20Johnson, J. (2002). ROI: It's your job. Extreme Programming 2002 Conference, Alghero, Sardinia, Italy.
Other 7%
Requirements47%
Design28%
Implementation18%
Defects
Always 7%
Often 13%
Sometimes16%
Rarely19%
Never45%
Waste
11
Agenda
Agile Motivation Agile Introduction
Agile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning
Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources
12
Today’s Whirlwind Environment
Overruns Attrition Escalation Runaways Cancellation
GlobalCompetition
DemandingCustomers
OrganizationDownsizing
SystemComplexity
TechnologyChange
VagueRequirements
Work LifeImbalance
13
Need for a new model of system development Cope with high-level of uncertainty and ambiguity With just the right balance of flexibility and discipline
Need for a New Model
Augustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education.Chin, G. (2004). Agile project management: How to succeed in the face of changing project requirements. Broadway, NY: Amacom.DeCarlo, D. (2004). Extreme project management: Using leadership, principles, and tools to deliver value in the face of volatility. San Francisco, CA: Jossey-Bass.Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
R&D Oriented People Centered Adaptive Customer Friendly Fast & Efficient Disciplined
New discoveries
Complex problems
One-off systems
Vague requirements
Incomplete information
High uncertainty
Experimentation
Simulations
Prototyping
Innovation oriented
New products
Creative solutions
Highly-talented people
Cross-functional teams
Small team size
A lot of communication
Interpersonal trust
Rich collaboration
Empowered decisions
Sustainable pace
Daily interaction
Rich communications
Face-to-face interaction
Cohesiveness
Global threats
Market threats
New customer needs
Changing scope
Changing technology
Changing regulations
Continuous change
Flexible culture
Flexible attitudes
Flexible policies
Flexible processes
Flexible technologies
Customer interaction
A lot of communication
Customer demos
Customer feedback
Business value focus
Customer satisfaction
Customer responsive
Customer sensitivity
Customer relationships
Customer contact
Customer involvement
Customer driven
New technology
Quick decision-making
Iterative delivery cycles
Frequent deliveries
Fast delivery schedules
Short timelines
Fast time-to-market
First-mover capability
Minimal process costs
Low work-in-process-
Flexible processes
Market responsiveness
Lightweight strategy
Lightweight plans
Lightweight lifecycles
Security engineering
Light requirements
Light architecture
Lightweight design
Code reviews
Rigorous V&V
Rigorous CM
Rigorous QA
Project reviews
14
A-gil-i-ty (ə-'ji-lə-tē) Property consisting of quickness, lightness, and ease of movement; To be very nimble
The ability to create and respond to change in order to profit in a turbulent global business environment
The ability to quickly reprioritize use of resources when requirements, technology, and knowledge shift
A very fast response to sudden market changes and emerging threats by intensive customer interaction
Use of evolutionary, incremental, and iterative delivery to converge on an optimal customer solution
Maximizing the BUSINESS VALUE with right-sized, just- enough, and just-in-time processes and documentation
What is Agility?
Highsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.
15
People-centric way to create innovative solutions Market-centric model to maximize business value Product-centric vs. wasteful processes/documents
What are Agile Methods?
Agile Manifesto. (2001). Manifesto for agile software development. Retrieved September 3, 2008, from http://www.agilemanifesto.org.
alsoknown as
CustomerCollaboration
Individuals &Interactions
WorkingSystems
Respondingto Change
CustomerInteraction
High PerformanceTeams
IterativeDevelopment
Adaptabilityor Flexibility
ContractNegotiation
Processes& Tools
ComprehensiveDocumentation
Followinga Plan
Agile Methods‘Values’
alsoknown as
alsoknown as
alsoknown as
valuedmore than
valuedmore than
valuedmore than
valuedmore than
Agile Methods‘Principles’
Traditional Methods‘Values’
16
Agile is naturally lean and based on small batches Agile directly supports six principles of lean thinking Agile may be converted to a continuous flow system
How do Lean/Agile Intersect?
Womack, J. P., & Jones, D. T. (1996). Lean thinking: Banish waste and create wealth in your corporation. New York, NY: Free Press.Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. New York, NY: Celeritas.Reagan, R. B., & Rico, D. F. (2010). Lean and agile acquisition and systems engineering: A paradigm whose time has come. DoD AT&L Magazine, 39(6).
Economic View
Decentralization
Fast Feedback
Control Cadence& Small Batches
Manage Queues/Exploit Variability
WIP Constraints& Kanban
Flow PrinciplesAgile Values
CustomerCollaboration
EmpoweredTeams
IterativeDelivery
Respondingto Change
Lean Pillars
Respectfor People
ContinuousImprovement
Customer Value
Relationships
Customer Pull
Continuous Flow
Perfection
Value Stream
Lean Principles Customer relationships, satisfaction, trust, and loyalty Team authority, empowerment, and resources Team identification, cohesion, and communication
Lean & Agile Practices
Product vision, mission, needs, and capabilities Product scope, constraints, and business value Product objectives, specifications, and performance As is policies, processes, procedures, and instructions To be business processes, flowcharts, and swim lanes Initial workflow analysis, metrication, and optimization Batch size, work in process, and artifact size constraints Cadence, queue size, buffers, slack, and bottlenecks Workflow, test, integration, and deployment automation Roadmaps, releases, iterations, and product priorities Epics, themes, feature sets, features, and user stories Product demonstrations, feedback, and new backlogs Refactor, test driven design, and continuous integration Standups, retrospectives, and process improvements Organization, project, and process adaptability/flexibility
17
On exploratory or research/development projects When fast customer responsiveness is paramount In organizations that are highly-innovative & creative
When to Use Agile Methods?
Pine, B. J. (1993). Mass customization: The new frontier in business competition. Boston, MA: Harvard Business School Press.
Agile Project Management
High-levels of uncertainty and unpredictability
High-technology projects
Fast-paced, highly-competitive industries Rapid pace of technological change Research-oriented, discovery projects Large-fluctuations in project performance Shorter-term, performance-based RDT&E contracts Achieving high-impact product/service effectiveness Highly-creative new product development contracts Customer-intensive, one-off product/service solutions Highly-volatile and unstable market conditions High-margin, intellectually-intensive industries Delivering value at the point-of-sale
Traditional Project Management
Predictable situations
Low-technology projects
Stable, slow-moving industries Low-levels of technological change Repeatable operations Low-rates of changing project performance Long-term, fixed-price production contracts Achieving concise economic efficiency goals Highly-administrative contracts Mass production and high-volume manufacturing Highly-predictable and stable market conditions Low-margin industries such as commodities Delivering value at the point-of-plan
18
Agility has many dimensions other than IT Ranges from leadership to technological agility This brief will touch upon most of these agile layers
Agile World View
Agile Leaders
Agile Organization Change
Agile Acquisition & Contracting
Agile Strategic Planning
Agile Capability Analysis
Agile Program Management
Agile Tech.
Agile Information Systems
Agile Tools
Agile Processes & Practices
Agile Systems Development
Agile Project Management
19
Agenda
Agile MotivationAgile Introduction
Agile Justification
Agile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning
Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources
20
VersionOne found 80% using agile methods today Most are using Scrum with several key XP practices Release planning/continuous integration are vital tools
Agile Adoption Rates
House, D. (2012). Sixth annual state of agile survey: State of agile development. Atlanta, GA: VersionOne.
21
Many surveys of agile methods since 2003 AmbySoft and VersionOne collect annual data Agile benefits are above 50% in most categories
Surveys of Agile Methods
Rico, D. F. (2008). What is the return-on-investment of agile methods? Retrieved February 3, 2009, from http://davidfrico.com/rico08a.pdf.
22
Agile (138 pt.) and traditional methods (99 pt.) Agile methods fare better in all benefits categories Agile methods 359% better than traditional methods
Case Studies of Agile Methods
Rico, D. F. (2008). What is the ROI of agile vs. traditional methods? TickIT International, 10(4), 9-18.
Agile TraditionalCategory
Return on Investment 2,811%
Customer Satisfaction Imp.
Quality Improvement
Productivity Improvement
Schedule Reduction
Cost Reduction
470%
Difference
2,341%
56%
24%
55%
33%
9%
23
Analysis of 23 agile vs. 7,500 traditional projects Agile projects are 54% better than traditional ones Agile has lower costs (61%) and fewer defects (93%)
Benefits of Agile Methods
Mah, M. (2008). Measuring agile in the enterprise: Proceedings of the Agile 2008 Conference, Toronto, Canada.
Project Cost in Millions $
0.75
1.50
2.25
3.00
2.8
1.1
Before Agile
After Agile
61%LowerCost
Total Staffing
18
11
Before Agile
After Agile
39%LessStaff
5
10
15
20
Delivery Time in Months
5
10
15
20
18
13.5
Before Agile
After Agile
24%Faster
Cumulative Defects
625
1250
1875
2500
2270
381
Before Agile
After Agile
93%Less
Defects
24
Costs based on avg. productivity and quality Productivity ranged from 3.5 to 86 LOC an hour Costs were $226,807, benefits were $4,283,190
Agile Costs & Benefits
Formula
(10,000 21.2374 + 1.7972 10 100) 100
$4,283,190 $226,807
($4,283,190 – $226,807) $226,807 100%
($4,283,190 5) 1.055) – $226,807
$226,807 ($4,509,997 $226,807 – 1)
NORMSDIST(2.99) $4,283,190 –NORMSDIST(1.59) $226,807 EXP(–5% 5)
(10,000 10.51 – 6,666.67 9) 100 – $226,807
Value
$226,807
19:1
1,788%
$3,481,988
$12,010
$4,110,305
$4,283,190
Metric
Costs
B/CR
ROI
NPV
BEP
ROA
Benefits
5
1i(
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing.
25
XP ROI 18X more than traditional methods Scrum ROI 3.4X more than traditional methods Agile methods ROI 10X more than trad. methods
ROI of Agile Methods
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing.
3,103%
1,788%1,607% 1,499%
580%
173%
0%
925%
1,850%
2,775%
3,700%
XP Agile TDD PP Scrum CMMI®
Software Method
Ret
urn
on I
nves
tmen
t
26
Productivity is accelerated with light weight processes Quality goals are obtained with disciplined processes Agile Methods have up to 20 times lower total costs
Business Value of Agile Methods
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross.
27
Study of 15 agile vs. non-agile Fortune 500 firms Based on models to measure organizational agility Agile firms out perform non-agile firms by up to 36%
Value of Organizational Agility
Hoque, F., et al. (2007). Business technology convergence. The role of business technology convergence in innovation and adaptability and its effect on financial performance. Stamford, CT: BTM Institute.
28
Agenda
Agile MotivationAgile IntroductionAgile Justification
Agile Life Cycles
Agile PracticesAgile RequirementsAgile Project Mgt.Agile Planning
Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources
29
Created by Alistair Cockburn in 1991 Has 14 practices, 10 roles, and 25 products Scalable family of techniques for critical systems
Crystal Methods
Cockburn, A. (2002). Agile software development. Boston, MA: Addison-Wesley.
30
Created by Jeff Sutherland at Easel in 1993 Has 5 practices, 3 roles, 5 products, rules, etc. Uses EVM to burn down backlog in 30-day iterations
Scrum
Schwaber, K., & Beedle, M. (2001). Agile software development with scrum. Upper Saddle River, NJ: Prentice-Hall.
31
Created by group of British firms in 1993 15 practices, 12 roles, and 23 work products Non-proprietary RAD approach from early 1990s
Dynamic Systems Dev.
Stapleton, J. (1997). DSDM: A framework for business centered development. Harlow, England: Addison-Wesley.
32
Created by Jeff De Luca at Nebulon in 1997 Has 8 practices, 14 roles, and 16 work products Uses object-oriented design and code inspections
Feature Driven Development
Palmer, S. R., & Felsing, J. M. (2002). A practical guide to feature driven development. Upper Saddle River, NJ: Prentice-Hall.
33
Created by Kent Beck at Chrysler in 1998 Has 28 practices, 7 roles, and 7 work products Popularized pair programming and test-driven dev.
Extreme Programming
Beck, K. (2000). Extreme programming explained: Embrace change. Reading, MA: Addison-Wesley.
UserStories
ArchitecturalSpike
ReleasePlanning Iteration Acceptance
TestsSmall
Releases
Spike
TestScenarios
SystemMetaphor
CustomerApproval
LatestVersion
ReleasePlan
NextIteration
BugsNewStoriesRequirements
UncertainEstimates
ConfidentEstimates
34
Adapted to IT by Dave Anderson in 2006 Activities, buffers, queues, WIP limits, tasks, etc. Lean, JIT pull/demand system leading to high quality
Lean-Kanban
Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press.
35
Agenda
Agile MotivationAgile IntroductionAgile JustificationAgile Life Cycles
Agile Practices
Agile RequirementsAgile Project Mgt.Agile Planning
Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources
36
Term coined by Kent Beck in 1999 Customer who sits with developers full-time Fast and efficient way to capture customer needs
Onsite Customers
Tabaka, J. (2006). Collaboration explained: Facilitation skills for software project leaders. Upper Saddle River, NJ: Addison Wesley.
37
Created by Kent Beck at Chrysler in 1998 Project plan with a 30-60-90-day timing horizon Disciplined and adaptable project management F/W
Release Planning
Beck, K., & Fowler, M. (2004). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.
38
Term coined by Kent Beck in 1999 Functions or features of value to customers Highly-adaptable requirements engineering process
User Stories
Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.
39
Term coined by Jim Coplien in 1995 Consists of two side-by-side developers Highly-effective group problem-solving technique
Pair Programming
Williams, L., & Kessler, R. (2002). Pair programming illuminated. Boston, MA: Pearson Education.
40
Term coined by William Opdyke in 1990 Process of frequently redesigning the system Improves readability, maintainability, and quality
Refactoring
Fowler, M. (1999). Refactoring: Improving the design of existing code. Boston, MA. Addison-Wesley.
41
Term coined by Kent Beck in 2003 Consists of writing all tests before design Ensures all components are verified and validated
Test-Driven Development
Beck, K. (2003). Test-driven development: By example. Boston, MA: Addison-Wesley.
42
Term coined by Martin Fowler in 1998 Process of automated build/regression testing Evaluates impact of changes against entire system
Continuous Integration
Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration: Improving software quality and reducing risk. Boston, MA: Addison-Wesley.
43
Agenda
Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile Practices
Agile Requirements
Agile Project Mgt.Agile Planning
Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources
44
Requirement written from perspective of a user Function or a feature that has value to a customer Discrete unit of functionality written on an index card
User Story
Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.
45
Conditions of satisfaction added to user stories Serve as a set of user acceptance test criteria Used for development and operational tests
Conditions of Satisfaction
Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.
46
Details can be added in smaller sub-stories Good way to functionally-decompose user stories May also represent an object-oriented point-of-view
Detailed Sub-Stories
Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.
47
Epics are very large enterprise requirements They are often called capabilities or feature sets A very-large unit of work that must be decomposed
Epics
Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.
48
Form stakeholder groups to brainstorm user stories Goal is to write as many user stories as possible Start with epics and decompose user stories
User Story Workshops
Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.
49
Agenda
Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile Requirements
Agile Project Mgt.
Agile Planning
Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources
50
Created by Jim Highsmith at Cutter in 2003 Focus on strategic plans and capability analysis Most holistic agile project management framework
Agile Project Management
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Innovation Lifecycle
Envision
Product Vision Product Architecture Project Objectives Project Community Delivery Approach
Speculate
Gather Requirements Product Backlog Release Planning Risk Planning Cost Estimation
Explore
Iteration Management Technical Practices Team Development Team Decisions Collaboration
Launch
Final Review Final Acceptance Final QA Final Documentation Final Deployment
Close
Clean Up Open Items Support Material Final Retrospective Final Reports Project Celebration
Iterative Delivery
Technical Planning
Story Analysis Task Development Task Estimation Task Splitting Task Planning
Standups, Architecture, Design, Build, Integration, Documentation, Change, Migration, and IntegrationStory Deployment
Adapt
Focus Groups Technical Reviews Team Evaluations Project Reporting Adaptive Action
Operational Testing
Integration Testing System Testing Operational Testing Usability Testing Acceptance Testing
Development, Test, & Evaluation
Development Pairing Unit Test Development Simple Designs Coding and Refactoring Unit and Component Testing
Continuous
51
Determine product vision and project objectives Identifies project community and project team The major output is a “Product Vision Box”
Envision Phase
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Envision Phase
Delivery Approach
Self-Organization Strategy Collaboration Strategy Communication Strategy Process Framework Tailoring Practice Selection & Tailoring
Project Objectives
Project Data SheetKey Business ObjectivesTradeoff MatrixExploration FactorRequirements Variability
Product Architecture
Skeleton Architecture Hardware Feature Breakdown Software Feature Breakdown Organizational Structure Guiding Principles
Project Community
Get the Right People Participant Identification Types of Stakeholders List of Stakeholders Customer-Developer Interaction
Product Vision
Product Vision Box Elevator Test Statement Product Roadmap Product Features Product Vision Document
52
Determine organizational capability/mission needs Identifies feature-sets and system requirements The major output is a “System Release Plan”
Speculate Phase
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Speculate Phase
Release Planning
Project Startup Activities Assign Stories to Iterations First Feasible Deployment Estimate Feature Velocity Determine Product Scope
Risk Planning
Risk Identification Risk Analysis Risk Responses Risk Monitoring Risk Control
Product Backlog
Product Features List Feature Cards Performance Requirements Prioritize Features Feature Breakdown Structure
Cost Estimation
Establish Estimate Scope Establish Technical Baseline Collect Project Data Size Project Information Prepare Baseline Estimates
Gather Requirements
Analyze Feasibility Studies Evaluate Marketing Reports Gather Stakeholder Suggestions Examine Competitive Intelligence Collaborate with Customers
53
Determine technical iteration objectives/approaches Identifies technical tasks and technical practices The major output is an “Operational Element”
Explore Phase
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Explore Phase
Team Development
Focus Team Molding Group into Team Develop Individual Capabilities Coach Customers Orchestrate Team Rhythm
Team Decisions
Decision Framing Decision Making Decision Retrospection Leadership and Decision Making Set and Delay Decision Making
Technical Practices
Reduce Technical Debt Simple Design Continuous Integration Ruthless Automated Testing Opportunistic Refactoring
Collaboration
Pair Programming Daily Standup Meetings Daily Product Team Interaction Stakeholder Coordination Customer Interactions
Iteration Management
Iteration Planning Estimate Task Size Iteration Length Workload Management Monitoring Iteration Progress
Launch Phase
Final Quality Assurance
Final Functional Configuration Audit Final Physical Configuration Audit Final Quality Assurance Plan Review Final QA Procedures Review Final Quality Assurance Review
Final Documentation
Final Release Plans Final Requirements Database Final Development Documents Final Maintenance Documents Final Operations Documents
Final Acceptance
Final Test Plan Review Final Test Case Review Final Test Environment Review Final Acceptance Test Review Final Test Results Review
Final Deployment
Final Source Code Final Build Final Integration Final Image Final Deployment Package
Final Review
Final Release Plan Review Final Requirements Review Final Design Review Final Code Review Final Development Team Review
54
Determine the state of the final deployment system Perform final development, test, and QA reviews The major output is a “Deployment Package”
Launch Phase
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
55
Determine project outcome and effectiveness Identifies strengths, weaknesses, and rewards The major output is a “Lessons-Learned Report”
Close Phase
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Close Phase
Support Material
Finalize Documentation Finalize Production Material Finalize Manufacturing Material Finalize Customer Documentation Finalize Maintenance Information
Final Reports
End-of-Project Reports Administrative Reports Release Notes Financial Reports Facilities Reports
Final Retrospective
Process Performance Assessment Internal Product Assessment External Product Assessment Team Performance Assessment Project Performance Assessment
Project Celebration
Individual Rewards Group Rewards Partner Rewards Managerial Rewards Product Rewards
Clean Up Open Items
Close Open Action Items Close Open Change Requests Close Open Problem Reports Close Open Defect Reports Close Open Project Issues
56
Agile management is delegated to the lowest level There remain key leadership roles & responsibilities Communication, coaching, & facilitation are key ones
Leadership Considerations
Rico, D. F. (2010). The paradox of agile project management and virtual teams. Fairfax, VA: Gantthead.Com.
Customer Communication
Product Visioning
Distribution Strategy
Team Development
Standards & Practices
Telecom Infrastructure
Development Tools
High Context Meetings
Coordination Meetings
F2F Communications
Performance Management
Facilitate selection of methods for obtaining and maintaining executive commitment, project resources, corporate communications, and customer interactionFacilitate selection of methods for communicating product purpose, goals, objectives, mission, vision, business value, scope, performance, budget, assumptions, constraints, etc.
Facilitate selection of virtual team distribution strategy to satisfy project goals and objectives
Facilitate selection of methods for training, coaching, mentoring, and other team building approachesFacilitate selection of project management and technical practices, conventions, roles, responsibilities, and performance measures
Facilitate selection of high bandwidth telecommunication products and services
Facilitate selection of agile project management tools and interactive development environment
Facilitate selection of high context agile project management and development meetings
Facilitate selection of meetings and forums for regular communications between site coordinatorsFacilitate selection of methods for maximizing periodic face to face interactions and collaborationFacilities selection of methods for process improvement, problem resolution, conflict management, team recognition, product performance, and customer satisfaction
57
Agenda
Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.
Agile Planning
Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources
58
Release planning is basic agile planning approach Begins with capturing and ordering customer needs Output is a release plan with resources and timelines
Release Planning
Write User Stories Estimate User Stories Prioritize User Stories Split User Stories Develop Release Plan
Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education.
• Estimate size using Delphi (PERT)
• Estimate using planning poker
• Estimate using analogy
• Estimate user algorithmic models
• Estimate using prototypes (spikes)
• Hold customer meeting
• Propose user stories
• Clarify user stories
• Record user stories
• Verify user stories
• Estimate total resources
• Estimate business value
• Estimate technical risks
• Sequence user stories
• Verify overall sequence
• Evaluate story size
• Evaluate needed resources
• Evaluate business value
• Evaluate risks and sequence
• Divide and reorder user stories
• Select release scope
• Select iteration velocity & length
• Estimate release budget
• Identify overall constraints
• Develop release plan
59
Release planning begins by identifying user needs User needs are captured in form of user stories Customer records needs on user story cards
Write User Stories
Write User Stories
HoldCustomerMeeting
ProposeUser
Stories
ClarifyUser
Stories
RecordUser
Stories
VerifyUser
Stories
Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education.
60
The complexity of each user story is then estimated Complexity is captured in the form of story points Story points are a relative size of user needs
Estimate User Stories
Estimate User Stories
EstimateUsing
Delphi (PERT)
EstimateUsing
Planning Poker
EstimateUsing
Analogy
EstimateUsing
Algorithmic Models
EstimateUsing
Prototypes (Spikes)
Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education.
61
Customers must prioritize all of their user stories Cost, value, risk, and other factors are considered Tradeoffs are made when rank ordering user stories
Prioritize User Stories
Prioritize User Stories
EstimateTotal
Resources
EstimateBusiness
Value
EstimateTechnical
Risks
SequenceUser
Stories
VerifyOverall
Sequence
Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education.
62
Stories may be decomposed for a variety of reasons Oftentimes, user stories are too big and complex Customers are responsible for splitting them
Split User Stories
Split User Stories
EvaluateUser Story
Size
EvaluateNeeded
Resources
EvaluateBusiness
Value
EvaluateRisks andSequence
Divideand ReorderUser Stories
Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education.
63
Customers identify which user stories they want Developers estimate iteration length, budget, etc. A release plan is designed covering 9 to 18 months
Develop Release Plan
Develop Release Plan
SelectReleaseScope
SelectIteration
Velocity & Length
EstimateReleaseBudget
IdentifyOverall
Constraints
DevelopRelease
Plan
Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education.
64
An example of release and iteration plan Relationships between user stories and plans Shows key data such as story points and velocity
Release & Iteration Plan
Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education.
Product Backlog, Release Plan, & Iteration Plan
Product BacklogUser Story Points
Find a flight 1
Reserve a flight 2
Book a flight 4
Verify a flight 1
Generate itinerary 2
Check flight status 4
Change flight 4
Cancel flight 1
Get a refund 2
Release PlanRelease Iteration
Release 1 Iteration 1
Iteration 2
Iteration 3
Release 2 Iteration 4
Iteration 5
Iteration 6
Release 3 Iteration 7
Iteration 8
Iteration 9
Iteration PlanTask Team Plan Actual
Specify airport Bob/Sue 2 hours 1 hours Specify dates 2 hours 1 hours Specify times 2 hours 1 hours Enter name John/Dave 4 hours 3 hours Enter address 4 hours 3 hours Get confirmation no 4 hours 3 hours Enter credit card Barb/Carol 8 hours 6 hours Enter billing info 8 hours 6 hours Get receipt 8 hours 6 hours Enter confirmation no Matt/Ken 2 hours 2 hours View itinerary 2 hours 2 hours View payment info 2 hours 2 hours Enter confirmation no Jim/Jane 4 hours 3 hours Print itinerary 4 hours 3 hours Download itinerary 4 hours 3 hours Enter confirmation no Nat/Tim 8 hours 6 hours View flight status 8 hours 6 hours View gate info 8 hours 6 hours Enter confirmation no Kim/Pat 8 hours 6 hours Change dates 8 hours 6 hours Change times 8 hours 6 hours Enter confirmation no Sam/Ron 2 hours 2 hours Cancel flight 2 hours 2 hours Verify cancellation 2 hours 2 hours Enter confirmation no Mark/Dan 4 hours 4 hours Initiate refund 4 hours 4 hours Verify refund status 4 hours 4 hours
65
Agenda
Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning
Agile Estimating
Agile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources
66
Created by RAND corporation in 1940s Applied to software effort estimation in 1970s Relies on expert judgment and consensus (PERT)
Wideband Delphi (PERT)
Estimate Using Wideband Delphi (PERT)
HoldMeeting withCustomers
ReviewEach
User Story
SolicitIndividualEstimates
Use PERTto CombineEstimates
Discussand VerifyEstimates
Graefe, A., & Armstrong, J. S. (2011). Comparing face-to-face meetings, nominal groups, delphi, and prediction markets on an estimation task.International Journal of Forecasting, 27(1), 183-195.
67
Created by James Grenning for Scrum in 2002 Similar to Wideband Delphi (or PERT) estimating Goal is to estimate size (complexity) in story points
Planning Poker
Estimate Using Planning Poker
HoldMeeting withCustomers
DistributePlanning
Poker Cards
ReviewEach
User Story
Vote onSize in
Story Points
Discussand VerifyEstimates
Molokken-Ostvold, K., & Haugen, N. C. (2007). Combining estimates with planning poker: An empirical study. Proceedings of the 18th AustralianSoftware Engineering Conference (ASWEC 2007), Melbourne, Australia, 349-358.
68
Utilized for software estimating in the 1970s Goal is to match new user stories with prior ones Generates estimate based on similar historical work
Analogous Estimating
Estimate by Analogy
HoldMeeting withCustomers
ReviewEach
User Story
AnalyzePrevious
User Stories
MatchOld and NewUser Stories
Agree onSize of NewUser Stories
Wen, J., Li, S., & Tang, L. (2009). Improve analogy-based software estimation using principal components analysis and correlation weighting.Proceedings of the 16th Asia-Pacific Software Engineering Conference (APSEC'2009), Penang, Malaysia, 179-186.
69
First regression models popularized in 1970s Grew into complex logarithmic models in 1990s Many algorithms and tools exist for agile estimates
Algorithmic Models
Estimate Using Algorithmic Models
HoldMeeting withCustomers
ReviewEach
User Story
SelectOne or More
Algorithmic Models
GenerateOne or MoreEstimates
AverageOutput of
Algorithmic Models
Rico, D. F. (2008). What is the ROI of agile vs. traditional methods? An analysis of extreme programming, test-driven development,pair programming, and scrum (using real options). TickIT International, 10(4), 9-18.
70
Prototyping applied to software in the 1970s Used for estimation by JAD and Spiral in 1980s Agile teams create rapid “Spikes” to size user stories
Prototypes (Spikes)
Estimate Using Prototypes (Spikes)
HoldMeeting withCustomers
ReviewEach
User Story
IdentifyProblematicUser Stories
DevelopRapid
Prototype (Spike)
EstimateUser Story
from New Data
Keaveney, S., & Conboy, K. (2006). Cost estimation in agile development projects. Proceedings of theEuropean Conference on Information Systems (ECIS 2006), Goteborg, Sweden.
71
Agenda
Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning
Agile Estimating Agile Testing
Agile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources
72
Traditional testing is a late, manual process Agile testing is an early and automated process The goal of agile testing is to deliver early and often
What is Agile Testing?
Grant, T. (2005). Continuous integration using cruise control. Northern Virginia Java Users Group (Novajug), Reston, Virginia, USA.
Traditional Testing
Combining source files
Combining software and environment
Combining software and data
Combining software and tests
Combining developers
Agile Testing
Code is frequently checked in
Code is automatically retrieved
Compilation is done automatically
Tests are done automatically
Code reports are generated
Developers get instant feedback
Code is automatically deployed or packaged for delivery
73
Developers check-in changes as they occur Server detects all changes and initiates testing Server compiles, tests, analyzes, builds, and deploys
Agile Automated Testing
Rady, B., & Coffin, R. (2011). Continuous testing: With ruby, rails, and javascript. Raleigh, NC: Pragmatic Bookshelf.Humble, J., & Farley, D. (2011). Continuous delivery: Reliable software releases through build, test, and deployment automation. Boston, MA: Pearson.
BuildIntegration
Server
VersionControlServer
BuildScripts
UsesWatches
BuildStatus
ProvidesDeveloper A
Developer B
Developer C
CommitsChanges
CommitsChanges
CommitsChanges
Compile Source Code
Run Unit Tests
Run Coverage TestsStatic Code Analysis
Build Database
Generate Help FilesArchive and Deploy
74
Agile testing consists of seven broad practices Includes automated builds, testing, inspections, etc. Also includes reporting, documentation, deployment, etc.
Agile Testing Practices
Practice
Building
Database
Inspections
Testing
Feedback
Documentation
Deployment
Description
Frequently assembling products and services to ensure delivery readiness
Frequently generating/analyzing database schemas, queries, and forms
Frequently performing automated static analysis of product/service quality
Frequently performing automated dynamic product and service evaluation
Frequently generating automated status reports/messages for all stakeholders
Frequently performing automated technical/customer document generation
Frequently performing automated delivery of products/services to end users
Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration: Improving software quality and reducing risk. Boston, MA: Addison-Wesley.
75
Fewer builds leave in higher bug counts A high number of builds eliminates the defects Goal is to have as many, early builds as possible
Agile Testing Statistics
Lacoste, F. J. (2009). Killing the gatekeeper: Introducing a continuous integration system. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA, 387-392.
76
Agile testing slows down with very large systems Slow testing slows integration and increases bugs Agile testing can speed back up with proper attention
Scaling Agile Testing
Kokko, H. (2009). Increase productivity with large scale CI: Reduce feedback cycle from weeks to 100 minutes. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA.
77
Most agile testing tools are “free” open source A build server is no more than a commodity PC 10x more efficient/effective than traditional testing
Agile Testing Costs & Benefits
Grant, T. (2005). Continuous integration using cruise control. Northern Virginia Java Users Group (Novajug), Reston, Virginia, USA.Fredrick, J. (2008). Accelerate software delivery with continuous integration and testing. Japanese Symposium on Software Testing, Tokyo, Japan.
78
Agile testing is 10x more efficient than manual tests ROI of agile testing is 27x more than traditional testing Performed 1,500x more often than traditional tests yearly
Agile Testing Cost of Quality
Rico, D. F. (2012). The Cost of Quality (CoQ) for Agile vs. Traditional Project Management. Fairfax, VA: Gantthead.Com.
79
Eliminates big-bang integration in the 11th hour Creates a repeatable and reliable testing process Evaluates system-wide changes throughout project
Agile Testing Side Effects
Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration: Improving software quality and reducing risk. Boston, MA: Addison-Wesley.
80
Agenda
Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning
Agile EstimatingAgile Testing
Agile Teamwork
Agile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources
81
A key element of any project is good teamwork Agile projects depend upon teamwork even more Balance between cohesion & out-of-the-box thinking
Agile Teamwork Model
Rico, D. F. (2011). The key attributes and factors of teams and teamwork for agile project management. Fairfax, VA: Gantthead.Com.
Factor
Leadership
Boundaries
Empowerment
Competence
Structure
Manageability
Motivation
Attributes
Credible, experienced, likeable, & nurturing project champion
Clear vision, mission, goals, & objectives
Adequate time, money, tools, & authority
Applicable skills, knowledge, experience, & personality
Clear roles, responsibilities, technical approach, & operating rules
Small, collaborative, cohesive, & frequently-communicating
Compensation, incentives, desire-to-succeed, & consequences
82
Agile teams start with great servant-leaders Agile teams rely more on coaches and mentors Coaches and mentors are wise and trusted teachers
Well-Coached
Davies, R., & Sedley (2009). Agile coaching. Raleigh, NC: Pragmatic Bookshelf.Adkins, L. (2010). Coaching agile teams: A companion for scrummasters, agile coaches, and project managers in transition. Boston, MA: Addison-Wesley.
83
Agile teams must be given clearly-stated mission Customers should specify their needs, not solution Agile teams must form a clear vision of the end-state
Clear Vision
Belsky, S. (2010). Making ideas happen: Overcoming the obstacles between vision and reality. New York, NY: Penguin Group.Kossoff, L. L. (1999). Executive thinking: The dream, the vision, the mission achieved. Palo Alto, CA: Davies-Black Publishing.Bates, S. (2009). Motivate like a CEO: Communicate your strategic vision and inspire people to act. New York, NY: McGraw-Hill.
84
Agile teams are empowered to get the job done Teams must have power, authority, and resources Egalitarian decision-making unleashes team capability
Fully-Empowered
Wordenweber, B. (2005). Innovation cell: Agile teams to master disruptive innovation. Berlin, Germany: Springer-Verlag.Wellins, R. S., Byham, W. C., & Wilson, J. M. (1993). Empowered teams: Creating self-directed work groups that improve quality, productivity, and participation. San Francisco, CA: Jossey-Bass..
85
Agile teams consist of highly-competent individuals Individuals must have the requisite training and skills Highly-talented individuals are the heart of agile teams
Highly-Talented
Bach, J. (1995). Enough about process: What we need are heroes. IEEE Software, 12(2), 96-98.Hunt, A., & Thomas, D. (1999). The pragmatic programmer. From journeyman to master. Reading, MA: Addison-Wesley.Martin, R. C. (2009). Clean code: A handbook of agile software craftsmanship. Upper Saddle River, NJ: Prentice-Hall.
86
Agile teams should be small and very manageable They should exhibit collectivism, cohesion, and trust Agile teams must seamlessly complement each other
Great Teamwork
Eckert, B., & Vehar, J. (2007). More lightning, less thunder: How to energize innovation teams. Paul Smiths, NY: New & Improved.Ancona, D., & Bresman, H. (2007). X-teams: How to build teams that lead, innovate, and succeed. Boston, MA: Harvard Business School Press.Kayser, T. (2010). Mining group gold: How to cash in on the collaborative brain power of a team for innovation and results. New York, NY: McGraw-Hill.
87
Agenda
Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning
Agile EstimatingAgile TestingAgile Teamwork
Agile Scrum
Agile TrackingAgile Case StudiesAgile SummaryAgile Resources
88
Created by Jeff Sutherland at Easel in 1993 Product backlog comprised of customer needs Barely-sufficient project management framework
Scrum Project Management
Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.
Initial Planning Sprint Cycle
Discovery Session
Agile Training Project Discovery Process Discovery Team Discovery Initial Backlog
Release Planning
Business Case Desired Backlog Hi-Level Estimates Prioritize Backlog Finalize Backlog
Product Backlog
Prioritized Requirements
Sprint Planning
Set Sprint Capacity Identify Tasks Estimate Tasks
Sprint Review
Present Backlog Items Record Feedback Adjust Backlog
Daily Scrum
Completed Backlog Items Planned Backlog Items Impediments to Progress
Sprint Backlog
List of Technical Tasks Assigned to a Sprint
Potentially Shippable Product
Working Operational Software
Sprint
Select Tasks and Create Tests Create Simple Designs Code and Test Software Units Perform Integration Testing Maintain Daily Burndown Chart Update Sprint Backlog
Sprint Retrospective
89
There are only three roles in the Scrum paradigm Product Owner is single wringable neck (cust. rep.) Scrum Master is overall process facilitator (i.e., coach)
Scrum Roles
Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.
Scrum Master
Product Owner Scrum Team
Scrum
Planning Progress
Clarification
Scrum Master - Responsible for facilitating the process
Product Owner - Represents the client and owns the requirements
Scrum Team - Responsible for completing the work and fulfilling the requirements
Scrum Master assists the Product Owner in planning the release and making resources available
Scrum Master helps the Scrum Team make progress by removing impediments
Product Owner works closely with the Scrum Team to provide clarification and approval on requirements
Whole team meets daily to review progress and review the completed work at the end of each sprint
90
An eight hour timeboxed Sprint planning meeting Identifies highest priority requirements to implement Purpose is to produce a Sprint plan for 14 to 30 days
Sprint Planning
Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.
Prepare Sprint
Ask QuestionsDevelop TasksCreate EstimatesMake Assignments
Release Planning
Create Stories Make ROI Goals Set Release Plans
Select Stories
Select StoriesSuggest StoriesDetermine Stories
CustomerNeeds
ProductBacklog
Agreed toBacklog
SprintBacklog
Product Owner, Scrum Master, Team
Eight Hour Time Limit
91
A 14 to 30 day timeboxed development iteration High priority requirements decomposed into tasks Purpose is to produce shippable product increment
Sprint
Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.
Track Status
Checkoff TasksEstimate VelocityBurndown Charts
Manage Sprint
Freeze Backlog Seek Information Adjust Backlog Decision to Proceed Create Product
Analyze TasksDesign Solution Implement Solution Test Solution
SprintBacklog
DevelopmentTasks
DevelopmentStatus
ShippableProduct
30 Day Time Limit
Product Owner, Scrum Master, Team
92
A 15 minute timeboxed daily status meeting Developers state progress in a round robin style Purpose is to ensure that developers collaborating
Daily Scrum Meeting
Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.
Establish Followup
Ask for Help Identify IssuesPlan Followup
Meeting Kickoff
Begin Meeting Facilitate Meeting Enforce Protocols
Report Status
Report ProgressState Daily PlansNote Impediments
Yesterday’sProgress
MeetingInitiation
DailyStatus
FollowupNotices
15 Minute Time Limit
Product Owner, Scrum Master, Team
93
A four hour timeboxed product demonstration Developers discuss requirements implemented Purpose is to show customers the result of Sprint
Sprint Review
Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.
Close Review
Gauge SatisfactionRearrange Backlog Identify New Needs
Prepare for Review
Arrange Location Verify Product Prepare Demo
Hold Review
State Sprint Goal List RequirementsReport ProgressPresent Product
ShippableProduct
ProductDemo
CustomerFeedback
NewBacklog
Four Hour Time Limit
Product Owner, Scrum Master, Team, Customers
94
A three hour timeboxed lessons learned meeting Developers identify potential process improvements Purpose is to identify new non-functional requirements
Sprint Retrospective
Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.
Review Changes
Discuss ChangesPrioritize ChangesBaseline Chances
Facilitate Meeting
Check Attendance Verify Preparations Enforce Protocol
Hold Retrospective
State StrengthsState WeaknessesState Improvements
SprintResults
SprintOutcomes
ProcessImprovements
ApprovedChanges
Three Hour Time Limit
Product Owner, Scrum Master, Team
95
Agenda
Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning
Agile EstimatingAgile TestingAgile TeamworkAgile Scrum
Agile Tracking
Agile Case StudiesAgile SummaryAgile Resources
96
Most basic tracking chart for agile projects Tracks number of work or time units completed Commonly used to track no. story points completed
Burndown
Rawsthorne, D. (2009). Agile metrics. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA.
Burndown Chart
Wor
k (S
tory
, Poi
nt, T
ask)
or E
ffor
t (W
eek,
Day
, Hou
r)
Planning (Roadmap, Release, Iteration) or Time Unit (Month, Week, Day)
97
Popular tracking chart for agile projects Tracks number of work or time units completed Basic form of cumulative workflow & overall progress
Burnup
Nicolette, D. (2009). Agile metrics. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA.
Wor
k (S
tory
, Poi
nt, T
ask)
or E
ffor
t (W
eek,
Day
, Hou
r)
Planning (Roadmap, Release, Iteration) or Time Unit (Month, Week, Day)
Burnup Chart
98
High work-in-process leads to longest lead times Low work-in-process greatly reduces lead times Results in better customer trust and satisfaction
Cumulative Flow
Anderson, D. J. (2004). Agile management for software engineering: Applying the theory ofconstraints for business results. Upper Saddle River, NJ: Pearson Education.
Traditional vs. Agile Cumulative Flow
Wor
k (S
tory
, Poi
nt, T
ask)
or E
ffor
t (W
eek,
Day
, Hou
r)
Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.)
Wor
k (S
tory
, Poi
nt, T
ask)
or E
ffor
t (W
eek,
Day
, Hou
r)
Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.)
Traditional Cumulative Flow Agile Cumulative Flow
99
Adaptation of EVM for agile projects Mapping between traditional and agile projects Work completed is more authoritative in agile projects
Agile EVM
Sulaiman, T., Barton, B., & Blackburn, T. (2006). Agile EVM: Earned value management in scrum projects.Proceedings of the Agile 2006 Conference (Agile 2006), Minneapolis, Minnesota, USA, 7-16.
Agile EVM
CPI
SPI
PPC
APC
Wor
k (S
tory
, Poi
nt, T
ask)
or E
ffor
t (W
eek,
Day
, Hou
r)
Planning (Roadmap, Release, Iteration) or Time Unit (Month, Week, Day)
100
ROI is estimated for user stories in agile projects Value accrues with each completed user story Value of completed tasks is more meaningful
Earned Business Value
Rawsthorne, D. (2010). Monitoring scrum projects with agile evm and earned business value metrics. Brisbane, CA: Collab.Net.
Earned Business Value
Wor
k (S
tory
, Poi
nt, T
ask)
or E
ffor
t (W
eek,
Day
, Hou
r)
Planning (Roadmap, Release, Iteration) or Time Unit (Month, Week, Day)
101
Agenda
Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning
Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile Tracking
Agile Case Studies
Agile SummaryAgile Resources
102
80% of worldwide IT projects use agile methods Includes highly-regulated industries like U.S. DoD Even split between top-down and bottom-up adoption
Agile Case Studies
Rico, D. F. (2010). Lean and agile project management: For large programs and projects. Proceedings of the First International Conference on Lean Enterprise Software and Systems, Helsinki, Finland, 37-43.
Industry
ShrinkWrapped
ElectronicCommerce
HealthCare
LawEnforcement
Org 20 teams 140 people 5 countries
Size
15 teams 90 people Collocated 4 teams 20 people Collocated 10 teams 50 people Collocated 3 teams 12 people Collocated
U.S.DoD
Primavera
Stratcom
FBI
FDA
Project
Primavera
Adwords
SKIweb
Sentinel
m2000
Purpose
ProjectManagement
Advertising
KnowledgeManagement
Case FileWorkflow
BloodAnalysis
1,838 User Stories 6,250 Function Points 500,000 Lines of Code
Metrics
26,809 User Stories 91,146 Function Points 7,291,666 Lines of Code 1,659 User Stories 5,640 Function Points 451,235 Lines of Code 3,947 User Stories 13,419 Function Points 1,073,529 Lines of Code 390 User Stories 1,324 Function Points 105,958 Lines of Code
103
Google started using agile methods in 2005 Used it on one of their most profitable products Incrementally adopted agile one practice at a time
E-Commerce—Google
Striebeck, M. (2006). Ssh: We are adding a process. Proceedings of the Agile 2006 Conference (Agile 2006), Minneapolis, Minnesota, USA, 193-201.
Project Name
Project Type
Project Size
Product Size
Environment
Before APM
APM Practices
After APM
Lessons Learned
AdWords
Pay-per-Click (PPC) Internet Advertising Mechanism
20 teams of 140 people distributed over 5 countries
1,838 user stories, 6,250 function points, 500,000 lines of code
Entrepreneurial, egalitarian, dynamic, unpredictable, informal, unstructured
Chronic schedule delays, poor quality, unpredictability, poor estimation
Release planning, wikis for APM support, early testing and continuous integration
Better planning and estimates, earlier testing, better quality, large-scale adoption
Agile fit like a hand-in-glove, introduce agile methods slowly and then scale-up
104
Primavera started using agile methods in 2004 Used it on their flagship project management tools Adopted agile all-at-once with top-down mgt. support
Shrink-Wrapped—Primavera
Schatz, B., & Abdelshafi, I. (2005). Primavera gets agile: A successful transition to agile development. IEEE Software, 22(3), 36-42.
Project Name
Project Type
Project Size
Product Size
Environment
APM Practices
After APM
Lessons Learned
Primavera
Enterprise Project Management Tool
15 teams of 90 people collocated at one site
26,809 user stories, 91,146 function points, 7,291,666 lines of code
Top-down, hierarchical, command and control, traditional, waterfall approach
Release planning, agile project management tools, automated testing tools
75% quality and 40% cycle time improvement, 40-hour work week, 0% attrition
Agile results in better communication, motivation, and empowerment
Before APM Poor relationships, quality, usability, and customer satisfaction, functional silos,18-hour days, 7-day work weeks, frustration, disappointment, apathy, exhaustion
105
FDA suppliers started using agile methods in 2008 Used it on most stringent Class 3 certified products Used to modernize 1990s era products & processes
Healthcare—FDA
Rasmussen, R., Hughes, T., Jenks, J. R., & Skach, J. (2009). Adopting agile in an FDA regulated environment. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 151-155.
Project Name
Project Type
Project Size
Product Size
Environment
APM Practices
After APM
Lessons Learned
m2000 Real-time PCR Diagnostics System
Human Blood Analysis Tool (i.e., HIV-1, HBV, HCV, CT, NG, etc.)
4 teams of 20 people collocated at one site
1,659 user stories, 5,640 function points, 451,235 lines of code
FDA-regulated medical devices, real-time, safety-critical, Class III–most stringent
Release planning, lighter-weight agile testing techniques, continuous integration
25% cycle time and staff-size reduction, 43% cost reduction, fewer defects
Agile enables the ability to balance fast cycle time with high-quality safety-critical solutions
Before APMCumbersome process, poor quality, long cycle time, slow big-bang integration, obsolete, hard-to-staff tools and methods, inability to keep pace with changing requirements,Intense market competition, exponential rate of technological change, fewer resources
106
IC started using agile methods following 9/11 Used it on billion dollar transformation initiatives Goal is to catch bad guys better, faster, and cheaper
Law Enforcement—FBI
Babuscio, J. (2009). How the FBI learned to catch bad guys one iteration at a time. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 96-100.
Project Name
Project Type
Project Size
Product Size
Environment
Before APM
APM Practices
After APM
Lessons Learned
Inter-Agency Intelligence Sharing System
Domestic Terrorist Database/Data Warehouse
3 teams of 12 people collocated at one site
643 user stories, 2,188 function points, 175,000 lines of code
CMMI Level 3, ISO 9001, government-mandated document-driven waterfall life cycle, emerging federal directives for more information sharing and integration amongintelligence community partners, rapidly changing customer requirements
Unresponsive waterfall life cycles, chronic schedule delays, anxious customers, unhappy developers, resource focus on becoming CMMI Level 3 certified caused everyone to lose track of the real goal, which was to “catch bad guys”
Release planning, user stories, test-driven development, continuous integration
50% quality improvement, 200% productivity increase, FBI created policy for agile methods
Agile enables fast response times, customer satisfaction, and ability to "catch bad guys"
107
U.S. DoD started using agile methods following 9/11 Used it on billion-dollar software-intensive systems Goals are to respond to rapidly emerging threats
U.S. DoD—STRATCOM
Fruhling, A., McDonald, P, & Dunbar, C. (2008). A case study: Introducing extreme programming in a U.S. government system development project. Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 2008), Waikaloa, Big Island, Hawaii, USA, 464-473.
Project Name
Project Type
Project Size
Product Size
Before APM
APM Practices
After APM
Lessons Learned
Strategic Knowledge Integration Website (SKIweb)
Knowledge Management System (KMS)—Advanced Search Capability
3 teams of 12 people collocated at one site
390 user stories, 1,324 function points, 105,958 lines of code
Long cycle times, dissatisfied customers, unresponsive life cycles, poor quality
Release planning, frequent customer collaboration, continuous integration
Good teamwork, 200% productivity increase, improved quality, fewer defects
Agile improves customer satisfaction/communication, and overall product quality
EnvironmentTraditional linear documentation-based development, contract-oriented, hierarchical communication, rapidly changing operational requirements, need for leaner U.S. military force, seeking better and faster ways of getting critical information to decision makers, decentralization, migration to net-centric service oriented architectures, egalitarian decisions
108
Agenda
Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning
Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case Studies
Agile Summary
Agile Resources
109
Common myths still abound, although agile methods have been around for ~20 years Agile methods are only good for rapid prototypes Agile methods are only for software development Agile methods are only for small co-located teams Agile methods have no requirements or documents Agile methods need traditional system architectures Agile methods have no project management model Agile methods are undisciplined and unmeasurable Agile methods create unmaintainable systems Agile methods result in security vulnerabilities Agile methods mean deliver it fast and fix it later
Agile Myths
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing.
110
Myth that voluminous documentation is needed Myth that agile methods do not use documentation Right-sized, just-in-time processes and documentation
Agile Documentation
Rueping, A. (2003). Agile documentation: A pattern guide to producing lightweight documents for software projects. West Sussex, England: John Wiley & Sons.
Contracts
Document Type
Project Plans
Requirements
Architecture
Design
Coding
Tests
User guides
Quality Assurance
Agile Documentation
Performance-based, time-and-materials, level-of-effort
Release plans, iteration plans, story boards, agile repositories
User stories, wire frames, use cases, paper prototypes
Metaphors, spikes, system modeling language, DoDAF
Wire frames, design patterns, unified modeling language
Code patterns, program design language, coding comments
Unit, component, integration, system, and acceptance tests
XML documents, online help, Wikis, FAQs, video and audio clips
Performance, reliability, code structure analysis, and test reports
111
Agile methods are based on traditional measures Size, effort, and velocity metrics are most common Top-notch shops use complexity and testing metrics
Basic Agile Metrics
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing.
Type
Size
Effort
Velocity
Structure
Quality
Satisfaction
Business Value
Example
Story Points, Ideal Days, Function Points, Lines of Code, etc.
Ideal or Actual Hours, Days, Weeks, Months, Years, etc.
Release/Iteration Burndown/Burnup, Cumulative Flow, EVM, etc.
Object-Oriented, Relational Database, McCabe, Halstead, etc.
Running Tested Features, Defect Density, FURPS, MTBF, etc.
CUPRIMDA, Communications, Trust, Loyalty, Retention, etc.
Costs, Benefits, BEP, B/CR, ROI, NPV, IRR, ROA, EBV, etc.
112
Agile Methods are a fundamentally new paradigm Agile Methods are “not” lighter Traditional Methods They should not be viewed through a traditional lens
Advanced Agile Measures
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing.
Customer Collaboration
Working Software
Individuals & Interactions
Responding to Change
valuedmore than
valuedmore than
valuedmore than
valuedmore than
Agile
Met
rics
Traditional Metrics
Contracts
Documentation
Processes
Project Plans
Frequent comm. Close proximity Regular meetings
Multiple comm. channels Frequent feedback Relationship strength
Leadership Boundaries Empowerment
Competence Structure Manageability/Motivation
Clear objectives Small/feasible scope Acceptance criteria
Short/timeboxed durations Valid operational results Regular cadence/intervals
Org. flexibility Mgt. flexibility Process flexibility
System flexibility Technology flexibility Infrastructure flexibility
Contract compliance Contract deliverables Contract change orders
Lifecycle compliance Process Maturity Level Regulatory compliance
Document deliveries Document comments Document compliance
Cost Compliance Scope Compliance Schedule Compliance
113
Agile tools exist to support the entire lifecycle Key tools exist as free and open source software Maximize flexibility, efficiency, reporting, and quality
Agile Tools & Automation
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing.
114
New contract models emerged for agile contracts Goals, objectives, and visions are established early Buyers and suppliers collaborate throughout contract
Agile Contracting Models
Rico, D. F. (2011). The necessity of new contract models for agile project management. Fairfax, VA: Gantthead.Com.
Contract Type Description
Dynamic Value
Performance Based
Target Cost
Optional Scope
Collaborative
Lean
Specify initial scope and needs (with iterative enhancements)
Establish performance objectives (but not technical solutions)
Broad boundaries for time, cost, and quality (but not scope)
Set minimum and maximum costs (based on initial scope)
Outline initial scope (with fixed no. of releases and iterations)
Lean tools such as small batches, Kanban, WIP constraints, etc.
115
Change, no matter how small or large, is difficult Smaller focused changes help to cross the chasm Shrinking, simplifying, and motivation are key factors
How to Cross the Chasm
Heath, C., & Heath, D. (2010). Switch: How to change things when change is hard. New York, NY: Random House.Patterson, K., et al. (2008). Influencer: The power to change anything: New York, NY: McGraw-Hill.
How to Cross the Chasm
Switch How to Change Things When Change is Hard Influencer The Power to Change Anything
Direct the Rider
Follow the bright spots - Clone what works Script the critical moves - Use prescriptive behaviors Point to the destination - Focus on the end game
Motivate the Elephant
Find the feeling - Appeal to emotion Shrink the change - Use incremental change Grow your people - Invest in training and education
Shape the Path
Tweak the environment - Simplify the change Build habits - Create simple recipes for action Rally the herd - Get everyone involved
Make the Undesirable Desirable Create new experiences - Make it interesting Create new motives - Appeal to sensibility
Surpass your Limits Perfect complex skills - Establish milestones Build emotional skills - Build maturity and people skills
Harness Peer Pressure Recruit public personalities - Involve public figures Recruit influential leaders - Involve recognized figures
Find Strength in Numbers Utilize teamwork - Enlist others to help out Enlist the power of social capital - Scale up and out
Design Rewards and Demand Accountability Use incentives wisely - Reward vital behaviors Use punishment sparingly - Warn before taking action
Change the Environment Make it easy - Simplify the change Make it unavoidable - Build change into daily routine
116
Agility is the evolution of management thought Confluence of traditional and non-traditional ideas Improve performance by over an order-of-magnitude
Conclusion
“The world of traditional methods belongs to yesterday”“Don’t waste your time using traditional methods on 21st century projects”
Agile methods are …
Systems development approachesNew product development approachesExpertly designed to be fast and efficientIntentionally lean and free of waste (muda) Systematic highly-disciplined approachesCapable of producing high quality systemsRight-sized, just-enough, and just-in-time tools
Scalable to large, complex mission-critical systems Designed to maximize business value for customers
Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education.
117
Agenda
Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning
Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile Summary
Agile Resources
118
Term agile methods coined around 2001 Earliest holistic text books emerged in 2002 Highsmith, Shore, & Cockburn most complete
Intros to Agile Methods
Highsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.Shore, J., & Warden, S. (2008). The art of agile development. Sebastopol, CA: O'Reilly.Subramaniam, V., & Hunt, A. (2006). Practices of an agile developer. Raleigh, NC: Pragmatic Bookshelf.Cockburn, A. (2007). Agile software development: The cooperative game. Boston, MA: Pearson Education.Martin, R. C. (3003). Agile software development: Principles, patterns, and practices. Upper Saddle River, NJ: Pearson.
119
Over 15 text books for agile project management Many of them stem from Planning XP by Kent Beck Agile Project Mgt. by Jim Highsmith is most complete
Agile Project Management
Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.Leffingwell, D. (2011). Agile software requirements: Lean requirements practices for teams, programs, and the enterprise. Boston, MA: Pearson Education.Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education.
120
100s of agile methods books exist for all disciplines Range from requirements through documentation Thwart notion that agile methods have big gaps
Agile Development
Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.Coplien, J. O., & Bjornvig, G. (2010). Lean architecture: For agile software development. West Sussex, UK: John Wiley & Sons.Martin, R. C. (2008). Clean code: A handbook of agile software craftsmanship. Upper Saddle River, NJ: Prentice-Hall.Crispin, L., & Gregory, J. (2009). Agile testing: A practical guide for testers and agile teams. Boston, MA: Addison-Wesley.Ruping, A. (2003). Agile documentation: A pattern guide to producing lightweight documents for software projects. West Sussex, UK: John Wiley & Sons.