Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers

Lean & Agile
Project Management
for Executives, Sr. Managers,
& Key Decision Makers
Dr. David F. Rico, PMP, ACP, CSM
Twitter: @dr_david_f_rico
Website: http://www.davidfrico.com
LinkedIn: http://www.linkedin.com/in/davidfrico
Facebook: http://www.facebook.com/profile.php?id=1540017424

Author Background
 DoD contractor with 28+ years of IT experience
 B.S. Comp. Sci., M.S. Soft. Eng., & D.M. Info. Sys.
 Large gov’t projects in U.S., Far/Mid-East, & Europe

 Published six books & numerous journal articles
 Adjunct at George Washington, UMUC, & Argosy
 Agile Program Management & Lean Development
 Specializes in metrics, models, & cost engineering
 Six Sigma, CMMI, ISO 9001, DoDAF, & DoD 5000
 Cloud Computing, SOA, Web Services, FOSS, etc.
2

Agenda

• Motivation • Virtual Teams
• Introduction • Lean/Kanban
• Business Case • Metrics and Models
• Major Approaches • Costs and Benefits
• Major Phases • Earned Value Mgt.
• Release Planning • Major Tools
• Iteration Planning • Contract Models
• Estimating Practices • Change Models
• Risk Analysis • Case Studies
• Security Engineering • Summary
• Scaling Practices • Resources
3

Information Age
 U.S. is no longer an industrial age nation
 U.S. part of a group of post industrial countries
 U.S. consists of information age knowledge workers
100%

80%
Percent of Economy

Information
60%
Service

40% Industry

Agriculture
20%

0%
1860 1870 1880 1890 1900 1910 1920 1930 1940 1950 1960 1970 1980 1990

Bell, D. (1999). The coming of post industrial society. New York, NY: Basic Books.
4

System Complexity is Growing
 21st century systems are becoming more complex
 Number of physical parts are becoming smaller
 Nano-circuitry and software hide complexity

Moody, J. A., et al. (1997). Metrics and case studies for evaluating engineering designs. Upper Saddle River, NJ: Prentice-Hall.
5

Software Century
 No. of software-intensive systems is growing
 80% of US DoD functions performed in software
 Major driver of cost, schedule, & tech. performance

Kennedy, M. P., & Umphress, D. A. (2011). An agile systems engineering process: The missing link. Crosstalk, 24(3), 16-20.
6

Technological Change
 21st century systems are technology intensive
 Technology is evolving at an exponential speed
 Technology is obsolete before project completion

Kurzweil, R. (2005). The singularity is near: When humans transcend biology. New York, NY: Penguin Group.
7

Large, Traditional Projects
 Big projects result in poor quality and scope changes
 Productivity declines with long queues/wait times
 Long projects are unsuccessful or canceled
Size vs. Quality Size vs. Requirements Growth
16.00 40%
Defect Density

12.80 32%

Percentage
9.60 24%

6.40 16%

3.20 8%

0.00 0%
0 2 6 25 100 400 0 2 6 25 100 400
Lines of Code (Thousands) Lines of Code (Thousands)

Size vs. Productivity Size vs. Success
5.00 60%
Code Production Rate

4.00 48%
Percentage

3.00 36%

2.00 24%

1.00 12%

0.00 0%
0 2 6 25 100 400 0 2 6 25 100 400
Lines of Code (Thousands) Lines of Code (Thousands)

Jones, C. (1991). Applied software measurement: Assuring productivity and quality. New York, NY: McGraw-Hill. 8

Global Project Failures
 Challenged and failed projects hover at 67%
 Big projects fail more often, which is 5% to 10%
 Of $1.7T spent on IT projects, over $858B were lost
$1.8
2010 33% 41% 26%

2008 32% 44% 24%
$1.4

Trillions (US Dollars)
2006 35% 46% 19%

2004 29% 53% 18% $1.1
Year

2002 34% 51% 15%

2000 28% 49% 23% $0.7

1998 26% 46% 28%
$0.4
1996 27% 33% 40%

1994 16% 53% 31%
$0.0
0% 20% 40% 60% 80% 100% 2002 2003 2004 2005 2006 2007 2008 2009 2010

Successful Challenged Failed Expenditures Failed Investments

Standish Group. (2010). Chaos summary 2010. Boston, MA: Author.
Sessions, R. (2009). The IT complexity crisis: Danger and opportunity. Houston, TX: Object Watch.
9

Requirements Defects & Waste
 Requirements defects are #1 reason projects fail
 Traditional projects specify too many requirements
 More than 65% of requirements are never used at all
Defects Waste
Never
Requirements
45%
47%
Other 7% Always 7%

