a 3-day introduction for sr. engineers and tech. support staff

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 3-Day Introduction for Sr. Engineers and Tech. Support Staff

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 Background

Agile IntroductionAgile Business CaseAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt. ModelsAgile Project Mgt. PhasesAgile Release PlanningAgile Iteration PlanningAgile EstimatingAgile Risk AnalysisAgile Automated TestingAgile Security Engineering

Agile TeamworkAgile ScalabilityAgile Lean/KanbanAgile ScrumAgile Metrics & ModelsAgile Costs & BenefitsAgile Earned Value Mgt.Agile DocumentationAgile Automated ToolsAgile Contract ModelsAgile Change ModelsAgile 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

AgendaAgile Background

Agile IntroductionAgile Business CaseAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt. ModelsAgile Project Mgt. PhasesAgile Release PlanningAgile Iteration PlanningAgile EstimatingAgile Risk AnalysisAgile Automated TestingAgile Security Engineering


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 The focus of this brief is systems development agility

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

AgendaAgile BackgroundAgile Introduction

Agile Business CaseAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt. ModelsAgile Project Mgt. PhasesAgile Release PlanningAgile Iteration PlanningAgile EstimatingAgile Risk AnalysisAgile Automated TestingAgile Security Engineering


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

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

Benefits of Organizational Agility

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.

25

AgendaAgile BackgroundAgile IntroductionAgile Business Case

Agile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt. ModelsAgile Project Mgt. PhasesAgile Release PlanningAgile Iteration PlanningAgile EstimatingAgile Risk AnalysisAgile Automated TestingAgile Security Engineering


26

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.

27

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.

28

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.

29

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.

30

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

31

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

Kanban

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

32

AgendaAgile BackgroundAgile IntroductionAgile Business CaseAgile Life Cycles

Agile PracticesAgile RequirementsAgile Project Mgt. ModelsAgile Project Mgt. PhasesAgile Release PlanningAgile Iteration PlanningAgile EstimatingAgile Risk AnalysisAgile Automated TestingAgile Security Engineering


33

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.

34

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.

35

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.

36

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.

37

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.

38

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.

39

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.

40

AgendaAgile BackgroundAgile IntroductionAgile Business CaseAgile Life CyclesAgile Practices

Agile RequirementsAgile Project Mgt. ModelsAgile Project Mgt. PhasesAgile Release PlanningAgile Iteration PlanningAgile EstimatingAgile Risk AnalysisAgile Automated TestingAgile Security Engineering


41

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


42

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


43

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


44

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


45

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


46

AgendaAgile BackgroundAgile IntroductionAgile Business CaseAgile Life CyclesAgile PracticesAgile Requirements

Agile Project Mgt. ModelsAgile Project Mgt. PhasesAgile Release PlanningAgile Iteration PlanningAgile EstimatingAgile Risk AnalysisAgile Autoamted TestingAgile Security Engineering


47

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

48

Created by Kent Beck at Chrysler in 1998 Release plan is comprised of customer needs Lightweight, rigorous near-term planning element

XP Project Management


Release Planning

Exploration Phase

Iteration Planning

Build a Team Write User Stories Estimate User Stories

Split User Stories Spike User Stories Write User Tests

Commitment Phase

Sort by Value Sort by Risk Set Velocity

Choose a Scope Set Iteration Length Develop Release Plan

Steering Phase

Select Iteration Adjust Velocity Insert New Stories

New Release Plan Select Tools Adjust Teams

Exploration Phase

Analyze Release Plan Identify Iteration Goal Select User Stories

Read User Stories Develop Tasks Split Tasks

Commitment Phase

Accept Tasks Set Individual Velocity Estimate Tasks

Analyze Schedules Set Load Factors Balance Tasks

Steering Phase

Select Partner Write Unit Tests Design and Code

Unit/Integration Test User Acceptance Test Record Progress

49

Created by Sanjiv Augustine at CC Pace in 2005 Builds agile cultures, mind-sets, and environments Leadership model for managing agile project teams

Project Leadership Model

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

Guiding Vision Simple Rules Open Information Light Touch

Foster Alignment and Cooperation Encourage Emergence and Self Organization

Adaptive Leadership

Learning/Adaptation

Leadership

Team Vision Team Alignment Bold Future Shared Expectations

Management

Business Outcomes Delineate Scope Estimate Effort Design Vision Box Elevator Statement

Leadership

Culture of Change Value Focus

Management

Assess Status Quo Customize Method Release Plan Iteration Plans Facilitate Design Conduct Testing Manage Releases

Leadership

Conduct Standups Promote Feedback Build Trust Facilitate Action

Management

Team Collocation Get Onsite Customer Practice Pairing Information Radiator Map Value Stream

Leadership

Adapt Style Roving Leadership Go With Flow Work Life Quality Build on Strengths Gain Commitments

Management

Decentralize Control Pull vs. Push Manage Flow Use Action Sprints

Leadership

Embodied Presence Embodied Learning

Management

Daily Feedback Monitor/Adapt Rules Monitor Practices Retrospectives Scenario Planning

Organic Teams

Leadership

Craftsmanship Collaboration Guiding Coalition Community

Management

Identify Community Design Structures Get Team Players Adaptive Enterprise

50

Created by Doug DeCarlo at Cutter in 2004 Focus is on collaboration, scoping, and speed Thinner traditional project management approach

Flexible Project Management

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

Visionate Speculate Innovate Re-evaluate Disseminate

Collective Vision

Select Core Team

Sponsor’s Vision

Interview Sponsor Describe Objectives Project Prospectus Business Questions

Collective Vision

Scope Meeting Future Scenarios Project Skinny Project Boundaries Project Vision Win Conditions Benefit Map Wow Factor Uncertainty Profile

Planning Meeting

Collective Vision Size Deliverables Map Schedule Choose Life Cycle Requirements ID’d Development Tools Risk Planning

