davidfrico.comdavidfrico.com/rico12g-2d.pdf · 2. dod contractor with 28+ years of it experience....

Dr. David F. Rico, PMP, ACP, CSMTwitter: @dr_david_f_rico

Website: http://www.davidfrico.comLinkedIn: http://www.linkedin.com/in/davidfrico

Facebook: http://www.facebook.com/profile.php?id=1540017424

A 2-Day Introduction for Technical Leaders, Staff, and Engineers

2

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

Author Background

Published six books & numerous journal articlesAdjunct at George Washington, UMUC, & ArgosyAgile Program Management & Lean DevelopmentSpecializes in metrics, models, & cost engineeringSix Sigma, CMMI, ISO 9001, DoDAF, & DoD 5000Cloud Computing, SOA, Web Services, FOSS, etc.

3

Agenda

Agile Motivation

Agile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning

Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources

4

U.S. is no longer an industrial-age nation U.S. part of a group of post-industrial countries U.S. consists of information-age knowledge workers

Information Age

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

0%

20%

40%

60%

80%

100%

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

Perc

ent o

f Eco

nom

y

Information

Service

Industry

Agriculture

5

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

System Complexity is Growing

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

6

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

Software Century

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

7

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

Technology Change

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

8

Big projects result in poor quality and scope changes Productivity declines with long queues/wait times Long projects are unsuccessful or canceled

Large, Traditional Projects

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

Size vs. Quality

Def

ect

Den

sity

0.00

3.20

6.40

9.60

12.80

16.00

0 2 6 25 100 400

Lines of Code (Thousands)

Size vs. Productivity

Cod

e P

rodu

ctio

n R

ate

0.00

1.00

2.00

3.00

4.00

5.00

0 2 6 25 100 400


Size vs. Requirements Growth

Per

cent

age

0%

8%

16%

24%

32%

40%

0 2 6 25 100 400


Size vs. SuccessP

erce

ntag

e

0%

12%

24%

36%

48%

60%

0 2 6 25 100 400


9

Challenged and failed projects hover at 67% Big projects fail more often, which is 5% to 10% Of $1.7T spent on IT projects, over $858B were lost

Global Project Failures

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

16% 53% 31%

27% 33% 40%

26% 46% 28%

28% 49% 23%

34% 51% 15%

29% 53% 18%

35% 46% 19%

32% 44% 24%

33% 41% 26%

0% 20% 40% 60% 80% 100%

1994

1996

1998

2000

2002

2004

2006

2008

2010

Year

Successful Challenged Failed

$0.0

$0.4

$0.7

$1.1

$1.4

$1.8

2002 2003 2004 2005 2006 2007 2008 2009 2010

Trill

ions

(US

Dolla

rs)

Expenditures Failed Investments

10

Requirements defects are #1 reason projects fail Traditional projects specify too many requirements More than 65% of requirements are never used at all

Requirements Defects & Waste

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

Other 7%

Requirements47%

Design28%

Implementation18%

Defects

Always 7%

Often 13%

Sometimes16%

Rarely19%

Never45%

Waste

11

Agenda

Agile Motivation Agile Introduction

Agile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning


12

Today’s Whirlwind Environment

Overruns Attrition Escalation Runaways Cancellation

GlobalCompetition

DemandingCustomers

OrganizationDownsizing

SystemComplexity

TechnologyChange

VagueRequirements

Work LifeImbalance

13

Need for a new model of system development Cope with high-level of uncertainty and ambiguity With just the right balance of flexibility and discipline

Need for a New Model

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

R&D Oriented People Centered Adaptive Customer Friendly Fast & Efficient Disciplined

New discoveries

Complex problems

One-off systems

Vague requirements

Incomplete information

High uncertainty

Experimentation

Simulations

Prototyping

Innovation oriented

New products

Creative solutions

Highly-talented people

Cross-functional teams

Small team size

A lot of communication

Interpersonal trust

Rich collaboration

Empowered decisions

Sustainable pace

Daily interaction

Rich communications

Face-to-face interaction

Cohesiveness

Global threats

Market threats

New customer needs

Changing scope

Changing technology

Changing regulations

Continuous change

Flexible culture

Flexible attitudes

Flexible policies

Flexible processes

Flexible technologies

Customer interaction

A lot of communication

Customer demos

Customer feedback

Business value focus

Customer satisfaction

Customer responsive

Customer sensitivity

Customer relationships

Customer contact

Customer involvement

Customer driven

New technology

Quick decision-making

Iterative delivery cycles

Frequent deliveries

Fast delivery schedules

Short timelines

Fast time-to-market

First-mover capability

Minimal process costs

Low work-in-process-

Flexible processes

Market responsiveness

Lightweight strategy

Lightweight plans

Lightweight lifecycles

Security engineering

Light requirements

Light architecture

Lightweight design

Code reviews

Rigorous V&V

Rigorous CM

Rigorous QA

Project reviews

14

