lean & agile project management: for executives, sr. managers, & key decision makers

Lean & Agile Project Managementfor Executives, Sr. Managers,

& Key Decision MakersDr. David F. Rico, PMP, ACP, CSM

Twitter: @dr_david_f_ricoWebsite: http://www.davidfrico.com

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

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

2

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

Agenda

3

• Motivation• Introduction• Business Case• Major Approaches• Major Phases• Release Planning• Iteration Planning• Estimating Practices• Risk Analysis• Security Engineering• Scaling Practices

• Virtual Teams• Lean/Kanban• Metrics and Models• Costs and Benefits• Earned Value Mgt.• Major Tools• Contract Models• Change Models• Case Studies• Summary• Resources

Information Age

4

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

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

0%

20%

40%

60%

80%

100%

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

Perc

ent o

f Eco

nom

y

Information

Service

Industry

Agriculture

System Complexity is Growing

5

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

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

Software Century

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

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

6

Technological Change

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

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

Large, Traditional Projects

8

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

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

Size vs. Quality

Def

ect

Den

sity

0.00

3.20

6.40

9.60

12.80

16.00

0 2 6 25 100 400

Lines of Code (Thousands)

Size vs. Productivity

Cod

e P

rodu

ctio

n R

ate

0.00

1.00

2.00

3.00

4.00

5.00

0 2 6 25 100 400


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


Global Project Failures

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

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

16% 53% 31%

27% 33% 40%

26% 46% 28%

28% 49% 23%

34% 51% 15%

29% 53% 18%

35% 46% 19%

32% 44% 24%

33% 41% 26%

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

1994

1996

1998

2000

2002

2004

2006

2008

2010

Year

Successful Challenged Failed

$0.0

$0.4

$0.7

$1.1

$1.4

$1.8

2002 2003 2004 2005 2006 2007 2008 2009 2010

Trill

ions

(US

Dolla

rs)

Expenditures Failed Investments

Requirements Defects & Waste

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

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

Other 7%

Requirements47%

Design28%

Implementation18%

Defects

Always 7%

Often 13%

Sometimes16%

Rarely19%

Never45%

Waste

Agenda

11



Today’s Whirlwind Environment

12

Overruns Attrition Escalation Runaways Cancellation

GlobalCompetition

DemandingCustomers

OrganizationDownsizing

SystemComplexity

TechnologyChange

VagueRequirements

Work LifeImbalance

Need for a New Model Need for a new model of project management Cope with high-level of uncertainty and ambiguity With just the right balance of flexibility and discipline

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

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

New discoveries

Complex problems

One-off systems

Vague requirements

Incomplete information

High uncertainty

Experimentation

Simulations

Prototyping

Innovation oriented

New products

Creative solutions

Highly-talented people

Cross-functional teams

Small team size

A lot of communication

Interpersonal trust

Rich collaboration

Empowered decisions

Sustainable pace

Daily interaction

Rich communications

Face-to-face interaction

Cohesiveness

Global threats

Market threats

New customer needs

Changing scope

Changing technology

Changing regulations

Continuous change

Flexible culture

Flexible attitudes

Flexible policies

Flexible processes

Flexible technologies

Customer interaction

A lot of communication

Customer demos

Customer feedback

Business value focus

Customer satisfaction

Customer responsive

Customer sensitivity

Customer relationships

Customer contact

Customer involvement

Customer driven

New technology

Quick decision-making

Iterative delivery cycles

Frequent deliveries

Fast delivery schedules

Short timelines

Fast time-to-market

First-mover capability

Minimal process costs

Low work-in-process-

Flexible processes

Market responsiveness

Lightweight strategy

Lightweight plans

Lightweight lifecycles

Security engineering

Light requirements

Light architecture

Lightweight design

Code reviews

Rigorous V&V

Rigorous CM

Rigorous QA

Project reviews

13