Post Meeting

PM Infrastructure Financial Goals Benefit Plan Partner Agreements

Business Questions

Go/No-Go Decision

Update Prospectus

Business Questions

Who Needs It? What Will It Take? Can We Get It? Is It Worth It?

Project Review

Check Performance Check Schedule Check Costs Check Benefits Check Project ROI Go/No-Go Decision

Project Changes

Re-Direct As-Needed Update Vision Update Stakeholders Re-examine Team

Product Launch

Acceptance Testing Documentation Support Plan Maintenance Plan Deploy Solution Customer Service

Track Benefits

Team Rewards

Lessons Learned

Stabilization

Training/Education Utilization Performance Feedback Corrective Action

Learning by Doing

SCORE Model Architecture Development Construction Testing Time Boxing Trial and Error Collaboration

Generate Results

Visibility Early Value Fast Failures

Update Prospectus

Business Questions

Modify Questions

51

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

Adaptive Project Management

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

Adaptive Project Framework

Scoping

Identify Opportunity Develop CoS Write PoS Document Needs Stage Gate 1 Review

Planning

Identify Project Type Prioritize Constraints Develop WBS Team Formation Stage Gate 2 Review

Feasibility

Develop Prototype Reprioritize Needs Detailed WBS Estimate Resources Stage Gate 3 Review

Checkpoint

Analyze Needs Evaluation Solution Estimate Value Determine Success Stage Gate 4 Review

Review

Finalize Documents Lessons Learned Process Changes Final Report Stage Gate 5 Review

Cyclical Product or Service Implementation

Cycle Planning

Responsibilities Timelines Work Packages Communications Governance

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

Review

Cycle Reviews

Update Requirements Update Scope Update Schedules Update Plans Inform Stakeholders

Daily Meetings

Arrange Facilities Prepare Agendas Send Meeting Notices Facilitate Meetings Record Action Items

Product or Service Implementation

Select Personnel with Needed Skills Identify Detailed Technical Tasks Create Detailed Architectures and Designs Select and Implement Technical Solutions Perform Development and Operational Tests

Continuous Improvement

52

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

53

AgendaAgile BackgroundAgile IntroductionAgile Business CaseAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt. Models

Agile Project Mgt. PhasesAgile Release PlanningAgile Iteration PlanningAgile EstimatingAgile Risk AnalysisAgile Automated TestingAgile Security Engineering


54

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

55

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

56

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

57

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

Launch Phase


58

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

59

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

60

AgendaAgile BackgroundAgile IntroductionAgile Business CaseAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt. ModelsAgile Project Mgt. Phases

Agile Release PlanningAgile Iteration PlanningAgile EstimatingAgile Risk AnalysisAgile Automated TestingAgile Security Engineering


61

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

62

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


63

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)


64

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


65

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


66

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


67

AgendaAgile BackgroundAgile IntroductionAgile Business CaseAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt. ModelsAgile Project Mgt. PhasesAgile Release Planning

Agile Iteration PlanningAgile EstimatingAgile Risk AnalysisAgile Automated TestingAgile Security Engineering


68

Customer and developers review user stories Developers divide user stories into technical tasks Detailed technical activity is recorded on task cards

Write Technical Tasks

Write Technical Tasks

Hold Customer Meeting

Review User

Stories

Identify Technical

Tasks

Write Task

Descriptions

Develop Acceptance

Criteria


69

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

Assign Technical Tasks

Assign Technical Tasks

EvaluateInitialTasks

IdentifyTechnical

Requirements

Align withSkills andInterests

OrganizeIntoPairs

AssignTasks

to Pairs


70

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

Estimate Technical Tasks

Estimate Technical Tasks

AnalyzeAssigned

Tasks

Estimateby Analogy,

Delphi, Tool, etc.

DetermineEffort in

Ideal Days

Develop Unit Level Test Cases

VerifyTechnical

Tasks


71

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

Decompose Technical Tasks

Decompose Technical Tasks

AnalyzeTechnicalTask Sizes

DecomposeLarge

Technical Tasks

IdentifyNew

Technical Tasks

Write NewTechnical Task

Descriptions

Assign NewTechnical Tasks

to Pairs


72

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

Develop Iteration Plans

Develop Iteration Plans

EstablishPersonnel

Load Factors

BalancePersonnelResources

EstablishTechnical Task

Traceability

CompileTechnical TaskAssignments

EstablishIteration

Plan


73

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

74

AgendaAgile BackgroundAgile IntroductionAgile Business CaseAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt. ModelsAgile Project Mgt. PhasesAgile Release PlanningAgile Iteration Planning

Agile EstimatingAgile Risk AnalysisAgile Automated TestingAgile Security Engineering


75

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.

76

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.

77

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

78

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

79

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.

80

AgendaAgile BackgroundAgile IntroductionAgile Business CaseAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt. ModelsAgile Project Mgt. PhasesAgile Release PlanningAgile Iteration PlanningAgile Estimating

Agile Risk AnalysisAgile Automated TestingAgile Security Engineering


81

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

Risk Planning

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

Risk Planning

HoldCustomerMeeting

IdentifyRisk Processes

or Stages

IdentifyRisk Tracking

Artifacts

IdentifyRisk Evaluation

Criteria

Review and Approve Risk Plan

82

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

Risk Identification

Risk Identification

IdentifyRisks During

Release Planning


Sprint Planning

Identify RisksDuring Daily

Standups


Sprint Reviews


Retrospectives


83

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

Risk Assessment


Risk Assessment

ReviewRisk

Backlog

Categorizeor DetermineType of Risk

DetermineRisk Probability

or Likelihood

IdentifyImpact of

Potential Risk

VerifyRisk

Assessment Data

84

Risks are reviewed along with response types Appropriate responses are selected and assigned Contingency plans are developed if risks are realized

Risk Response