A-gil-i-ty (ə-'ji-lə-tē) Property consisting of quickness, lightness, and ease of movement; To be very nimble

The ability to create and respond to change in order to profit in a turbulent global business environment

The ability to quickly reprioritize use of resources when requirements, technology, and knowledge shift

A very fast response to sudden market changes and emerging threats by intensive customer interaction

Use of evolutionary, incremental, and iterative delivery to converge on an optimal customer solution

Maximizing the BUSINESS VALUE with right-sized, just- enough, and just-in-time processes and documentation

What is Agility?

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

15

People-centric way to create innovative solutions Market-centric model to maximize business value Product-centric vs. wasteful processes/documents

What are Agile Methods?

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

alsoknown as

CustomerCollaboration

Individuals &Interactions

WorkingSystems

Respondingto Change

CustomerInteraction

High PerformanceTeams

IterativeDevelopment

Adaptabilityor Flexibility

ContractNegotiation

Processes& Tools

ComprehensiveDocumentation

Followinga Plan

Agile Methods‘Values’

alsoknown as

alsoknown as

alsoknown as

valuedmore than

valuedmore than

valuedmore than

valuedmore than

Agile Methods‘Principles’

Traditional Methods‘Values’

16

Agile is naturally lean and based on small batches Agile directly supports six principles of lean thinking Agile may be converted to a continuous flow system

How do Lean/Agile Intersect?

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

Economic View

Decentralization

Fast Feedback

Control Cadence& Small Batches

Manage Queues/Exploit Variability

WIP Constraints& Kanban

Flow PrinciplesAgile Values

CustomerCollaboration

EmpoweredTeams

IterativeDelivery

Respondingto Change

Lean Pillars

Respectfor People

ContinuousImprovement

Customer Value

Relationships

Customer Pull

Continuous Flow

Perfection

Value Stream

Lean Principles Customer relationships, satisfaction, trust, and loyalty Team authority, empowerment, and resources Team identification, cohesion, and communication

Lean & Agile Practices

Product vision, mission, needs, and capabilities Product scope, constraints, and business value Product objectives, specifications, and performance As is policies, processes, procedures, and instructions To be business processes, flowcharts, and swim lanes Initial workflow analysis, metrication, and optimization Batch size, work in process, and artifact size constraints Cadence, queue size, buffers, slack, and bottlenecks Workflow, test, integration, and deployment automation Roadmaps, releases, iterations, and product priorities Epics, themes, feature sets, features, and user stories Product demonstrations, feedback, and new backlogs Refactor, test driven design, and continuous integration Standups, retrospectives, and process improvements Organization, project, and process adaptability/flexibility

17

On exploratory or research/development projects When fast customer responsiveness is paramount In organizations that are highly-innovative & creative

When to Use Agile Methods?

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

Agile Project Management

High-levels of uncertainty and unpredictability

High-technology projects

Fast-paced, highly-competitive industries Rapid pace of technological change Research-oriented, discovery projects Large-fluctuations in project performance Shorter-term, performance-based RDT&E contracts Achieving high-impact product/service effectiveness Highly-creative new product development contracts Customer-intensive, one-off product/service solutions Highly-volatile and unstable market conditions High-margin, intellectually-intensive industries Delivering value at the point-of-sale

Traditional Project Management

Predictable situations

Low-technology projects

Stable, slow-moving industries Low-levels of technological change Repeatable operations Low-rates of changing project performance Long-term, fixed-price production contracts Achieving concise economic efficiency goals Highly-administrative contracts Mass production and high-volume manufacturing Highly-predictable and stable market conditions Low-margin industries such as commodities Delivering value at the point-of-plan

18

Agility has many dimensions other than IT Ranges from leadership to technological agility This brief will touch upon most of these agile layers

Agile World View

Agile Leaders

Agile Organization Change

Agile Acquisition & Contracting

Agile Strategic Planning

Agile Capability Analysis

Agile Program Management

Agile Tech.

Agile Information Systems

Agile Tools

Agile Processes & Practices

Agile Systems Development


19

Agenda

Agile MotivationAgile Introduction

Agile Justification

Agile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning


20

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

Agile Adoption Rates

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

21

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

Surveys of Agile Methods

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

22

Agile (138 pt.) and traditional methods (99 pt.) Agile methods fare better in all benefits categories Agile methods 359% better than traditional methods

Case Studies of Agile Methods

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

Agile TraditionalCategory

Return on Investment 2,811%

Customer Satisfaction Imp.

Quality Improvement

Productivity Improvement

Schedule Reduction

Cost Reduction

470%

Difference

2,341%

56%

24%

55%

33%

9%

23

Analysis of 23 agile vs. 7,500 traditional projects Agile projects are 54% better than traditional ones Agile has lower costs (61%) and fewer defects (93%)

Benefits of Agile Methods

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

Project Cost in Millions $

0.75

1.50

2.25

3.00

2.8

1.1

Before Agile

After Agile

61%LowerCost

Total Staffing

18

11

Before Agile

After Agile

39%LessStaff

5

10

15

20

Delivery Time in Months

5

10

15

20

18

13.5

Before Agile

After Agile

24%Faster

Cumulative Defects

625

1250

1875

2500

2270

381

Before Agile

After Agile

93%Less

Defects

24

Costs based on avg. productivity and quality Productivity ranged from 3.5 to 86 LOC an hour Costs were $226,807, benefits were $4,283,190

Agile Costs & Benefits

Formula

(10,000 21.2374 + 1.7972 10 100) 100

$4,283,190 $226,807

($4,283,190 – $226,807) $226,807 100%

($4,283,190 5) 1.055) – $226,807

$226,807 ($4,509,997 $226,807 – 1)

NORMSDIST(2.99) $4,283,190 –NORMSDIST(1.59) $226,807 EXP(–5% 5)

(10,000 10.51 – 6,666.67 9) 100 – $226,807

Value

$226,807

19:1

1,788%

$3,481,988

$12,010

$4,110,305

$4,283,190

Metric

Costs

B/CR

ROI

NPV

BEP

ROA

Benefits

5

