Lean & Agile Project Management: For Large Programs & Projects

Lean & Agile
Project Management
for Large Programs & Projects
Dr. David F. Rico, PMP, CSM

Website: http://davidfrico.com
LinkedIn: http://www.linkedin.com/in/davidfrico
Facebook: http://www.facebook.com/profile.php?id=1540017424

Author Background
 DoD contractor with 27+ 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 2

Agenda

 Need for Agile Project Mgt.
Intro to Agile Project Mgt.
Types of Agile Project Mgt.
Phases of Agile Project Mgt.
Scaling Agile Project Mgt.
Scaling Agile to Lean/Kanban
Metrics for Agile Project Mgt.
Cases of Agile Project Mgt.
Summary of Agile Project Mgt.
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

Global Competition
 Globalization has intensified market competition
 High-tech market dominated by international firms
 The trade deficit with the Far East is growing bigger

Khanna, P. (2009). The second world: How emerging powers are redefining global competition in the twenty-first century. New York, NY: Random House.
5

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.
6

Today’s Environment
 Highly-unstable global and domestic markets
 Customers are demanding and difficult to please
 Project plans cannot cope with this level of volatility
Market Technology Organization Project People
Result
 Fierce rivalry  Economic driver  Downsizing  Vague requirements  Inability to cope  Poor performance

 Global competition  Market driver  Restructuring  Volatile specs.  High stress  Cost overruns

 Restructuring  Dependent  Bankruptcy  Shorter schedules  Over-allocated  Schedule overruns

 Market fluctuation  Constant change  Mergers & Acq.  Smaller budgets  Over-worked  Poor quality

 Currency instability  Exponential change  Lost revenues  More work  Work-life imbalance  Angry customers

 Global recession  Disruptive  Budget reductions  Tough customers  Beleaguered  Market share loss

 Market dependency  Growing complexity  Reorganizations  Politically-sensitive  Individualistic  Business loss

 Imbalanced trade  Software-intensive  Interdependencies  Large scale and size  Poor people skills  Revenue loss

 Political instability  Smaller  Bloated processes  Globally-distributed  Bad communication  Unprofitability

 Regional warfare  Ubiquitous  Legacy systems  Very high-risks  No commitment  Poor morale

 Emerging threats  Poor usability  Need technology  Uncertainty  Lack of ownership  High attrition

 Cyber attacks  Nano technology  Project dependent  No business value  Poor customer skill  Bad reputation

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. 7

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


Agenda
Need for Agile Project Mgt.

 Intro to Agile Project Mgt.
9

What is Agile Project Mgt.?
 A-P-M (ā-pē-ĕm): Light, flexible, collaborative, and
adaptive; Market-centric project management model:
 Sound, yet flexible process to manage projects under
uncertainty, urgency, and a need for unique expertise
 Values, principles, and practices to help project teams
in coming to grips with a challenging environment
 Managing the flow of human thoughts, emotions, and
interactions in a way that produces business value
 Rapidly and reliably creating value by engaging
customers, continuously learning, and adapting
 Lightweight, yet disciplined project management model
for building high-quality technology-intensive systems

Agile World View
 “Agility” has many dimensions other than software
 Ranges from organizational to technological agility
 The focus of this brief is project management agility
Agile Leadership

 Agile Acquisition
Agile Organizations 
Agile Strategic Planning
Agile Capability Analysis

 Agile Program Management
Agile Project Management

Agile Systems Development

 Agile Processes & Practices
Agile Tools

Agile Information Systems
Agile Technology 11

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 Manifesto. (2001). Manifesto for agile software development. Retrieved September 3, 2008, from http://www.agilemanifesto.org
12

Essence of Agile Project Mgt.
 High degree of customer & developer interaction
 Highly-skilled teams producing frequent iterations
 Right-sized, just-enough, and just-in-time process

• Business Value
• Leadership
• ROI, NPV, ROA
• Empowerment, trust
• Trust, Loyalty,
• Coaching, mentoring
Relationships

• Market responsive • Early market feedback
• Business agility • Experimentation
• Customer sensitive • Sense and response

Highsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.
13

How do Lean & Agile Intersect?
 Lean thinking provides the what (requirements)
 Agile thinking provides the how (implementation)
 Agile proj. mgt. is lean, light, adaptable, and flexible
Agile Pillars Agile Principles Lean Pillars Lean Principles Other Principles
Customer defines
Intensive customer Economic view
Customer value
collaboration and
collaboration
interaction Respect for Customer pulls value Fast feedback
people
Individuals Small empowered high-
and performance multi- Respect for people Decentralize control
interactions disciplinary teams
Reduce batch size
Working Iterative development of Continuous flow
Control cadence
systems and working operational
Continuous Manage queue size
software systems and software Continuous
improvement Exploit variability
improvement
Responding to change with
Responding to Map value stream Manage work-in-
flexible culture, process,
change (eliminate waste) process
and product

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).
14

Agenda

 Types of Agile Project Mgt.
15

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.
16

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.
17

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

18

Adaptive Project Management
 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

19

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, and 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. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
20

Agenda

 Phases of Agile Project Mgt.
21

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  Product Skeleton Architecture
 Collaboration Strategy  Hardware Feature Breakdown
 Communication Strategy  Software Feature Breakdown
 Process Framework Tailoring  Organizational Structure
 Practice Selection and 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

22

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

23

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

24

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

25

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

26

Agenda

 Scaling Agile Project Mgt.
27

Multi-Level Teams
 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 Release Management Team

 Product Manager
 Project Manager
 Chief Architect
 Feature team members (1-2 per feature team)

Feature Team Feature Teams

 Product Specialist (and owner)
 Iteration Manager
 Technical and product Members
 Development team members (1-2 per development team)

28

Multi-Level Planning
 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 Release Plan

 Subsystem architecture
 Feature set focused
 Strategy, objectives, and backlog
 6 to 12 weeks

Iteration Plan Iteration Plan

 Component-level architecture
 User story focused
 Implementation plan, objectives, and backlog
 2 to 4 weeks

29

Multi-Level Backlog
 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
Capability Capability Capability  High-level business or product function
1 2 3
 Also called an Epic, i.e., multiple feature sets
 Comprises 18-90 days worth of work

Feature Sets Feature Set

 Cross-functional mission threads
Feature Feature Feature
1 2 3
 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 Stories User Story

Story 1 Story 4 Story 7  Functional, system-level requirements
 Simple requirement written by customer or user
Story 2 Story 5 Story 8
 A small unit of functionality having business value
Story 3 Story 6 Story 9  Comprises 2 to 10 days worth of work

30

Multi-Level Coordination
 Enables lean and agile methods to scale-up
 Allows enterprises to create large-scale programs
 Unleashes optimum productivity and overall control
Multi-Level Coordination

Capability Team

Feature Set Team Feature Set Team Feature Set Team

Feature Team Feature Team Feature Team

31

Multi-Level Governance
 Enables enterprises to achieve functional needs
 Allows programs to coordinate functional activities
 Ensures optimal technical performance is achieved
Multi-Level Governance

Governing Team

R T S

Functional Team Functional Team Functional Team
R R R T T T S S S
R R R T T T S S S
R R R T T T S S S

Feature Team Feature Team Feature Team
R A D R A D R A D R A D R A D R A D R A D R A D R A D
I T C I T C I T C I T C I T C I T C I T C I T C I T C
Q M S Q M S Q M S Q M S Q M S Q M S Q M S Q M S Q M S

32

Agenda

 Scaling Agile to Lean/Kanban
33

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
 Results in high customer satisfaction, stakeholder
trust, quality, productivity, efficiency, and morale
34

Kanban Goals
 Kanban seeks initially to change as little as possible
 Change without resistance is the first Kanban goal
 Focus on improving quality, lead time and morale
Goal 1 Optimize existing processes (rather than change them)

Goal 2 Deliver high product quality (to build stakeholder trust)

Goal 3 Reduce long lead times (and stabilize them)

Goal 4 Achieve sustainable pace (work-life balance)