Risk Response

ReviewRisk

Assessment Data

ReviewRisk Response

Categories

Select aRisk Response

Category

DefineContingency

Plans and Actions

VerifyRisk

Response Data

85

Risk meetings are held with customers High priority risks are evaluated from backlog Risks are mitigated and reprioritized as necessary

Risk Review


Risk Review

ReviewRisk

Backlog

EvaluateHigh-Priority

Risks

Determine ifRisks Have

Been Realized

ActivateRisk Responses

if Necessary

Re-categorize& ReprioritizeRisk Backlog

86

AgendaAgile BackgroundAgile IntroductionAgile Business CaseAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt. ModelsAgile Project Mgt. PhasesAgile Release PlanningAgile Iteration PlanningAgile EstimatingAgile Risk Analysis

Agile Automated TestingAgile Security Engineering


87

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

88

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

89

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


90

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.

91

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.

92

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.

93

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

Fredrick, J. (2008). Accelerate software delivery with continuous integration and testing. Proceedings of the Sixth Japan Symposium on Software Testing (JASST 2008), Tokyo, Japan.

94

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


95

AgendaAgile BackgroundAgile IntroductionAgile Business CaseAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt. ModelsAgile Project Mgt. PhasesAgile Release PlanningAgile Iteration PlanningAgile EstimatingAgile Risk AnalysisAgile Automated Testing

Agile Security Engineering


96

First step is to appoint a security team lead Identifying security risks & requirements is key Emphasis on training & security incident prevention

Security by Plan

Microsoft. (2009). Security development lifecycle for agile development. Redmond, WA: Author.Microsoft. (2010). Security development lifecycle. Redmond, WA: Author.

Security by Plan

AppointSecurity

Coordinator

PerformSecurityTraining

Perform Security& Privacy RiskAssessment

Identify Security& Privacy

Requirements

DevelopSecurity

Plan

97

Next step is to identify design requirements Identify security architecture and subsystems Develop threat model and reduce attack surface

Security by Design


Security by Design

Identify Security& Privacy Design

Requirements

Document SecurityArchitecture &Attack Surface

Identify CriticalComponents &Security Assets

Develop andAnalyze Threat

Model & ReduceAttack Surface

PerformSecurity

Design Review

98

Then identify development & evaluation tools Identify and apply security patterns & practices Must perform manual & automated code reviews

Security by Implementation


Security by Implementation

IdentifyDevelopmentEnvironment

Identify Static& Dynamic

Security Tools

Identify SecurityCoding Patterns,

Standards, &Practices

ApplySecurity CodingBest Practices

Perform Manual& Automated

SecurityCode Analysis

99

Also develop security test plans and procedures Perform automated security testing & analysis Validate to-be vs. as-is security architecture

Security by Validation


Security by Validation

CreateSecurity & Privacy

Test Plans &Procedures

Perform DynamicSecurity Testing

& Analysis

Perform Fuzz& Penetration

Testing

Perform ThreatModel & AttackSurface Review

ReviewTest Results &

Update SecurityDocumentation

100

Finally, develop security incidence response plan Systematically collect security incident reports Analyze, implement, re-verify, and update

Security by Support


Security by Support

DevelopIncidence

Response Plan

Perform FinalSecurity Review &

Archive Project

Collect, Analyze,& Classify

Security IncidentReports

Develop & PrioritizeSecurity

Maintenance Plans

Implement & VerifySecurity Changes,

Enhancements,& Upgrades

101

Top 25 security vulnerabilities identified each year Many resources available to help mitigate them 88% are preventable by security engineering

Top 25 Vulnerabilities

Brink, D. E. (2010). Security and the software development lifecycle: Secure at the source. Boston, MA: Aberdeen Group.Sans Institute. (2010). Top 25 most dangerous software errors. Retrieved April 21, 2011 from http://www.sans.org/top25-software-errors.

Top 25 Most Dangerous Security Vulnerabilities

Interactions

Cross Site Scripting

SQL Injection

Cross Site Requests

Unrestricted File Upload

OS Command Injection

Information Exposure

URL Redirection

Race Condition

Resources

Buffer Overflow

Path Traversal

PHP File Inclusion

Incorrect Buffer Length

Improper Exceptions

Array Index Validation

Integer Overflow

Buffer Size Calculation

Software Download

Resource Allocation

Defenses

Access Control

Untrusted Inputs

Missing Encryption

Hard Coded Credentials

Missing Authentication

Permission Assignment

Cryptographic Algorithm

102

AgendaAgile BackgroundAgile IntroductionAgile Business CaseAgile Life CyclesAgile PracticesAgile RequirementsAgile Project Mgt. ModelsAgile Project Mgt. PhasesAgile Release PlanningAgile Iteration PlanningAgile EstimatingAgile Risk AnalysisAgile Automated TestingAgile Security Engineering


103

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

104

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.

105

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.

106

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

107

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.

108

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.

109


Agile Teamwork Agile Scalability

Agile Lean/KanbanAgile ScrumAgile Metrics & ModelsAgile Costs & BenefitsAgile Earned Value Mgt.Agile DocumentationAgile Automated ToolsAgile Contract ModelsAgile Change ModelsAgile Case StudiesAgile SummaryAgile Resources

110

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

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

111

Enables multiple levels of abstraction to co-exist Allows customers and developers to communicate Makes optimum use of everyone’s time and resources

Multi-Level Backlog


112

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


113

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

Multi-Level Coordination


114

Enables enterprises to achieve functional needs Allows programs to coordinate functional activities Ensures optimal technical performance is achieved

Multi-Level Governance


Q

I

R

W

T

A

S

C

D

R

R

R

R

R

R

R

R

R

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

T

T

T

T

T

T

T

T

T

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

S

S

S

S

S

S

S

S

S

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

Q

I

R

W

T

A

S

C

D

R T S

115