1i(

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

25

XP ROI 18X more than traditional methods Scrum ROI 3.4X more than traditional methods Agile methods ROI 10X more than trad. methods

ROI of Agile Methods


3,103%

1,788%1,607% 1,499%

580%

173%

0%

925%

1,850%

2,775%

3,700%

XP Agile TDD PP Scrum CMMI®

Software Method

Ret

urn

on I

nves

tmen

t

26

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

Business Value of Agile Methods

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

27

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

Value of Organizational Agility

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

28

Agenda

Agile MotivationAgile IntroductionAgile Justification

Agile Life Cycles

Agile PracticesAgile RequirementsAgile Project Mgt.Agile Planning


29

Created by Alistair Cockburn in 1991 Has 14 practices, 10 roles, and 25 products Scalable family of techniques for critical systems

Crystal Methods

Cockburn, A. (2002). Agile software development. Boston, MA: Addison-Wesley.

30

Created by Jeff Sutherland at Easel in 1993 Has 5 practices, 3 roles, 5 products, rules, etc. Uses EVM to burn down backlog in 30-day iterations

Scrum

Schwaber, K., & Beedle, M. (2001). Agile software development with scrum. Upper Saddle River, NJ: Prentice-Hall.

31

Created by group of British firms in 1993 15 practices, 12 roles, and 23 work products Non-proprietary RAD approach from early 1990s

Dynamic Systems Dev.

Stapleton, J. (1997). DSDM: A framework for business centered development. Harlow, England: Addison-Wesley.

32

Created by Jeff De Luca at Nebulon in 1997 Has 8 practices, 14 roles, and 16 work products Uses object-oriented design and code inspections

Feature Driven Development

Palmer, S. R., & Felsing, J. M. (2002). A practical guide to feature driven development. Upper Saddle River, NJ: Prentice-Hall.

33

Created by Kent Beck at Chrysler in 1998 Has 28 practices, 7 roles, and 7 work products Popularized pair programming and test-driven dev.

Extreme Programming

Beck, K. (2000). Extreme programming explained: Embrace change. Reading, MA: Addison-Wesley.

UserStories

ArchitecturalSpike

ReleasePlanning Iteration Acceptance

TestsSmall

Releases

Spike

TestScenarios

SystemMetaphor

CustomerApproval

LatestVersion

ReleasePlan

NextIteration

BugsNewStoriesRequirements

UncertainEstimates

ConfidentEstimates

34

Adapted to IT by Dave Anderson in 2006 Activities, buffers, queues, WIP limits, tasks, etc. Lean, JIT pull/demand system leading to high quality

Lean-Kanban

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

35

Agenda

Agile MotivationAgile IntroductionAgile JustificationAgile Life Cycles

Agile Practices

Agile RequirementsAgile Project Mgt.Agile Planning


36

Term coined by Kent Beck in 1999 Customer who sits with developers full-time Fast and efficient way to capture customer needs

Onsite Customers

Tabaka, J. (2006). Collaboration explained: Facilitation skills for software project leaders. Upper Saddle River, NJ: Addison Wesley.

37

Created by Kent Beck at Chrysler in 1998 Project plan with a 30-60-90-day timing horizon Disciplined and adaptable project management F/W

Release Planning

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

38

Term coined by Kent Beck in 1999 Functions or features of value to customers Highly-adaptable requirements engineering process

User Stories

Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.

39

Term coined by Jim Coplien in 1995 Consists of two side-by-side developers Highly-effective group problem-solving technique

Pair Programming

Williams, L., & Kessler, R. (2002). Pair programming illuminated. Boston, MA: Pearson Education.

40

Term coined by William Opdyke in 1990 Process of frequently redesigning the system Improves readability, maintainability, and quality

Refactoring

Fowler, M. (1999). Refactoring: Improving the design of existing code. Boston, MA. Addison-Wesley.

41

Term coined by Kent Beck in 2003 Consists of writing all tests before design Ensures all components are verified and validated

Test-Driven Development

Beck, K. (2003). Test-driven development: By example. Boston, MA: Addison-Wesley.

42

Term coined by Martin Fowler in 1998 Process of automated build/regression testing Evaluates impact of changes against entire system

Continuous Integration

Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration: Improving software quality and reducing risk. Boston, MA: Addison-Wesley.

43

Agenda

Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile Practices

Agile Requirements

Agile Project Mgt.Agile Planning


44

Requirement written from perspective of a user Function or a feature that has value to a customer Discrete unit of functionality written on an index card

User Story


45

Conditions of satisfaction added to user stories Serve as a set of user acceptance test criteria Used for development and operational tests

Conditions of Satisfaction


46

Details can be added in smaller sub-stories Good way to functionally-decompose user stories May also represent an object-oriented point-of-view

Detailed Sub-Stories


47

Epics are very large enterprise requirements They are often called capabilities or feature sets A very-large unit of work that must be decomposed

Epics


48

Form stakeholder groups to brainstorm user stories Goal is to write as many user stories as possible Start with epics and decompose user stories

User Story Workshops


49

Agenda

Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile Requirements

Agile Project Mgt.

Agile Planning


50

Created by Jim Highsmith at Cutter in 2003 Focus on strategic plans and capability analysis Most holistic agile project management framework


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

Innovation Lifecycle

Envision

Product Vision Product Architecture Project Objectives Project Community Delivery Approach

Speculate

Gather Requirements Product Backlog Release Planning Risk Planning Cost Estimation

Explore

Iteration Management Technical Practices Team Development Team Decisions Collaboration

Launch

Final Review Final Acceptance Final QA Final Documentation Final Deployment

Close

Clean Up Open Items Support Material Final Retrospective Final Reports Project Celebration

Iterative Delivery

Technical Planning

Story Analysis Task Development Task Estimation Task Splitting Task Planning

Standups, Architecture, Design, Build, Integration, Documentation, Change, Migration, and IntegrationStory Deployment

Adapt

Focus Groups Technical Reviews Team Evaluations Project Reporting Adaptive Action

Operational Testing

Integration Testing System Testing Operational Testing Usability Testing Acceptance Testing

Development, Test, & Evaluation

Development Pairing Unit Test Development Simple Designs Coding and Refactoring Unit and Component Testing

Continuous

51

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

Envision Phase


Envision Phase

Delivery Approach

Self-Organization Strategy Collaboration Strategy Communication Strategy Process Framework Tailoring Practice Selection & Tailoring

Project Objectives

Project Data SheetKey Business ObjectivesTradeoff MatrixExploration FactorRequirements Variability

Product Architecture

Skeleton Architecture Hardware Feature Breakdown Software Feature Breakdown Organizational Structure Guiding Principles

Project Community

Get the Right People Participant Identification Types of Stakeholders List of Stakeholders Customer-Developer Interaction

Product Vision

Product Vision Box Elevator Test Statement Product Roadmap Product Features Product Vision Document

52

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

Speculate Phase


Speculate Phase

Release Planning

Project Startup Activities Assign Stories to Iterations First Feasible Deployment Estimate Feature Velocity Determine Product Scope

Risk Planning

Risk Identification Risk Analysis Risk Responses Risk Monitoring Risk Control

Product Backlog

Product Features List Feature Cards Performance Requirements Prioritize Features Feature Breakdown Structure

Cost Estimation

Establish Estimate Scope Establish Technical Baseline Collect Project Data Size Project Information Prepare Baseline Estimates

Gather Requirements

Analyze Feasibility Studies Evaluate Marketing Reports Gather Stakeholder Suggestions Examine Competitive Intelligence Collaborate with Customers

53

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

Explore Phase


Explore Phase

Team Development

Focus Team Molding Group into Team Develop Individual Capabilities Coach Customers Orchestrate Team Rhythm

Team Decisions

Decision Framing Decision Making Decision Retrospection Leadership and Decision Making Set and Delay Decision Making

Technical Practices

Reduce Technical Debt Simple Design Continuous Integration Ruthless Automated Testing Opportunistic Refactoring

Collaboration

Pair Programming Daily Standup Meetings Daily Product Team Interaction Stakeholder Coordination Customer Interactions

Iteration Management

Iteration Planning Estimate Task Size Iteration Length Workload Management Monitoring Iteration Progress

Launch Phase

Final Quality Assurance

Final Functional Configuration Audit Final Physical Configuration Audit Final Quality Assurance Plan Review Final QA Procedures Review Final Quality Assurance Review

Final Documentation

Final Release Plans Final Requirements Database Final Development Documents Final Maintenance Documents Final Operations Documents

Final Acceptance

Final Test Plan Review Final Test Case Review Final Test Environment Review Final Acceptance Test Review Final Test Results Review

Final Deployment

Final Source Code Final Build Final Integration Final Image Final Deployment Package

Final Review

Final Release Plan Review Final Requirements Review Final Design Review Final Code Review Final Development Team Review

54

Determine the state of the final deployment system Perform final development, test, and QA reviews The major output is a “Deployment Package”

Launch Phase


55

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

Close Phase


Close Phase

Support Material

Finalize Documentation Finalize Production Material Finalize Manufacturing Material Finalize Customer Documentation Finalize Maintenance Information

Final Reports

End-of-Project Reports Administrative Reports Release Notes Financial Reports Facilities Reports

Final Retrospective

Process Performance Assessment Internal Product Assessment External Product Assessment Team Performance Assessment Project Performance Assessment

Project Celebration

Individual Rewards Group Rewards Partner Rewards Managerial Rewards Product Rewards

Clean Up Open Items

Close Open Action Items Close Open Change Requests Close Open Problem Reports Close Open Defect Reports Close Open Project Issues

56

Agile management is delegated to the lowest level There remain key leadership roles & responsibilities Communication, coaching, & facilitation are key ones

Leadership Considerations

Rico, D. F. (2010). The paradox of agile project management and virtual teams. Fairfax, VA: Gantthead.Com.

Customer Communication

Product Visioning

Distribution Strategy

Team Development

Standards & Practices

Telecom Infrastructure

Development Tools

High Context Meetings

Coordination Meetings

F2F Communications

Performance Management

Facilitate selection of methods for obtaining and maintaining executive commitment, project resources, corporate communications, and customer interactionFacilitate selection of methods for communicating product purpose, goals, objectives, mission, vision, business value, scope, performance, budget, assumptions, constraints, etc.

Facilitate selection of virtual team distribution strategy to satisfy project goals and objectives

Facilitate selection of methods for training, coaching, mentoring, and other team building approachesFacilitate selection of project management and technical practices, conventions, roles, responsibilities, and performance measures

Facilitate selection of high bandwidth telecommunication products and services

Facilitate selection of agile project management tools and interactive development environment

Facilitate selection of high context agile project management and development meetings

Facilitate selection of meetings and forums for regular communications between site coordinatorsFacilitate selection of methods for maximizing periodic face to face interactions and collaborationFacilities selection of methods for process improvement, problem resolution, conflict management, team recognition, product performance, and customer satisfaction

57

Agenda

Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.

Agile Planning


58

Release planning is basic agile planning approach Begins with capturing and ordering customer needs Output is a release plan with resources and timelines

Release Planning

Write User Stories Estimate User Stories Prioritize User Stories Split User Stories Develop Release Plan

Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education.

• Estimate size using Delphi (PERT)

• Estimate using planning poker

• Estimate using analogy

• Estimate user algorithmic models

• Estimate using prototypes (spikes)

• Hold customer meeting

• Propose user stories

• Clarify user stories

• Record user stories

• Verify user stories

• Estimate total resources

• Estimate business value

• Estimate technical risks

• Sequence user stories

• Verify overall sequence

• Evaluate story size

• Evaluate needed resources

• Evaluate business value

• Evaluate risks and sequence

• Divide and reorder user stories

• Select release scope

• Select iteration velocity & length

• Estimate release budget

• Identify overall constraints

• Develop release plan

59

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

Write User Stories

Write User Stories

HoldCustomerMeeting

ProposeUser

Stories

ClarifyUser

Stories

RecordUser

Stories

VerifyUser

Stories


60

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

Estimate User Stories

Estimate User Stories

EstimateUsing

Delphi (PERT)

EstimateUsing

Planning Poker

EstimateUsing

Analogy

EstimateUsing

Algorithmic Models

EstimateUsing

Prototypes (Spikes)


61

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

Prioritize User Stories

Prioritize User Stories

EstimateTotal

Resources

EstimateBusiness

Value

EstimateTechnical

Risks

SequenceUser

Stories

VerifyOverall

Sequence


62

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

Split User Stories

Split User Stories

EvaluateUser Story

Size

EvaluateNeeded

Resources

EvaluateBusiness

Value

EvaluateRisks andSequence

Divideand ReorderUser Stories


63

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

Develop Release Plan

Develop Release Plan

SelectReleaseScope

SelectIteration

Velocity & Length

EstimateReleaseBudget

IdentifyOverall

Constraints

DevelopRelease

Plan


64

An example of release and iteration plan Relationships between user stories and plans Shows key data such as story points and velocity

Release & Iteration Plan


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


Iteration 5

Iteration 6


Iteration 8

Iteration 9

Iteration PlanTask Team Plan Actual

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

65

Agenda

Agile MotivationAgile IntroductionAgile JustificationAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt.Agile Planning

Agile Estimating

Agile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources

66

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

Wideband Delphi (PERT)

Estimate Using Wideband Delphi (PERT)

HoldMeeting withCustomers

ReviewEach

User Story

SolicitIndividualEstimates

Use PERTto CombineEstimates

Discussand VerifyEstimates

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

67

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

Planning Poker

Estimate Using Planning Poker


DistributePlanning

Poker Cards

ReviewEach

User Story

Vote onSize in

Story Points

Discussand VerifyEstimates

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

68

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

Analogous Estimating

Estimate by Analogy


ReviewEach

User Story

AnalyzePrevious

User Stories

MatchOld and NewUser Stories

Agree onSize of NewUser Stories

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

69

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

Algorithmic Models

Estimate Using Algorithmic Models


ReviewEach

User Story

SelectOne or More

Algorithmic Models

GenerateOne or MoreEstimates

AverageOutput of

Algorithmic Models

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

70

Prototyping applied to software in the 1970s Used for estimation by JAD and Spiral in 1980s Agile teams create rapid “Spikes” to size user stories

Prototypes (Spikes)

Estimate Using Prototypes (Spikes)


ReviewEach

User Story

IdentifyProblematicUser Stories

DevelopRapid

Prototype (Spike)

EstimateUser Story

from New Data

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

71

Agenda


Agile Estimating Agile Testing

Agile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources

72

Traditional testing is a late, manual process Agile testing is an early and automated process The goal of agile testing is to deliver early and often

What is Agile Testing?

Grant, T. (2005). Continuous integration using cruise control. Northern Virginia Java Users Group (Novajug), Reston, Virginia, USA.

Traditional Testing

Combining source files

Combining software and environment

Combining software and data

Combining software and tests

Combining developers

Agile Testing

Code is frequently checked in

Code is automatically retrieved

Compilation is done automatically

Tests are done automatically

Code reports are generated

Developers get instant feedback

Code is automatically deployed or packaged for delivery

73

Developers check-in changes as they occur Server detects all changes and initiates testing Server compiles, tests, analyzes, builds, and deploys

Agile Automated Testing

Rady, B., & Coffin, R. (2011). Continuous testing: With ruby, rails, and javascript. Raleigh, NC: Pragmatic Bookshelf.Humble, J., & Farley, D. (2011). Continuous delivery: Reliable software releases through build, test, and deployment automation. Boston, MA: Pearson.

BuildIntegration

Server

VersionControlServer

BuildScripts

UsesWatches

BuildStatus

ProvidesDeveloper A

Developer B

Developer C

CommitsChanges

CommitsChanges

CommitsChanges

Compile Source Code

Run Unit Tests

Run Coverage TestsStatic Code Analysis

Build Database

Generate Help FilesArchive and Deploy

74

Agile testing consists of seven broad practices Includes automated builds, testing, inspections, etc. Also includes reporting, documentation, deployment, etc.

Agile Testing Practices

Practice

Building

Database

Inspections

Testing

Feedback

Documentation

Deployment

Description

Frequently assembling products and services to ensure delivery readiness

Frequently generating/analyzing database schemas, queries, and forms

Frequently performing automated static analysis of product/service quality

Frequently performing automated dynamic product and service evaluation

Frequently generating automated status reports/messages for all stakeholders

Frequently performing automated technical/customer document generation

Frequently performing automated delivery of products/services to end users


75

Fewer builds leave in higher bug counts A high number of builds eliminates the defects Goal is to have as many, early builds as possible

Agile Testing Statistics

Lacoste, F. J. (2009). Killing the gatekeeper: Introducing a continuous integration system. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA, 387-392.

76

Agile testing slows down with very large systems Slow testing slows integration and increases bugs Agile testing can speed back up with proper attention

Scaling Agile Testing

Kokko, H. (2009). Increase productivity with large scale CI: Reduce feedback cycle from weeks to 100 minutes. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA.

77

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

Agile Testing Costs & Benefits

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

78

Agile testing is 10x more efficient than manual tests ROI of agile testing is 27x more than traditional testing Performed 1,500x more often than traditional tests yearly

Agile Testing Cost of Quality

Rico, D. F. (2012). The Cost of Quality (CoQ) for Agile vs. Traditional Project Management. Fairfax, VA: Gantthead.Com.

79

Eliminates big-bang integration in the 11th hour Creates a repeatable and reliable testing process Evaluates system-wide changes throughout project

Agile Testing Side Effects


80

Agenda


Agile EstimatingAgile Testing

Agile Teamwork

Agile ScrumAgile TrackingAgile Case StudiesAgile SummaryAgile Resources

81

A key element of any project is good teamwork Agile projects depend upon teamwork even more Balance between cohesion & out-of-the-box thinking

Agile Teamwork Model

Rico, D. F. (2011). The key attributes and factors of teams and teamwork for agile project management. Fairfax, VA: Gantthead.Com.

Factor

Leadership

Boundaries

Empowerment

Competence

Structure

Manageability

Motivation

Attributes

Credible, experienced, likeable, & nurturing project champion

Clear vision, mission, goals, & objectives

Adequate time, money, tools, & authority

Applicable skills, knowledge, experience, & personality

Clear roles, responsibilities, technical approach, & operating rules

Small, collaborative, cohesive, & frequently-communicating

Compensation, incentives, desire-to-succeed, & consequences

82

Agile teams start with great servant-leaders Agile teams rely more on coaches and mentors Coaches and mentors are wise and trusted teachers

Well-Coached

Davies, R., & Sedley (2009). Agile coaching. Raleigh, NC: Pragmatic Bookshelf.Adkins, L. (2010). Coaching agile teams: A companion for scrummasters, agile coaches, and project managers in transition. Boston, MA: Addison-Wesley.

83

Agile teams must be given clearly-stated mission Customers should specify their needs, not solution Agile teams must form a clear vision of the end-state

Clear Vision

Belsky, S. (2010). Making ideas happen: Overcoming the obstacles between vision and reality. New York, NY: Penguin Group.Kossoff, L. L. (1999). Executive thinking: The dream, the vision, the mission achieved. Palo Alto, CA: Davies-Black Publishing.Bates, S. (2009). Motivate like a CEO: Communicate your strategic vision and inspire people to act. New York, NY: McGraw-Hill.

84

Agile teams are empowered to get the job done Teams must have power, authority, and resources Egalitarian decision-making unleashes team capability

Fully-Empowered

Wordenweber, B. (2005). Innovation cell: Agile teams to master disruptive innovation. Berlin, Germany: Springer-Verlag.Wellins, R. S., Byham, W. C., & Wilson, J. M. (1993). Empowered teams: Creating self-directed work groups that improve quality, productivity, and participation. San Francisco, CA: Jossey-Bass..

85

Agile teams consist of highly-competent individuals Individuals must have the requisite training and skills Highly-talented individuals are the heart of agile teams

Highly-Talented

Bach, J. (1995). Enough about process: What we need are heroes. IEEE Software, 12(2), 96-98.Hunt, A., & Thomas, D. (1999). The pragmatic programmer. From journeyman to master. Reading, MA: Addison-Wesley.Martin, R. C. (2009). Clean code: A handbook of agile software craftsmanship. Upper Saddle River, NJ: Prentice-Hall.

86

Agile teams should be small and very manageable They should exhibit collectivism, cohesion, and trust Agile teams must seamlessly complement each other

Great Teamwork

Eckert, B., & Vehar, J. (2007). More lightning, less thunder: How to energize innovation teams. Paul Smiths, NY: New & Improved.Ancona, D., & Bresman, H. (2007). X-teams: How to build teams that lead, innovate, and succeed. Boston, MA: Harvard Business School Press.Kayser, T. (2010). Mining group gold: How to cash in on the collaborative brain power of a team for innovation and results. New York, NY: McGraw-Hill.

87

Agenda


Agile EstimatingAgile TestingAgile Teamwork

Agile Scrum

Agile TrackingAgile Case StudiesAgile SummaryAgile Resources

88

Created by Jeff Sutherland at Easel in 1993 Product backlog comprised of customer needs Barely-sufficient project management framework

Scrum Project Management

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

Initial Planning Sprint Cycle

Discovery Session

Agile Training Project Discovery Process Discovery Team Discovery Initial Backlog

Release Planning

Business Case Desired Backlog Hi-Level Estimates Prioritize Backlog Finalize Backlog

Product Backlog

Prioritized Requirements

Sprint Planning

Set Sprint Capacity Identify Tasks Estimate Tasks

Sprint Review

Present Backlog Items Record Feedback Adjust Backlog

Daily Scrum

Completed Backlog Items Planned Backlog Items Impediments to Progress

Sprint Backlog

List of Technical Tasks Assigned to a Sprint

Potentially Shippable Product

Working Operational Software

Sprint

Select Tasks and Create Tests Create Simple Designs Code and Test Software Units Perform Integration Testing Maintain Daily Burndown Chart Update Sprint Backlog

Sprint Retrospective

89

There are only three roles in the Scrum paradigm Product Owner is single wringable neck (cust. rep.) Scrum Master is overall process facilitator (i.e., coach)

Scrum Roles


Scrum Master

Product Owner Scrum Team

Scrum

Planning Progress

Clarification

Scrum Master - Responsible for facilitating the process

Product Owner - Represents the client and owns the requirements

Scrum Team - Responsible for completing the work and fulfilling the requirements

Scrum Master assists the Product Owner in planning the release and making resources available

Scrum Master helps the Scrum Team make progress by removing impediments

Product Owner works closely with the Scrum Team to provide clarification and approval on requirements

Whole team meets daily to review progress and review the completed work at the end of each sprint

90

An eight hour timeboxed Sprint planning meeting Identifies highest priority requirements to implement Purpose is to produce a Sprint plan for 14 to 30 days

Sprint Planning


Prepare Sprint

Ask QuestionsDevelop TasksCreate EstimatesMake Assignments

Release Planning

Create Stories Make ROI Goals Set Release Plans

Select Stories

Select StoriesSuggest StoriesDetermine Stories

CustomerNeeds

ProductBacklog

Agreed toBacklog

SprintBacklog

Product Owner, Scrum Master, Team

Eight Hour Time Limit

91

A 14 to 30 day timeboxed development iteration High priority requirements decomposed into tasks Purpose is to produce shippable product increment

Sprint


Track Status

Checkoff TasksEstimate VelocityBurndown Charts

Manage Sprint

Freeze Backlog Seek Information Adjust Backlog Decision to Proceed Create Product

Analyze TasksDesign Solution Implement Solution Test Solution

SprintBacklog

DevelopmentTasks

DevelopmentStatus

ShippableProduct

30 Day Time Limit


92

A 15 minute timeboxed daily status meeting Developers state progress in a round robin style Purpose is to ensure that developers collaborating

Daily Scrum Meeting


Establish Followup

Ask for Help Identify IssuesPlan Followup

Meeting Kickoff

Begin Meeting Facilitate Meeting Enforce Protocols

Report Status

Report ProgressState Daily PlansNote Impediments

Yesterday’sProgress

MeetingInitiation

DailyStatus

FollowupNotices

15 Minute Time Limit


93

A four hour timeboxed product demonstration Developers discuss requirements implemented Purpose is to show customers the result of Sprint

Sprint Review


Close Review

Gauge SatisfactionRearrange Backlog Identify New Needs

Prepare for Review

Arrange Location Verify Product Prepare Demo

Hold Review

State Sprint Goal List RequirementsReport ProgressPresent Product

ShippableProduct

ProductDemo

CustomerFeedback

NewBacklog

Four Hour Time Limit

Product Owner, Scrum Master, Team, Customers

94

A three hour timeboxed lessons learned meeting Developers identify potential process improvements Purpose is to identify new non-functional requirements

Sprint Retrospective


Review Changes

Discuss ChangesPrioritize ChangesBaseline Chances

Facilitate Meeting

Check Attendance Verify Preparations Enforce Protocol

Hold Retrospective

State StrengthsState WeaknessesState Improvements

SprintResults

SprintOutcomes

ProcessImprovements

ApprovedChanges

Three Hour Time Limit


95

Agenda


Agile EstimatingAgile TestingAgile TeamworkAgile Scrum

Agile Tracking

Agile Case StudiesAgile SummaryAgile Resources

96

Most basic tracking chart for agile projects Tracks number of work or time units completed Commonly used to track no. story points completed

Burndown

Rawsthorne, D. (2009). Agile metrics. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA.

Burndown Chart

Wor

k (S

tory

, Poi

nt, T

ask)

or E

ffor

t (W

eek,

Day

, Hou

r)

Planning (Roadmap, Release, Iteration) or Time Unit (Month, Week, Day)

97

Popular tracking chart for agile projects Tracks number of work or time units completed Basic form of cumulative workflow & overall progress

Burnup

Nicolette, D. (2009). Agile metrics. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA.

Wor

k (S

tory

, Poi

nt, T

ask)

or E

ffor

t (W

eek,

Day

, Hou

r)


Burnup Chart

98

High work-in-process leads to longest lead times Low work-in-process greatly reduces lead times Results in better customer trust and satisfaction

Cumulative Flow

Anderson, D. J. (2004). Agile management for software engineering: Applying the theory ofconstraints for business results. Upper Saddle River, NJ: Pearson Education.

Traditional vs. Agile Cumulative Flow

Wor

k (S

tory

, Poi

nt, T

ask)

or E

ffor

t (W

eek,

Day

, Hou

r)

Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.)

