This document provides an overview of Lean and Agile project management approaches for executives and key decision makers. It discusses how modern systems have become more complex due to growing software usage and rapid technological changes. Traditional large projects often experience poor quality, scope changes, low productivity, and high failure rates. Lean and Agile methods aim to address these issues through iterative development, early delivery of business value, and flexibility to adapt to changing needs and technologies.
1. Lean & Agile
Project Management
for Executives, Sr. Managers,
& Key Decision Makers
Dr. David F. Rico, PMP, ACP, CSM
Twitter: @dr_david_f_rico
Website: http://www.davidfrico.com
LinkedIn: http://www.linkedin.com/in/davidfrico
Facebook: http://www.facebook.com/profile.php?id=1540017424
2. Author Background
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
Published six books & numerous journal articles
Adjunct at George Washington, UMUC, & Argosy
Agile Program Management & Lean Development
Specializes in metrics, models, & cost engineering
Six Sigma, CMMI, ISO 9001, DoDAF, & DoD 5000
Cloud Computing, SOA, Web Services, FOSS, etc.
2
3. Agenda
• Motivation • Virtual Teams
• Introduction • Lean/Kanban
• Business Case • Metrics and Models
• Major Approaches • Costs and Benefits
• Major Phases • Earned Value Mgt.
• Release Planning • Major Tools
• Iteration Planning • Contract Models
• Estimating Practices • Change Models
• Risk Analysis • Case Studies
• Security Engineering • Summary
• Scaling Practices • Resources
3
4. Information Age
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
100%
80%
Percent of Economy
Information
60%
Service
40% Industry
Agriculture
20%
0%
1860 1870 1880 1890 1900 1910 1920 1930 1940 1950 1960 1970 1980 1990
Bell, D. (1999). The coming of post industrial society. New York, NY: Basic Books.
4
5. System Complexity is Growing
21st century systems are becoming more complex
Number of physical parts are becoming smaller
Nano-circuitry and software hide complexity
Moody, J. A., et al. (1997). Metrics and case studies for evaluating engineering designs. Upper Saddle River, NJ: Prentice-Hall.
5
6. Software Century
No. of software-intensive systems is growing
80% of US DoD functions performed in software
Major driver of cost, schedule, & tech. performance
Kennedy, M. P., & Umphress, D. A. (2011). An agile systems engineering process: The missing link. Crosstalk, 24(3), 16-20.
6
7. Technological Change
21st century systems are technology intensive
Technology is evolving at an exponential speed
Technology is obsolete before project completion
Kurzweil, R. (2005). The singularity is near: When humans transcend biology. New York, NY: Penguin Group.
7
8. Large, Traditional Projects
Big projects result in poor quality and scope changes
Productivity declines with long queues/wait times
Long projects are unsuccessful or canceled
Size vs. Quality Size vs. Requirements Growth
16.00 40%
Defect Density
12.80 32%
Percentage
9.60 24%
6.40 16%
3.20 8%
0.00 0%
0 2 6 25 100 400 0 2 6 25 100 400
Lines of Code (Thousands) Lines of Code (Thousands)
Size vs. Productivity Size vs. Success
5.00 60%
Code Production Rate
4.00 48%
Percentage
3.00 36%
2.00 24%
1.00 12%
0.00 0%
0 2 6 25 100 400 0 2 6 25 100 400
Lines of Code (Thousands) Lines of Code (Thousands)
Jones, C. (1991). Applied software measurement: Assuring productivity and quality. New York, NY: McGraw-Hill. 8
9. Global Project Failures
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
$1.8
2010 33% 41% 26%
2008 32% 44% 24%
$1.4
Trillions (US Dollars)
2006 35% 46% 19%
2004 29% 53% 18% $1.1
Year
2002 34% 51% 15%
2000 28% 49% 23% $0.7
1998 26% 46% 28%
$0.4
1996 27% 33% 40%
1994 16% 53% 31%
$0.0
0% 20% 40% 60% 80% 100% 2002 2003 2004 2005 2006 2007 2008 2009 2010
Successful Challenged Failed Expenditures Failed Investments
Standish Group. (2010). Chaos summary 2010. Boston, MA: Author.
Sessions, R. (2009). The IT complexity crisis: Danger and opportunity. Houston, TX: Object Watch.
9
10. Requirements Defects & Waste
Requirements defects are #1 reason projects fail
Traditional projects specify too many requirements
More than 65% of requirements are never used at all
Defects Waste
Never
Requirements
45%
47%
Other 7% Always 7%
Implementation
Often 13%
18% Rarely
Design 19%
28% Sometimes
16%
Sheldon, F. T. et al. (1992). Reliability measurement: From theory to practice. IEEE Software, 9(4), 13-20
Johnson, J. (2002). ROI: It's your job. Extreme Programming 2002 Conference, Alghero, Sardinia, Italy.
10
11. Agenda
• Motivation • Virtual Teams
• Introduction • Lean/Kanban
• Business Case • Metrics and Models
• Major Approaches • Costs and Benefits
• Major Phases • Earned Value Mgt.
• Release Planning • Major Tools
• Iteration Planning • Contract Models
• Estimating Practices • Change Models
• Risk Analysis • Case Studies
• Security Engineering • Summary
• Scaling Practices • Resources
11
12. Today’s Whirlwind Environment
Global
Competition
Work Life
Imbalance
Demanding
Customers
Overruns
Vague Attrition
Requirements Escalation
Runaways
Cancellation
Organization
Downsizing
Technology
Change
System
Complexity
12
13. Need for a New Model
Need for a new model of project management
Cope with high-level of uncertainty and ambiguity
With just the right balance of flexibility and discipline
R&D Oriented People Centered Adaptive Customer Friendly Fast & Efficient Disciplined
New discoveries Highly-talented people Global threats Customer interaction New technology Lightweight strategy
Complex problems Cross-functional teams Market threats A lot of communication Quick decision-making Lightweight plans
One-off systems Small team size New customer needs Customer demos Iterative delivery cycles Lightweight lifecycles
Vague requirements A lot of communication Changing scope Customer feedback Frequent deliveries Security engineering
Incomplete information Interpersonal trust Changing technology Business value focus Fast delivery schedules Light requirements
High uncertainty Rich collaboration Changing regulations Customer satisfaction Short timelines Light architecture
Experimentation Empowered decisions Continuous change Customer responsive Fast time-to-market Lightweight design
Simulations Sustainable pace Flexible culture Customer sensitivity First-mover capability Code reviews
Prototyping Daily interaction Flexible attitudes Customer relationships Minimal process costs Rigorous V&V
Innovation oriented Rich communications Flexible policies Customer contact Low work-in-process
- Rigorous CM
New products Face-to-face interaction Flexible processes Customer involvement Flexible processes Rigorous QA
Creative solutions Cohesiveness Flexible technologies Customer driven Market responsiveness Project reviews
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. 13
14. What is Agility?
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
Highsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.
14
15. Values of Agile Project Mgt.
People-centric way to create innovative solutions
Market-centric model to maximize business value
Alternative to large document-based methodologies
Agile Methods Agile Methods Traditional Methods
‘Values’ ‘Principles’ ‘Values’
Customer also Customer valued Contract
known as more than
Collaboration Interaction Negotiation
Individuals & also High Performance valued Processes
known as more than
Interactions Teams & Tools
Working also Iterative valued Comprehensive
known as more than
Systems Development Documentation
Responding also Adaptability valued Following
to Change known as more than a Plan
or Flexibility
Agile Manifesto. (2001). Manifesto for agile software development. Retrieved September 3, 2008, from http://www.agilemanifesto.org
15
16. How do Lean & Agile Intersect?
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
Agile Values Lean Pillars Lean Principles Lean & Agile Practices Flow Principles
Customer relationships, satisfaction, trust, and loyalty
Empowered Relationships Team authority, empowerment, and resources Decentralization
Teams Team identification, cohesion, and communication
Product vision, mission, needs, and capabilities
Respect
Customer Value Product scope, constraints, and business value Economic View
for People Product objectives, specifications, and performance
Customer
As is policies, processes, procedures, and instructions
Collaboration To be business processes, flowcharts, and swim lanes
WIP Constraints
Value Stream
Initial workflow analysis, metrication, and optimization & Kanban
Batch size, work in process, and artifact size constraints
Control Cadence
Iterative Continuous Flow Cadence, queue size, buffers, slack, and bottlenecks
Delivery Workflow, test, integration, and deployment automation & Small Batches
Roadmaps, releases, iterations, and product priorities
Continuous Epics, themes, feature sets, features, and user stories
Customer Pull Fast Feedback
Improvement Product demonstrations, feedback, and new backlogs
Responding
Refactor, test driven design, and continuous integration
to Change Standups, retrospectives, and process improvements
Manage Queues/
Perfection
Organization, project, and process adaptability/flexibility Exploit Variability
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). 16
17. When to use Agile Proj. Mgt.
On exploratory or research/development projects
When fast customer responsiveness is paramount
In organizations that are highly innovative & creative
Traditional Project Management Agile Project Management
Predictable situations High levels of uncertainty and unpredictability
Low technology projects High technology projects
Stable, slow moving industries Fast paced, highly competitive industries
Low levels of technological change Rapid pace of technological change
Repeatable operations Research oriented, discovery projects
Low rates of changing project performance Large fluctuations in project performance
Long term, fixed price production contracts Shorter term, performance based RDT&E contracts
Achieving concise economic efficiency goals Achieving high impact product/service effectiveness
Highly administrative contracts Highly creative new product development contracts
Mass production and high volume manufacturing Customer intensive, one off product/service solutions
Highly predictable and stable market conditions Highly volatile and unstable market conditions
Low margin industries such as commodities High margin, intellectually intensive industries
Delivering value at the point of plan Delivering value at the point of sale
Pine, B. J. (1993). Mass customization: The new frontier in business competition. Boston, MA: Harvard Business School Press.
17
18. Agile World View
“Agility” has many dimensions other than IT
It ranges from leadership to technological agility
The focus of this brief is program management agility
Agile Leaders
Agile Organization Change
Agile Acquisition & Contracting
Agile Strategic Planning
Agile Capability Analysis
Agile Program Management
Agile Project Management
Agile Systems Development
Agile Processes & Practices
Agile Tools
Agile Information Systems
Agile Tech. 18
19. Agenda
• Motivation • Virtual Teams
• Introduction • Lean/Kanban
• Business Case • Metrics and Models
• Major Approaches • Costs and Benefits
• Major Phases • Earned Value Mgt.
• Release Planning • Major Tools
• Iteration Planning • Contract Models
• Estimating Practices • Change Models
• Risk Analysis • Case Studies
• Security Engineering • Summary
• Scaling Practices • Resources
19
20. Agile Adoption Rates
VersionOne found 80% using agile methods today
Most are using Scrum with several key XP practices
Release planning/continuous integration are vital tools
House, D. (2012). Sixth annual state of agile survey: State of agile development. Atlanta, GA: VersionOne.
20
21. Surveys of Agile Methods
Many surveys of agile methods since 2003
AmbySoft and VersionOne collect annual data
Agile benefits are above 50% in most categories
Rico, D. F. (2008). What is the return-on-investment of agile methods? Retrieved February 3, 2009, from http://davidfrico.com/rico08a.pdf
21
22. Case Studies of Agile Methods
Agile (138 pt.) and traditional methods (99 pt.)
Agile methods fare better in all benefits categories
Agile methods 359% better than traditional methods
Category Agile Traditional Difference
Cost Reduction 9%
Schedule Reduction 33%
Productivity Improvement 55%
Quality Improvement 24%
Customer Satisfaction Imp. 56%
Return on Investment 2,811% 470% 2,341%
Rico, D. F. (2008). What is the ROI of agile vs. traditional methods? TickIT International, 10(4), 9-18.
22
23. Benefits of Agile Methods
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%)
2.8 18
Before Agile Before Agile
3.00 20
After Agile After Agile
2.25 15 11
1.1
1.50 10
61% 39%
0.75 5
Lower Less
Cost Staff
Project Cost in Millions $ Total Staffing
18 2270
Before Agile Before Agile
20 2500
13.5 After Agile After Agile
15 1875
10 1250
381
93%
5 24% 625 Less
Faster
Defects
Delivery Time in Months Cumulative Defects
Mah, M. (2008). Measuring agile in the enterprise: Proceedings of the Agile 2008 Conference, Toronto, Canada.
23
24. Agile Testing Costs & Benefits
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
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.
24
25. Business Value of Agile Methods
Productivity is accelerated with light weight processes
Quality goals are obtained with disciplined processes
Agile Methods have up to 20 times lower total costs
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.
25
26. Benefits of Organizational Agility
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%
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.
26
27. Agenda
• Motivation • Virtual Teams
• Introduction • Lean/Kanban
• Business Case • Metrics and Models
• Major Approaches • Costs and Benefits
• Major Phases • Earned Value Mgt.
• Release Planning • Major Tools
• Iteration Planning • Contract Models
• Estimating Practices • Change Models
• Risk Analysis • Case Studies
• Security Engineering • Summary
• Scaling Practices • Resources
27
28. Scrum Project Management
Created by Jeff Sutherland at Easel in 1993
Product backlog comprised of customer needs
Barely-sufficient project management framework
Initial Planning Sprint Cycle
Discovery Session Sprint
Agile Training Select Tasks and Create Tests
Project Discovery Create Simple Designs
Code and Test Software Units
Process Discovery
Perform Integration Testing
Team Discovery
Maintain Daily Burndown Chart
Initial Backlog Update Sprint Backlog
Release Planning Sprint Planning Daily Scrum Sprint Review
Business Case Set Sprint Capacity Completed Backlog Items Present Backlog Items
Desired Backlog Identify Tasks Planned Backlog Items Record Feedback
Estimate Tasks Impediments to Progress Adjust Backlog
Hi-Level Estimates
Prioritize Backlog
Finalize Backlog
Sprint Retrospective
Product Backlog Sprint Backlog Potentially Shippable Product
Prioritized Requirements List of Technical Tasks Assigned to a Sprint Working Operational Software
Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.
28
29. XP Project Management
Created by Kent Beck at Chrysler in 1998
Release plan is comprised of customer needs
Lightweight, rigorous near-term planning element
Release Planning Iteration Planning
Exploration Phase Exploration Phase
Build a Team Split User Stories Analyze Release Plan Read User Stories
Write User Stories Spike User Stories Identify Iteration Goal Develop Tasks
Estimate User Stories Write User Tests Select User Stories Split Tasks
Commitment Phase Commitment Phase
Sort by Value Choose a Scope Accept Tasks Analyze Schedules
Sort by Risk Set Iteration Length Set Individual Velocity Set Load Factors
Set Velocity Develop Release Plan Estimate Tasks Balance Tasks
Steering Phase Steering Phase
Select Iteration New Release Plan Select Partner Unit/Integration Test
Adjust Velocity Select Tools Write Unit Tests User Acceptance Test
Insert New Stories Adjust Teams Design and Code Record Progress
Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.
29
30. Project Leadership Model
Created by Sanjiv Augustine at CC Pace in 2005
Builds agile cultures, mind-sets, and environments
Leadership model for managing agile project teams
Foster Alignment and Cooperation Encourage Emergence and Self Organization Learning/Adaptation
Organic Teams Guiding Vision Simple Rules Open Information Light Touch Adaptive Leadership
Leadership Leadership Leadership Leadership Leadership Leadership
Craftsmanship Team Vision Culture of Change Conduct Standups Adapt Style Embodied Presence
Collaboration Team Alignment Value Focus Promote Feedback Roving Leadership Embodied Learning
Guiding Coalition Bold Future Build Trust Go With Flow
Community Shared Expectations Facilitate Action Work Life Quality
Build on Strengths
Gain Commitments
Management Management Management Management Management Management
Identify Community Business Outcomes Assess Status Quo Team Collocation Decentralize Control Daily Feedback
Design Structures Delineate Scope Customize Method Get Onsite Customer Pull vs. Push Monitor/Adapt Rules
Get Team Players Estimate Effort Release Plan Practice Pairing Manage Flow Monitor Practices
Adaptive Enterprise Design Vision Box Iteration Plans Information Radiator Use Action Sprints Retrospectives
Elevator Statement Facilitate Design Map Value Stream Scenario Planning
Conduct Testing
Manage Releases
Augustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education.
30
31. Flexible Project Management
Created by Doug DeCarlo at Cutter in 2004
Focus is on collaboration, scoping, and speed
Thinner traditional project management approach
Visionate Speculate Innovate Re-Evaluate Disseminate
Sponsor’s Vision Planning Meeting Learning by Doing Business Questions Product Launch
Interview Sponsor Collective Vision SCORE Model Who Needs It? Acceptance Testing
Describe Objectives Size Deliverables Architecture What Will It Take? Documentation
Project Prospectus Map Schedule Development Can We Get It? Support Plan
Business Questions Choose Life Cycle Construction Is It Worth It? Maintenance Plan
Requirements ID’d Testing Deploy Solution
Development Tools Time Boxing Customer Service
Collective Vision Project Review
Risk Planning Trial and Error
Scope Meeting Check Performance
Collaboration
Future Scenarios Check Schedule Stabilization
Post Meeting
Project Skinny Check Costs Training/Education
Project Boundaries PM Infrastructure Generate Results Check Benefits Utilization
Project Vision Financial Goals Visibility Check Project ROI Performance
Win Conditions Benefit Plan Early Value Go/No-Go Decision Feedback
Benefit Map Partner Agreements Fast Failures Corrective Action
Wow Factor
Project Changes
Uncertainty Profile Business Questions Business Questions Lessons Learned
Re-Direct As-Needed
Go/No-Go Decision Modify Questions Update Vision
Collective Vision Team Rewards
Update Stakeholders
Select Core Team Update Prospectus Update Prospectus Re-examine Team Track Benefits
DeCarlo, D. (2004). Extreme project management: Using leadership, principles, and tools to deliver value in the face of volatility. San Francisco, CA: Jossey-Bass.
31
32. Adaptive Project Framework
Created by Bob Wysocki for consulting in 2008
Designed to be a generic model for non-IT projects
Lightweight traditional project management approach
Adaptive Project Framework
Scoping Planning Feasibility Checkpoint Review
Identify Opportunity Identify Project Type Develop Prototype Analyze Needs Finalize Documents
Develop CoS Prioritize Constraints Reprioritize Needs Evaluation Solution Lessons Learned
Write PoS Develop WBS Detailed WBS Estimate Value Process Changes
Document Needs Team Formation Estimate Resources Determine Success Final Report
Stage Gate 1 Review Stage Gate 2 Review Stage Gate 3 Review Stage Gate 4 Review Stage Gate 5 Review
Cyclical Product or Service Implementation
Cycle Planning Product or Service Implementation Daily Meetings Cycle Reviews
Responsibilities Select Personnel with Needed Skills Arrange Facilities Update Requirements
Timelines Identify Detailed Technical Tasks Prepare Agendas Update Scope
Work Packages Create Detailed Architectures and Designs Send Meeting Notices Update Schedules
Communications Select and Implement Technical Solutions Facilitate Meetings Update Plans
Governance Perform Development and Operational Tests Record Action Items Inform Stakeholders
Continuous Improvement
Stage Gate 3.n
Continually improve process, documents, team, architecture, designs, implementation, tests, etc. Review
Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education.
32
33. Agile Project Management
Created by Jim Highsmith at Cutter in 2003
Focus on strategic plans and capability analysis
Most holistic agile project management framework
Innovation Lifecycle
Envision Speculate Explore Launch Close
Product Vision Gather Requirements Iteration Management Final Review Clean Up Open Items
Product Architecture Product Backlog Technical Practices Final Acceptance Support Material
Project Objectives Release Planning Team Development Final QA Final Retrospective
Project Community Risk Planning Team Decisions Final Documentation Final Reports
Delivery Approach Cost Estimation Collaboration Final Deployment Project Celebration
Iterative Delivery
Technical Planning Development, Test, & Evaluation Operational Testing Adapt
Story Analysis Development Pairing Integration Testing Focus Groups
Task Development Unit Test Development System Testing Technical Reviews
Task Estimation Simple Designs Operational Testing Team Evaluations
Task Splitting Coding and Refactoring Usability Testing Project Reporting
Task Planning Unit and Component Testing Acceptance Testing Adaptive Action
Continuous
Story Deployment
Standups, Architecture, Design, Build, Integration, Documentation, Change, Migration, and Integration
Highsmith, J. A. (2004). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
33
34. Agenda
• Motivation • Virtual Teams
• Introduction • Lean/Kanban
• Business Case • Metrics and Models
• Major Approaches • Costs and Benefits
• Major Phases • Earned Value Mgt.
• Release Planning • Major Tools
• Iteration Planning • Contract Models
• Estimating Practices • Change Models
• Risk Analysis • Case Studies
• Security Engineering • Summary
• Scaling Practices • Resources
34
35. Envision Phase
Determine product vision and project objectives
Identifies project community and project team
The major output is a “Product Vision Box”
Envision Phase
Product Vision
Product Vision Box
Elevator Test Statement
Product Roadmap
Product Features
Delivery Approach Product Vision Document Product Architecture
Self-Organization Strategy Skeleton Architecture
Collaboration Strategy Hardware Feature Breakdown
Communication Strategy Software Feature Breakdown
Process Framework Tailoring Organizational Structure
Practice Selection & Tailoring Guiding Principles
Project Community Project Objectives
Get the Right People Project Data Sheet
Participant Identification Key Business Objectives
Types of Stakeholders Tradeoff Matrix
List of Stakeholders Exploration Factor
Customer-Developer Interaction Requirements Variability
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
35
36. Speculate Phase
Determine organizational capability/mission needs
Identifies feature-sets and system requirements
The major output is a “System Release Plan”
Speculate Phase
Gather Requirements
Analyze Feasibility Studies
Evaluate Marketing Reports
Gather Stakeholder Suggestions
Examine Competitive Intelligence
Cost Estimation Collaborate with Customers Product Backlog
Establish Estimate Scope Product Features List
Establish Technical Baseline Feature Cards
Collect Project Data Performance Requirements
Size Project Information Prioritize Features
Prepare Baseline Estimates Feature Breakdown Structure
Risk Planning Release Planning
Risk Identification Project Startup Activities
Risk Analysis Assign Stories to Iterations
Risk Responses First Feasible Deployment
Risk Monitoring Estimate Feature Velocity
Risk Control Determine Product Scope
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
36
37. Explore Phase
Determine technical iteration objectives/approaches
Identifies technical tasks and technical practices
The major output is an “Operational Element”
Explore Phase
Iteration Management
Iteration Planning
Estimate Task Size
Iteration Length
Workload Management
Collaboration Monitoring Iteration Progress Technical Practices
Pair Programming Reduce Technical Debt
Daily Standup Meetings Simple Design
Daily Product Team Interaction Continuous Integration
Stakeholder Coordination Ruthless Automated Testing
Customer Interactions Opportunistic Refactoring
Team Decisions Team Development
Decision Framing Focus Team
Decision Making Molding Group into Team
Decision Retrospection Develop Individual Capabilities
Leadership and Decision Making Coach Customers
Set and Delay Decision Making Orchestrate Team Rhythm
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
37
38. Adapt Phase
Determine the effectiveness of operational elements
Identifies customer feedback and corrective actions
The major output is a “Process Improvement Plan”
Adapt Phase
Customer Focus Groups
Requirements Reviews
Preliminary Design Reviews
Critical Design Reviews
Product Demonstration Reviews
Adaptive Action Acceptance Testing Reviews Technical Reviews
Release Plan Adaptations Desk Checks/Individual Reviews
Iteration Plan Adaptations Structured Walkthroughs
Feature Set Adaptations Formal Software Inspections
User Story Adaptations Quality Assurance Audits
Task Plan Adaptations Configuration Management Audits
Project Reporting Team Evaluations
Scope and Quality Status Communications Quality
Cost and Schedule Status Team Cohesiveness
Risk and Value Status Interpersonal Trust
Customer Satisfaction Status Individual Talent and Effort
Team and Agility Status Team Performance/Effectiveness
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
38
39. Close Phase
Determine project outcome and effectiveness
Identifies strengths, weaknesses, and rewards
The major output is a “Lessons-Learned Report”
Close Phase
Clean Up Open Items
Close Open Action Items
Close Open Change Requests
Close Open Problem Reports
Close Open Defect Reports
Project Celebration Close Open Project Issues Support Material
Individual Rewards Finalize Documentation
Group Rewards Finalize Production Material
Partner Rewards Finalize Manufacturing Material
Managerial Rewards Finalize Customer Documentation
Product Rewards Finalize Maintenance Information
Final Reports Final Retrospective
End-of-Project Reports Process Performance Assessment
Administrative Reports Internal Product Assessment
Release Notes External Product Assessment
Financial Reports Team Performance Assessment
Facilities Reports Project Performance Assessment
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
39
40. Agenda
• Motivation • Virtual Teams
• Introduction • Lean/Kanban
• Business Case • Metrics and Models
• Major Approaches • Costs and Benefits
• Major Phases • Earned Value Mgt.
• Release Planning • Major Tools
• Iteration Planning • Contract Models
• Estimating Practices • Change Models
• Risk Analysis • Case Studies
• Security Engineering • Summary
• Scaling Practices • Resources
40
41. Write User Stories
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
Hold
Customer
Meeting
Verify Propose
User User
Stories Stories
Record Clarify
User User
Stories 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.
41
42. Estimate User Stories
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
Using
Delphi (PERT)
Estimate Estimate
Using Using
Prototypes (Spikes) Planning Poker
Estimate Estimate
Using Using
Algorithmic Models Analogy
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.
42
43. Prioritize User Stories
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
Estimate
Total
Resources
Verify Estimate
Overall Business
Sequence Value
Sequence Estimate
User Technical
Stories Risks
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.
43
44. Split User Stories
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
Evaluate
User Story
Size
Divide Evaluate
and Reorder Needed
User Stories Resources
Evaluate Evaluate
Risks and Business
Sequence Value
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.
44
45. Develop Release Plan
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
Select
Release
Scope
Develop Select
Release Iteration
Plan Velocity & Length
Identify Estimate
Overall Release
Constraints Budget
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.
45
46. User Story Example
Simple one sentence user needs from customers
May be decomposed into lower level user stories
Acceptance test criteria are often written as well
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.
46
47. Agenda
• Motivation • Virtual Teams
• Introduction • Lean/Kanban
• Business Case • Metrics and Models
• Major Approaches • Costs and Benefits
• Major Phases • Earned Value Mgt.
• Release Planning • Major Tools
• Iteration Planning • Contract Models
• Estimating Practices • Change Models
• Risk Analysis • Case Studies
• Security Engineering • Summary
• Scaling Practices • Resources
47
48. Write Technical Tasks
Customers and developers review user stories
Developers divide user stories into technical tasks
Detailed technical activity is recorded on task cards
Write Technical Tasks
Hold
Customer
Meeting
Develop Review
Acceptance User
Criteria Stories
Write Identify
Task Technical
Descriptions Tasks
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.
48
49. Assign Technical Tasks
Complete task list is reviewed by developers
Technical requirements are aligned by skill sets
Technical tasks are assigned to programmer pairs
Assign Technical Tasks
Evaluate
Initial
Tasks
Assign Identify
Tasks Technical
to Pairs Requirements
Organize Align with
Into Skills and
Pairs Interests
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.
49
50. Estimate Technical Tasks
Technical tasks are analyzed by pair groupings
Effort is estimated by analogy, Delphi method, etc.
Unit test cases are developed and tasks are verified
Estimate Technical Tasks
Analyze
Assigned
Tasks
Verify Estimate
Technical by Analogy,
Tasks Delphi, Tool, etc.
Develop Determine
Unit Level Effort in
Test Cases Ideal Days
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.
50
51. Decompose Technical Tasks
Overall technical task sizes are evaluated
Larger tasks are decomposed into smaller ones
New technical tasks are developed and propagated
Decompose Technical Tasks
Analyze
Technical
Task Sizes
Assign New Decompose
Technical Tasks Large
to Pairs Technical Tasks
Write New Identify
Technical Task New
Descriptions Technical Tasks
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.
51
52. Develop Iteration Plans
Establish individual productivity time and pace
Balance the workload among individual resources
Develop iteration plans with tasks, dates, pairs, etc.
Develop Iteration Plans
Establish
Personnel
Load Factors
Establish Balance
Iteration Personnel
Plan Resources
Compile Establish
Technical Task Technical Task
Assignments Traceability
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.
52
53. Release/Iteration Plan
An example of release and iteration plan
Relationships between user stories and plans
Shows key data such as story points and velocity
Product Backlog, Release Plan, & Iteration Plan
Product Backlog Release Plan Iteration Plan
User Story Points Release Iteration Task Team Plan Actual
Find a flight 1 Release 1 Iteration 1 Specify airport Bob/Sue 2 hours 1 hours
Specify dates 2 hours 1 hours
Specify times 2 hours 1 hours
Reserve a flight 2 Iteration 2 Enter name John/Dave 4 hours 3 hours
Enter address 4 hours 3 hours
Get confirmation no 4 hours 3 hours
Book a flight 4 Iteration 3 Enter credit card Barb/Carol 8 hours 6 hours
Enter billing info 8 hours 6 hours
Get receipt 8 hours 6 hours
Verify a flight 1 Release 2 Iteration 4 Enter confirmation no Matt/Ken 2 hours 2 hours
View itinerary 2 hours 2 hours
View payment info 2 hours 2 hours
Generate itinerary 2 Iteration 5 Enter confirmation no Jim/Jane 4 hours 3 hours
Print itinerary 4 hours 3 hours
Download itinerary 4 hours 3 hours
Check flight status 4 Iteration 6 Enter confirmation no Nat/Tim 8 hours 6 hours
View flight status 8 hours 6 hours
View gate info 8 hours 6 hours
Change flight 4 Release 3 Iteration 7 Enter confirmation no Kim/Pat 8 hours 6 hours
Change dates 8 hours 6 hours
Change times 8 hours 6 hours
Cancel flight 1 Iteration 8 Enter confirmation no Sam/Ron 2 hours 2 hours
Cancel flight 2 hours 2 hours
Verify cancellation 2 hours 2 hours
Get a refund 2 Iteration 9 Enter confirmation no Mark/Dan 4 hours 4 hours
Initiate refund 4 hours 4 hours
Verify refund status 4 hours 4 hours
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.
53
54. Agenda
• Motivation • Virtual Teams
• Introduction • Lean/Kanban
• Business Case • Metrics and Models
• Major Approaches • Costs and Benefits
• Major Phases • Earned Value Mgt.
• Release Planning • Major Tools
• Iteration Planning • Contract Models
• Estimating Practices • Change Models
• Risk Analysis • Case Studies
• Security Engineering • Summary
• Scaling Practices • Resources
54
55. Wideband Delphi (PERT)
Created by RAND corporation in 1940s
Applied to software effort estimation in 1970s
Relies on expert judgment and consensus (PERT)
Estimate Using Wideband Delphi (PERT)
Hold
Meeting with
Customers
Discuss Review
and Verify Each
Estimates User Story
Use PERT Solicit
to Combine Individual
Estimates Estimates
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.
55
56. Planning Poker
Created by James Grenning for Scrum in 2002
Similar to Wideband Delphi (or PERT) estimating
Goal is to estimate size (complexity) in story points
Estimate Using Planning Poker
Hold
Meeting with
Customers
Discuss Distribute
and Verify Planning
Estimates Poker Cards
Vote on Review
Size in Each
Story Points User Story
Molokken-Ostvold, K., & Haugen, N. C. (2007). Combining estimates with planning poker: An empirical study. Proceedings of the 18th Australian
Software Engineering Conference (ASWEC 2007), Melbourne, Australia, 349-358.
56
57. Analogous Estimating
Utilized for software estimating in the 1970s
Goal is to match new user stories with prior ones
Generates estimate based on similar historical work
Estimate by Analogy
Hold
Meeting with
Customers
Agree on Review
Size of New Each
User Stories User Story
Match Analyze
Old and New Previous
User Stories User 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.
57
58. Algorithmic Models
First regression models popularized in 1970s
Grew into complex logarithmic models in 1990s
Many algorithms and tools exist for agile estimates
Estimate Using Algorithmic Models
Hold
Meeting with
Customers
Average Review
Output of Each
Algorithmic Models User Story
Generate Select
One or More One or More
Estimates 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.
58
59. Prototypes (Spikes)
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
Estimate Based on Prototypes (Spikes)
Hold
Meeting with
Customers
Estimate Review
User Story Each
from New Data User Story
Develop Identify
Rapid Problematic
Prototype (Spike) User Stories
Keaveney, S., & Conboy, K. (2006). Cost estimation in agile development projects. Proceedings of the
European Conference on Information Systems (ECIS 2006), Goteborg, Sweden.
59
60. Agenda
• Motivation • Virtual Teams
• Introduction • Lean/Kanban
• Business Case • Metrics and Models
• Major Approaches • Costs and Benefits
• Major Phases • Earned Value Mgt.
• Release Planning • Major Tools
• Iteration Planning • Contract Models
• Estimating Practices • Change Models
• Risk Analysis • Case Studies
• Security Engineering • Summary
• Scaling Practices • Resources
60
61. Risk Planning
Kickoff meeting is held during release planning
Type of project and risks of initial stories identified
Risk management process is aligned with challenges
Risk Planning
Hold
Customer
Meeting
Identify
Review and Approve
Risk Processes
Risk Plan
or Stages
Identify Identify
Risk Evaluation Risk Tracking
Criteria Artifacts
Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011
from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes.
61
62. Risk Identification
Low level risks identified at each stage
Risks are attached to stories, tasks, tests, etc.
Many risks identified during standups/retrospectives
Risk Identification
Identify
Risks During
Release Planning
Identify Identify
Risks During Risks During
Retrospectives Sprint Planning
Identify Identify Risks
Risks During During Daily
Sprint Reviews Standups
Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011
from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes.
62
63. Risk Assessment
Risk backlog is periodically reviewed
Risks are categorized along with likelihood
Risk impact is estimated and risk data is verified
Risk Assessment
Review
Risk
Backlog
Verify Categorize
Risk or Determine
Assessment Data Type of Risk
Identify Determine
Impact of Risk Probability
Potential Risk or Likelihood
Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011
from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes.
63