What is Agility? A-gil-i-ty (ə-'ji-lə-tē) Property consisting of quickness,

lightness, and ease of movement; To be very nimble The ability to create and respond to change in order to

profit in a turbulent global business environment The ability to quickly reprioritize use of resources when

requirements, technology, and knowledge shift A very fast response to sudden market changes and

emerging threats by intensive customer interaction Use of evolutionary, incremental, and iterative delivery

to converge on an optimal customer solution Maximizing the BUSINESS VALUE with right sized, just-

enough, and just-in-time processes and documentationHighsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.

14

Values of Agile Project Mgt.

15

People-centric way to create innovative solutions Market-centric model to maximize business value Alternative to large document-based methodologies

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

alsoknown as

CustomerCollaboration

Individuals &Interactions

WorkingSystems

Respondingto Change

CustomerInteraction

High PerformanceTeams

IterativeDevelopment

Adaptabilityor Flexibility

ContractNegotiation

Processes& Tools

ComprehensiveDocumentation

Followinga Plan

Agile Methods‘Values’

alsoknown as

alsoknown as

alsoknown as

valuedmore than

valuedmore than

valuedmore than

valuedmore than

Agile Methods‘Principles’

Traditional Methods‘Values’

How do Lean & Agile Intersect?

16

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

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

Economic View

Decentralization

Fast Feedback

Control Cadence& Small Batches

Manage Queues/Exploit Variability

WIP Constraints& Kanban

Flow PrinciplesAgile Values

CustomerCollaboration

EmpoweredTeams

IterativeDelivery

Respondingto Change

Lean Pillars

Respectfor People

ContinuousImprovement

Customer Value

Relationships

Customer Pull

Continuous Flow

Perfection

Value Stream

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

Lean & Agile Practices

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

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

Agile Project Management

High levels of uncertainty and unpredictability

High technology projects

Fast paced, highly competitive industries

Rapid pace of technological change

Research oriented, discovery projects

Large fluctuations in project performance

Shorter term, performance based RDT&E contracts

Achieving high impact product/service effectiveness

Highly creative new product development contracts

Customer intensive, one off product/service solutions

Highly volatile and unstable market conditions

High margin, intellectually intensive industries

Delivering value at the point of sale

Traditional Project Management

Predictable situations

Low technology projects

Stable, slow moving industries

Low levels of technological change

Repeatable operations

Low rates of changing project performance

Long term, fixed price production contracts

Achieving concise economic efficiency goals

Highly administrative contracts

Mass production and high volume manufacturing

Highly predictable and stable market conditions

Low margin industries such as commodities

Delivering value at the point of plan

17

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

When to use Agile Proj. Mgt.

Agile World View “Agility” has many dimensions other than IT It ranges from leadership to technological agility The focus of this brief is program management agility

Agile Leaders

Agile Organization Change

Agile Acquisition & Contracting

Agile Strategic Planning

Agile Capability Analysis

Agile Program Management

Agile Tech.

Agile Information Systems

Agile Tools

Agile Processes & Practices

Agile Systems Development


18

Agenda

19



Agile Adoption Rates

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

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

20

Surveys of Agile Methods

21

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

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

Case Studies of Agile Methods

22

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

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

Agile TraditionalCategory

Return on Investment 2,811%

Customer Satisfaction Imp.

Quality Improvement

Productivity Improvement

Schedule Reduction

Cost Reduction

470%

Difference

2,341%

56%

24%

55%

33%

9%

Benefits of Agile Methods

23

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

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

Project Cost in Millions $

0.75

1.50

2.25

3.00

2.8

1.1

Before Agile

After Agile

61%LowerCost

Total Staffing

18

11

Before Agile

After Agile

39%LessStaff

5

10

15

20

Delivery Time in Months

5

10

15

20

18

13.5

Before Agile

After Agile

24%Faster

Cumulative Defects

625

1250

1875

2500

2270

381

Before Agile

After Agile

93%Less

Defects

Agile Testing Costs & Benefits

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

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

24

Business Value of Agile Methods

25

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

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

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

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

Benefits of Organizational Agility

Agenda

27



Scrum Project Management

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

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

Initial Planning Sprint Cycle

Discovery Session

Agile Training Project Discovery Process Discovery Team Discovery Initial Backlog

Release Planning

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

Product Backlog

Prioritized Requirements

Sprint Planning

Set Sprint Capacity Identify Tasks Estimate Tasks

Sprint Review

Present Backlog Items Record Feedback Adjust Backlog

Daily Scrum

Completed Backlog Items Planned Backlog Items Impediments to Progress

Sprint Backlog

List of Technical Tasks Assigned to a Sprint

Potentially Shippable Product

Working Operational Software

Sprint

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

Sprint Retrospective

28

XP Project Management

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

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

Release Planning

Exploration Phase

Iteration Planning

Build a Team Write User Stories Estimate User Stories

Split User Stories Spike User Stories Write User Tests

Commitment Phase

Sort by Value Sort by Risk Set Velocity

Choose a Scope Set Iteration Length Develop Release Plan

Steering Phase

Select Iteration Adjust Velocity Insert New Stories

New Release Plan Select Tools Adjust Teams

Exploration Phase

Analyze Release Plan Identify Iteration Goal Select User Stories

Read User Stories Develop Tasks Split Tasks

Commitment Phase

Accept Tasks Set Individual Velocity Estimate Tasks

Analyze Schedules Set Load Factors Balance Tasks

Steering Phase

Select Partner Write Unit Tests Design and Code

Unit/Integration Test User Acceptance Test Record Progress

29

Project Leadership Model

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

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

Guiding Vision Simple Rules Open Information Light Touch

Foster Alignment and Cooperation Encourage Emergence and Self Organization

Adaptive Leadership

Learning/Adaptation

Leadership

Team Vision Team Alignment Bold Future Shared Expectations

Management

Business Outcomes Delineate Scope Estimate Effort Design Vision Box Elevator Statement

Leadership

Culture of Change Value Focus

Management

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

Leadership

Conduct Standups Promote Feedback Build Trust Facilitate Action

Management

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

Leadership

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

Management

Decentralize Control Pull vs. Push Manage Flow Use Action Sprints

Leadership

Embodied Presence Embodied Learning

Management

Daily Feedback Monitor/Adapt Rules Monitor Practices Retrospectives Scenario Planning

Organic Teams

Leadership

Craftsmanship Collaboration Guiding Coalition Community

Management

Identify Community Design Structures Get Team Players Adaptive Enterprise

30

Flexible Project Management

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

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

Visionate Speculate Innovate Re-Evaluate Disseminate

Collective Vision

Select Core Team

Sponsor’s Vision

Interview Sponsor Describe Objectives Project Prospectus Business Questions

Collective Vision

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

Planning Meeting

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

Post Meeting

PM Infrastructure Financial Goals Benefit Plan Partner Agreements

Business Questions

Go/No-Go Decision

Update Prospectus

Business Questions

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

Project Review

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

Project Changes

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

Product Launch

Acceptance Testing Documentation Support Plan Maintenance Plan Deploy Solution Customer Service

Track Benefits

Team Rewards

Lessons Learned

Stabilization

Training/Education Utilization Performance Feedback Corrective Action

Learning by Doing

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

Generate Results

Visibility Early Value Fast Failures

Update Prospectus

Business Questions

Modify Questions

31

Adaptive Project Framework

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

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

Adaptive Project Framework

Scoping

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

Planning

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

Feasibility

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

Checkpoint

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

Review

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

Cyclical Product or Service Implementation

Cycle Planning

Responsibilities Timelines Work Packages Communications Governance

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

Review

Cycle Reviews

Update Requirements Update Scope Update Schedules Update Plans Inform Stakeholders

Daily Meetings

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

Product or Service Implementation

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

Continuous Improvement

32


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

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

Innovation Lifecycle

Envision

Product Vision Product Architecture Project Objectives Project Community Delivery Approach

Speculate

Gather Requirements Product Backlog Release Planning Risk Planning Cost Estimation

Explore

Iteration Management Technical Practices Team Development Team Decisions Collaboration

Launch

Final Review Final Acceptance Final QA Final Documentation Final Deployment

Close

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

Iterative Delivery

Technical Planning

Story Analysis Task Development Task Estimation Task Splitting Task Planning

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

Adapt

Focus Groups Technical Reviews Team Evaluations Project Reporting Adaptive Action

Operational Testing

Integration Testing System Testing Operational Testing Usability Testing Acceptance Testing

Development, Test, & Evaluation

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

Continuous

33

Agenda

34



Envision Phase


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

Envision Phase

Delivery Approach

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

Project Objectives

Project Data SheetKey Business ObjectivesTradeoff MatrixExploration FactorRequirements Variability

Product Architecture

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

Project Community

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

Product Vision

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

35

Speculate Phase


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

Speculate Phase

Release Planning

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

Risk Planning

Risk Identification Risk Analysis Risk Responses Risk Monitoring Risk Control

Product Backlog

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

Cost Estimation

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

Gather Requirements

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

36

Explore Phase


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

Explore Phase

Team Development

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

Team Decisions

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

Technical Practices

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

Collaboration

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

Iteration Management

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

37

Adapt Phase


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

Adapt Phase

Team Evaluations

Communications Quality Team Cohesiveness Interpersonal Trust Individual Talent and Effort Team Performance/Effectiveness

Project Reporting

Scope and Quality Status Cost and Schedule Status Risk and Value Status Customer Satisfaction Status Team and Agility Status

Technical Reviews

Desk Checks/Individual Reviews Structured Walkthroughs Formal Software Inspections Quality Assurance Audits Configuration Management Audits

Adaptive Action

Release Plan Adaptations Iteration Plan Adaptations Feature Set Adaptations User Story Adaptations Task Plan Adaptations

Customer Focus Groups

Requirements Reviews Preliminary Design Reviews Critical Design Reviews Product Demonstration Reviews Acceptance Testing Reviews

38

Close Phase


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

Close Phase

Support Material

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

Final Reports

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

Final Retrospective

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

Project Celebration

Individual Rewards Group Rewards Partner Rewards Managerial Rewards Product Rewards

Clean Up Open Items

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

39

Agenda

40



Write User Stories

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

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

41

Write User Stories

HoldCustomerMeeting

ProposeUser

Stories

ClarifyUser

Stories

RecordUser

Stories

VerifyUser

Stories

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

42

Estimate User Stories

EstimateUsing

Delphi (PERT)

EstimateUsing

Planning Poker

EstimateUsing

Analogy

EstimateUsing

Algorithmic Models

EstimateUsing

Prototypes (Spikes)


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

43

Prioritize User Stories

EstimateTotal

Resources

EstimateBusiness

Value

EstimateTechnical

Risks

SequenceUser

Stories

VerifyOverall

Sequence


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

44

Split User Stories

EvaluateUser Story

Size

EvaluateNeeded

Resources

EvaluateBusiness

Value

EvaluateRisks andSequence

Divideand ReorderUser Stories


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

45

Develop Release Plan

SelectReleaseScope

SelectIteration

Velocity & Length

EstimateReleaseBudget

IdentifyOverall

Constraints

DevelopRelease

Plan


User Story Example Simple one sentence user needs from customers May be decomposed into lower level user stories Acceptance test criteria are often written as well

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

Agenda

47



Write Technical Tasks


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

48

Write Technical Tasks

Hold Customer Meeting

Review User

Stories

Identify Technical

Tasks

Write Task

Descriptions

Develop Acceptance

Criteria

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

49

Assign Technical Tasks

EvaluateInitialTasks

IdentifyTechnical

Requirements

Align withSkills andInterests

OrganizeIntoPairs

AssignTasks

to Pairs


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

50

Estimate Technical Tasks

AnalyzeAssigned

Tasks

Estimateby Analogy,

Delphi, Tool, etc.

DetermineEffort in

Ideal Days

Develop Unit Level Test Cases

VerifyTechnical

Tasks


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

51

Decompose Technical Tasks

AnalyzeTechnicalTask Sizes

DecomposeLarge

Technical Tasks

IdentifyNew

Technical Tasks

Write NewTechnical Task

Descriptions

Assign NewTechnical Tasks

to Pairs


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

52

Develop Iteration Plans

EstablishPersonnel

Load Factors

BalancePersonnelResources

EstablishTechnical Task

Traceability

CompileTechnical TaskAssignments

EstablishIteration

Plan


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

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

Product Backlog, Release Plan, & Iteration Plan

Product BacklogUser Story Points

Find a flight 1

Reserve a flight 2

Book a flight 4

Verify a flight 1

Generate itinerary 2

Check flight status 4

Change flight 4

Cancel flight 1

Get a refund 2

Release PlanRelease Iteration

Release 1 Iteration 1

Iteration 2

Iteration 3


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

Agenda

54



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

55

Estimate Using Wideband Delphi (PERT)

HoldMeeting withCustomers

ReviewEach

User Story

SolicitIndividualEstimates

Use PERTto CombineEstimates

Discussand VerifyEstimates

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

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

56

Estimate Using Planning Poker


DistributePlanning

Poker Cards

ReviewEach

User Story

Vote onSize in

Story Points

Discussand VerifyEstimates

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

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

57

Estimate by Analogy


ReviewEach

User Story

AnalyzePrevious

User Stories

MatchOld and NewUser Stories

Agree onSize of NewUser Stories

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

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

58

Estimate Using Algorithmic Models


ReviewEach

User Story

SelectOne or More

Algorithmic Models

GenerateOne or MoreEstimates

AverageOutput of

Algorithmic Models

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

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

59

Estimate Based on Prototypes (Spikes)


ReviewEach

User Story

IdentifyProblematicUser Stories

DevelopRapid

Prototype (Spike)

EstimateUser Story

from New Data

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

Agenda

60



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

61

Risk Planning

HoldCustomerMeeting

IdentifyRisk Processes

or Stages

IdentifyRisk Tracking

Artifacts

IdentifyRisk Evaluation

Criteria

Review and Approve Risk Plan

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

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

62

Risk Identification

IdentifyRisks During

Release Planning


Sprint Planning

Identify RisksDuring Daily

Standups


Sprint Reviews


Retrospectives


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

63

Risk Assessment

ReviewRisk

Backlog

Categorizeor DetermineType of Risk

DetermineRisk Probability

or Likelihood

IdentifyImpact of

Potential Risk

VerifyRisk

Assessment Data


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

64

Risk Response

ReviewRisk

Assessment Data

ReviewRisk Response

Categories

Select aRisk Response

Category

DefineContingency

Plans and Actions

VerifyRisk

Response Data


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

65

Risk Review

ReviewRisk

Backlog

EvaluateHigh-Priority

Risks

Determine ifRisks Have

Been Realized

ActivateRisk Responses

if Necessary

Re-categorize& ReprioritizeRisk Backlog


Agenda

66



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

67

Security by Plan

AppointSecurity

Coordinator

PerformSecurityTraining

Perform Security& Privacy RiskAssessment

Identify Security& Privacy

Requirements

DevelopSecurity

Plan

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

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

68

Security by Design

Identify Security& Privacy Design

Requirements

Document SecurityArchitecture &Attack Surface

Identify CriticalComponents &Security Assets

Develop andAnalyze Threat

Model & ReduceAttack Surface

PerformSecurity

Design Review


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

69

Security by Implementation

IdentifyDevelopmentEnvironment

Identify Static& Dynamic

Security Tools

Identify SecurityCoding Patterns,

Standards, &Practices

ApplySecurity CodingBest Practices

Perform Manual& Automated

SecurityCode Analysis


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

70

Security by Validation

CreateSecurity & Privacy

Test Plans &Procedures

Perform DynamicSecurity Testing

& Analysis

Perform Fuzz& Penetration

Testing

Perform ThreatModel & AttackSurface Review

ReviewTest Results &

Update SecurityDocumentation


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

71

Security by Support

DevelopIncidence

Response Plan

Perform FinalSecurity Review &

Archive Project

Collect, Analyze,& Classify

Security IncidentReports

Develop & PrioritizeSecurity

Maintenance Plans

Implement & VerifySecurity Changes,

Enhancements,& Upgrades


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

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

Top 25 Most Dangerous Security Vulnerabilities

Interactions

Cross Site Scripting

SQL Injection

Cross Site Requests

Unrestricted File Upload

OS Command Injection

Information Exposure

URL Redirection

Race Condition

Resources

Buffer Overflow

Path Traversal

PHP File Inclusion

Incorrect Buffer Length

Improper Exceptions

Array Index Validation

Integer Overflow

Buffer Size Calculation

Software Download

Resource Allocation

Defenses

Access Control

Untrusted Inputs

Missing Encryption

Hard Coded Credentials

Missing Authentication

Permission Assignment

Cryptographic Algorithm

Agenda

73



Multi-Level Teams


Enables projects to plan for the future and present Decomposes capabilities into implementable pieces Unclogs the drainpipes to let the execution flow freely

Multi-Level Teams

Product Management Team Product Management Team

Chief Product Manager Chief Architect Product Development Manager Release Management Team members (1-2 per release team)

Release Management Team

Feature Team

Release Management Team

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

Feature Teams

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

74

Multi-Level Planning


Enables multiple level enterprise plans to co-exist Allows stakeholders to build viewpoint-specific plans Ensures capabilities are delivered at regular intervals

Multi-Level Planning

Product Roadmap Product Roadmap

Enterprise architecture needs Capability focused Vision, objectives, and backlog 18 to 36 weeks

Release Plan

Iteration Plan

Release Plan

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

Iteration Plan

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

75

Multi-Level Backlog


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

Multi-Level Backlog

Capabilities Capability

Mission goal or objective level High-level business or product function Also called an Epic, i.e., multiple feature sets Comprises 18-90 days worth of work

Feature Set

Cross-functional mission threads Related user stories that are grouped together Also called a Theme, i.e., implemented as an entity Comprises 6 to 30 days worth of work

User Story

Functional, system-level requirements Simple requirement written by customer or user A small unit of functionality having business value Comprises 2 to 10 days worth of work

Capability1

Capability2

Capability3

Feature Sets

Feature1

Feature2

Feature3

User Stories

Story 1 Story 4 Story 7



76

Multi-Level Coordination


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

Multi-Level Coordination

Feature Team Feature Team Feature Team

Feature Set Team

Capability Team

Feature Set Team Feature Set Team

77

Multi-Level Governance


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

Multi-Level Governance

Feature Team Feature Team Feature Team

Functional Team

Governing Team

Functional Team Functional Team

R T S

RRR

RRR

RRR

TTT

TTT

TTT

SSS

SSS

SSS

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

QIR

TA

SCD

M M M

M M

M M M

M

M M M

M M M

M M M

M M M

M M M

M M M

78

Multi-Level Delivery Model

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

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

79

Agenda

80



Standard Practices

81

Standard practices is an oft cited aid to virtual teams Agile methodologies are not known in every country Training should be provided and standards created

Young, C., & Terashima, H. (2008). How did we adapt agile processes to our distributed development? Agile Conference, Toronto, Canada, 304-309.

VIDEOVideo used to record and playback communications

CODINGCoding conventions are established

WIRE FRAMESWire frames are used for visual support

USER STORIESCustomer needs are captured in user stories

TEMPLATESTemplates are established for project communications

PROCESSESEntire team follows the same agile process

TRAININGEntire team is trained on agile methods

Virtual Infrastructure

82

Infrastructure needs are most often overlooked Many countries do not have adequate computers Internet service is also a luxury in across the globe

Vax, M., & Michaud, S. (2008). Distributed agile: Growing a practice together. Agile Conference, Toronto, Canada, 310-314.

SECURITYInformation security is established to protect project information

SUPPORT24x7 infrastructure support is available

INTERNETBroadband Internet is leased and utilized

SOFTWARESynchronous and asynchronous tools are selected

SERVERSDedicated servers are established for project information

LAPTOPSEntire team is provided with laptops for office and home use

MOBILEEntire team is provided with cell phones, smart phones, tablets, etc.

Virtual Tools

83

Many projects do not standardize development tools Complete development tools are easy to assemble Development environments should be integrated

Cannizzo, F., Marcionetti, G., & Moser, P. (2008). Evolution of the tools and practices of a large distributed agile team. Agile Conference, Toronto, Canada, 513-518.

MULTIMEDIADevelopment tools with collaborative capabilities are utilized

CONTENTWikis and other repositories are utilized

METRICSCode metrics and defect tracking tools are used

TESTINGUnit, system, and acceptance testing tools are used

BUILDBuild tools are used for continuous integration and deployment

VERSIONINGConfiguration management tools are used to manage source code

WORKFLOWRelease and iteration workflow tools are used

Virtual Meetings

84

Frequent communication is a key to project success Communication is better than documentation alone A critical key is to encourage frequent interactions

Summers, S. (2008). Insights into an agile adventure with offshore partners. Agile Conference, Toronto, Canada, 513-518.

SPLINTERVirtual splinter group meetings are held, i.e., design, brainstorming, etc.

RETROSPECTIVEVirtual iteration retrospectives are held

DEMONSTRATIONEntire team participates in virtual demonstrations

DEVELOPMENTVirtual development meetings held, i.e., pair programming

STANDUPEntire team participates in virtual daily standup meetings

ITERATIONEntire team participates in virtual iteration planning meetings

RELEASEEntire team participates in virtual release planning sessions

Light Coordination

85

The work of two or more teams requires facilitation Local/remote team leaders must communicate often All team leaders can then pass on critical information

Drummond, B. S., & Unson, J. F. (2008). Yahoo distributed agile: Notes from the world over. Agile Conference, Toronto, Canada, 315-321.

FEEDBACKCustomer feedback to developers is provided very quickly

REPORTINGManual and automated status reporting

FACILITATIONProactive management of intercultural dissonance

TECHNICALCoordination between local and remote technical leaders

GOVERNANCELightweight governance teams with local and remote members

LEADERSHIPRegular communications between local and remote process leaders

CUSTOMERRegular communications between customers and remote teams

Periodic Rotations

86

Periodic F2F interaction is a CSF for virtual teams Teams should meet at critical junctures, i.e., kickoff Rotating customers and leaders helps establish trust

Robarts, J. M. (2008). Practical considerations for distributed agile projects. Agile Conference, Toronto, Canada, 327-332.

ENDPOINTSTeams collocate at critical junctures, i.e., kickoff, middle, closeout, etc.

DEVELOPMENTTeams periodically collocate for iterations

PLANNINGTeams collocate for release and iteration planning

PERSONNELIndividuals rotate to maintain healthy relationships

LEADERSProject leaders keep local and remote teams in-synch

AMBASSADORSAmbassadors are exchanged to minimize intercultural dissonance

CUSTOMERSCustomer apprises remote teams of product vision, mission, goals, objectives, etc.

Regional Localization

87

Minimizing interfaces between timezones is oft cited Products should be structured to localize activities It’s easier to communicate with nearshore teams

Ramesh, B., Cao, L., Mohan, K., & Xu, P. (2006). Can distributed software development be agile? Communications of the ACM, 41(10), 41-46.

DEVELOPMENTSubsystem interfaces are devised to localize development activities

SOCIALIZATIONRemote teams engage in social activities

EMPOWERMENTEmpower remote teams to make technical decisions

MEETINGSHold synchronous meetings at the local level

LEADERSEmpower local personnel to serve as process facilitators

CUSTOMERSEmpower local personnel to serve as customer proxies

TIMEZONESMinimize organizational interfaces and organize teams by timezones

Agenda

88



What is Kanban? Kan-ban ('kæn-bæn): Signboard, billboard, signal

cards; Lean, just-in-time system of production A lean and just-in-time manufacturing process for

regulating the flow of production based on demand A pull-system philosophy of customized production vs.

a push system of mass-market manufacturing A set of principles for creating a lean, efficient, and

waste-free product flow by limiting work-in-process Use of simple organizational policy changes resulting

in order-of-magnitude performance improvements Framework for optimizing workflow that maximizes

efficiency, product quality, and customer satisfaction

89

Kniberg, H., & Skarin, M. (2010). Kanban and scrum: Making the most of both. Toronto, ON: C4 Media, Inc.Ladas, C. (2008). Scrumban: Essays on kanban systems for lean software development. Seattle, WA: Modus Cooperandi.Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press.

Kanban Goals

90

Kanban initially seeks to change as little as possible Change without resistance is the first Kanban goal Focus on improving quality, lead time and morale

Goal 2

Goal 3

Goal 4

Goal 5

Goal 6

Goal 7

Goal 8

Deliver high product quality (to build stakeholder trust)

Reduce long lead times (and stabilize them)

Achieve sustainable pace (work-life balance)

Provide process slack (for process improvement)

Simplify workload prioritization (of customer needs)

Provide transparency (into design and operations)

Strive for process maturity (to improve performance)

Goal 1 Optimize existing processes (rather than change them)

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

Kanban Recipe for Success

91

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

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

Walkthroughs

Inspections

Technical reviews

Peer reviews

Pair programming

Test driven design

Continuous integration

Design patterns

Refactoring

Design simplicity

Usability engineering

Formal methods

Process flowcharts

Workflow analysis

Kanban boards

Limit work tasks

Limit queues

Limit buffers

Limit backlogs

Simple prioritization

Adequate resources

Process automation

Policy statements

Simplify process

Short releases

Short increments

Short iterations

Small releases

Frequent releases

Small batch sizes

Customer collaboration

Developer collaboration

Ample communication

Frequent builds

Deploy often

Automatic updates

Regulate inputs

Identify bottlenecks

Create slack

Limit work-in-process

Create pull system

Focus on precision

Focus on quality

Take pride in work

Improve morale

Learn new skills

Obtain training

Continuously improve

Prioritize inputs

Business focus-

Business value focus

Influence prioritization

Stabilize process

Build stakeholder trust

Perform risk analysis

Analyze demand

Evaluate size

Evaluate complexity

Market forecasting

Technology analysis

Work item size

Work item type mix

Service class mix

Irregular flow

Rework

Ambiguous reqmnts.

Expedited requests

Environment avail.

Market fluctuations

Coordination

Technological change

Skill/experience mix


Value Stream Mapping

92

Start by flow-charting the as-is product workflow Add buffers and queues one feels are necessary Add WIP limits to buffers, queues, and activity


Work-in-Process

93

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


Bad Project

0

35

70

105

140

175

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

Time

Feat

ure

s

Inventory Started Designed Coded Complete

Good Project

0

48

96

144

192

240

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

Time

Fea

ture

s

Inventory Started Designed Coded Complete

Agenda

94



Basic Agile Proj. Mgt. Metrics

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

Agile methods are based on traditional measures Size, effort, velocity, structure, and quality common Top-notch shops use satisfaction and business value

Type

Size

Effort

Velocity

Structure

Quality

Satisfaction

Business Value

Example

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

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

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

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

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

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

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

95

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

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

Type

Ideal Days

Actual Days

Ideal Hours

Actual Hours

User Stories

Story Points

Technical Tasks

Example

How many days something takes without interruptions

How many days something takes with interruptions

How many hours something takes without interruptions

How many hours something takes with interruptions

How many customer requirements have been satisfied

How many units of software size have been satisfied

How many technical tasks have been completed

96

Agile Cost Models


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

Type

Basic Form

XP

TDD

PP

Scrum

Agile

Example

(LOC Productivity + Quality KLOC 100) Hourly Rate

(LOC 16.1575 + 0.7466 KLOC 100) Hourly Rate





97

Agile Business Value


A major principle of Agile Methods is creating value ROI is the measure of value within Agile Methods There are seven closely related ROI measures

Type

Costs

Benefits

Breakeven

B/CR

ROI

NPV

Real Options

Example

Total amount of money spent on agile methods

Total amount of money gained from using agile methods

Point when the benefits of using agile methods exceed the costs

Ratio of agile methods benefits to costs of using agile methods

Ratio of adjusted agile methods benefits to costs of using them

Present value of agile methods benefits that result from their use

Value gained from incremental investments in high-risk projects

98

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

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

Type

PMB

SBL

BAC

PPC

APC

SPC

SPA

Example

Total number of story points planned for a release

Total number of iterations multiplied by iteration length

The planned budget for the release

Number of current iterations divided by planned iterations

Total story points completed divided by story points planned

Story points of work completed from backlog during iteration

Story points added/subtracted from backlog during iteration

99

Agenda

100



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

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

Formula

(10,000 16.1575 0.7466 10 30) 100

$4,373,446 $136,551

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

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

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

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

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

Value

$136,551

32:1

3,103%

$3,650,396

$4,263

$4,267,100

$4,373,446

Metric

Costs

B/CR

ROI

NPV

BEP

ROA

Benefits

5

1i(

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

102

Formula

(10,000 29.2800 + 2.1550 10 100) 100

$4,260,344 $249,653

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

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

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

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

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

Value

$249,653

17:1

1,607%

$3,439,359

$14,629

$4,074,506

$4,260,344

Metric

Costs

B/CR

ROI

NPV

BEP

ROA

Benefits

5

1i(


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

103

Formula

(10,000 33.4044 + 2.3550 10 100) 100

$4,244,561 $265,436

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

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

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


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


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

104

Formula

(10,000 5.4436 + 3.9450 10 100) 100

$3,931,795 $578,202

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

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

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

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

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

Value

$578,202

7:1

580%

$2,826,321

$85,029

$3,660,805

$3,931,795

Metric

Costs

B/CR

ROI

NPV

BEP

ROA

Benefits

5

1i(


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

105

Formula

(10,000 21.2374 + 1.7972 10 100) 100

$4,283,190 $226,807

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

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

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


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


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

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

3,103%

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

580%

173%

0%

925%

1,850%

2,775%

3,700%

XP Agile TDD PP Scrum CMMI®

Software Method

Ret

urn

on I

nves

tmen

t

Agenda

107



Burndown

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

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

108

Burndown Chart

Wor

k (S

tory

, Poi

nt, T

ask)

or E

ffor

t (W

eek,

Day

, Hou

r)

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

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

109

Wor

k (S

tory

, Poi

nt, T

ask)

or E

ffor

t (W

eek,

Day

, Hou

r)


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

Burnup Chart

Cumulative Flow (Trad. vs. Agile)

110

Traditional vs. Agile Cumulative Flow

Wor

k (S

tory

, Poi

nt, T

ask)

or E

ffor

t (W

eek,

Day

, Hou

r)

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

Wor

k (S

tory

, Poi

nt, T

ask)

or E

ffor

t (W

eek,

Day

, Hou

r)

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

Traditional Cumulative Flow Agile Cumulative Flow

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

Anderson, D. J. (2004). Agile management for software engineering. Upper Saddle River, NJ: Pearson Education.Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press.

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

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

Agile EVM Chart

CPI

SPI

PPC

APC

Wor

k (S

tory

, Poi

nt, T

ask)

or E

ffor

t (W

eek,

Day

, Hou

r)


Earned Business Value

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

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

112

Earned Business Value

Wor

k (S

tory

, Poi

nt, T

ask)

or E

ffor

t (W

eek,

Day

, Hou

r)


Agenda

113



APM Tool Variety

114

There are literally dozens, if not 100s of APM tools There are dozens of free open source software tools Annual tool & price surveys are frequently conducted

VersionOne. (2010). 5th annual state of agile survey. Atlanta, GA: Author.Allen, W. (2008). Agile PM tools (hosted). Retrieved May 11, 2011 from http://weblogs.asp.net/wallen.

VersionOne

115

One of the first APM tools created in 2003 Has about 36% of the marketshare for APM tools Free for small teams, but increases sharply thereafter

http://www.versionone.com

Product Roadmapping Roadmap Authoring Customization Collaboration Publishing

Product Planning Backlog Planning and Management Epics, Goals, Themes, Feature Groups Customer Requests and Idea Management Product Roadmapping Features

Release Planning Release Planning Release Forecasting Cross Project Planning and Scheduling Regression Test Planning

Sprint Planning High Level Sprint Planning Detailed Sprint Planning Capacity Planning Issue Management Features

Iteration Closeout Reviews Sprint Reviews Sprint Retrospectives Issue and Action Item Tracking Backlog reconciliation

Tracking Sprint and Member Tracking Storyboard Wall Task Board and Test Board My Work and My Dashboard

Reporting and Analytics Program Dashboard Project Dashboard Iteration Dashboard Burnup/Burndown Reports

Other Features Agile Closeout Reviews Test Management Collaboration Open Source Integration

Rally

116

One of the first web-based APM tools created in 2004 Has about 20-30% of the marketshare for APM tools Also free for small teams and gets more expensive

http://www.rallydev.com

Communication and Collaboration Customizable Role Dashboards Rich Text, Email, and RSS Support Social Media Style Interfaces Comments, Discussions, and IM

Development Management Requirements Management Test Management Defect Management Build and Source Code Traceability

Reporting Flexible Queries and Filters Customer Tabular Graphical Reports Burnup/Burndown Reporting, etc. User Generated Mashup Support

Product Management Customer Feedback Management Product Field Support Demand Management CRM Integration and Support

Agile Project Management High Level Roadmap Decomposition Epic, Theme, and Feature Tracking User Story Planning and Tracking User Story Breakdown Management

Multi-Team Management Organization Chart Mirroring Multi Level Project Hierarchies Common Progress and Status Views Program, Feature, and Resource Rollup

Release Planning Step by Step Release Planning Team Velocity Determination Release and Iteration Schedules User Story Allocation to Iterations

Iteration Planning Iteration Goal and Theme Support Team Capacity Determination Backlog Item Prioritization Task Creation, Estimation, and Tracking

ScrumWorks

117

Scrum project management tool created circa 2004 Similar size of user base to VersionOne and Rally Leadership in agile metrics and business value

http://www.danube.com

Real Time Custom Dashboards Velocity Charts Milestone Charts Cycle Time Charts Cross Product Status Reporting

Data Accessibility Full Excel Import/Export Print to User Story Cards Web Services API Backups and Notifications

User Management Full Access Control Role Based Access Permissions Cross Site Role Templates Security Management

Integration Commercial Environment Integration Open Source Environment Integration Issue and Defect Tracking Integration Support for Tool Plugins

Product Management Project Milestone Management Epics for Project Scope Goals Categorization using Themes Business Weighting and ROI

Program Management Coordination of Multiple Projects Manage and Track Overlapping Goals Shared Component/System Modeling High Level Feature Management

Iteration Management Drag and Drop Iteration Planning Team Task Board Sprint Task Tracking Impediment Tracking

Reporting and Analytics Release Date Forecasting Basic Burnup/Burndown Reporting Canned and Custom Report Generation Analysis of Planned vs. Actuals

ExtremePlanner

118

XP project management tool created around 2004 Noted commercial tool for managing XP projects No free version, although it is moderately priced

http://www.extremeplanner.com

Test Management Test Criteria Generation Test Case Generation and Capture Test Case Initiation Test Status Reporting

Integrated Issue Tracking Track Customer Support Requests Track Bug Reports Track Ad Hoc Suggestions Transition Issues to User Stories

Report Generation Velocity and Task Tracking Iteration Burnup/Burndown Charts Cumulative Workflow Diagrams User Defined Reports

Notification and Alerts Email Notifications Notification Capture and Management Notification Viewing and Filtering User Selectable Notifications

Multiple Project Support Multiple Project Definition Multiple Project Status Tracking Multiple Project Report Generation Multiple Project Task Tracking

User Story Generation Cross Project Story Themes Create a Story from an Issue Theme and Story Template Reuse Inter Project Story Management

Release Planning Capture User Stories Generated Estimate and Prioritize User Stories View Schedule Stories for Releases View Estimated Effort for Releases

Drag and Drop Iteration Planning Iteration Generation and Management Drag and Drop User Story Management Iteration Effort Estimation Iteration Status Reporting

Mingle

119

APM tool created by ThoughtWorks in late 2007 Extensible templates for multiple agile methods Growing user base that is free for small teams

http://www.thoughtworks-studios.com

Test Management Visual Defect Workflows User Story and Defect Traceability RSS and Email Test Alerting Wiki Support for Screenshots and Reports

Project Collaboration Virtual Drag and Drop Card Walls Integrated Wiki RSS Feeds and Email Alerts Murmurs, Queues , and Comments

Enterprise Support Application Life Cycle Management Integration with IDEs Integration with Versioning Tools Integration with Build/Deployment Tools

External Interfaces I/O from Common Data Formats Integration with External Databases Integration with Workflow Tools Integration with External Software

Program Management Support for Multiple Projects Multi Project Status Tracking Multi Project Report Generation Resource Allocation and Management

Project Management Multi Agile Method Support Customizable Dashboards Workflow Generators User Management and Access Control

Release and Iteration Planning Hierarchical Card Trees Prioritized Card Ranking User Story Searching and Recall Global User Story Updating

Tracking and Reporting Customizable Templates Customizable Tabs, Favorites, and Views Advanced Filtering, Properties, and Tags Burndown, Velocity, and Ad Hoc Reports

Target Process

120

APM tool originally created for XP circa 2004 Now includes support Scrum, Lean, Kanban, etc. Also free for small teams and then price rises sharply

http://www.targetprocess.com

Quality Assurance Test Plan and Test Case Generation Automated Test Initiation User Story/Test Case Traceability Defect Tracking and Management

Reports and Dashboards Customizable Dashboards Release and Iteration Forecasting Release and Iteration Burndown Charts Task, User Story, and Iteration Progress

Collaboration Customizable Email Notifications Content Sharing and Management Support for Multiple Content Types Integration with Synchronous Tools

Product Support Customer Help Desk Portal Ideas and Issues Tracking Bug Reports Traceable to User Stories Full Customer Email Integration

Agile Planning and Tracking Backlog Management and Prioritization Release and Iteration Planning Task Boards and Personal To Do Lists Impediments and Blockage Management

Lean Development Value Stream Mapping Kanban Boards Cumulative Workflow Diagrams Work in Process Limits

Customization Customizable Development Process Customizable User Roles and Terminology Customizable Navigation and Lists Customizable Fields and Other Attributes

Integration Web Services API Visual Studio and Eclipse IDE Integration Subversion, Bugzilla, JUnit, and Selenium Single Sign On Support

Agenda

121



Contract Type Description

Agile Contracting Models

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

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

122

Dynamic Value

Performance Based

Target Cost

Optional Scope

Collaborative

Lean

Specify initial scope and needs (with iterative enhancements)

Establish performance objectives (but not technical solutions)

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

Set minimum and maximum costs (based on initial scope)

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

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

Performance Based Acquisition

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

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

123

Performance Based Services Acquisition

Integrated Solutions Team

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

Problem Statement

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

Private and Public Solutions

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

Statement of Objectives

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

Measure Performance

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

Select Contract

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

Manage Performance

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

Target Cost

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

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

124

Target Cost Contract

Scope Statement

Business vision System metaphor User stories Effort estimate Priorities Roadmap

Statement of Work

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

Master Agreement

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

Release Plan

Feature priorities Wireframes Development tasks Task effort Iteration plan Workflow tool

Closeout

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

Development

Iterations, Sprints, or Increments

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

Change Management

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

Support Processes

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

PS2000 for Agile

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

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

125

PS2000 Agile Contract

Needs Phase

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

Solution Description Phase

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

Approval and Completion Phase

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

Iterative Construction

SignContract

ApproveSolution

PrepareDelivery

Detailed Planning

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

Product Development and Verification

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

Testing and Debugging

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

Checkpoints and Other Services

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

, Beta Testing,

Evolutionary Acquisition

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

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

126

Evolutionary Acquisition

Technology Development

Engineering &Manufacturing

Production &Deployment

Operations &Support

6 Months 12 Months 18 Months 24 Months 30 Months

Increment 1Spiral 1 Spiral 2 Spiral 3

Technology Strategy


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

Lean & Agile Acquisition

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

Originated from agile methods popularity in 2002 Gained foothold in U.S. DoD with Scrum popularity Front loads acquisition process with early deliveries

127

Lean & Agile Acquisition

Program 1

Program 2

Program n

6 months 12 months 18 months 24 months 30 months

A1 B1 C1 FRP FOCMDD

Release 1Sprint 0 Sprint 3 Sprint 6

Operational Capability







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

Agenda

128



Diffusion of Innovations

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

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

129

Diffusion of Innovations

Dif

fusi

on

Innovators EarlyAdopters

EarlyMajority

LateMajority Laggards

Crossing the Chasm

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

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

130

Crossing the Chasm

Dif

fusi

on

Innovators EarlyAdopters

EarlyMajority

LateMajority Laggards

Virginia Satir Model

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

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

131

Virginia Satir Model

StatusQuo Resistance Chaos Recovery New

State

Pro

duct

ivit

y

Incremental Change

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

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

132

Incremental Change

StatusQuo

Resist-stance Chaos Reco-

veryNewState

StatusQuo

Resist-ance Chaos Reco-

veryNewState

StatusQuo

Resist-ance Chaos Reco-

veryNewState

Pro

duct

ivit

y

Organizational Change

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

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

133

How to Cross the Chasm

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

Direct the Rider

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

Motivate the Elephant

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

Shape the Path

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

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

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

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

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

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

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

Organization Change Methods

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

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

134

Organization Change Methods

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

Personal Influence

Business Case

Executive Coaching

Executive Commitment

Adequate Resources

Top Down Change

Model Driven Change

Manager Involvement

Employee Involvement

Training & Education

Evolutionary Change

Project Champion

Coaching & Mentoring

Just Do It

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

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

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

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

Formal allocation of resources to execute a large organizational change initiative

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

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

Psychological involvement and commitment of middle managers to avoid bureaucratic obfuscation

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

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

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

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

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

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

Agenda

135



136

E-Commerce—Google

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

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

Project Name

Project Type

Project Size

Product Size

Environment

Before APM

APM Practices

After APM

Lessons Learned

AdWords

Pay-per-Click (PPC) Internet Advertising Mechanism

20 teams of 140 people distributed over 5 countries

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

Entrepreneurial, egalitarian, dynamic, unpredictable, informal, unstructured

Chronic schedule delays, poor quality, unpredictability, poor estimation

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

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

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

137

Shrink-Wrapped—Primavera

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

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

Project Name

Project Type

Project Size

Product Size

Environment

APM Practices

After APM

Lessons Learned

Primavera

Enterprise Project Management Tool

15 teams of 90 people collocated at one site

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

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

Release planning, agile project management tools, automated testing tools

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

Agile results in better communication, motivation, and empowerment

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

138

Healthcare—FDA

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

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

Project Name

Project Type

Project Size

Product Size

Environment

APM Practices

After APM

Lessons Learned

m2000 Real-time PCR Diagnostics System

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


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

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

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

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

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

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

139

Law Enforcement—FBI

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

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

Project Name

Project Type

Project Size

Product Size

Environment

Before APM

APM Practices

After APM

Lessons Learned

Inter-Agency Intelligence Sharing System

Domestic Terrorist Database/Data Warehouse


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

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

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

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

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

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

140

U.S. DoD—STRATCOM

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

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

Project Name

Project Type

Project Size

Product Size

Before APM

APM Practices

After APM

Lessons Learned

Strategic Knowledge Integration Website (SKIweb)

Knowledge Management System (KMS)—Advanced Search Capability


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

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

Release planning, frequent customer collaboration, continuous integration

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

Agile improves customer satisfaction/communication, and overall product quality

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

Agenda

141



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

142

Customer Communication

Product Visioning

Distribution Strategy

Team Development

Standards & Practices

Telecom Infrastructure

Development Tools

High Context Meetings

Coordination Meetings

F2F Communications

Performance Management

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

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

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

Facilitate selection of high bandwidth telecommunication products and services

Facilitate selection of agile project management tools and interactive development environment

Facilitate selection of high context agile project management and development meetings

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

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


Customer Collaboration

Working Software

Individuals & Interactions

Responding to Change

valuedmore than

valuedmore than

valuedmore than

valuedmore than

Agile

Met

rics

Traditional Metrics

Contracts

Documentation

Processes

Project Plans

Interaction frequency Comm. quality Relationship strength

Customer trust Customer loyalty Customer satisfaction

Team competence Team motivation Team cooperation

Team trust Team cohesion Team communications

Batch/queue size WIP/WIP constraints Cadence/iterations

Experimental willingness Risk/failure threshold Feedback/criticism thresh.

Org. flexibility Mgt. flexibility Individual flexibility

Process flexibility Design flexibility Technology flexibility

Contract compliance Contract deliverables Contract change orders

Lifecycle compliance Process Maturity Level Regulatory compliance

Document deliveries Document comments Document compliance

Cost Compliance Scope Compliance Schedule Compliance

143

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

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

Factor

Leadership

Boundaries

Empowerment

Competence

Structure

Manageability

Motivation

Attributes

Credible, experienced, likeable, & nurturing project champion

Clear vision, mission, goals, & objectives

Adequate time, money, tools, & authority

Applicable skills, knowledge, experience, & personality

Clear roles, responsibilities, technical approach, & operating rules

Small, collaborative, cohesive, & frequently-communicating

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

144

Agile UX—User Experience Design

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

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

Product Owner Agile UX Development

Define Product Vision & Strategy

DefineUser Needs

BuildUser Experience

BuildProduct

Competitive Analysis

Define Feature Set

Quantify Business Value

Prioritization

Define Business Rules

Pricing & Budgeting

Project Accountability

Partnerships & Licensing

User Interviews

Contextual Inquiry

User Flows

Wireframes & Mockups

Prototyping

Usability Testing

Web Metrics Analysis

User Feedback

GUI Implementation

Core Capabilities

Core Services

Value Adding Capabilities

Value Adding Services

Distributed Framework

Central Framework

Support Services

Front End Code

Back End Code

Database Schema

Technology Selection

Usability Testing

User Experience Testing

Market Testing

Overall Product Evaluation

Myths about Agile Proj. Mgt. Common myths abound, although agile methods

have been around for ~20 years: Agile methods are only for software development Agile methods are only for small co-located teams Agile methods have no documentation Agile methods have no requirements Agile methods need traditional system architectures Agile methods have no project management Agile methods are undisciplined and unmeasurable Agile methods create unmaintainable systems Agile methods result in security vulnerabilities

146

Agile Documentation

147Rico, D. F. (2008). Agile methods and software documentation. Retrieved April 21, 2011 from http://davidfrico.com/rico08e.pdfRueping, A. (2003). Agile documentation: A pattern guide to producing lightweight documents for software projects. West Sussex, England: John Wiley & Sons.

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

Contracts

Document Type

Project Plans

Requirements

Architecture

Design

Coding

Tests

User guides

Quality Assurance

Agile Documentation

Performance, target cost, agile contract, lean acquisition

Release plans, iteration plans, kanban boards, workflow tools

Vision, mission, capabilities, scope, user stories, use cases

Metaphors, story boards, system modeling language, spikes

Wire frames, design patterns, unified modeling language

Code patterns, program design language, coding comments

Unit, component, integration, system, and acceptance tests

XML documents, online help, wikis, FAQs, video & audio clips

Code structure, defects, running tests, reliability, performance

Conclusion

148

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

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

Agile project management is …

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

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

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

Agenda

149



APM Textbooks I

150

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

Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.Highsmith, J. A. (2004). Agile project management: Creating innovative products. Boston, MA: Pearson Education.DeCarlo, D. (2004). Extreme project management: Using leadership, principles, and tools to deliver value in the face of volatility. San Francisco, CA: Jossey-Bass.Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education.

APM Textbooks II

151

Many other Agile Project Management books Good background on Agile Project Management Newer Agile Project Management books emerging

Chin, G. L. (2004). Agile project management: How to succeed in the face of changing project requirements. New York, NY: Amacom.Aguanno, K. (2005). Managing agile projects. Lakefield, Ontario, Canada: Multi-Media Publications.Pries, K. H., & Quigley, J. M. (2010). Scrum project management. Boca Raton, FL: CRC Press.Augustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education.Sliger, M., & Broderick, S. (2008). The software project manager's bridge to agility. Boston, MA: Addison-Wesley.

APM Textbooks III

152

Project management books continuing to emerge Project management becoming dominant paradigm Some are from popular project management authors

Wysocki, R. K. (2009). Effective project management: Traditional, agile, and extreme. Indianapolis, IN: Wiley.Anderson, D. J. (2004). Agile management for software engineering: Applying the theory of constraints for business results. Upper Saddle River, NJ: Pearson Education.Goodpasture, J. C. (2010). Project management the agile way: Making it work in the enterprise. Ft. Lauderdale, FL: J. Ross Publishing.Cobb, C. G. (2011). Making sense of agile project management: Balancing control and agility. Hoboken, NJ: John Wiley & Sons.Layton, M. C., & Maurer, R. (2011). Agile project management for dummies. Hoboken, NJ: Wiley Publishing.

Scaling Agile Methods

153

Scaling is the new frontier in Agile Methods research Many of them stem from Planning XP by Kent Beck Books emerging on global distributed agile teams

Woodward, E., Surdek, S., & Ganis, M. (2010). A practical guide to distributed scrum. Indianapolis, IN: IBM Press.Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Pearson Education.Schiel, J. (2010). Enterprise-scale agile software development. Boca Raton, FL: CRC Press.Larman, C., & Vodde, B. (2008). Scaling lean and agile development: Thinking and organizational tools for large-scale scrum. Boston, MA: Addison-Wesley.Larman, C., & Vodde, B. (2010). Practices for scaling lean and agile development. Boston, MA: Addison-Wesley.

Agile Organization Change

154

Agile methods are one of the newest innovations Organizational change is a major obstacle for agile Many books emerging to help manage agile adoption

Appelo, J. (2011). Management 3.0: Leading agile developers and developing agile leaders. Boston, MA: Pearson Education.Cohn, M. (2010). Succeeding with agile: Software development using scrum. Boston, MA: Pearson Education.Elssamadisy, A. (2009). Agile adoption patterns: A roadmap to organizational success. Boston, MA: Pearson Education.Coplien, J. O., & Harrison, N. B. (2004). Organizational patterns of agile software development. Upper Saddle River, NJ: Prentice-Hall.Smith, G., & Sidky, A. (2009). Becoming agile: In an imperfect world. Greenwich, CT: Manning Publications.

Agile Development

155

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

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