Wor

k (S

tory

, Poi

nt, T

ask)

or E

ffor

t (W

eek,

Day

, Hou

r)

Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.)

Traditional Cumulative Flow Agile Cumulative Flow

99

Adaptation of EVM for agile projects Mapping between traditional and agile projects Work completed is more authoritative in agile projects

Agile EVM

Sulaiman, T., Barton, B., & Blackburn, T. (2006). Agile EVM: Earned value management in scrum projects.Proceedings of the Agile 2006 Conference (Agile 2006), Minneapolis, Minnesota, USA, 7-16.

Agile EVM

CPI

SPI

PPC

APC

Wor

k (S

tory

, Poi

nt, T

ask)

or E

ffor

t (W

eek,

Day

, Hou

r)


100

ROI is estimated for user stories in agile projects Value accrues with each completed user story Value of completed tasks is more meaningful

Earned Business Value

Rawsthorne, D. (2010). Monitoring scrum projects with agile evm and earned business value metrics. Brisbane, CA: Collab.Net.

Earned Business Value

Wor

k (S

tory

, Poi

nt, T

ask)

or E

ffor

t (W

eek,

Day

, Hou

r)


101

Agenda


Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile Tracking

Agile Case Studies

Agile SummaryAgile Resources

102

80% of worldwide IT projects use agile methods Includes highly-regulated industries like U.S. DoD Even split between top-down and bottom-up adoption