Goal 5 Provide process slack (for process improvement)

Goal 6 Simplify workload prioritization (of customer needs)

Goal 7 Provide transparency (into design and operations)

Goal 8 Strive for process maturity (to improve performance)

Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press.
35

Kanban Recipe for Success
 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  Process flowcharting  Short releases  Regulate inputs  Prioritize inputs  Work item size

 Inspections  Workflow analysis  Short increments  Identify bottlenecks  Business focus
-  Work item type mix
 Technical reviews  Kanban boards  Short iterations  Create slack  Business value focus  Service class mix
 Peer reviews  Limit work tasks  Small releases  Limit work-in-process  Influence prioritization  Irregular flow
 Pair programming  Limit queues  Frequent releases  Create pull system  Stabilize process  Rework

 Test driven design  Limit buffers  Small batch sizes  Focus on precision  Build stakeholder trust  Ambiguous reqmnts.
 Continuous integration  Limit backlogs  Customer collaboration  Focus on quality  Perform risk analysis  Expedited requests
 Design patterns  Simple prioritization  Developer collaboration  Take pride in work  Analyze demand  Environment avail.
 Refactoring  Adequate resources  Ample communication  Improve morale  Evaluate size  Market fluctuations

 Design simplicity  Process automation  Frequent builds  Learn new skills  Evaluate complexity  Coordination
 Usability engineering  Policy statements  Deploy often  Obtain training  Market forecasting  Technological change
 Formal methods  Simplify process  Automatic updates  Continuously improve  Technology analysis  Skill/experience mix

36

Value Stream Mapping
 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

37

Work-in-Process
 High work-in-process leads to longest lead times
 Low work-in-process greatly reduces lead times
 Results in better customer trust and satisfaction
Bad Project Good Project
175 240

140 192
Features

Features
105 144

70 96

35 48

0 0
10/9 10/23 11/6 11/20 12/4 12/18 1/1 1/15 1/29 2/12 2/26 2/10 2/17 2/24 3/2 3/9 3/16

Time Time
Inventory Started Designed Coded Complete Inventory Started Designed Coded Complete

38

Agenda

 Metrics for Agile Project Mgt.
39

Basic Agile Metrics
 Agile methods are based on traditional measures
 Size, effort, and velocity metrics are most common
 Top-notch shops use complexity and testing metrics
Type Example
Size Story, Story Point, Task, Function Point, LOC, etc.

Effort Ideal or Actual Hours, Days, Weeks, Months, Years, etc.

Velocity Story, Story Points, Function Points, or LOC per Iteration/Sprint

Complexity McCabe, Halstead, Object-Oriented, Relational Database, etc.

Quality Defect Density, Defect Removal Efficiency, Rayleigh, etc.

Testing Tests Passed/Failed/Broken, Running Tested Features, etc.

Reliability Mean Time to Failure, Mean Time between Failure, etc.

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.
40

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
Type Example
Ideal Days How many days something takes without interruptions

Actual Days How many days something takes with interruptions

Ideal Hours How many hours something takes without interruptions

Actual Hours How many hours something takes with interruptions

User Stories How many customer requirements have been satisfied

Story Points How many units of software size have been satisfied

Technical Tasks How many technical tasks have been completed

Cohn, M. (2006). Agile estimating and planning. Upper Saddle River, NJ: Pearson Education.
41

Agile Cost Models
 Costs based on productivity and quality models
 Development costs based on LOC  productivity rate
 Maintenance costs based on defects  KLOC  MH
Type Example
Basic Form (LOC  Productivity + Quality  KLOC  100)  Hourly Rate

XP (LOC  16.1575 + 0.7466  KLOC  100)  Hourly Rate

TDD (LOC  29.2800 + 2.1550  KLOC  100)  Hourly Rate

PP (LOC  33.4044 + 2.3550  KLOC  100)  Hourly Rate

Scrum (LOC  05.4436 + 3.9450  KLOC  100)  Hourly Rate

Agile (LOC  21.2374 + 1.7972  KLOC  100)  Hourly Rate