Begins with a high-level product vision/architecture Includes multi-level teams and product requirements Demonstrates agile delivery model for large programs

Multi-Level Delivery Model

Leffingwell, D. (2011). Agile software requirements: Lean requirements practices for teams, programs, and the enterprise. Boston, MA: Pearson Education.

116


Agile TeamworkAgile Scalability

Agile Lean/KanbanAgile ScrumAgile Metrics & ModelsAgile Costs & BenefitsAgile Earned Value Mgt.Agile DocumentationAgile Automated ToolsAgile Contract ModelsAgile Change ModelsAgile Case StudiesAgile SummaryAgile Resources

117

Kan-ban ('kæn-bæn): Signboard, billboard, signal cards; Lean, just-in-time system of production

A lean and just-in-time manufacturing process for regulating the flow of production based on demand

A pull-system philosophy of customized production vs. a push-system of mass-market manufacturing

A set of principles for creating a lean, efficient, and waste-free product flow by limiting work-in-process

Use of simple organizational policy changes resulting in order-of-magnitude performance improvements

Framework for optimizing workflow that maximizes efficiency, product quality, and customer satisfaction

What is Kanban?


118

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

Kanban Goals

Goal 2

Goal 3

Goal 4

Goal 5

Goal 6

Goal 7

Goal 8

Deliver high product quality (to build stakeholder trust)

Reduce long lead times (and stabilize them)

Achieve sustainable pace (work-life balance)

Provide process slack (for process improvement)

Simplify workload prioritization (of customer needs)

Provide transparency (into design and operations)

Strive for process maturity (to improve performance)

Goal 1 Optimize existing processes (rather than change them)


119

Based on principles for product development flow Uses operations and mathematical queue theory Pragmatic operating principles for development

Kanban Recipe for Success


Focus on Quality Reduce WIP Deliver Often Balance Demand Prioritize Attack Variability

Walkthroughs

Inspections

Technical reviews

Peer reviews

Pair programming

Test driven design

Continuous integration

Design patterns

Refactoring

Design simplicity

Usability engineering

Formal methods

Process flowcharting

Workflow analysis

Kanban boards

Limit work tasks

Limit queues

Limit buffers

Limit backlogs

Simple prioritization

Adequate resources

Process automation

Policy statements

Simplify process

Short releases

Short increments

Short iterations

Small releases

Frequent releases

Small batch sizes

Customer collaboration

Developer collaboration

Ample communication

Frequent builds

Deploy often

Automatic updates

Regulate inputs

Identify bottlenecks

Create slack

Limit work-in-process

Create pull system

Focus on precision

Focus on quality

Take pride in work

Improve morale

Learn new skills

Obtain training

Continuously improve

Prioritize inputs

Business focus-

Business value focus

Influence prioritization

Stabilize process

Build stakeholder trust

Perform risk analysis

Analyze demand

Evaluate size

Evaluate complexity

Market forecasting

Technology analysis

Work item size

Work item type mix

Service class mix

Irregular flow

Rework

Ambiguous reqmnts.

Expedited requests

Environment avail.

Market fluctuations

Coordination

Technological change

Skill/experience mix

120

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

Value Stream Mapping


121

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

Work-in-Process


Bad Project

0

35

70

105

140

175

10/9 10/23 11/6 11/20 12/4 12/18 1/1 1/15 1/29 2/12 2/26

Time

Feat

ure

s

Inventory Started Designed Coded Complete

Good Project

0

48

96

144

192

240

2/10 2/17 2/24 3/2 3/9 3/16

Time

Fea

ture

s

Inventory Started Designed Coded Complete

122


Agile TeamworkAgile ScalabilityAgile Lean/Kanban

Agile ScrumAgile Metrics & ModelsAgile Costs & BenefitsAgile Earned Value Mgt.Agile DocumentationAgile Automated ToolsAgile Contract ModelsAgile Change ModelsAgile Case StudiesAgile SummaryAgile Resources

123

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

Scrum Project Management


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


124

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

125

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

126

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


127

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


128

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

129

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



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


130


Agile TeamworkAgile ScalabilityAgile Lean/KanbanAgile Scrum

Agile Metrics & ModelsAgile Costs & BenefitsAgile Earned Value Mgt.Agile DocumentationAgile Automated ToolsAgile Contract ModelsAgile Change ModelsAgile Case StudiesAgile SummaryAgile Resources

131

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

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.

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.

132

Time expended is used for project tracking Tracked on a per-iteration or per-sprint basis Often described as a basic earned-value metric

Burndown/Burnup Metrics

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

Type

Ideal Days

Actual Days

Ideal Hours

Actual Hours

User Stories

Story Points

Technical Tasks

Example

How many days something takes without interruptions

How many days something takes with interruptions

How many hours something takes without interruptions

How many hours something takes with interruptions

How many customer requirements have been satisfied

How many units of software size have been satisfied

How many technical tasks have been completed

133

Costs based on productivity and quality Development costs based on LOC productivity Maintenance costs based on defects KLOC MH

Agile Cost Models

Type

Basic Form

XP

TDD

PP

Scrum

Agile

Example

(LOC Productivity + Quality KLOC 100) Hourly Rate

(LOC 16.1575 + 0.7466 KLOC 100) Hourly Rate






134

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

Agile Business Value

Type

Costs

Benefits

Breakeven

B/CR

ROI

NPV

Real Options

Example

Total amount of money spent on agile methods

Total amount of money gained from using agile methods

Point when the benefits of using agile methods exceed the costs

Ratio of agile methods benefits to costs of using agile methods

Ratio of adjusted agile methods benefits to costs of using them

Present value of agile methods benefits that result from their use

Value gained from incremental investments in high-risk projects


135

EVM has been adapted to Agile Methods EVM based on notion that total scope is known EVM may “not” be well-suited for large agile projects

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.

Type

PMB

SBL

BAC

PPC

APC

SPC

SPA

Example

Total number of story points planned for a release

Total number of iterations multiplied by iteration length

The planned budget for the release

Number of current iterations divided by planned iterations

Total story points completed divided by story points planned

Story points of work completed from backlog during iteration

Story points added/subtracted from backlog during iteration

136


Agile TeamworkAgile ScalabilityAgile Lean/KanbanAgile ScrumAgile Metrics & Models

Agile Costs & BenefitsAgile Earned Value Mgt.Agile DocumentationAgile Automated ToolsAgile Contract ModelsAgile Change ModelsAgile Case StudiesAgile SummaryAgile Resources

137

Costs based on avg. productivity and quality Productivity ranged from 3.5 to 43 LOC an hour Costs were $136,551, benefits were $4,373,446

Extreme Programming


Formula

(10,000 16.1575 0.7466 10 30) 100

$4,373,446 $136,551

($4,373,446 – $136,551) $136,551 100%

($4,373,446 5) 1.055) – $136,551