Agile Case Studies

Rico, D. F. (2010). Lean and agile project management: For large programs and projects. Proceedings of the First International Conference on Lean Enterprise Software and Systems, Helsinki, Finland, 37-43.

Industry

ShrinkWrapped

ElectronicCommerce

HealthCare

LawEnforcement

Org 20 teams 140 people 5 countries

Size

15 teams 90 people Collocated 4 teams 20 people Collocated 10 teams 50 people Collocated 3 teams 12 people Collocated

U.S.DoD

Primavera

Google

Stratcom

FBI

FDA

Project

Primavera

Adwords

SKIweb

Sentinel

m2000

Purpose

ProjectManagement

Advertising

KnowledgeManagement

Case FileWorkflow

BloodAnalysis

1,838 User Stories 6,250 Function Points 500,000 Lines of Code

Metrics

26,809 User Stories 91,146 Function Points 7,291,666 Lines of Code 1,659 User Stories 5,640 Function Points 451,235 Lines of Code 3,947 User Stories 13,419 Function Points 1,073,529 Lines of Code 390 User Stories 1,324 Function Points 105,958 Lines of Code

103

Google started using agile methods in 2005 Used it on one of their most profitable products Incrementally adopted agile one practice at a time

E-Commerce—Google

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

Project Name

Project Type

