ww.davidfrico.comww.davidfrico.com/rico11a.pdf · Large, Traditional Projects. 8. Big projects...
Transcript of ww.davidfrico.comww.davidfrico.com/rico11a.pdf · Large, Traditional Projects. 8. Big projects...
Lean & Agile Project Managementfor Executives, Sr. Managers,
& Key Decision MakersDr. David F. Rico, PMP, ACP, CSM
Twitter: @dr_david_f_ricoWebsite: http://www.davidfrico.com
LinkedIn: http://www.linkedin.com/in/davidfricoFacebook: http://www.facebook.com/profile.php?id=1540017424
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
2
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.
Agenda
3
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Information Age
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
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
System Complexity is Growing
5
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.
Software Century
Kennedy, M. P., & Umphress, D. A. (2011). An agile systems engineering process: The missing link. Crosstalk, 24(3), 16-20.
No. of software-intensive systems is growing 80% of US DoD functions performed in software Major driver of cost, schedule, & tech. performance
6
Technological Change
7Kurzweil, R. (2005). The singularity is near: When humans transcend biology. New York, NY: Penguin Group.
21st century systems are technology intensive Technology is evolving at an exponential speed Technology is obsolete before project completion
Large, Traditional Projects
8
Big projects result in poor quality and scope changes Productivity declines with long queues/wait times Long projects are unsuccessful or canceled
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)
Global Project Failures
9Standish Group. (2010). Chaos summary 2010. Boston, MA: Author.Sessions, R. (2009). The IT complexity crisis: Danger and opportunity. Houston, TX: Object Watch.
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
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
Requirements Defects & Waste
10Sheldon, 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.
Requirements defects are #1 reason projects fail Traditional projects specify too many requirements More than 65% of requirements are never used at all
Other 7%
Requirements47%
Design28%
Implementation18%
Defects
Always 7%
Often 13%
Sometimes16%
Rarely19%
Never45%
Waste
Agenda
11
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Today’s Whirlwind Environment
12
Overruns Attrition Escalation Runaways Cancellation
GlobalCompetition
DemandingCustomers
OrganizationDownsizing
SystemComplexity
TechnologyChange
VagueRequirements
Work LifeImbalance
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
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
13
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 documentationHighsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.
14
Values of Agile Project Mgt.
15
People-centric way to create innovative solutions Market-centric model to maximize business value Alternative to large document-based methodologies
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’
How do Lean & Agile Intersect?
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
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
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
17
On exploratory or research/development projects When fast customer responsiveness is paramount In organizations that are highly innovative & creative
When to use Agile Proj. Mgt.
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 Tech.
Agile Information Systems
Agile Tools
Agile Processes & Practices
Agile Systems Development
Agile Project Management
18
Agenda
19
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Agile Adoption Rates
House, D. (2012). Sixth annual state of agile survey: State of agile development. Atlanta, GA: VersionOne.
VersionOne found 80% using agile methods today Most are using Scrum with several key XP practices Release planning/continuous integration are vital tools
20
Surveys of Agile Methods
21
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
Case Studies of Agile Methods
22
Agile (138 pt.) and traditional methods (99 pt.) Agile methods fare better in all benefits categories Agile methods 359% better than traditional 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%
Benefits of Agile Methods
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%)
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
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.
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
24
Business Value of Agile Methods
25
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.
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
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%
Benefits of Organizational Agility
Agenda
27
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Scrum Project Management
Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.
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
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
28
XP Project Management
Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.
Created by Kent Beck at Chrysler in 1998 Release plan is comprised of customer needs Lightweight, rigorous near-term planning element
Release Planning
Exploration Phase
Iteration Planning
Build a Team Write User Stories Estimate User Stories
Split User Stories Spike User Stories Write User Tests
Commitment Phase
Sort by Value Sort by Risk Set Velocity
Choose a Scope Set Iteration Length Develop Release Plan
Steering Phase
Select Iteration Adjust Velocity Insert New Stories
New Release Plan Select Tools Adjust Teams
Exploration Phase
Analyze Release Plan Identify Iteration Goal Select User Stories
Read User Stories Develop Tasks Split Tasks
Commitment Phase
Accept Tasks Set Individual Velocity Estimate Tasks
Analyze Schedules Set Load Factors Balance Tasks
Steering Phase
Select Partner Write Unit Tests Design and Code
Unit/Integration Test User Acceptance Test Record Progress
29
Project Leadership Model
Augustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education.
Created by Sanjiv Augustine at CC Pace in 2005 Builds agile cultures, mind-sets, and environments Leadership model for managing agile project teams
Guiding Vision Simple Rules Open Information Light Touch
Foster Alignment and Cooperation Encourage Emergence and Self Organization
Adaptive Leadership
Learning/Adaptation
Leadership
Team Vision Team Alignment Bold Future Shared Expectations
Management
Business Outcomes Delineate Scope Estimate Effort Design Vision Box Elevator Statement
Leadership
Culture of Change Value Focus
Management
Assess Status Quo Customize Method Release Plan Iteration Plans Facilitate Design Conduct Testing Manage Releases
Leadership
Conduct Standups Promote Feedback Build Trust Facilitate Action
Management
Team Collocation Get Onsite Customer Practice Pairing Information Radiator Map Value Stream
Leadership
Adapt Style Roving Leadership Go With Flow Work Life Quality Build on Strengths Gain Commitments
Management
Decentralize Control Pull vs. Push Manage Flow Use Action Sprints
Leadership
Embodied Presence Embodied Learning
Management
Daily Feedback Monitor/Adapt Rules Monitor Practices Retrospectives Scenario Planning
Organic Teams
Leadership
Craftsmanship Collaboration Guiding Coalition Community
Management
Identify Community Design Structures Get Team Players Adaptive Enterprise
30
Flexible Project Management
DeCarlo, D. (2004). Extreme project management: Using leadership, principles, and tools to deliver value in the face of volatility. San Francisco, CA: Jossey-Bass.
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
Collective Vision
Select Core Team
Sponsor’s Vision
Interview Sponsor Describe Objectives Project Prospectus Business Questions
Collective Vision
Scope Meeting Future Scenarios Project Skinny Project Boundaries Project Vision Win Conditions Benefit Map Wow Factor Uncertainty Profile
Planning Meeting
Collective Vision Size Deliverables Map Schedule Choose Life Cycle Requirements ID’d Development Tools Risk Planning
Post Meeting
PM Infrastructure Financial Goals Benefit Plan Partner Agreements
Business Questions
Go/No-Go Decision
Update Prospectus
Business Questions
Who Needs It? What Will It Take? Can We Get It? Is It Worth It?
Project Review
Check Performance Check Schedule Check Costs Check Benefits Check Project ROI Go/No-Go Decision
Project Changes
Re-Direct As-Needed Update Vision Update Stakeholders Re-examine Team
Product Launch
Acceptance Testing Documentation Support Plan Maintenance Plan Deploy Solution Customer Service
Track Benefits
Team Rewards
Lessons Learned
Stabilization
Training/Education Utilization Performance Feedback Corrective Action
Learning by Doing
SCORE Model Architecture Development Construction Testing Time Boxing Trial and Error Collaboration
Generate Results
Visibility Early Value Fast Failures
Update Prospectus
Business Questions
Modify Questions
31
Adaptive Project Framework
Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education.
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
Identify Opportunity Develop CoS Write PoS Document Needs Stage Gate 1 Review
Planning
Identify Project Type Prioritize Constraints Develop WBS Team Formation Stage Gate 2 Review
Feasibility
Develop Prototype Reprioritize Needs Detailed WBS Estimate Resources Stage Gate 3 Review
Checkpoint
Analyze Needs Evaluation Solution Estimate Value Determine Success Stage Gate 4 Review
Review
Finalize Documents Lessons Learned Process Changes Final Report Stage Gate 5 Review
Cyclical Product or Service Implementation
Cycle Planning
Responsibilities Timelines Work Packages Communications Governance
Continually improve process, documents, team, architecture, designs, implementation, tests, etc.Stage Gate 3.n
Review
Cycle Reviews
Update Requirements Update Scope Update Schedules Update Plans Inform Stakeholders
Daily Meetings
Arrange Facilities Prepare Agendas Send Meeting Notices Facilitate Meetings Record Action Items
Product or Service Implementation
Select Personnel with Needed Skills Identify Detailed Technical Tasks Create Detailed Architectures and Designs Select and Implement Technical Solutions Perform Development and Operational Tests
Continuous Improvement
32
Agile Project Management
Highsmith, J. A. (2004). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Created by Jim Highsmith at Cutter in 2003 Focus on strategic plans and capability analysis Most holistic agile project management framework
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
33
Agenda
34
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Envision Phase
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Determine product vision and project objectives Identifies project community and project team The major output is a “Product Vision Box”
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
35
Speculate Phase
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Determine organizational capability/mission needs Identifies feature-sets and system requirements The major output is a “System Release Plan”
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
36
Explore Phase
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Determine technical iteration objectives/approaches Identifies technical tasks and technical practices The major output is an “Operational Element”
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
37
Adapt Phase
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Determine the effectiveness of operational elements Identifies customer feedback and corrective actions The major output is a “Process Improvement Plan”
Adapt Phase
Team Evaluations
Communications Quality Team Cohesiveness Interpersonal Trust Individual Talent and Effort Team Performance/Effectiveness
Project Reporting
Scope and Quality Status Cost and Schedule Status Risk and Value Status Customer Satisfaction Status Team and Agility Status
Technical Reviews
Desk Checks/Individual Reviews Structured Walkthroughs Formal Software Inspections Quality Assurance Audits Configuration Management Audits
Adaptive Action
Release Plan Adaptations Iteration Plan Adaptations Feature Set Adaptations User Story Adaptations Task Plan Adaptations
Customer Focus Groups
Requirements Reviews Preliminary Design Reviews Critical Design Reviews Product Demonstration Reviews Acceptance Testing Reviews
38
Close Phase
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Determine project outcome and effectiveness Identifies strengths, weaknesses, and rewards The major output is a “Lessons-Learned Report”
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
39
Agenda
40
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Write User 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.
Release planning begins by identifying user needs User needs are captured in form of user stories Customer records needs on user story cards
41
Write User Stories
HoldCustomerMeeting
ProposeUser
Stories
ClarifyUser
Stories
RecordUser
Stories
VerifyUser
Stories
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
42
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.
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
43
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.
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
44
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.
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
45
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.
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
46Beck, 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.
Agenda
47
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Write 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.
Customers and developers review user stories Developers divide user stories into technical tasks Detailed technical activity is recorded on task cards
48
Write Technical Tasks
Hold Customer Meeting
Review User
Stories
Identify Technical
Tasks
Write Task
Descriptions
Develop Acceptance
Criteria
Assign Technical Tasks Complete task list is reviewed by developers Technical requirements are aligned by skill sets Technical tasks are assigned to programmer pairs
49
Assign Technical Tasks
EvaluateInitialTasks
IdentifyTechnical
Requirements
Align withSkills andInterests
OrganizeIntoPairs
AssignTasks
to Pairs
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 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
50
Estimate Technical Tasks
AnalyzeAssigned
Tasks
Estimateby Analogy,
Delphi, Tool, etc.
DetermineEffort in
Ideal Days
Develop Unit Level Test Cases
VerifyTechnical
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.
Decompose Technical Tasks Overall technical task sizes are evaluated Larger tasks are decomposed into smaller ones New technical tasks are developed and propagated
51
Decompose Technical Tasks
AnalyzeTechnicalTask Sizes
DecomposeLarge
Technical Tasks
IdentifyNew
Technical Tasks
Write NewTechnical Task
Descriptions
Assign NewTechnical Tasks
to Pairs
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.
Develop Iteration Plans Establish individual productivity time and pace Balance the workload among individual resources Develop iteration plans with tasks, dates, pairs, etc.
52
Develop Iteration Plans
EstablishPersonnel
Load Factors
BalancePersonnelResources
EstablishTechnical Task
Traceability
CompileTechnical TaskAssignments
EstablishIteration
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.
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
53Beck, 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
Agenda
54
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Wideband Delphi (PERT) Created by RAND corporation in 1940s Applied to software effort estimation in 1970s Relies on expert judgment and consensus (PERT)
55
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.
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
56
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.
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
57
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.
Algorithmic Models First regression models popularized in 1970s Grew into complex logarithmic models in 1990s Many algorithms and tools exist for agile estimates
58
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.
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
59
Estimate Based on 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.
Agenda
60
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
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
61
Risk Planning
HoldCustomerMeeting
IdentifyRisk Processes
or Stages
IdentifyRisk Tracking
Artifacts
IdentifyRisk Evaluation
Criteria
Review and Approve Risk Plan
Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes.
Risk Identification Low level risks identified at each stage Risks are attached to stories, tasks, tests, etc. Many risks identified during standups/retrospectives
62
Risk Identification
IdentifyRisks During
Release Planning
IdentifyRisks During
Sprint Planning
Identify RisksDuring Daily
Standups
IdentifyRisks During
Sprint Reviews
IdentifyRisks During
Retrospectives
Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes.
Risk Assessment Risk backlog is periodically reviewed Risks are categorized along with likelihood Risk impact is estimated and risk data is verified
63
Risk Assessment
ReviewRisk
Backlog
Categorizeor DetermineType of Risk
DetermineRisk Probability
or Likelihood
IdentifyImpact of
Potential Risk
VerifyRisk
Assessment Data
Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes.
Risk Response Risks are reviewed along with response types Appropriate responses are selected and assigned Contingency plans are developed if risks are realized
64
Risk Response
ReviewRisk
Assessment Data
ReviewRisk Response
Categories
Select aRisk Response
Category
DefineContingency
Plans and Actions
VerifyRisk
Response Data
Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes.
Risk Review Risk meetings are held with customers High priority risks are evaluated from backlog Risks are mitigated and reprioritized as necessary
65
Risk Review
ReviewRisk
Backlog
EvaluateHigh-Priority
Risks
Determine ifRisks Have
Been Realized
ActivateRisk Responses
if Necessary
Re-categorize& ReprioritizeRisk Backlog
Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes.
Agenda
66
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Security by Plan First step is to appoint a security team lead Identifying security risks & requirements is key Emphasis on training & security incident prevention
67
Security by Plan
AppointSecurity
Coordinator
PerformSecurityTraining
Perform Security& Privacy RiskAssessment
Identify Security& Privacy
Requirements
DevelopSecurity
Plan
Microsoft. (2009). Security development lifecycle for agile development. Redmond, WA: Author.Microsoft. (2010). Security development lifecycle. Redmond, WA: Author.
Security by Design Next step is to identify design requirements Identify security architecture and subsystems Develop threat model and reduce attack surface
68
Security by Design
Identify Security& Privacy Design
Requirements
Document SecurityArchitecture &Attack Surface
Identify CriticalComponents &Security Assets
Develop andAnalyze Threat
Model & ReduceAttack Surface
PerformSecurity
Design Review
Microsoft. (2009). Security development lifecycle for agile development. Redmond, WA: Author.Microsoft. (2010). Security development lifecycle. Redmond, WA: Author.
Security by Implementation Then identify development & evaluation tools Identify and apply security patterns & practices Must perform manual & automated code reviews
69
Security by Implementation
IdentifyDevelopmentEnvironment
Identify Static& Dynamic
Security Tools
Identify SecurityCoding Patterns,
Standards, &Practices
ApplySecurity CodingBest Practices
Perform Manual& Automated
SecurityCode Analysis
Microsoft. (2009). Security development lifecycle for agile development. Redmond, WA: Author.Microsoft. (2010). Security development lifecycle. Redmond, WA: Author.
Security by Validation Also develop security test plans and procedures Perform automated security testing & analysis Validate to-be vs. as-is security architecture
70
Security by Validation
CreateSecurity & Privacy
Test Plans &Procedures
Perform DynamicSecurity Testing
& Analysis
Perform Fuzz& Penetration
Testing
Perform ThreatModel & AttackSurface Review
ReviewTest Results &
Update SecurityDocumentation
Microsoft. (2009). Security development lifecycle for agile development. Redmond, WA: Author.Microsoft. (2010). Security development lifecycle. Redmond, WA: Author.
Security by Support Finally, develop security incidence response plan Systematically collect security incident reports Analyze, implement, re-verify, and update
71
Security by Support
DevelopIncidence
Response Plan
Perform FinalSecurity Review &
Archive Project
Collect, Analyze,& Classify
Security IncidentReports
Develop & PrioritizeSecurity
Maintenance Plans
Implement & VerifySecurity Changes,
Enhancements,& Upgrades
Microsoft. (2009). Security development lifecycle for agile development. Redmond, WA: Author.Microsoft. (2010). Security development lifecycle. Redmond, WA: Author.
Top 25 Vulnerabilities Top 25 security vulnerabilities identified each year Many resources available to help mitigate them 88% are preventable by security engineering
72Brink, D. E. (2010). Security and the software development lifecycle: Secure at the source. Boston, MA: Aberdeen Group.Sans Institute. (2010). Top 25 most dangerous software errors. Retrieved April 21, 2011 from http://www.sans.org/top25-software-errors
Top 25 Most Dangerous Security Vulnerabilities
Interactions
Cross Site Scripting
SQL Injection
Cross Site Requests
Unrestricted File Upload
OS Command Injection
Information Exposure
URL Redirection
Race Condition
Resources
Buffer Overflow
Path Traversal
PHP File Inclusion
Incorrect Buffer Length
Improper Exceptions
Array Index Validation
Integer Overflow
Buffer Size Calculation
Software Download
Resource Allocation
Defenses
Access Control
Untrusted Inputs
Missing Encryption
Hard Coded Credentials
Missing Authentication
Permission Assignment
Cryptographic Algorithm
Agenda
73
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Multi-Level Teams
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Enables projects to plan for the future and present Decomposes capabilities into implementable pieces Unclogs the drainpipes to let the execution flow freely
Multi-Level Teams
Product Management Team Product Management Team
Chief Product Manager Chief Architect Product Development Manager Release Management Team members (1-2 per release team)
Release Management Team
Feature Team
Release Management Team
Product Manager Project Manager Chief Architect Feature team members (1-2 per feature team)
Feature Teams
Product Specialist (and owner) Iteration Manager Technical and product Members Development team members (1-2 per development team)
74
Multi-Level Planning
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Enables multiple level enterprise plans to co-exist Allows stakeholders to build viewpoint-specific plans Ensures capabilities are delivered at regular intervals
Multi-Level Planning
Product Roadmap Product Roadmap
Enterprise architecture needs Capability focused Vision, objectives, and backlog 18 to 36 weeks
Release Plan
Iteration Plan
Release Plan
Subsystem architecture Feature set focused Strategy, objectives, and backlog 6 to 12 weeks
Iteration Plan
Component-level architecture User story focused Implementation plan, objectives, and backlog 2 to 4 weeks
75
Multi-Level Backlog
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Enables multiple levels of abstraction to co-exist Allows customers and developers to communicate Makes optimum use of people’s time and resources
Multi-Level Backlog
Capabilities Capability
Mission goal or objective level High-level business or product function Also called an Epic, i.e., multiple feature sets Comprises 18-90 days worth of work
Feature Set
Cross-functional mission threads Related user stories that are grouped together Also called a Theme, i.e., implemented as an entity Comprises 6 to 30 days worth of work
User Story
Functional, system-level requirements Simple requirement written by customer or user A small unit of functionality having business value Comprises 2 to 10 days worth of work
Capability1
Capability2
Capability3
Feature Sets
Feature1
Feature2
Feature3
User Stories
Story 1 Story 4 Story 7
Story 2 Story 5 Story 8
Story 3 Story 6 Story 9
76
Multi-Level Coordination
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Enables lean and agile methods to scale-up Allows enterprises to create large-scale programs Unleashes optimum productivity and overall control
Multi-Level Coordination
Feature Team Feature Team Feature Team
Feature Set Team
Capability Team
Feature Set Team Feature Set Team
77
Multi-Level Governance
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Enables enterprises to achieve functional needs Allows programs to coordinate functional activities Ensures optimal technical performance is achieved
Multi-Level Governance
Feature Team Feature Team Feature Team
Functional Team
Governing Team
Functional Team Functional Team
R T S
RRR
RRR
RRR
TTT
TTT
TTT
SSS
SSS
SSS
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
M M M
M M
M M M
M
M M M
M M M
M M M
M M M
M M M
M M M
78
Multi-Level Delivery Model
Leffingwell, D. (2011). Agile software requirements: Lean requirements practices for teams, programs, and the enterprise. Boston, MA: Pearson Education.
Begins with a high-level product vision/architecture Includes multi-level teams and product requirements Demonstrates agile delivery model for large programs
79
Agenda
80
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Standard Practices
81
Standard practices is an oft cited aid to virtual teams Agile methodologies are not known in every country Training should be provided and standards created
Young, C., & Terashima, H. (2008). How did we adapt agile processes to our distributed development? Agile Conference, Toronto, Canada, 304-309.
VIDEOVideo used to record and playback communications
CODINGCoding conventions are established
WIRE FRAMESWire frames are used for visual support
USER STORIESCustomer needs are captured in user stories
TEMPLATESTemplates are established for project communications
PROCESSESEntire team follows the same agile process
TRAININGEntire team is trained on agile methods
Virtual Infrastructure
82
Infrastructure needs are most often overlooked Many countries do not have adequate computers Internet service is also a luxury in across the globe
Vax, M., & Michaud, S. (2008). Distributed agile: Growing a practice together. Agile Conference, Toronto, Canada, 310-314.
SECURITYInformation security is established to protect project information
SUPPORT24x7 infrastructure support is available
INTERNETBroadband Internet is leased and utilized
SOFTWARESynchronous and asynchronous tools are selected
SERVERSDedicated servers are established for project information
LAPTOPSEntire team is provided with laptops for office and home use
MOBILEEntire team is provided with cell phones, smart phones, tablets, etc.
Virtual Tools
83
Many projects do not standardize development tools Complete development tools are easy to assemble Development environments should be integrated
Cannizzo, F., Marcionetti, G., & Moser, P. (2008). Evolution of the tools and practices of a large distributed agile team. Agile Conference, Toronto, Canada, 513-518.
MULTIMEDIADevelopment tools with collaborative capabilities are utilized
CONTENTWikis and other repositories are utilized
METRICSCode metrics and defect tracking tools are used
TESTINGUnit, system, and acceptance testing tools are used
BUILDBuild tools are used for continuous integration and deployment
VERSIONINGConfiguration management tools are used to manage source code
WORKFLOWRelease and iteration workflow tools are used
Virtual Meetings
84
Frequent communication is a key to project success Communication is better than documentation alone A critical key is to encourage frequent interactions
Summers, S. (2008). Insights into an agile adventure with offshore partners. Agile Conference, Toronto, Canada, 513-518.
SPLINTERVirtual splinter group meetings are held, i.e., design, brainstorming, etc.
RETROSPECTIVEVirtual iteration retrospectives are held
DEMONSTRATIONEntire team participates in virtual demonstrations
DEVELOPMENTVirtual development meetings held, i.e., pair programming
STANDUPEntire team participates in virtual daily standup meetings
ITERATIONEntire team participates in virtual iteration planning meetings
RELEASEEntire team participates in virtual release planning sessions
Light Coordination
85
The work of two or more teams requires facilitation Local/remote team leaders must communicate often All team leaders can then pass on critical information
Drummond, B. S., & Unson, J. F. (2008). Yahoo distributed agile: Notes from the world over. Agile Conference, Toronto, Canada, 315-321.
FEEDBACKCustomer feedback to developers is provided very quickly
REPORTINGManual and automated status reporting
FACILITATIONProactive management of intercultural dissonance
TECHNICALCoordination between local and remote technical leaders
GOVERNANCELightweight governance teams with local and remote members
LEADERSHIPRegular communications between local and remote process leaders
CUSTOMERRegular communications between customers and remote teams
Periodic Rotations
86
Periodic F2F interaction is a CSF for virtual teams Teams should meet at critical junctures, i.e., kickoff Rotating customers and leaders helps establish trust
Robarts, J. M. (2008). Practical considerations for distributed agile projects. Agile Conference, Toronto, Canada, 327-332.
ENDPOINTSTeams collocate at critical junctures, i.e., kickoff, middle, closeout, etc.
DEVELOPMENTTeams periodically collocate for iterations
PLANNINGTeams collocate for release and iteration planning
PERSONNELIndividuals rotate to maintain healthy relationships
LEADERSProject leaders keep local and remote teams in-synch
AMBASSADORSAmbassadors are exchanged to minimize intercultural dissonance
CUSTOMERSCustomer apprises remote teams of product vision, mission, goals, objectives, etc.
Regional Localization
87
Minimizing interfaces between timezones is oft cited Products should be structured to localize activities It’s easier to communicate with nearshore teams
Ramesh, B., Cao, L., Mohan, K., & Xu, P. (2006). Can distributed software development be agile? Communications of the ACM, 41(10), 41-46.
DEVELOPMENTSubsystem interfaces are devised to localize development activities
SOCIALIZATIONRemote teams engage in social activities
EMPOWERMENTEmpower remote teams to make technical decisions
MEETINGSHold synchronous meetings at the local level
LEADERSEmpower local personnel to serve as process facilitators
CUSTOMERSEmpower local personnel to serve as customer proxies
TIMEZONESMinimize organizational interfaces and organize teams by timezones
Agenda
88
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
What is Kanban? Kan-ban ('kæn-bæn): Signboard, billboard, signal
cards; Lean, just-in-time system of production A lean and just-in-time manufacturing process for
regulating the flow of production based on demand A pull-system philosophy of customized production vs.
a push system of mass-market manufacturing A set of principles for creating a lean, efficient, and
waste-free product flow by limiting work-in-process Use of simple organizational policy changes resulting
in order-of-magnitude performance improvements Framework for optimizing workflow that maximizes
efficiency, product quality, and customer satisfaction
89
Kniberg, H., & Skarin, M. (2010). Kanban and scrum: Making the most of both. Toronto, ON: C4 Media, Inc.Ladas, C. (2008). Scrumban: Essays on kanban systems for lean software development. Seattle, WA: Modus Cooperandi.Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press.
Kanban Goals
90
Kanban initially seeks to change as little as possible Change without resistance is the first Kanban goal Focus on improving quality, lead time and morale
Goal 2
Goal 3
Goal 4
Goal 5
Goal 6
Goal 7
Goal 8
Deliver high product quality (to build stakeholder trust)
Reduce long lead times (and stabilize them)
Achieve sustainable pace (work-life balance)
Provide process slack (for process improvement)
Simplify workload prioritization (of customer needs)
Provide transparency (into design and operations)
Strive for process maturity (to improve performance)
Goal 1 Optimize existing processes (rather than change them)
Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press.
Kanban Recipe for Success
91
Based on principles for product development flow Uses operations and mathematical queue theory Pragmatic operating principles for development
Focus on Quality Reduce WIP Deliver Often Balance Demand Prioritize Attack Variability
Walkthroughs
Inspections
Technical reviews
Peer reviews
Pair programming
Test driven design
Continuous integration
Design patterns
Refactoring
Design simplicity
Usability engineering
Formal methods
Process flowcharts
Workflow analysis
Kanban boards
Limit work tasks
Limit queues
Limit buffers
Limit backlogs
Simple prioritization
Adequate resources
Process automation
Policy statements
Simplify process
Short releases
Short increments
Short iterations
Small releases
Frequent releases
Small batch sizes
Customer collaboration
Developer collaboration
Ample communication
Frequent builds
Deploy often
Automatic updates
Regulate inputs
Identify bottlenecks
Create slack
Limit work-in-process
Create pull system
Focus on precision
Focus on quality
Take pride in work
Improve morale
Learn new skills
Obtain training
Continuously improve
Prioritize inputs
Business focus-
Business value focus
Influence prioritization
Stabilize process
Build stakeholder trust
Perform risk analysis
Analyze demand
Evaluate size
Evaluate complexity
Market forecasting
Technology analysis
Work item size
Work item type mix
Service class mix
Irregular flow
Rework
Ambiguous reqmnts.
Expedited requests
Environment avail.
Market fluctuations
Coordination
Technological change
Skill/experience mix
Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press.
Value Stream Mapping
92
Start by flow-charting the as-is product workflow Add buffers and queues one feels are necessary Add WIP limits to buffers, queues, and activity
Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press.
Work-in-Process
93
High work-in-process leads to longest lead times Low work-in-process greatly reduces lead times Results in better customer trust and satisfaction
Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press.
Bad Project
0
35
70
105
140
175
10/9 10/23 11/6 11/20 12/4 12/18 1/1 1/15 1/29 2/12 2/26
Time
Feat
ure
s
Inventory Started Designed Coded Complete
Good Project
0
48
96
144
192
240
2/10 2/17 2/24 3/2 3/9 3/16
Time
Fea
ture
s
Inventory Started Designed Coded Complete
Agenda
94
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Basic Agile Proj. Mgt. 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.
Agile methods are based on traditional measures Size, effort, velocity, structure, and quality common Top-notch shops use satisfaction and business value
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.
95
Burndown/Burnup Metrics Time expended is used for project tracking Tracked on a per iteration or per sprint basis Often described as a basic earned value metric
Cohn, M. (2006). Agile estimating and planning. Upper Saddle River, NJ: Pearson Education.
Type
Ideal Days
Actual Days
Ideal Hours
Actual Hours
User Stories
Story Points
Technical Tasks
Example
How many days something takes without interruptions
How many days something takes with interruptions
How many hours something takes without interruptions
How many hours something takes with interruptions
How many customer requirements have been satisfied
How many units of software size have been satisfied
How many technical tasks have been completed
96
Agile Cost Models
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.
Costs based on productivity and quality models Development costs based on LOC productivity rate Maintenance costs based on defects KLOC MH
Type
Basic Form
XP
TDD
PP
Scrum
Agile
Example
(LOC Productivity + Quality KLOC 100) Hourly Rate
(LOC 16.1575 + 0.7466 KLOC 100) Hourly Rate
(LOC 29.2800 + 2.1550 KLOC 100) Hourly Rate
(LOC 33.4044 + 2.3550 KLOC 100) Hourly Rate
(LOC 05.4436 + 3.9450 KLOC 100) Hourly Rate
(LOC 21.2374 + 1.7972 KLOC 100) Hourly Rate
97
Agile Business Value
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.
A major principle of Agile Methods is creating value ROI is the measure of value within Agile Methods There are seven closely related ROI measures
Type
Costs
Benefits
Breakeven
B/CR
ROI
NPV
Real Options
Example
Total amount of money spent on agile methods
Total amount of money gained from using agile methods
Point when the benefits of using agile methods exceed the costs
Ratio of agile methods benefits to costs of using agile methods
Ratio of adjusted agile methods benefits to costs of using them
Present value of agile methods benefits that result from their use
Value gained from incremental investments in high-risk projects
98
Agile EVM EVM has been adapted to Agile Methods EVM based on notion that total scope is known EVM may “not” be well-suited for large agile projects
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.
Type
PMB
SBL
BAC
PPC
APC
SPC
SPA
Example
Total number of story points planned for a release
Total number of iterations multiplied by iteration length
The planned budget for the release
Number of current iterations divided by planned iterations
Total story points completed divided by story points planned
Story points of work completed from backlog during iteration
Story points added/subtracted from backlog during iteration
99
Agenda
100
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Extreme Programming Costs based on avg. productivity and quality Productivity ranged from 3.5 to 43 LOC an hour Costs were $136,551, benefits were $4,373,446
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. 101
Formula
(10,000 16.1575 0.7466 10 30) 100
$4,373,446 $136,551
($4,373,446 – $136,551) $136,551 100%
($4,373,446 5) 1.055) – $136,551
$136,551 ($4,509,997 $136,551 – 1)
NORMSDIST (8.07) $4,373,446 –NORMSDIST (7.59) $136,551 EXP (–5% 5)
(10,000 .51 – 6,666.7 ) 100 – $136,551
Value
$136,551
32:1
3,103%
$3,650,396
$4,263
$4,267,100
$4,373,446
Metric
Costs
B/CR
ROI
NPV
BEP
ROA
Benefits
5
1i(
Test Driven Development Costs based on avg. productivity and quality Productivity ranged from 12 to 46 LOC an hour Costs were $249,653, benefits were $4,260,344
102
Formula
(10,000 29.2800 + 2.1550 10 100) 100
$4,260,344 $249,653
($4,260,344 – $249,653) $249,653 100%
($4,260,344 5) 1.055) – $249,653
$249,653 ($4,509,997 $249,653 – 1)
NORMSDIST(2.79) $4,260,344 –NORMSDIST(1.27) $249,653 EXP(–5% 5)
(10,000 10.51 – 6,666.67 9) 100 – $249,653
Value
$249,653
17:1
1,607%
$3,439,359
$14,629
$4,074,506
$4,260,344
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.
Pair Programming Costs based on avg. productivity and quality Productivity ranged from 15 to 86 LOC an hour Costs were $265,436, benefits were $4,244,561
103
Formula
(10,000 33.4044 + 2.3550 10 100) 100
$4,244,561 $265,436
($4,244,561 – $265,436) $265,436 100%
($4,244,561 5) 1.055) – $265,436
$265,436 ($4,509,997 $265,436 – 1)
NORMSDIST(2.69) $4,244,561 –NORMSDIST(1.10) $265,436 EXP(–5% 5)
(10,000 10.51 – 6,666.67 9) 100 – $265,436
Value
$265,436
16:1
1,499%
$3,409,909
$16,599
$4,050,919
$4,244,561
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.
Scrum Costs based on avg. productivity and quality Productivity ranged from 4.7 to 5.9 LOC an hour Costs were $578,202, benefits were $3,931,795
104
Formula
(10,000 5.4436 + 3.9450 10 100) 100
$3,931,795 $578,202
($3,931,795 – $578,202) $578,202 100%
($3,931,795 5) 1.055) – $578,202
$578,202 ($4,509,997 $578,202 – 1)
NORMSDIST(2.08) $3,931,795 –NORMSDIST(-0.15) $578,202 EXP(–5% 5)
(10,000 10.51 – 6,666.67 9) 100 – $578,202
Value
$578,202
7:1
580%
$2,826,321
$85,029
$3,660,805
$3,931,795
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.
Agile Methods 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
105
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.
ROI of Agile Methods XP ROI 18X more than traditional methods Scrum ROI 3.4X more than traditional methods Agile methods ROI 10X more than trad. methods
106Rico, 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
Agenda
107
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Burndown
Rawsthorne, D. (2009). Agile metrics. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA.
Most basic tracking chart for agile projects Tracks number of work or time units completed Commonly used to track no. story points completed
108
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)
Burnup Popular tracking chart for agile projects Tracks number of work or time units completed Basic form of cumulative workflow & overall progress
109
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)
Nicolette, D. (2009). Agile metrics. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA.
Burnup Chart
Cumulative Flow (Trad. vs. Agile)
110
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
High work-in-process leads to longest lead times Low work-in-process greatly reduces lead times Results in better customer trust and satisfaction
Anderson, D. J. (2004). Agile management for software engineering. Upper Saddle River, NJ: Pearson Education.Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press.
Agile EVM Adaptation of EVM for agile projects Mapping between traditional and agile projects Work completed is more authoritative in agile projects
111Sulaiman, 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 Chart
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)
Earned Business Value
Rawsthorne, D. (2010). Monitoring scrum projects with agile evm and earned business value metrics. Brisbane, CA: Collab.Net.
ROI is estimated for user stories in agile projects Value accrues with each completed user story Value of completed tasks is more meaningful
112
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)
Agenda
113
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
APM Tool Variety
114
There are literally dozens, if not 100s of APM tools There are dozens of free open source software tools Annual tool & price surveys are frequently conducted
VersionOne. (2010). 5th annual state of agile survey. Atlanta, GA: Author.Allen, W. (2008). Agile PM tools (hosted). Retrieved May 11, 2011 from http://weblogs.asp.net/wallen.
VersionOne
115
One of the first APM tools created in 2003 Has about 36% of the marketshare for APM tools Free for small teams, but increases sharply thereafter
http://www.versionone.com
Product Roadmapping Roadmap Authoring Customization Collaboration Publishing
Product Planning Backlog Planning and Management Epics, Goals, Themes, Feature Groups Customer Requests and Idea Management Product Roadmapping Features
Release Planning Release Planning Release Forecasting Cross Project Planning and Scheduling Regression Test Planning
Sprint Planning High Level Sprint Planning Detailed Sprint Planning Capacity Planning Issue Management Features
Iteration Closeout Reviews Sprint Reviews Sprint Retrospectives Issue and Action Item Tracking Backlog reconciliation
Tracking Sprint and Member Tracking Storyboard Wall Task Board and Test Board My Work and My Dashboard
Reporting and Analytics Program Dashboard Project Dashboard Iteration Dashboard Burnup/Burndown Reports
Other Features Agile Closeout Reviews Test Management Collaboration Open Source Integration
Rally
116
One of the first web-based APM tools created in 2004 Has about 20-30% of the marketshare for APM tools Also free for small teams and gets more expensive
http://www.rallydev.com
Communication and Collaboration Customizable Role Dashboards Rich Text, Email, and RSS Support Social Media Style Interfaces Comments, Discussions, and IM
Development Management Requirements Management Test Management Defect Management Build and Source Code Traceability
Reporting Flexible Queries and Filters Customer Tabular Graphical Reports Burnup/Burndown Reporting, etc. User Generated Mashup Support
Product Management Customer Feedback Management Product Field Support Demand Management CRM Integration and Support
Agile Project Management High Level Roadmap Decomposition Epic, Theme, and Feature Tracking User Story Planning and Tracking User Story Breakdown Management
Multi-Team Management Organization Chart Mirroring Multi Level Project Hierarchies Common Progress and Status Views Program, Feature, and Resource Rollup
Release Planning Step by Step Release Planning Team Velocity Determination Release and Iteration Schedules User Story Allocation to Iterations
Iteration Planning Iteration Goal and Theme Support Team Capacity Determination Backlog Item Prioritization Task Creation, Estimation, and Tracking
ScrumWorks
117
Scrum project management tool created circa 2004 Similar size of user base to VersionOne and Rally Leadership in agile metrics and business value
http://www.danube.com
Real Time Custom Dashboards Velocity Charts Milestone Charts Cycle Time Charts Cross Product Status Reporting
Data Accessibility Full Excel Import/Export Print to User Story Cards Web Services API Backups and Notifications
User Management Full Access Control Role Based Access Permissions Cross Site Role Templates Security Management
Integration Commercial Environment Integration Open Source Environment Integration Issue and Defect Tracking Integration Support for Tool Plugins
Product Management Project Milestone Management Epics for Project Scope Goals Categorization using Themes Business Weighting and ROI
Program Management Coordination of Multiple Projects Manage and Track Overlapping Goals Shared Component/System Modeling High Level Feature Management
Iteration Management Drag and Drop Iteration Planning Team Task Board Sprint Task Tracking Impediment Tracking
Reporting and Analytics Release Date Forecasting Basic Burnup/Burndown Reporting Canned and Custom Report Generation Analysis of Planned vs. Actuals
ExtremePlanner
118
XP project management tool created around 2004 Noted commercial tool for managing XP projects No free version, although it is moderately priced
http://www.extremeplanner.com
Test Management Test Criteria Generation Test Case Generation and Capture Test Case Initiation Test Status Reporting
Integrated Issue Tracking Track Customer Support Requests Track Bug Reports Track Ad Hoc Suggestions Transition Issues to User Stories
Report Generation Velocity and Task Tracking Iteration Burnup/Burndown Charts Cumulative Workflow Diagrams User Defined Reports
Notification and Alerts Email Notifications Notification Capture and Management Notification Viewing and Filtering User Selectable Notifications
Multiple Project Support Multiple Project Definition Multiple Project Status Tracking Multiple Project Report Generation Multiple Project Task Tracking
User Story Generation Cross Project Story Themes Create a Story from an Issue Theme and Story Template Reuse Inter Project Story Management
Release Planning Capture User Stories Generated Estimate and Prioritize User Stories View Schedule Stories for Releases View Estimated Effort for Releases
Drag and Drop Iteration Planning Iteration Generation and Management Drag and Drop User Story Management Iteration Effort Estimation Iteration Status Reporting
Mingle
119
APM tool created by ThoughtWorks in late 2007 Extensible templates for multiple agile methods Growing user base that is free for small teams
http://www.thoughtworks-studios.com
Test Management Visual Defect Workflows User Story and Defect Traceability RSS and Email Test Alerting Wiki Support for Screenshots and Reports
Project Collaboration Virtual Drag and Drop Card Walls Integrated Wiki RSS Feeds and Email Alerts Murmurs, Queues , and Comments
Enterprise Support Application Life Cycle Management Integration with IDEs Integration with Versioning Tools Integration with Build/Deployment Tools
External Interfaces I/O from Common Data Formats Integration with External Databases Integration with Workflow Tools Integration with External Software
Program Management Support for Multiple Projects Multi Project Status Tracking Multi Project Report Generation Resource Allocation and Management
Project Management Multi Agile Method Support Customizable Dashboards Workflow Generators User Management and Access Control
Release and Iteration Planning Hierarchical Card Trees Prioritized Card Ranking User Story Searching and Recall Global User Story Updating
Tracking and Reporting Customizable Templates Customizable Tabs, Favorites, and Views Advanced Filtering, Properties, and Tags Burndown, Velocity, and Ad Hoc Reports
Target Process
120
APM tool originally created for XP circa 2004 Now includes support Scrum, Lean, Kanban, etc. Also free for small teams and then price rises sharply
http://www.targetprocess.com
Quality Assurance Test Plan and Test Case Generation Automated Test Initiation User Story/Test Case Traceability Defect Tracking and Management
Reports and Dashboards Customizable Dashboards Release and Iteration Forecasting Release and Iteration Burndown Charts Task, User Story, and Iteration Progress
Collaboration Customizable Email Notifications Content Sharing and Management Support for Multiple Content Types Integration with Synchronous Tools
Product Support Customer Help Desk Portal Ideas and Issues Tracking Bug Reports Traceable to User Stories Full Customer Email Integration
Agile Planning and Tracking Backlog Management and Prioritization Release and Iteration Planning Task Boards and Personal To Do Lists Impediments and Blockage Management
Lean Development Value Stream Mapping Kanban Boards Cumulative Workflow Diagrams Work in Process Limits
Customization Customizable Development Process Customizable User Roles and Terminology Customizable Navigation and Lists Customizable Fields and Other Attributes
Integration Web Services API Visual Studio and Eclipse IDE Integration Subversion, Bugzilla, JUnit, and Selenium Single Sign On Support
Agenda
121
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Contract Type Description
Agile Contracting Models
Rico, D. F. (2011). The necessity of new contract models for agile project management. Fairfax, VA: Gantthead.Com.
New contract models emerged for agile contracts Goals, objectives, and visions are established early Buyers and suppliers collaborate throughout contract
122
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.
Performance Based Acquisition
Gansler, J. S. (2000). Guidebook for performance based services acquisition in the U.S. DoD. Washington, DC: Author.Sade, M. (2009). Seven steps to performance based services acquisition. Washington, DC: General Services Administration.
Developed by U.S. DoD in the 2000 timeframe Born out of radical acquisition reforms of 1990s Focuses on objectives and outcomes vs. process
123
Performance Based Services Acquisition
Integrated Solutions Team
Ensure management involvement Tap multi disciplinary expertise Define roles and responsibilities Develop rules of conduct Empower and incentivize team Identify stakeholders
Problem Statement
Link acquisition to strategic roadmap Link acquisition to mission objectives Link acquisition to performance goals Define desired results at a high level Decide what constitutes success Determine current performance level
Private and Public Solutions
Team approach to market research Learn from public sector Consult with private sector firms One on one industry meetings Look for existing contracts Document market research
Statement of Objectives
Elevator message Describe the scope Performance objectives Share objectives Identify the constraints Develop the background
Measure Performance
Success determinants Quality standards Proposed metrics Meaningful measures Contractual language Order of precedence
Select Contract
Compete the solution Oral presentations Past performance Best value evaluation Final source selection Conflict of interest
Manage Performance
Keep the team together Roles and responsibilities Assign accountability Formal kick off meeting Performance based mgt Review performance
Target Cost
Eckfeldt, B., Madden, R., & Horowitz, J. (2005). Selling agile: Target cost contracts. Proceedings of the Agile Conference (Agile 2005), Denver, Colorado, USA, 160-166.
Concept attributed to Toyota Production System Adapted for agile project management in 2005 Good balance of structure, flexibility, & trust
124
Target Cost Contract
Scope Statement
Business vision System metaphor User stories Effort estimate Priorities Roadmap
Statement of Work
Development days Support estimate Contingency Cost estimate Fixed profit Total cost estimate
Master Agreement
Non-disclosure terms Product ownership Indemnification terms Non-compete terms Administration Termination terms
Release Plan
Feature priorities Wireframes Development tasks Task effort Iteration plan Workflow tool
Closeout
Acceptance test Final documentation Document handover Deployment testing Joint evaluation Administrative close
Development
Iterations, Sprints, or Increments
Perform daily standup meetings Develop acceptance and unit tests Create or refactor software code in pairs Check-in code and perform unit testing Perform continuous integration Hold iteration retrospective
Change Management
Perform customer demonstration Solicit feedback from client Classify and categorize feedback Negotiate scope changes with client Update letter of agreement (LOA) Update release and iteration plans
Support Processes
Security engineering, user experience design, software certification testing, quality assurance, configuration management, etc.
PS2000 for Agile
Norwegian Computer Society. (2010). PS2000 standard contract for agile software development. Oslo, Norway: Author.
Developed by Norwegian Computer Society Adapted for IT, incremental, and agile methods Upfront scoping similar to Feature Driven Design
125
PS2000 Agile Contract
Needs Phase
Perform needs analysis Develop uncertainty matrix Analyze top level risks areas Identify development environment Prepare milestones and schedules
Solution Description Phase
Develop high level prototypes Develop architecture and design Establish development priorities Prepare description of solution Verify solution description
Approval and Completion Phase
Perform acceptance testing Perform quality certification Deliver final documentation Perform joint project evaluation Perform limited maintenance
Iterative Construction
SignContract
ApproveSolution
PrepareDelivery
Detailed Planning
Analyze needs and solution description Develop detailed iteration plan Develop detailed specifications Develop detailed design models Verify detailed design
Product Development and Verification
Document development methods and tools Develop prototypes and components Demonstrate prototypes and components Gather customer or end user feedback Perform verification and quality assurance
Testing and Debugging
Prepare test plans and specifications Perform detailed component testing Perform integration and system testing Monitor, log, and remediate defects Perform quality and reliability modeling
Checkpoints and Other Services
Configuration management, iteration retrospectives, checkpoint progress reviews, re-planning and mid-course corrections, training, etc.
, Beta Testing,
Evolutionary Acquisition
Ford, D. N., & Dillard, J. (2009). Modeling the performance an risks of evolutionary acquisition. Defense Acquisition Review Journal, 16(2), 143-158.
Idea originated from Barry Boehm in 1985 Adapted to U.S. DoD acquisitions in 1999/2000 Incrementally insert emerging technology into acq.
126
Evolutionary Acquisition
Technology Development
Engineering &Manufacturing
Production &Deployment
Operations &Support
6 Months 12 Months 18 Months 24 Months 30 Months
Increment 1Spiral 1 Spiral 2 Spiral 3
Technology Strategy
Increment 2Spiral 1 Spiral 2 Spiral 3
Technology Strategy
Increment 3Spiral 1 Spiral 2 Spiral 3
Technology Strategy
Increment 4Spiral 1 Spiral 2 Spiral 3
Technology Strategy
Increment 5Spiral 1 Spiral 2 Spiral 3
Technology Strategy
Increment 1Spiral 1 Spiral 2 Spiral 3
System Prototype
Increment 2Spiral 1 Spiral 2 Spiral 3
System Prototype
Increment 3Spiral 1 Spiral 2 Spiral 3
System Prototype
Increment 4Spiral 1 Spiral 2 Spiral 3
System Prototype
Increment 1Spiral 1 Spiral 2 Spiral 3
Finished System
Increment 2Spiral 1 Spiral 2 Spiral 3
Finished System
Increment 3Spiral 1 Spiral 2 Spiral 3
Finished System
Increment 1Spiral 1 Spiral 2 Spiral 3
LRIP
Increment 2Spiral 1 Spiral 2 Spiral 3
LRIP
Increment 1Spiral 1 Spiral 2 Spiral 3
FRPS
CDR CDRCDR
FDR FDR
Material Solution Analysis
MDD
A1
MDD
A2
B1
MDD
A3
B2
C1
MDD
A4
B3
C2
MDD
IOC
FOC
Lean & Agile Acquisition
Reagan, R. B., & Rico, D. F. (2010). Lean and agile acquisition and systems engineering: A paradigm whose time has come. Defense AT&L Magazine, 39(6), 48-52.
Originated from agile methods popularity in 2002 Gained foothold in U.S. DoD with Scrum popularity Front loads acquisition process with early deliveries
127
Lean & Agile Acquisition
Program 1
Program 2
Program n
6 months 12 months 18 months 24 months 30 months
A1 B1 C1 FRP FOCMDD
Release 1Sprint 0 Sprint 3 Sprint 6
Operational Capability
Release 2Sprint 0 Sprint 3 Sprint 6
Operational Capability
Release 3Sprint 0 Sprint 3 Sprint 6
Operational Capability
Release 4Sprint 0 Sprint 3 Sprint 6
Operational Capability
FDR IOC
Material Solution Analysis
Technology Development
Engineering & Manufacturing
Production &Deployment
Operations &Support
Release 5Sprint 0 Sprint 3 Sprint 6
Operational Capability
CDR
A2 B2 C2 FRP FOCMDD
Release 1Sprint 0 Sprint 3 Sprint 6
Operational Capability
Release 2Sprint 0 Sprint 3 Sprint 6
Operational Capability
Release 3Sprint 0 Sprint 3 Sprint 6
Operational Capability
Release 4Sprint 0 Sprint 3 Sprint 6
Operational Capability
FDR IOC
Release 5Sprint 0 Sprint 3 Sprint 6
Operational Capability
CDR
A3 B3 C3 FRP FOCMDD
Release 1Sprint 0 Sprint 3 Sprint 6
Operational Capability
Release 2Sprint 0 Sprint 3 Sprint 6
Operational Capability
Release 3Sprint 0 Sprint 3 Sprint 6
Operational Capability
Release 4Sprint 0 Sprint 3 Sprint 6
Operational Capability
FDR IOC
Release 5Sprint 0 Sprint 3 Sprint 6
Operational Capability
CDR
Agenda
128
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Diffusion of Innovations
Rogers, E. (2003). Diffusion of innovations. New York, NY: Free Press.
Idea originated with Everett Rogers in 1962 A few early adopters will embrace a new idea The majority will resist change for a longer time
129
Diffusion of Innovations
Dif
fusi
on
Innovators EarlyAdopters
EarlyMajority
LateMajority Laggards
Crossing the Chasm
Moore, G. A. (2002). Crossing the chasm: Marketing and selling high tech products to mainstream customers. New York, NY: HarperCollins.
Idea originated with Geoffrey Moore in 1991 Time between adoption phases is not uniform Large gap between early adopters and majority
130
Crossing the Chasm
Dif
fusi
on
Innovators EarlyAdopters
EarlyMajority
LateMajority Laggards
Virginia Satir Model
Satir, V., Banmen, J., Gerber, J., & Gomori, M. (1991). The satir model: Family therapy and beyond. Palo Alto, CA: Science and Behavior Books.
Idea originated with Virginia Satir in 1980s Large changes plunge organizations into chaos Depth and length of chaos is related to its magnitude
131
Virginia Satir Model
StatusQuo Resistance Chaos Recovery New
State
Pro
duct
ivit
y
Incremental Change
Smith, G., & Sidky, A. (2009). Becoming agile: In an imperfect world. Greenwich, CT: Manning Publications.
Large change, no matter how good, often fails Goal is to break changes into smaller increments Smaller and imperceptible change is more successful
132
Incremental Change
StatusQuo
Resist-stance Chaos Reco-
veryNewState
StatusQuo
Resist-ance Chaos Reco-
veryNewState
StatusQuo
Resist-ance Chaos Reco-
veryNewState
Pro
duct
ivit
y
Organizational Change
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.
Change, no matter how small or large, is difficult Smaller focused changes help to cross the chasm Shrinking, simplifying, and motivation are key factors
133
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
Organization Change Methods
Holman, P., Devane, T., & Cady, S. (2007). The change handbook: The definitive resource on today’s best methods for emerging whole systems. Berrett-Koehler.
Top down big bang change is most often tried Punctuated equilibrium is most well known form Project champions and coaching are very effective
134
Organization Change Methods
One time radical organizational change often motivated by a severe crisis, i.e., crisis is a catalyst for changePunctuated Equilibrium
Personal Influence
Business Case
Executive Coaching
Executive Commitment
Adequate Resources
Top Down Change
Model Driven Change
Manager Involvement
Employee Involvement
Training & Education
Evolutionary Change
Project Champion
Coaching & Mentoring
Just Do It
Informal appeal for authority to change based on personal trust or relationships, i.e., elevator speech
Compelling qualitative and quantitative business value analysis, i.e., return on investment analysis
Formal or informal mentoring or tutoring of organizational executives and senior leaders
A personal endorsement for change from an organizational executive or senior leader
Formal allocation of resources to execute a large organizational change initiative
One time organization change initiative based on a formal strategic plan, i.e., big bang organization change
Isolated change initiatives based on step by step frameworks, i.e., PDCA, DMAIC, DMADV, etc.
Psychological involvement and commitment of middle managers to avoid bureaucratic obfuscation
Psychological involvement and commitment of lower level workforce to avoid operational resistance
Formal classroom instruction and education to impart the skills necessary for successful change
The implementation of numerous smaller scale changes to prevent long term psychological resistance and chaos
Formal appointment of an individual to take personal responsibility for success of change, i.e., heavyweight PM
Formal or informal mentoring or tutoring of employees or team members to help them overcome hidden obstacles
Assuming personal responsibility for change with or without formal authorization, i.e., forgiveness vs. permission
Agenda
135
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
136
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.
Google started using agile methods in 2005 Used it on one of their most profitable products Incrementally adopted agile one practice at a time
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
137
Shrink-Wrapped—Primavera
Schatz, B., & Abdelshafi, I. (2005). Primavera gets agile: A successful transition to agile development. IEEE Software, 22(3), 36-42.
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
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
138
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.
FDA suppliers started using agile methods in 2008 Used it on most stringent Class 3 certified products Used to modernize 1990s era products & processes
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
139
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.
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
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"
140
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.
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
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
Agenda
141
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
Leadership Considerations Agile management is delegated to the lowest level There remain key leadership roles & responsibilities Communication, coaching, & facilitation are key ones
142
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
Advanced Agile Measures Agile Methods are a fundamentally new paradigm Agile Methods are “not” lighter Traditional Methods They should not be viewed through a traditional lens
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
Interaction frequency Comm. quality Relationship strength
Customer trust Customer loyalty Customer satisfaction
Team competence Team motivation Team cooperation
Team trust Team cohesion Team communications
Batch/queue size WIP/WIP constraints Cadence/iterations
Experimental willingness Risk/failure threshold Feedback/criticism thresh.
Org. flexibility Mgt. flexibility Individual flexibility
Process flexibility Design flexibility Technology 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
143
Agile Teamwork Model A key element of any project is good teamwork Agile projects depend upon teamwork even more Balance between cohesion & out-of-the-box thinking
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
144
Agile UX—User Experience Design
145Johnson, J. D. (2010). Agile UX retreat: We should value competencies over roles. Retrieved April 22, 2011 from http://www.jeremydjohnson.com/index.php/2010/03Kollmann, J., Sharp, H., & Blandford, A. (2009). The importance of identity and vision to user experience designers on agile projects. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA, 11-18.
User experience is key ingredient to success UX should be included throughout agile life cycle UX involves end to end product & service experience
Product Owner Agile UX Development
Define Product Vision & Strategy
DefineUser Needs
BuildUser Experience
BuildProduct
Competitive Analysis
Define Feature Set
Quantify Business Value
Prioritization
Define Business Rules
Pricing & Budgeting
Project Accountability
Partnerships & Licensing
User Interviews
Contextual Inquiry
User Flows
Wireframes & Mockups
Prototyping
Usability Testing
Web Metrics Analysis
User Feedback
GUI Implementation
Core Capabilities
Core Services
Value Adding Capabilities
Value Adding Services
Distributed Framework
Central Framework
Support Services
Front End Code
Back End Code
Database Schema
Technology Selection
Usability Testing
User Experience Testing
Market Testing
Overall Product Evaluation
Myths about Agile Proj. Mgt. Common myths abound, although agile methods
have been around for ~20 years: Agile methods are only for software development Agile methods are only for small co-located teams Agile methods have no documentation Agile methods have no requirements Agile methods need traditional system architectures Agile methods have no project management Agile methods are undisciplined and unmeasurable Agile methods create unmaintainable systems Agile methods result in security vulnerabilities
146
Agile Documentation
147Rico, D. F. (2008). Agile methods and software documentation. Retrieved April 21, 2011 from http://davidfrico.com/rico08e.pdfRueping, A. (2003). Agile documentation: A pattern guide to producing lightweight documents for software projects. West Sussex, England: John Wiley & Sons.
Myth that voluminous documentation is needed Myth that agile methods do not use documentation Right sized, just in time, and just enough documents
Contracts
Document Type
Project Plans
Requirements
Architecture
Design
Coding
Tests
User guides
Quality Assurance
Agile Documentation
Performance, target cost, agile contract, lean acquisition
Release plans, iteration plans, kanban boards, workflow tools
Vision, mission, capabilities, scope, user stories, use cases
Metaphors, story boards, system modeling language, spikes
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 & audio clips
Code structure, defects, running tests, reliability, performance
Conclusion
148
Agility is the evolution of management thought Confluence of traditional and non-traditional ideas Improve performance by over an order of magnitude
“The world of traditional project management belongs to yesterday”“Don’t waste your time using traditional project management on 21st century projects”
Agile project management is …
A systems development approachNew product development approachExpertly 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.
Agenda
149
• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices
• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources
APM Textbooks I
150
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
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. (2004). Agile project management: Creating innovative products. Boston, MA: Pearson Education.DeCarlo, D. (2004). Extreme project management: Using leadership, principles, and tools to deliver value in the face of volatility. San Francisco, CA: Jossey-Bass.Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education.
APM Textbooks II
151
Many other Agile Project Management books Good background on Agile Project Management Newer Agile Project Management books emerging
Chin, G. L. (2004). Agile project management: How to succeed in the face of changing project requirements. New York, NY: Amacom.Aguanno, K. (2005). Managing agile projects. Lakefield, Ontario, Canada: Multi-Media Publications.Pries, K. H., & Quigley, J. M. (2010). Scrum project management. Boca Raton, FL: CRC Press.Augustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education.Sliger, M., & Broderick, S. (2008). The software project manager's bridge to agility. Boston, MA: Addison-Wesley.
APM Textbooks III
152
Project management books continuing to emerge Project management becoming dominant paradigm Some are from popular project management authors
Wysocki, R. K. (2009). Effective project management: Traditional, agile, and extreme. Indianapolis, IN: Wiley.Anderson, D. J. (2004). Agile management for software engineering: Applying the theory of constraints for business results. Upper Saddle River, NJ: Pearson Education.Goodpasture, J. C. (2010). Project management the agile way: Making it work in the enterprise. Ft. Lauderdale, FL: J. Ross Publishing.Cobb, C. G. (2011). Making sense of agile project management: Balancing control and agility. Hoboken, NJ: John Wiley & Sons.Layton, M. C., & Maurer, R. (2011). Agile project management for dummies. Hoboken, NJ: Wiley Publishing.
Scaling Agile Methods
153
Scaling is the new frontier in Agile Methods research Many of them stem from Planning XP by Kent Beck Books emerging on global distributed agile teams
Woodward, E., Surdek, S., & Ganis, M. (2010). A practical guide to distributed scrum. Indianapolis, IN: IBM Press.Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Pearson Education.Schiel, J. (2010). Enterprise-scale agile software development. Boca Raton, FL: CRC Press.Larman, C., & Vodde, B. (2008). Scaling lean and agile development: Thinking and organizational tools for large-scale scrum. Boston, MA: Addison-Wesley.Larman, C., & Vodde, B. (2010). Practices for scaling lean and agile development. Boston, MA: Addison-Wesley.
Agile Organization Change
154
Agile methods are one of the newest innovations Organizational change is a major obstacle for agile Many books emerging to help manage agile adoption
Appelo, J. (2011). Management 3.0: Leading agile developers and developing agile leaders. Boston, MA: Pearson Education.Cohn, M. (2010). Succeeding with agile: Software development using scrum. Boston, MA: Pearson Education.Elssamadisy, A. (2009). Agile adoption patterns: A roadmap to organizational success. Boston, MA: Pearson Education.Coplien, J. O., & Harrison, N. B. (2004). Organizational patterns of agile software development. Upper Saddle River, NJ: Prentice-Hall.Smith, G., & Sidky, A. (2009). Becoming agile: In an imperfect world. Greenwich, CT: Manning Publications.
Agile Development
155
100s of agile methods books exist for all disciplines Range from requirements through documentation Thwart notion that agile methods have big gaps
Leffingwell, D. (2011). Agile software requirements: Lean requirements practices for teams, programs, and the enterprise. Boston, MA: Pearson Education.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.