$136,551 ($4,509,997 $136,551 – 1)

NORMSDIST (8.07) $4,373,446 –NORMSDIST (7.59) $136,551 EXP (–5% 5)

(10,000 .51 – 6,666.7 ) 100 – $136,551

Value

$136,551

32:1

3,103%

$3,650,396

$4,263

$4,267,100

$4,373,446

Metric

Costs

B/CR

ROI

NPV

BEP

ROA

Benefits

5

1i(

138

Costs based on avg. productivity and quality Productivity ranged from 12 to 46 LOC an hour Costs were $249,653, benefits were $4,260,344

Test-Driven Development

Formula

(10,000 29.2800 + 2.1550 10 100) 100

$4,260,344 $249,653

($4,260,344 – $249,653) $249,653 100%

($4,260,344 5) 1.055) – $249,653

$249,653 ($4,509,997 $249,653 – 1)

NORMSDIST(2.79) $4,260,344 –NORMSDIST(1.27) $249,653 EXP(–5% 5)

(10,000 10.51 – 6,666.67 9) 100 – $249,653

Value

$249,653

17:1

1,607%

$3,439,359

$14,629

$4,074,506

$4,260,344

Metric

Costs

B/CR

ROI

NPV

BEP

ROA

Benefits

5

1i(


139

Costs based on avg. productivity and quality Productivity ranged from 15 to 86 LOC an hour Costs were $265,436, benefits were $4,244,561

Pair Programming

Formula

(10,000 33.4044 + 2.3550 10 100) 100

$4,244,561 $265,436

($4,244,561 – $265,436) $265,436 100%

($4,244,561 5) 1.055) – $265,436

$265,436 ($4,509,997 $265,436 – 1)


(10,000 10.51 – 6,666.67 9) 100 – $265,436

Value

$265,436

16:1

1,499%

$3,409,909

$16,599

$4,050,919

$4,244,561

Metric

Costs

B/CR

ROI

NPV

BEP

ROA

Benefits

5

1i(


140

Costs based on avg. productivity and quality Productivity ranged from 4.7 to 5.9 LOC an hour Costs were $578,202, benefits were $3,931,795

Scrum

Formula

(10,000 5.4436 + 3.9450 10 100) 100

$3,931,795 $578,202

($3,931,795 – $578,202) $578,202 100%

($3,931,795 5) 1.055) – $578,202

$578,202 ($4,509,997 $578,202 – 1)

NORMSDIST(2.08) $3,931,795 –NORMSDIST(-0.15) $578,202 EXP(–5% 5)

(10,000 10.51 – 6,666.67 9) 100 – $578,202

Value

$578,202

7:1

580%

$2,826,321

$85,029

$3,660,805

$3,931,795

Metric

Costs

B/CR

ROI

NPV

BEP

ROA

Benefits

5

1i(


141

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 Methods

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)


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


142

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

143

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.

144


Agile TeamworkAgile ScalabilityAgile Lean/KanbanAgile ScrumAgile Metrics & ModelsAgile Costs & Benefits

Agile Earned Value Mgt.Agile DocumentationAgile Automated ToolsAgile Contract ModelsAgile Change ModelsAgile Case StudiesAgile SummaryAgile Resources

145

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)

146

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

147

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

148

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)


149

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)


150


Agile TeamworkAgile ScalabilityAgile Lean/KanbanAgile ScrumAgile Metrics & ModelsAgile Costs & BenefitsAgile Earned Value Mgt.

Agile DocumentationAgile Automated ToolsAgile Contract ModelsAgile Change ModelsAgile Case StudiesAgile SummaryAgile Resources

151

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

152

Fluid, informal roadmap for planning releases Includes dates for releases, iterations, and stories Must prioritize, split, estimate, and order user stories

Release Plan

Release Plan

Release PlanReleaseIteration

Release PlanRelease Iteration

1234n

1122n

Story01 thru 0607 thru 1213 thru 1819 thru 2425 thru nn


153

Plan that divides iterations into development tasks Each iteration is one to three weeks in duration Iteration plans updated using daily standups

Iteration Plan


154

A function or feature of value to a customer An estimable and testable software requirement Six user stories should be implemented per iteration

User Story


155

Simple story about how the whole system works Overarching 10,000 foot view of system architecture Pushes the system into a sense of coherent cohesion

System Metaphor


156

Black-box, functional tests to be performed Specified by customers during iteration planning Run when user stories and unit tests are completed

Acceptance Tests


157


Agile TeamworkAgile ScalabilityAgile Lean/KanbanAgile ScrumAgile Metrics & ModelsAgile Costs & BenefitsAgile Earned Value Mgt.Agile Documentation

Agile Automated ToolsAgile Contract ModelsAgile Change ModelsAgile Case StudiesAgile SummaryAgile Resources

158

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


159