Project Size

Product Size

Environment

Before APM

APM Practices

After APM

Lessons Learned

AdWords

Pay-per-Click (PPC) Internet Advertising Mechanism

20 teams of 140 people distributed over 5 countries

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

Entrepreneurial, egalitarian, dynamic, unpredictable, informal, unstructured

Chronic schedule delays, poor quality, unpredictability, poor estimation

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

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

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

104

Primavera started using agile methods in 2004 Used it on their flagship project management tools Adopted agile all-at-once with top-down mgt. support

Shrink-Wrapped—Primavera

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

Project Name

Project Type

Project Size

Product Size

Environment

APM Practices

After APM

Lessons Learned

Primavera

Enterprise Project Management Tool

15 teams of 90 people collocated at one site

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

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

Release planning, agile project management tools, automated testing tools

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

Agile results in better communication, motivation, and empowerment

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

105

FDA suppliers started using agile methods in 2008 Used it on most stringent Class 3 certified products Used to modernize 1990s era products & processes

Healthcare—FDA

Rasmussen, R., Hughes, T., Jenks, J. R., & Skach, J. (2009). Adopting agile in an FDA regulated environment. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 151-155.

Project Name

Project Type

Project Size

Product Size

Environment

APM Practices

After APM

Lessons Learned

m2000 Real-time PCR Diagnostics System

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


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

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

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

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

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

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