42

Agile Business Value
 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 Example
Costs Total amount of money spent on agile methods

Benefits Total amount of money gained from using agile methods

Breakeven Point when the benefits of using agile methods exceed the costs

B/CR Ratio of agile methods benefits to costs of using agile methods

ROI Ratio of adjusted agile methods benefits to costs of using them

NPV Present value of agile methods benefits that result from their use

Real Options Value gained from incremental investments in high-risk projects

43

Agile EVM
 EVM has been adapted to Agile Methods
 EVM based on notion that total scope is known
 EVM is “not” well-suited for large-scale agile projects
Type Example
PMB Total number of story points planned for a release

SBL Total number of iterations multiplied by iteration length

BAC The planned budget for the release

PPC Number of current iterations divided by planned iterations

APC Total story points completed divided by story points planned

SPC Story points of work completed from backlog during iteration

SPA Story points added/subtracted from backlog during iteration

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.
44

Agenda

 Cases of Agile Project Mgt.
45

E-Commerce—Google
 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 AdWords

Project Type Pay-per-Click (PPC) Internet Advertising Mechanism

Project Size 20 teams of 140 people distributed over 5 countries

Product Size 1,838 user stories, 6,250 function points, 500,000 lines of code

Environment Entrepreneurial, egalitarian, dynamic, unpredictable, informal, unstructured

Before APM Chronic schedule delays, poor quality, unpredictability, poor estimation

APM Practices Release planning, wikis for APM support, early testing and continuous integration

After APM Better planning and estimates, earlier testing, better quality, large-scale adoption

Lessons Learned Agile fit like a hand-in-glove, introduce agile methods slowly and then scale-up

Striebeck, M. (2006). Ssh: We are adding a process. Proceedings of the Agile 2006 Conference (Agile 2006), Minneapolis, Minnesota, USA, 193-201.
46

Shrink-Wrapped—Primavera
 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 Primavera

Project Type Enterprise Project Management Tool

Project Size 15 teams of 90 people collocated at one site

Product Size 26,809 user stories, 91,146 function points, 7,291,666 lines of code

Environment Top-down, hierarchical, command and control, traditional, waterfall approach

Poor relationships, quality, usability, and customer satisfaction, functional silos,
Before APM 18-hour days, 7-day work weeks, frustration, disappointment, apathy, exhaustion

APM Practices Release planning, agile project management tools, automated testing tools

After APM 75% quality and 40% cycle time improvement, 40-hour work week, 0% attrition

Lessons Learned Agile results in better communication, motivation, and empowerment

Schatz, B., & Abdelshafi, I. (2005). Primavera gets agile: A successful transition to agile development. IEEE Software, 22(3), 36-42.
47

Healthcare—FDA
 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 m2000 Real-time PCR Diagnostics System

Project Type Human Blood Analysis Tool (i.e., HIV-1, HBV, HCV, CT, NG, etc.)


Product Size 1,659 user stories, 5,640 function points, 451,235 lines of code

Environment FDA-regulated medical devices, real-time, safety-critical, Class III–most stringent

Cumbersome process, poor quality, long cycle time, slow big-bang integration, obsolete,
Before APM hard-to-staff tools and methods, inability to keep pace with changing requirements,
Intense market competition, exponential rate of technological change, fewer resources

APM Practices Release planning, lighter-weight agile testing techniques, continuous integration

After APM 25% cycle time and staff-size reduction, 43% cost reduction, fewer defects

Lessons Learned Agile enables the ability to balance fast cycle time with high-quality safety-critical solutions

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.
48

Law Enforcement—FBI
 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 Inter-Agency Intelligence Sharing System

Project Type Domestic Terrorist Database/Data Warehouse


Product Size 643 user stories, 2,188 function points, 175,000 lines of code

CMMI Level 3, ISO 9001, government-mandated document-driven waterfall life cycle,
Environment emerging federal directives for more information sharing and integration among
intelligence community partners, rapidly changing customer requirements