Range from project management to communications Includes information sharing/knowledge management Workflow tools are helpful for large, distributed projects

Agile Workflow Tools

Schiel, J. (2010). Enterprise-scale agile software development. Boca Raton, FL: CRC Press.

Project Management

Version OneRally Scrum Works Xplanner Ice ScrumMingle

Collaboration

WebEx SkypeMeetMeWimba SameTimeNetMeeting

Wiki

MediaWiki TracWiki PhpWiki MoinMoin TikiWiki WakkaWiki

Chat

ICQ AOL MSN Cahoots Yahoo PowWow

160

Range from requirements to unit testing automation Includes design automation such as screen mockups Agile engineering tools are good for distributed projects

Agile Engineering Tools

Ambler, S. W. (2002). Agile modeling: Effective practices for extreme programming and the unified process. New York, NY: John Wiley & Sons.Ambler, S. W. (2004). The object primer: Agile model-driven development with UML 2.0. New York, NY: Cambridge University Press.

Requirements

DOORSRequisiteProSLATERDD-100CoreRTM

Design

Rhapsody Telelogic SARational SAArtisan Papyrus Statemate

Coding

Notepad++ JEdit Notepad2 Prog. Notepad Crimson Editor ConTEXT

Testing

JUnit NUnit Xunit CPPUnit Gtest Fit

161

Range from code analysis to continuous integration Includes one-touch system-level regression analysis Agile support tools are scalable to large-scale projects

Agile Support Tools

Mason, M. (2006). Pragmatic version control: Using subversion. Raleigh, NC: Pragmatic Bookshelf.Clark, M. (2004). Pragmatic project automation: How to build, deploy, and monitor jave apps. Raleigh, NC: Pragmatic Bookshelf.Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration: Improving software quality and reducing risk. Boston, MA: Addison-Wesley.

Quality Assurance

CheckStylePMDEMMA JdependCoberturaGcov

Configuration Mgt

Subversion CVSClearCaseMKS Perforce VSS

Build Automation

Ant NAnt Maven Make Rake Jar

Continuous Integ

Cruise Control Hudson BuildBot Continuum TeamCity AntHill

162

Range from IDEs to middleware frameworks Includes Web mashup application composition Agile middleware tools are useful for all projects

Agile Middleware Tools

Hemrajani, A. (2006). Agile java development with spring, hibernate, and eclipse. Indianapolis, IN: Sams Publishing.Klocker, C. (2008). Mashups: A new concept in web application programming. Saarbrucken, Germany: VDM Verlag.

Environments

Eclipse Visual Studio Sun StudioNetBeansGNAT Prog StudioOpenWatson

Frameworks

SpringHibernate StrutsAJAXGoogle GuiceHiveMind

Mashups

Google Maps Google Search Google Docs Amazon Web Flickr Twitter

Documentation

NDoc Javadoc Doxygen iText SoDa ROBODoc

163

Range from Web graphics to turnkey e-commerce Includes full-service Web hosting and shopping carts Agile e-commerce tools are ideal for very large projects

Agile E-Commerce Tools

Elad, J. (2008). Web stores: Do it yourself for dummies. Hoboken, NJ: Wiley Publishing.Kaye, D. (2002). Strategies for web hosting and managed services. New York, NY: John Wiley.

Web Graphics

PhotoShop Illustrator PainterMangaArtweaverOpencanvas

Website Design

Flash FireworksColdFusionDreamweaver FrontPage Freehand

Website Hosting

Inmotion iPage JustHost WebHostingPad FatCow WebHostingHub

Web Stores

Shopsite Pro Merchandizer Pro Network Solutions SunShop StoreFront Mercantec

164


Agile TeamworkAgile ScalabilityAgile Lean/KanbanAgile ScrumAgile Metrics & ModelsAgile Costs & BenefitsAgile Earned Value Mgt.Agile DocumentationAgile Automated Tools

Agile Contract ModelsAgile Change ModelsAgile Case StudiesAgile SummaryAgile Resources

165

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.

166

Developed by U.S. DoD in the 2000 timeframe Born out of radical acquisition reforms of 1990s Focuses on objectives and outcomes vs. process

Performance-Based Acquisition

Gansler, J. S. (2000). Guidebook for performance based services acquisition in the U.S. DoD. Washington, DC: Author.Sade, M. (2009). Seven steps to performance based services acquisition. Washington, DC: General Services Administration.

Performance Based Services Acquisition

Integrated Solutions Team

Ensure management involvement Tap multi disciplinary expertise Define roles and responsibilities Develop rules of conduct Empower and incentivize team Identify stakeholders

Problem Statement

Link acquisition to strategic roadmap Link acquisition to mission objectives Link acquisition to performance goals Define desired results at a high level Decide what constitutes success Determine current performance level

Private and Public Solutions

Team approach to market research Learn from public sector Consult with private sector firms One on one industry meetings Look for existing contracts Document market research

Statement of Objectives

Elevator message Describe the scope Performance objectives Share objectives Identify the constraints Develop the background

Measure Performance

Success determinants Quality standards Proposed metrics Meaningful measures Contractual language Order of precedence

Select Contract

Compete the solution Oral presentations Past performance Best value evaluation Final source selection Conflict of interest

Manage Performance

Keep the team together Roles and responsibilities Assign accountability Formal kick off meeting Performance based mgt Review performance

167

Concept attributed to Toyota Production System Adapted for agile project management in 2005 Good balance of structure, flexibility, & trust

Target Cost

Eckfeldt, B., Madden, R., & Horowitz, J. (2005). Selling agile: Target cost contracts. Proceedings of the Agile Conference (Agile 2005), Denver, Colorado, USA, 160-166.

Target Cost Contract

Scope Statement

Business vision System metaphor User stories Effort estimate Priorities Roadmap

Statement of Work

Development days Support estimate Contingency Cost estimate Fixed profit Total cost estimate

Master Agreement