106

IC started using agile methods following 9/11 Used it on billion dollar transformation initiatives Goal is to catch bad guys better, faster, and cheaper

Law Enforcement—FBI

Babuscio, J. (2009). How the FBI learned to catch bad guys one iteration at a time. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 96-100.

Project Name

Project Type

Project Size

Product Size

Environment

Before APM

APM Practices

After APM

Lessons Learned

Inter-Agency Intelligence Sharing System

Domestic Terrorist Database/Data Warehouse


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

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

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

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

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

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

107

U.S. DoD started using agile methods following 9/11 Used it on billion-dollar software-intensive systems Goals are to respond to rapidly emerging threats

U.S. DoD—STRATCOM

Fruhling, A., McDonald, P, & Dunbar, C. (2008). A case study: Introducing extreme programming in a U.S. government system development project. Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 2008), Waikaloa, Big Island, Hawaii, USA, 464-473.

Project Name

Project Type

Project Size

Product Size

Before APM

APM Practices

After APM

Lessons Learned

Strategic Knowledge Integration Website (SKIweb)

Knowledge Management System (KMS)—Advanced Search Capability


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

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

Release planning, frequent customer collaboration, continuous integration

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

Agile improves customer satisfaction/communication, and overall product quality

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

108

Agenda


Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case Studies

Agile Summary

Agile Resources

109

Common myths still abound, although agile methods have been around for ~20 years Agile methods are only good for rapid prototypes Agile methods are only for software development Agile methods are only for small co-located teams Agile methods have no requirements or documents Agile methods need traditional system architectures Agile methods have no project management model Agile methods are undisciplined and unmeasurable Agile methods create unmaintainable systems Agile methods result in security vulnerabilities Agile methods mean deliver it fast and fix it later

Agile Myths


110

Myth that voluminous documentation is needed Myth that agile methods do not use documentation Right-sized, just-in-time processes and documentation

Agile Documentation

Rueping, A. (2003). Agile documentation: A pattern guide to producing lightweight documents for software projects. West Sussex, England: John Wiley & Sons.

Contracts

Document Type

Project Plans

Requirements

Architecture

Design

Coding

Tests

User guides

Quality Assurance

Agile Documentation

Performance-based, time-and-materials, level-of-effort

Release plans, iteration plans, story boards, agile repositories

User stories, wire frames, use cases, paper prototypes

Metaphors, spikes, system modeling language, DoDAF

Wire frames, design patterns, unified modeling language

Code patterns, program design language, coding comments

Unit, component, integration, system, and acceptance tests

XML documents, online help, Wikis, FAQs, video and audio clips

Performance, reliability, code structure analysis, and test reports

111

Agile methods are based on traditional measures Size, effort, and velocity metrics are most common Top-notch shops use complexity and testing metrics

Basic Agile Metrics


Type

Size

Effort

Velocity

Structure

Quality

Satisfaction

Business Value

Example

Story Points, Ideal Days, Function Points, Lines of Code, etc.

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

Release/Iteration Burndown/Burnup, Cumulative Flow, EVM, etc.

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

Running Tested Features, Defect Density, FURPS, MTBF, etc.

CUPRIMDA, Communications, Trust, Loyalty, Retention, etc.

Costs, Benefits, BEP, B/CR, ROI, NPV, IRR, ROA, EBV, etc.

112

Agile Methods are a fundamentally new paradigm Agile Methods are “not” lighter Traditional Methods They should not be viewed through a traditional lens

Advanced Agile Measures


Customer Collaboration

Working Software

Individuals & Interactions

Responding to Change

valuedmore than

valuedmore than

valuedmore than

valuedmore than

Agile

Met

rics

Traditional Metrics

Contracts

Documentation

Processes

Project Plans

Frequent comm. Close proximity Regular meetings

Multiple comm. channels Frequent feedback Relationship strength

Leadership Boundaries Empowerment

Competence Structure Manageability/Motivation

Clear objectives Small/feasible scope Acceptance criteria

Short/timeboxed durations Valid operational results Regular cadence/intervals

Org. flexibility Mgt. flexibility Process flexibility

System flexibility Technology flexibility Infrastructure flexibility

Contract compliance Contract deliverables Contract change orders

Lifecycle compliance Process Maturity Level Regulatory compliance

Document deliveries Document comments Document compliance

Cost Compliance Scope Compliance Schedule Compliance

113

Agile tools exist to support the entire lifecycle Key tools exist as free and open source software Maximize flexibility, efficiency, reporting, and quality

Agile Tools & Automation


114

New contract models emerged for agile contracts Goals, objectives, and visions are established early Buyers and suppliers collaborate throughout contract

Agile Contracting Models

Rico, D. F. (2011). The necessity of new contract models for agile project management. Fairfax, VA: Gantthead.Com.

Contract Type Description

Dynamic Value

Performance Based

Target Cost

Optional Scope

Collaborative

Lean

Specify initial scope and needs (with iterative enhancements)

Establish performance objectives (but not technical solutions)

Broad boundaries for time, cost, and quality (but not scope)

Set minimum and maximum costs (based on initial scope)

Outline initial scope (with fixed no. of releases and iterations)

Lean tools such as small batches, Kanban, WIP constraints, etc.

115

Change, no matter how small or large, is difficult Smaller focused changes help to cross the chasm Shrinking, simplifying, and motivation are key factors

How to Cross the Chasm

Heath, C., & Heath, D. (2010). Switch: How to change things when change is hard. New York, NY: Random House.Patterson, K., et al. (2008). Influencer: The power to change anything: New York, NY: McGraw-Hill.

How to Cross the Chasm

Switch How to Change Things When Change is Hard Influencer The Power to Change Anything

Direct the Rider

Follow the bright spots - Clone what works Script the critical moves - Use prescriptive behaviors Point to the destination - Focus on the end game

Motivate the Elephant

Find the feeling - Appeal to emotion Shrink the change - Use incremental change Grow your people - Invest in training and education

Shape the Path

Tweak the environment - Simplify the change Build habits - Create simple recipes for action Rally the herd - Get everyone involved

Make the Undesirable Desirable Create new experiences - Make it interesting Create new motives - Appeal to sensibility

Surpass your Limits Perfect complex skills - Establish milestones Build emotional skills - Build maturity and people skills

Harness Peer Pressure Recruit public personalities - Involve public figures Recruit influential leaders - Involve recognized figures

Find Strength in Numbers Utilize teamwork - Enlist others to help out Enlist the power of social capital - Scale up and out

Design Rewards and Demand Accountability Use incentives wisely - Reward vital behaviors Use punishment sparingly - Warn before taking action

Change the Environment Make it easy - Simplify the change Make it unavoidable - Build change into daily routine

116

Agility is the evolution of management thought Confluence of traditional and non-traditional ideas Improve performance by over an order-of-magnitude

Conclusion

“The world of traditional methods belongs to yesterday”“Don’t waste your time using traditional methods on 21st century projects”

Agile methods are …

Systems development approachesNew product development approachesExpertly designed to be fast and efficientIntentionally lean and free of waste (muda) Systematic highly-disciplined approachesCapable of producing high quality systemsRight-sized, just-enough, and just-in-time tools

Scalable to large, complex mission-critical systems Designed to maximize business value for customers

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

117

Agenda


Agile EstimatingAgile TestingAgile TeamworkAgile ScrumAgile TrackingAgile Case StudiesAgile Summary

Agile Resources

118

Term agile methods coined around 2001 Earliest holistic text books emerged in 2002 Highsmith, Shore, & Cockburn most complete

Intros to Agile Methods

Highsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.Shore, J., & Warden, S. (2008). The art of agile development. Sebastopol, CA: O'Reilly.Subramaniam, V., & Hunt, A. (2006). Practices of an agile developer. Raleigh, NC: Pragmatic Bookshelf.Cockburn, A. (2007). Agile software development: The cooperative game. Boston, MA: Pearson Education.Martin, R. C. (3003). Agile software development: Principles, patterns, and practices. Upper Saddle River, NJ: Pearson.

119

Over 15 text books for agile project management Many of them stem from Planning XP by Kent Beck Agile Project Mgt. by Jim Highsmith is most complete


Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.Leffingwell, D. (2011). Agile software requirements: Lean requirements practices for teams, programs, and the enterprise. Boston, MA: Pearson Education.Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education.

120

100s of agile methods books exist for all disciplines Range from requirements through documentation Thwart notion that agile methods have big gaps

Agile Development

Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.Coplien, J. O., & Bjornvig, G. (2010). Lean architecture: For agile software development. West Sussex, UK: John Wiley & Sons.Martin, R. C. (2008). Clean code: A handbook of agile software craftsmanship. Upper Saddle River, NJ: Prentice-Hall.Crispin, L., & Gregory, J. (2009). Agile testing: A practical guide for testers and agile teams. Boston, MA: Addison-Wesley.Ruping, A. (2003). Agile documentation: A pattern guide to producing lightweight documents for software projects. West Sussex, UK: John Wiley & Sons.