Implementation
Often 13%
18% Rarely
Design 19%
28% Sometimes
16%

Sheldon, F. T. et al. (1992). Reliability measurement: From theory to practice. IEEE Software, 9(4), 13-20
Johnson, J. (2002). ROI: It's your job. Extreme Programming 2002 Conference, Alghero, Sardinia, Italy.
10

Agenda

11

Today’s Whirlwind Environment

Global
Competition
Work Life
Imbalance
Demanding
Customers
 Overruns
Vague  Attrition
Requirements  Escalation
 Runaways
 Cancellation
Organization
Downsizing
Technology
Change
System
Complexity

12

Need for a New Model
 Need for a new model of project management
 Cope with high-level of uncertainty and ambiguity
 With just the right balance of flexibility and discipline
R&D Oriented People Centered Adaptive Customer Friendly Fast & Efficient Disciplined

 New discoveries  Highly-talented people  Global threats  Customer interaction  New technology  Lightweight strategy

 Complex problems  Cross-functional teams  Market threats  A lot of communication  Quick decision-making  Lightweight plans
 One-off systems  Small team size  New customer needs  Customer demos  Iterative delivery cycles  Lightweight lifecycles
 Vague requirements  A lot of communication  Changing scope  Customer feedback  Frequent deliveries  Security engineering
 Incomplete information  Interpersonal trust  Changing technology  Business value focus  Fast delivery schedules  Light requirements

 High uncertainty  Rich collaboration  Changing regulations  Customer satisfaction  Short timelines  Light architecture
 Experimentation  Empowered decisions  Continuous change  Customer responsive  Fast time-to-market  Lightweight design
 Simulations  Sustainable pace  Flexible culture  Customer sensitivity  First-mover capability  Code reviews
 Prototyping  Daily interaction  Flexible attitudes  Customer relationships  Minimal process costs  Rigorous V&V

 Innovation oriented  Rich communications  Flexible policies  Customer contact  Low work-in-process
-  Rigorous CM
 New products  Face-to-face interaction  Flexible processes  Customer involvement  Flexible processes  Rigorous QA
 Creative solutions  Cohesiveness  Flexible technologies  Customer driven  Market responsiveness  Project reviews

Augustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education.
Chin, G. (2004). Agile project management: How to succeed in the face of changing project requirements. Broadway, NY: Amacom.
DeCarlo, D. (2004). Extreme project management: Using leadership, principles, and tools to deliver value in the face of volatility. San Francisco, CA: Jossey-Bass.
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 13