Non-disclosure terms Product ownership Indemnification terms Non-compete terms Administration Termination terms

Release Plan

Feature priorities Wireframes Development tasks Task effort Iteration plan Workflow tool

Closeout

Acceptance test Final documentation Document handover Deployment testing Joint evaluation Administrative close

Development

Iterations, Sprints, or Increments

Perform daily standup meetings Develop acceptance and unit tests Create or refactor software code in pairs Check-in code and perform unit testing Perform continuous integration Hold iteration retrospective

Change Management

Perform customer demonstration Solicit feedback from client Classify and categorize feedback Negotiate scope changes with client Update letter of agreement (LOA) Update release and iteration plans

Support Processes

Security engineering, user experience design, software certification testing, quality assurance, configuration management, etc.

168

Developed by Norwegian Computer Society Adapted for IT, incremental, and agile methods Upfront scoping similar to Feature Driven Design

PS2000 for Agile

Norwegian Computer Society. (2010). PS2000 standard contract for software development. Oslo, Norway: Author.

PS2000 Agile Contract

Needs Phase

Perform needs analysis Develop uncertainty matrix Analyze top level risks areas Identify development environment Prepare milestones and schedules

Solution Description Phase

Develop high level prototypes Develop architecture and design Establish development priorities Prepare description of solution Verify solution description

Approval and Completion Phase

Perform acceptance testing Perform quality certification Deliver final documentation Perform joint project evaluation Perform limited maintenance

Iterative Construction

SignContract

ApproveSolution

PrepareDelivery

Detailed Planning

Analyze needs and solution description Develop detailed iteration plan Develop detailed specifications Develop detailed design models Verify detailed design

Product Development and Verification

Document development methods and tools Develop prototypes and components Demonstrate prototypes and components Gather customer or end user feedback Perform verification and quality assurance

Testing and Debugging

Prepare test plans and specifications Perform detailed component testing Perform integration and system testing Monitor, log, and remediate defects Perform quality and reliability modeling

Checkpoints and Other Services

Configuration management, iteration retrospectives, checkpoint progress reviews, re-planning and mid-course corrections, training, etc.

, Beta Testing,

169

Idea originated from Barry Boehm in 1985 Adapted to U.S. DoD acquisitions in 1999/2000 Incrementally insert emerging technology into acq.

Evolutionary Acquisition

Ford, D. N., & Dillard, J. (2009). Modeling the performance an risks of evolutionary acquisition. Defense Acquisition Review Journal, 16(2), 143-158.

Evolutionary Acquisition

Technology Development

Engineering &Manufacturing

Production &Deployment

Operations &Support

6 Months 12 Months 18 Months 24 Months 30 Months

Increment 1Spiral 1 Spiral 2 Spiral 3

Technology Strategy


Technology Strategy


Technology Strategy


Technology Strategy


Technology Strategy


System Prototype


System Prototype


System Prototype


System Prototype


Finished System


Finished System


Finished System


LRIP


LRIP


FRPS

CDR CDRCDR

FDR FDR

Material Solution Analysis

MDD

A1

MDD

A2

B1

MDD

A3

B2

C1

MDD

A4

B3

C2

MDD

IOC

FOC

170

Originated from agile methods popularity in 2002 Gained foothold in U.S. DoD with scrum popularity Frontloads systems engineering with early systems

Lean & Agile Acquisition

Reagan, R. B., & Rico, D. F. (2010). Lean and agile acquisition and systems engineering: A paradigm whose time has come. Defense AT&L Magazine, 39(6), 48-52.

Lean & Agile Acquisition

Program 1

Program 2

Program n

6 months 12 months 18 months 24 months 30 months

A1 B1 C1 FRP FOCMDD

Release 1Sprint 0 Sprint 3 Sprint 6

Operational Capability







FDR IOC

Material Solution Analysis

Technology Development

Engineering & Manufacturing

Production &Deployment

Operations &Support



CDR

A2 B2 C2 FRP FOCMDD









FDR IOC



CDR

A3 B3 C3 FRP FOCMDD









FDR IOC



CDR

171


Agile TeamworkAgile ScalabilityAgile Lean/KanbanAgile ScrumAgile Metrics & ModelsAgile Costs & BenefitsAgile Earned Value Mgt.Agile DocumentationAgile Automated ToolsAgile Contract Models

Agile Change ModelsAgile Case StudiesAgile SummaryAgile Resources

172

Idea originated with Everett Rogers in 1962 A few early adopters will embrace a new idea The majority will resist change for a longer time

Diffusion of Innovations

Rogers, E. (2003). Diffusion of innovations. New York, NY: Free Press.

Diffusion of Innovations

Dif

fusi

on

Innovators EarlyAdopters

EarlyMajority

LateMajority Laggards

173

Idea originated with Geoffrey Moore in 1991 Time between adoption phases is not uniform Large gap between early adopters and majority

Crossing the Chasm

Moore, G. A. (2002). Crossing the chasm: Marketing and selling high tech products to mainstream customers. New York, NY: HarperCollins..

Crossing the Chasm

Dif

fusi

on

Innovators EarlyAdopters

EarlyMajority

LateMajority Laggards

174

Idea originated with Virginia Satir in 1980s Large changes plunge organizations into chaos Depth and length of chaos is related to its magnitude

Virginia Satir Model

Satir, V., Banmen, J., Gerber, J., & Gomori, M. (1991). The satir model: Family therapy and beyond. Palo Alto, CA: Science and Behavior Books.

Virginia Satir Model

StatusQuo Resistance Chaos Recovery New

State

Pro

duct

ivit

y

175

Large change, no matter how good, often fails Goal is to break changes into smaller increments Smaller and imperceptible change is more successful

Incremental Change

Smith, G., & Sidky, A. (2009). Becoming agile: In an imperfect world. Greenwich, CT: Manning Publications.

Incremental Change

StatusQuo

Resist-stance Chaos Reco-

veryNewState

StatusQuo

Resist-ance Chaos Reco-

veryNewState

StatusQuo

Resist-ance Chaos Reco-

veryNewState

Pro

duct

ivit

y

176

Top down big bang change is most often tried Punctuated equilibrium is most well known form Project champions and coaching are very effective

Organization Change Methods

Holman, P., Devane, T., & Cady, S. (2007). The change handbook: The definitive resource on today’s best methods for emerging whole systems. Berrett-Koehler.

Organization Change Methods

One time radical organizational change often motivated by a severe crisis, i.e., crisis is a catalyst for changePunctuated Equilibrium

Personal Influence

Business Case

Executive Coaching

Executive Commitment

Adequate Resources

Top Down Change

Model Driven Change

Manager Involvement

Employee Involvement

Training & Education

Evolutionary Change

Project Champion

Coaching & Mentoring

Just Do It

Informal appeal for authority to change based on personal trust or relationships, i.e., elevator speech

Compelling qualitative and quantitative business value analysis, i.e., return on investment analysis

Formal or informal mentoring or tutoring of organizational executives and senior leaders

A personal endorsement for change from an organizational executive or senior leader

Formal allocation of resources to execute a large organizational change initiative

One time organization change initiative based on a formal strategic plan, i.e., big bang organization change

Isolated change initiatives based on step by step frameworks, i.e., PDCA, DMAIC, DMADV, etc.

Psychological involvement and commitment of middle managers to avoid bureaucratic obfuscation

Psychological involvement and commitment of lower level workforce to avoid operational resistance

Formal classroom instruction and education to impart the skills necessary for successful change

The implementation of numerous smaller scale changes to prevent long term psychological resistance and chaos

Formal appointment of an individual to take personal responsibility for success of change, i.e., heavyweight PM

Formal or informal mentoring or tutoring of employees or team members to help them overcome hidden obstacles

Assuming personal responsibility for change with or without formal authorization, i.e., forgiveness vs. permission

177

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

178


Agile TeamworkAgile ScalabilityAgile Lean/KanbanAgile ScrumAgile Metrics & ModelsAgile Costs & BenefitsAgile Earned Value Mgt.Agile DocumentationAgile Automated ToolsAgile Contract ModelsAgile Change Models

Agile Case StudiesAgile SummaryAgile Resources

179

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

180

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

181

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

182

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

183

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"

184

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

185


Agile TeamworkAgile ScalabilityAgile Lean/KanbanAgile ScrumAgile Metrics & ModelsAgile Costs & BenefitsAgile Earned Value Mgt.Agile DocumentationAgile Automated ToolsAgile Contract ModelsAgile Change ModelsAgile Case Studies

Agile SummaryAgile Resources

186

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


187

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

188

User experience is key ingredient to success UX should be included throughout agile life cycle UX involves end to end product & service experience

Agile User Experience Design

Johnson, J. D. (2010). Agile UX retreat: We should value competencies over roles. Retrieved April 22, 2011 from http://www.jeremydjohnson.com/index.php/2010/03Kollmann, J., Sharp, H., & Blandford, A. (2009). The importance of identity and vision to user experience designers on agile projects. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA, 11-18.

Product Owner Agile UX Development

Define Product Vision & Strategy

DefineUser Needs

BuildUser Experience

BuildProduct

Competitive Analysis

Define Feature Set

Quantify Business Value

Prioritization

Define Business Rules

Pricing & Budgeting

Project Accountability

Partnerships & Licensing

User Interviews

Contextual Inquiry

User Flows

Wireframes & Mockups

Prototyping

Usability Testing

Web Metrics Analysis

User Feedback

GUI Implementation

Core Capabilities

Core Services

Value Adding Capabilities

Value Adding Services

Distributed Framework

Central Framework

Support Services

Front End Code

Back End Code

Database Schema

Technology Selection

Usability Testing

User Experience Testing

Market Testing

Overall Product Evaluation

189

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.

190


Agile TeamworkAgile ScalabilityAgile Lean/KanbanAgile ScrumAgile Metrics & ModelsAgile Costs & BenefitsAgile Earned Value Mgt.Agile DocumentationAgile Automated ToolsAgile Contract ModelsAgile Change ModelsAgile Case StudiesAgile Summary

Agile Resources

191

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.

192

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.

193

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.

194

Scaling is the last frontier in agile methods research Many of them stem from Planning XP by Kent Beck Meta models of agile project mgt. address scaling

Scaling Agile Methods

Eckstein, J. (2004). Agile software development in the large: Diving into the deep. New York, NY: Dorset House..Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Pearson Education.Schiel, J. (2010). Enterprise-scale agile software development. Boca Raton, FL: CRC Press.Larman, C., & Vodde, B. (2008). Scaling lean and agile development: Thinking and organizational tools for large-scale scrum. Boston, MA: Addison-Wesley.Larman, C., & Vodde, B. (2010). Practices for scaling lean and agile development. Boston, MA: Addison-Wesley.

195

Agile Methods are applied to many domains Include CMMI, CM, QA, Offshoring, Games Dev. Agile-CMMI textbooks are the newest phenomenon

Agile Specialty Topics

McMahon, P. E. (2010). Integrating CMMI and agile development: Case studies and proven techniques for faster performance improvement. Boston, MA: Addison-Wesley.Moreira, M. E. (2009). Adapting configuration management for agile teams: Balancing sustainability and speed. New York, NY: John Wiley.Stamelos, J. G., & Sfetsos, P. (2007). Agile software development quality assurance. Hershey, PA: Idea Group.Woodward, E., Surdek, S., & Ganis, M. (2010). A practical guide to distributed scrum. Indianapolis, IN: IBM Press.Clinton, K. (2010). Agile game development with scrum. Boston, MA: Addison-Wesley.