Unresponsive waterfall life cycles, chronic schedule delays, anxious customers, unhappy
Before APM developers, resource focus on becoming CMMI Level 3 certified caused everyone to lose
track of the real goal, which was to “catch bad guys”

APM Practices Release planning, user stories, test-driven development, continuous integration

After APM 50% quality improvement, 200% productivity increase, FBI created policy for agile methods

Lessons Learned Agile enables fast response times, customer satisfaction, and ability to "catch bad guys"

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.
49

U.S. DoD—STRATCOM
 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 Strategic Knowledge Integration Website (SKIweb)

Project Type Knowledge Management System (KMS)—Advanced Search Capability


Product Size 390 user stories, 1,324 function points, 105,958 lines of code

Traditional linear documentation-based development, contract-oriented, hierarchical
communication, rapidly changing operational requirements, need for leaner U.S. military
Environment force, seeking better and faster ways of getting critical information to decision makers,
decentralization, migration to net-centric service oriented architectures, egalitarian decisions

Before APM Long cycle times, dissatisfied customers, unresponsive life cycles, poor quality

APM Practices Release planning, frequent customer collaboration, continuous integration

After APM Good teamwork, 200% productivity increase, improved quality, fewer defects

Lessons Learned Agile improves customer satisfaction/communication, and overall product quality

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.
50

Agenda

 Summary of Agile Project Mgt.
51

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

Traditional Metrics
Customer Collaboration Contracts
 Interaction frequency  Customer trust valued  Contract compliance
 Communication quality  Customer loyalty more than  Contract deliverables
Agile Metrics

 Strength of Relationship  Customer satisfaction  Contract change orders

Individuals & Interactions Processes
 Team competence  Team trust valued  Lifecycle compliance
 Team motivation  Team cohesion more than  Process Maturity Level
 Team cooperation  Team communications  Regulatory compliance

Working Software Documentation
 Iteration size  Continuous iterations valued  Document deliveries
 Iteration number  Operational iterations more than  Document comments
 Iteration frequency  Validated iterations  Document compliance

Responding to Change Project Plans
 Organizational flexibility  Process flexibility valued  Cost Compliance
 Management flexibility  Design flexibility more than  Scope Compliance
 Individual flexibility  Technology flexibility  Schedule Compliance

52

Benefits of Agile Proj. Mgt.
 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.
53

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
 Systems built using agile methods are unmaintainable
and insecure
54

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.
55

Conclusion
 Traditional methods are well-suited for predictability
 Agile Methods are well-suited for high uncertainty
 It comes down to efficiency versus effectiveness

Thomke, S. (2003). Experimentation matters: Unlocking the potential of new technologies for innovation. Boston, MA: Harvard Business School Publishing.
Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. New York, NY: Celeritas.
56

New Book on Agile Methods
 Guide to Agile Methods for business leaders
 Communicates business value of Agile Methods
 Rosetta stone to Agile Methods for traditional folks
Table of Contents
1. Introduction to Agile Methods
2. Values of Agile Methods
3. History of Agile Methods
4. Antecedents of Agile Methods
5. Types of Agile Methods
6. Practices of Agile Methods
7. Agile Project Management
8. Agile Software Engineering
9. Agile Support Processes
10. Agile Tools and Technologies
11. Comparison of Agile Methods
12. Agile Metrics and Models
13. Surveys of Agile Methods
14. Costs-Benefits of Agile Methods
15. ROI Metrics of Agile Methods
16. Measures of Agile Methods
17. Costs of Agile Methods
18. Benefits of Agile Methods
19. ROI of Agile Methods
20. NPV of Agile Methods
21. Real Options of Agile Methods
22. Business Value of Agile Methods
23. Agile vs. Traditional Methods
24. Future of Agile Methods

 http://davidfrico.com/agile-book.htm (Description)
 http://www.amazon.com/dp/1604270314 (Amazon)
57

Lean & Agile Project Management: For Large Programs & Projects

More Related Content

What's hot

Similar to Lean & Agile Project Management: For Large Programs & Projects

More from David Rico

Lean & Agile Project Management: For Large Programs & Projects