What is Agility?
 A-gil-i-ty (ə-'ji-lə-tē) Property consisting of quickness,
lightness, and ease of movement; To be very nimble
 The ability to create and respond to change in order to
profit in a turbulent global business environment
 The ability to quickly reprioritize use of resources when
requirements, technology, and knowledge shift
 A very fast response to sudden market changes and
emerging threats by intensive customer interaction
 Use of evolutionary, incremental, and iterative delivery
to converge on an optimal customer solution
  Maximizing the BUSINESS VALUE with right sized, just-
enough, and just-in-time processes and documentation 
Highsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.

14

Values of Agile Project Mgt.
 People-centric way to create innovative solutions
 Market-centric model to maximize business value
 Alternative to large document-based methodologies
Agile Methods Agile Methods Traditional Methods
‘Values’ ‘Principles’ ‘Values’
Customer also Customer valued Contract
known as more than
Collaboration Interaction Negotiation

Individuals & also High Performance valued Processes
known as more than
Interactions Teams & Tools

Working also Iterative valued Comprehensive
known as more than
Systems Development Documentation

Responding also Adaptability valued Following
to Change known as more than a Plan
or Flexibility

Agile Manifesto. (2001). Manifesto for agile software development. Retrieved September 3, 2008, from http://www.agilemanifesto.org
15

How do Lean & Agile Intersect?
 Agile is naturally lean and based on small batches
 Agile directly supports six principles of lean thinking
 Agile may be converted to a continuous flow system
Agile Values Lean Pillars Lean Principles Lean & Agile Practices Flow Principles
 Customer relationships, satisfaction, trust, and loyalty
Empowered Relationships  Team authority, empowerment, and resources Decentralization
Teams  Team identification, cohesion, and communication
 Product vision, mission, needs, and capabilities
Respect
Customer Value  Product scope, constraints, and business value Economic View
for People  Product objectives, specifications, and performance
Customer
 As is policies, processes, procedures, and instructions
Collaboration  To be business processes, flowcharts, and swim lanes
WIP Constraints
Value Stream
 Initial workflow analysis, metrication, and optimization & Kanban
 Batch size, work in process, and artifact size constraints
Control Cadence
Iterative Continuous Flow  Cadence, queue size, buffers, slack, and bottlenecks
Delivery  Workflow, test, integration, and deployment automation & Small Batches
 Roadmaps, releases, iterations, and product priorities
Continuous  Epics, themes, feature sets, features, and user stories
Customer Pull Fast Feedback
Improvement  Product demonstrations, feedback, and new backlogs
Responding
 Refactor, test driven design, and continuous integration
to Change  Standups, retrospectives, and process improvements
Manage Queues/
Perfection
 Organization, project, and process adaptability/flexibility Exploit Variability

  
Womack, J. P., & Jones, D. T. (1996). Lean thinking: Banish waste and create wealth in your corporation. New York, NY: Free Press.
Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. New York, NY: Celeritas.
Reagan, R. B., & Rico, D. F. (2010). Lean and agile acquisition and systems engineering: A paradigm whose time has come. DoD AT&L Magazine, 39(6). 16

When to use Agile Proj. Mgt.
 On exploratory or research/development projects
 When fast customer responsiveness is paramount
 In organizations that are highly innovative & creative
Traditional Project Management Agile Project Management
 Predictable situations  High levels of uncertainty and unpredictability
 Low technology projects  High technology projects
 Stable, slow moving industries  Fast paced, highly competitive industries
 Low levels of technological change  Rapid pace of technological change
 Repeatable operations  Research oriented, discovery projects
 Low rates of changing project performance  Large fluctuations in project performance
 Long term, fixed price production contracts  Shorter term, performance based RDT&E contracts
 Achieving concise economic efficiency goals  Achieving high impact product/service effectiveness
 Highly administrative contracts  Highly creative new product development contracts
 Mass production and high volume manufacturing  Customer intensive, one off product/service solutions
 Highly predictable and stable market conditions  Highly volatile and unstable market conditions
 Low margin industries such as commodities  High margin, intellectually intensive industries
 Delivering value at the point of plan  Delivering value at the point of sale

Pine, B. J. (1993). Mass customization: The new frontier in business competition. Boston, MA: Harvard Business School Press.
17

Agile World View
 “Agility” has many dimensions other than IT
 It ranges from leadership to technological agility
 The focus of this brief is program management agility
Agile Leaders
Agile Organization Change
Agile Acquisition & Contracting
Agile Strategic Planning

 Agile Capability Analysis
Agile Program Management

Agile Project Management
Agile Systems Development
Agile Processes & Practices
Agile Tools
Agile Information Systems
Agile Tech. 18

Agenda

19

Agile Adoption Rates
 VersionOne found 80% using agile methods today
 Most are using Scrum with several key XP practices
 Release planning/continuous integration are vital tools

House, D. (2012). Sixth annual state of agile survey: State of agile development. Atlanta, GA: VersionOne.
20

Surveys of Agile Methods
 Many surveys of agile methods since 2003
 AmbySoft and VersionOne collect annual data
 Agile benefits are above 50% in most categories

Rico, D. F. (2008). What is the return-on-investment of agile methods? Retrieved February 3, 2009, from http://davidfrico.com/rico08a.pdf
21

Case Studies of Agile Methods
 Agile (138 pt.) and traditional methods (99 pt.)
 Agile methods fare better in all benefits categories
 Agile methods 359% better than traditional methods
Category Agile Traditional Difference
Cost Reduction 9%
Schedule Reduction 33%
Productivity Improvement 55%
Quality Improvement 24%
Customer Satisfaction Imp. 56%
Return on Investment 2,811% 470% 2,341%

Rico, D. F. (2008). What is the ROI of agile vs. traditional methods? TickIT International, 10(4), 9-18.
22

Benefits of Agile Methods
 Analysis of 23 agile vs. 7,500 traditional projects
 Agile projects are 54% better than traditional ones
 Agile has lower costs (61%) and fewer defects (93%)
2.8 18
Before Agile Before Agile
3.00 20
After Agile After Agile
2.25 15 11
1.1
1.50 10

61% 39%
0.75 5
Lower Less
Cost Staff
Project Cost in Millions $ Total Staffing

18 2270
Before Agile Before Agile
20 2500
13.5 After Agile After Agile
15 1875

10 1250
381
93%
5 24% 625 Less
Faster
Defects
Delivery Time in Months Cumulative Defects

Mah, M. (2008). Measuring agile in the enterprise: Proceedings of the Agile 2008 Conference, Toronto, Canada.
23

Agile Testing Costs & Benefits
 Most agile testing tools are “free” open source
 A build server is no more than a commodity PC
 10x more efficient/effective than traditional testing

Grant, T. (2005). Continuous integration using cruise control. Northern Virginia Java Users Group (Novajug), Reston, Virginia, USA.
Fredrick, J. (2008). Accelerate software delivery with continuous integration and testing. Japanese Symposium on Software Testing, Tokyo, Japan.
24

Business Value of Agile Methods
 Productivity is accelerated with light weight processes
 Quality goals are obtained with disciplined processes
 Agile Methods have up to 20 times lower total costs

Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods:
Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross.
25

Benefits of Organizational Agility
 Study of 15 agile vs. non-agile Fortune 500 firms
 Based on models to measure organizational agility
 Agile firms out perform non-agile firms by up to 36%

Hoque, F., et al. (2007). Business technology convergence. The role of business technology convergence in innovation
and adaptability and its effect on financial performance. Stamford, CT: BTM Institute.
26

Agenda

27

Scrum Project Management
 Created by Jeff Sutherland at Easel in 1993
 Product backlog comprised of customer needs
 Barely-sufficient project management framework
Initial Planning Sprint Cycle

Discovery Session Sprint

 Agile Training  Select Tasks and Create Tests
 Project Discovery  Create Simple Designs
 Code and Test Software Units
 Process Discovery
 Perform Integration Testing
 Team Discovery
 Maintain Daily Burndown Chart
 Initial Backlog  Update Sprint Backlog

Release Planning Sprint Planning Daily Scrum Sprint Review

 Business Case  Set Sprint Capacity  Completed Backlog Items  Present Backlog Items
 Desired Backlog  Identify Tasks  Planned Backlog Items  Record Feedback
 Estimate Tasks  Impediments to Progress  Adjust Backlog
 Hi-Level Estimates
 Prioritize Backlog
 Finalize Backlog
Sprint Retrospective

Product Backlog Sprint Backlog Potentially Shippable Product

 Prioritized Requirements  List of Technical Tasks Assigned to a Sprint  Working Operational Software

Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.
28

XP Project Management
 Created by Kent Beck at Chrysler in 1998
 Release plan is comprised of customer needs
 Lightweight, rigorous near-term planning element
Release Planning Iteration Planning

Exploration Phase Exploration Phase

 Build a Team  Split User Stories  Analyze Release Plan  Read User Stories
 Write User Stories  Spike User Stories  Identify Iteration Goal  Develop Tasks
 Estimate User Stories  Write User Tests  Select User Stories  Split Tasks

Commitment Phase Commitment Phase

 Sort by Value  Choose a Scope  Accept Tasks  Analyze Schedules
 Sort by Risk  Set Iteration Length  Set Individual Velocity  Set Load Factors
 Set Velocity  Develop Release Plan  Estimate Tasks  Balance Tasks

Steering Phase Steering Phase

 Select Iteration  New Release Plan  Select Partner  Unit/Integration Test
 Adjust Velocity  Select Tools  Write Unit Tests  User Acceptance Test
 Insert New Stories  Adjust Teams  Design and Code  Record Progress

Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.
29

Project Leadership Model
 Created by Sanjiv Augustine at CC Pace in 2005
 Builds agile cultures, mind-sets, and environments
 Leadership model for managing agile project teams
Foster Alignment and Cooperation Encourage Emergence and Self Organization Learning/Adaptation

Organic Teams Guiding Vision Simple Rules Open Information Light Touch Adaptive Leadership

Leadership Leadership Leadership Leadership Leadership Leadership

 Craftsmanship  Team Vision  Culture of Change  Conduct Standups  Adapt Style  Embodied Presence
 Collaboration  Team Alignment  Value Focus  Promote Feedback  Roving Leadership  Embodied Learning
 Guiding Coalition  Bold Future  Build Trust  Go With Flow
 Community  Shared Expectations  Facilitate Action  Work Life Quality
 Build on Strengths
 Gain Commitments

Management Management Management Management Management Management

 Identify Community  Business Outcomes  Assess Status Quo  Team Collocation  Decentralize Control  Daily Feedback
 Design Structures  Delineate Scope  Customize Method  Get Onsite Customer  Pull vs. Push  Monitor/Adapt Rules
 Get Team Players  Estimate Effort  Release Plan  Practice Pairing  Manage Flow  Monitor Practices
 Adaptive Enterprise  Design Vision Box  Iteration Plans  Information Radiator  Use Action Sprints  Retrospectives
 Elevator Statement  Facilitate Design  Map Value Stream  Scenario Planning
 Conduct Testing
 Manage Releases

Augustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education.
30

Flexible Project Management
 Created by Doug DeCarlo at Cutter in 2004
 Focus is on collaboration, scoping, and speed
 Thinner traditional project management approach
Visionate Speculate Innovate Re-Evaluate Disseminate

Sponsor’s Vision Planning Meeting Learning by Doing Business Questions Product Launch

 Interview Sponsor  Collective Vision  SCORE Model  Who Needs It?  Acceptance Testing
 Describe Objectives  Size Deliverables  Architecture  What Will It Take?  Documentation
 Project Prospectus  Map Schedule  Development  Can We Get It?  Support Plan
 Business Questions  Choose Life Cycle  Construction  Is It Worth It?  Maintenance Plan
 Requirements ID’d  Testing  Deploy Solution
 Development Tools  Time Boxing  Customer Service
Collective Vision Project Review
 Risk Planning  Trial and Error
 Scope Meeting  Check Performance
 Collaboration
 Future Scenarios  Check Schedule Stabilization
Post Meeting
 Project Skinny  Check Costs  Training/Education
 Project Boundaries  PM Infrastructure Generate Results  Check Benefits  Utilization
 Project Vision  Financial Goals  Visibility  Check Project ROI  Performance
 Win Conditions  Benefit Plan  Early Value  Go/No-Go Decision  Feedback
 Benefit Map  Partner Agreements  Fast Failures  Corrective Action
 Wow Factor
Project Changes
 Uncertainty Profile Business Questions Business Questions Lessons Learned
 Re-Direct As-Needed
 Go/No-Go Decision  Modify Questions  Update Vision
Collective Vision Team Rewards
 Update Stakeholders
Select Core Team Update Prospectus Update Prospectus  Re-examine Team Track Benefits

DeCarlo, D. (2004). Extreme project management: Using leadership, principles, and tools to deliver value in the face of volatility. San Francisco, CA: Jossey-Bass.
31

Adaptive Project Framework
 Created by Bob Wysocki for consulting in 2008
 Designed to be a generic model for non-IT projects
 Lightweight traditional project management approach
Adaptive Project Framework

Scoping Planning Feasibility Checkpoint Review

 Identify Opportunity  Identify Project Type  Develop Prototype  Analyze Needs  Finalize Documents
 Develop CoS  Prioritize Constraints  Reprioritize Needs  Evaluation Solution  Lessons Learned
 Write PoS  Develop WBS  Detailed WBS  Estimate Value  Process Changes
 Document Needs  Team Formation  Estimate Resources  Determine Success  Final Report
 Stage Gate 1 Review  Stage Gate 2 Review  Stage Gate 3 Review  Stage Gate 4 Review  Stage Gate 5 Review

Cyclical Product or Service Implementation

Cycle Planning Product or Service Implementation Daily Meetings Cycle Reviews

 Responsibilities  Select Personnel with Needed Skills  Arrange Facilities  Update Requirements
 Timelines  Identify Detailed Technical Tasks  Prepare Agendas  Update Scope
 Work Packages  Create Detailed Architectures and Designs  Send Meeting Notices  Update Schedules
 Communications  Select and Implement Technical Solutions  Facilitate Meetings  Update Plans
 Governance  Perform Development and Operational Tests  Record Action Items  Inform Stakeholders

Continuous Improvement
Stage Gate 3.n
 Continually improve process, documents, team, architecture, designs, implementation, tests, etc. Review

Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education.
32

Agile Project Management
 Created by Jim Highsmith at Cutter in 2003
 Focus on strategic plans and capability analysis
 Most holistic agile project management framework
Innovation Lifecycle

Envision Speculate Explore Launch Close

 Product Vision  Gather Requirements  Iteration Management  Final Review  Clean Up Open Items
 Product Architecture  Product Backlog  Technical Practices  Final Acceptance  Support Material
 Project Objectives  Release Planning  Team Development  Final QA  Final Retrospective
 Project Community  Risk Planning  Team Decisions  Final Documentation  Final Reports
 Delivery Approach  Cost Estimation  Collaboration  Final Deployment  Project Celebration

Iterative Delivery

Technical Planning Development, Test, & Evaluation Operational Testing Adapt

 Story Analysis  Development Pairing  Integration Testing  Focus Groups
 Task Development  Unit Test Development  System Testing  Technical Reviews
 Task Estimation  Simple Designs  Operational Testing  Team Evaluations
 Task Splitting  Coding and Refactoring  Usability Testing  Project Reporting
 Task Planning  Unit and Component Testing  Acceptance Testing  Adaptive Action

Continuous
Story Deployment
 Standups, Architecture, Design, Build, Integration, Documentation, Change, Migration, and Integration

Highsmith, J. A. (2004). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
33

Agenda

34

Envision Phase
 Determine product vision and project objectives
 Identifies project community and project team
 The major output is a “Product Vision Box”
Envision Phase

Product Vision

 Product Vision Box
 Elevator Test Statement
 Product Roadmap
 Product Features
Delivery Approach  Product Vision Document Product Architecture

 Self-Organization Strategy  Skeleton Architecture
 Collaboration Strategy  Hardware Feature Breakdown
 Communication Strategy  Software Feature Breakdown
 Process Framework Tailoring  Organizational Structure
 Practice Selection & Tailoring  Guiding Principles

Project Community Project Objectives

 Get the Right People  Project Data Sheet
 Participant Identification  Key Business Objectives
 Types of Stakeholders  Tradeoff Matrix
 List of Stakeholders  Exploration Factor
 Customer-Developer Interaction  Requirements Variability

35

Speculate Phase
 Determine organizational capability/mission needs
 Identifies feature-sets and system requirements
 The major output is a “System Release Plan”
Speculate Phase

Gather Requirements

 Analyze Feasibility Studies
 Evaluate Marketing Reports
 Gather Stakeholder Suggestions
 Examine Competitive Intelligence
Cost Estimation  Collaborate with Customers Product Backlog

 Establish Estimate Scope  Product Features List
 Establish Technical Baseline  Feature Cards
 Collect Project Data  Performance Requirements
 Size Project Information  Prioritize Features
 Prepare Baseline Estimates  Feature Breakdown Structure

Risk Planning Release Planning

 Risk Identification  Project Startup Activities
 Risk Analysis  Assign Stories to Iterations
 Risk Responses  First Feasible Deployment
 Risk Monitoring  Estimate Feature Velocity
 Risk Control  Determine Product Scope

36

Explore Phase
 Determine technical iteration objectives/approaches
 Identifies technical tasks and technical practices
 The major output is an “Operational Element”
Explore Phase

Iteration Management

 Iteration Planning
 Estimate Task Size
 Iteration Length
 Workload Management
Collaboration  Monitoring Iteration Progress Technical Practices

 Pair Programming  Reduce Technical Debt
 Daily Standup Meetings  Simple Design
 Daily Product Team Interaction  Continuous Integration
 Stakeholder Coordination  Ruthless Automated Testing
 Customer Interactions  Opportunistic Refactoring

Team Decisions Team Development

 Decision Framing  Focus Team
 Decision Making  Molding Group into Team
 Decision Retrospection  Develop Individual Capabilities
 Leadership and Decision Making  Coach Customers
 Set and Delay Decision Making  Orchestrate Team Rhythm

37

Adapt Phase
 Determine the effectiveness of operational elements
 Identifies customer feedback and corrective actions
 The major output is a “Process Improvement Plan”
Adapt Phase

Customer Focus Groups

 Requirements Reviews
 Preliminary Design Reviews
 Critical Design Reviews
 Product Demonstration Reviews
Adaptive Action  Acceptance Testing Reviews Technical Reviews

 Release Plan Adaptations  Desk Checks/Individual Reviews
 Iteration Plan Adaptations  Structured Walkthroughs
 Feature Set Adaptations  Formal Software Inspections
 User Story Adaptations  Quality Assurance Audits
 Task Plan Adaptations  Configuration Management Audits

Project Reporting Team Evaluations

 Scope and Quality Status  Communications Quality
 Cost and Schedule Status  Team Cohesiveness
 Risk and Value Status  Interpersonal Trust
 Customer Satisfaction Status  Individual Talent and Effort
 Team and Agility Status  Team Performance/Effectiveness

38

Close Phase
 Determine project outcome and effectiveness
 Identifies strengths, weaknesses, and rewards
 The major output is a “Lessons-Learned Report”
Close Phase

Clean Up Open Items

 Close Open Action Items
 Close Open Change Requests
 Close Open Problem Reports
 Close Open Defect Reports
Project Celebration  Close Open Project Issues Support Material

 Individual Rewards  Finalize Documentation
 Group Rewards  Finalize Production Material
 Partner Rewards  Finalize Manufacturing Material
 Managerial Rewards  Finalize Customer Documentation
 Product Rewards  Finalize Maintenance Information

Final Reports Final Retrospective

 End-of-Project Reports  Process Performance Assessment
 Administrative Reports  Internal Product Assessment
 Release Notes  External Product Assessment
 Financial Reports  Team Performance Assessment
 Facilities Reports  Project Performance Assessment

39

Agenda

40

Write User Stories
 Release planning begins by identifying user needs
 User needs are captured in form of user stories
 Customer records needs on user story cards
Write User Stories

Hold
Customer
Meeting
Verify Propose
User User
Stories Stories

Record Clarify
User User
Stories Stories

Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education.
41

Estimate User Stories
 The complexity of each user story is then estimated
 Complexity is captured in the form of story points
 Story points are a relative size of user needs
Estimate User Stories

Estimate
Using
Delphi (PERT)
Estimate Estimate
Using Using
Prototypes (Spikes) Planning Poker

Estimate Estimate
Using Using
Algorithmic Models Analogy

42

Prioritize User Stories
 Customers must prioritize all of their user stories
 Cost, value, risk, and other factors are considered
 Tradeoffs are made when rank ordering user stories
Prioritize User Stories

Estimate
Total
Resources
Verify Estimate
Overall Business
Sequence Value

Sequence Estimate
User Technical
Stories Risks

43

Split User Stories
 Stories may be decomposed for a variety of reasons
 Oftentimes, user stories are too big and complex
 Customers are responsible for splitting them
Split User Stories

Evaluate
User Story
Size
Divide Evaluate
and Reorder Needed
User Stories Resources

Evaluate Evaluate
Risks and Business
Sequence Value

44

Develop Release Plan
 Customers identify which user stories they want
 Developers estimate iteration length, budget, etc.
 A release plan is designed covering 9 to 18 months
Develop Release Plan

Select
Release
Scope
Develop Select
Release Iteration
Plan Velocity & Length

Identify Estimate
Overall Release
Constraints Budget

45

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

46

Agenda

47

Write Technical Tasks
 Customers and developers review user stories
 Developers divide user stories into technical tasks
 Detailed technical activity is recorded on task cards
Write Technical Tasks

Hold
Customer
Meeting
Develop Review
Acceptance User
Criteria Stories

Write Identify
Task Technical
Descriptions Tasks

48

Assign Technical Tasks
 Complete task list is reviewed by developers
 Technical requirements are aligned by skill sets
 Technical tasks are assigned to programmer pairs
Assign Technical Tasks

Evaluate
Initial
Tasks
Assign Identify
Tasks Technical
to Pairs Requirements

Organize Align with
Into Skills and
Pairs Interests

49

Estimate Technical Tasks
 Technical tasks are analyzed by pair groupings
 Effort is estimated by analogy, Delphi method, etc.
 Unit test cases are developed and tasks are verified
Estimate Technical Tasks

Analyze
Assigned
Tasks
Verify Estimate
Technical by Analogy,
Tasks Delphi, Tool, etc.

Develop Determine
Unit Level Effort in
Test Cases Ideal Days

50

Decompose Technical Tasks
 Overall technical task sizes are evaluated
 Larger tasks are decomposed into smaller ones
 New technical tasks are developed and propagated
Decompose Technical Tasks

Analyze
Technical
Task Sizes
Assign New Decompose
Technical Tasks Large
to Pairs Technical Tasks

Write New Identify
Technical Task New
Descriptions Technical Tasks

51

Develop Iteration Plans
 Establish individual productivity time and pace
 Balance the workload among individual resources
 Develop iteration plans with tasks, dates, pairs, etc.
Develop Iteration Plans

Establish
Personnel
Load Factors
Establish Balance
Iteration Personnel
Plan Resources

Compile Establish
Technical Task Technical Task
Assignments Traceability

52

Release/Iteration Plan
 An example of release and iteration plan
 Relationships between user stories and plans
 Shows key data such as story points and velocity
Product Backlog, Release Plan, & Iteration Plan

Product Backlog Release Plan Iteration Plan
User Story Points Release Iteration Task Team Plan Actual

 Find a flight 1  Release 1 Iteration 1  Specify airport Bob/Sue 2 hours 1 hours
 Specify dates 2 hours 1 hours
 Specify times 2 hours 1 hours
 Reserve a flight 2 Iteration 2  Enter name John/Dave 4 hours 3 hours
 Enter address 4 hours 3 hours
 Get confirmation no 4 hours 3 hours
 Book a flight 4 Iteration 3  Enter credit card Barb/Carol 8 hours 6 hours
 Enter billing info 8 hours 6 hours
 Get receipt 8 hours 6 hours
 Verify a flight 1  Release 2 Iteration 4  Enter confirmation no Matt/Ken 2 hours 2 hours
 View itinerary 2 hours 2 hours
 View payment info 2 hours 2 hours
 Generate itinerary 2 Iteration 5  Enter confirmation no Jim/Jane 4 hours 3 hours
 Print itinerary 4 hours 3 hours
 Download itinerary 4 hours 3 hours
 Check flight status 4 Iteration 6  Enter confirmation no Nat/Tim 8 hours 6 hours
 View flight status 8 hours 6 hours
 View gate info 8 hours 6 hours
 Change flight 4  Release 3 Iteration 7  Enter confirmation no Kim/Pat 8 hours 6 hours
 Change dates 8 hours 6 hours
 Change times 8 hours 6 hours
 Cancel flight 1 Iteration 8  Enter confirmation no Sam/Ron 2 hours 2 hours
 Cancel flight 2 hours 2 hours
 Verify cancellation 2 hours 2 hours
 Get a refund 2 Iteration 9  Enter confirmation no Mark/Dan 4 hours 4 hours
 Initiate refund 4 hours 4 hours
 Verify refund status 4 hours 4 hours

53

Agenda

54

Wideband Delphi (PERT)
 Created by RAND corporation in 1940s
 Applied to software effort estimation in 1970s
 Relies on expert judgment and consensus (PERT)
Estimate Using Wideband Delphi (PERT)

Hold
Meeting with
Customers
Discuss Review
and Verify Each
Estimates User Story

Use PERT Solicit
to Combine Individual
Estimates Estimates

Graefe, A., & Armstrong, J. S. (2011). Comparing face-to-face meetings, nominal groups, delphi, and prediction markets on an estimation task.
International Journal of Forecasting, 27(1), 183-195.
55

Planning Poker
 Created by James Grenning for Scrum in 2002
 Similar to Wideband Delphi (or PERT) estimating
 Goal is to estimate size (complexity) in story points
Estimate Using Planning Poker

Hold
Meeting with
Customers
Discuss Distribute
and Verify Planning
Estimates Poker Cards

Vote on Review
Size in Each
Story Points User Story

Molokken-Ostvold, K., & Haugen, N. C. (2007). Combining estimates with planning poker: An empirical study. Proceedings of the 18th Australian
Software Engineering Conference (ASWEC 2007), Melbourne, Australia, 349-358.
56

Analogous Estimating
 Utilized for software estimating in the 1970s
 Goal is to match new user stories with prior ones
 Generates estimate based on similar historical work
Estimate by Analogy

Hold
Meeting with
Customers
Agree on Review
Size of New Each
User Stories User Story

Match Analyze
Old and New Previous
User Stories User Stories

Wen, J., Li, S., & Tang, L. (2009). Improve analogy-based software estimation using principal components analysis and correlation weighting.
Proceedings of the 16th Asia-Pacific Software Engineering Conference (APSEC'2009), Penang, Malaysia, 179-186.
57

Algorithmic Models
 First regression models popularized in 1970s
 Grew into complex logarithmic models in 1990s
 Many algorithms and tools exist for agile estimates
Estimate Using Algorithmic Models

Hold
Meeting with
Customers
Average Review
Output of Each
Algorithmic Models User Story

Generate Select
One or More One or More
Estimates Algorithmic Models

Rico, D. F. (2008). What is the ROI of agile vs. traditional methods? An analysis of extreme programming, test-driven development,
pair programming, and scrum (using real options). TickIT International, 10(4), 9-18.
58

Prototypes (Spikes)
 Prototyping applied to software in the 1970s
 Used for estimation by JAD and Spiral in 1980s
 Agile teams create rapid “Spikes” to size user stories
Estimate Based on Prototypes (Spikes)

Hold
Meeting with
Customers
Estimate Review
User Story Each
from New Data User Story

Develop Identify
Rapid Problematic
Prototype (Spike) User Stories

Keaveney, S., & Conboy, K. (2006). Cost estimation in agile development projects. Proceedings of the
European Conference on Information Systems (ECIS 2006), Goteborg, Sweden.
59

Agenda

60

Risk Planning
 Kickoff meeting is held during release planning
 Type of project and risks of initial stories identified
 Risk management process is aligned with challenges
Risk Planning

Hold
Customer
Meeting
Identify
Review and Approve
Risk Processes
Risk Plan
or Stages

Identify Identify
Risk Evaluation Risk Tracking
Criteria Artifacts

Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011
from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes.
61

Risk Identification
 Low level risks identified at each stage
 Risks are attached to stories, tasks, tests, etc.
 Many risks identified during standups/retrospectives
Risk Identification

Identify
Risks During
Release Planning
Identify Identify
Risks During Risks During
Retrospectives Sprint Planning

Identify Identify Risks
Risks During During Daily
Sprint Reviews Standups

62

Risk Assessment
 Risk backlog is periodically reviewed
 Risks are categorized along with likelihood
 Risk impact is estimated and risk data is verified
Risk Assessment

Review
Risk
Backlog
Verify Categorize
Risk or Determine
Assessment Data Type of Risk

Identify Determine
Impact of Risk Probability
Potential Risk or Likelihood

63

Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers

Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers

Recommended

Recommended

More Related Content

What's hot

What's hot (12)

Similar to Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers

Similar to Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers (20)

More from David Rico

More from David Rico (16)

Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers