Balancing Agility and Discipline (Part 1)

CS 566 – Software Management and Economics

Lecture 9 (Boehm and Turner Tutorial 2004;

Chapters 1 – 3, Boehm and Turner Book 2004)

Ali Afzal Malik

LUMS 2

Outline

• General software trends and implications– Sources of perplexity about agile, plan-driven methods

• Overview of agile and plan-driven methods– XP, TSP “days in the life”– Comparisons of differences, strengths, weaknesses

• Risk-based balance of agility and discipline– Small, medium, large examples

• Observations and Way Forward– Hands-on exercise

• Conclusions; review of learning objectives

LUMS 3

Information Technology Trends

Traditional Development

• Standalone systems

• Stable requirements

• Rqts. determine capabilities

• Control over evolution

• Enough time to keep stable

• Stable jobs

• Failures noncritical

• Reductionist systems

• Repeatability-oriented process,

maturity models

Current/Future Trends

• Everything connected (maybe)

• Rapid requirements change

• COTS capabilities determine rqts.

• No control over COTS evolution

• Ever-decreasing cycle times

• Outsourced jobs

• Failures critical

• Complex, adaptive, emergent

systems of systems

• Adaptive process models

LUMS 4

Background

• Two approaches to software development – Disciplined (SW-CMM, document-based, heavy process)

– Agile (XP, tacit knowledge, light process)

• Both have strengths and weaknesses

• Agile and disciplined proponents are believers

• Many of us are perplexed

LUMS 5

Key Definitions

• Agile method –– one which fully adopts the four value propositions and

twelve principles in the Agile Manifesto.

• Discipline – (per Webster)– control gained by enforcing obedience or order; – orderly or prescribed conduct or pattern of behavior; – self-control.

• Plan-driven –– a description for disciplined methods (order is often

defined in plans)

• Plan – (per Webster)– a method for achieving an end (a process plan); – an orderly arrangement of parts of an overall design (a

product plan). – We assume that such plans are documented.

LUMS 6

The Agile Manifesto

•• Individuals and interactionsIndividuals and interactions over processes and tools

•• Working softwareWorking software over comprehensive documentation

•• Customer collaborationCustomer collaboration over contract negotiation

•• Responding to changeResponding to change over following a plan

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

That is, while there is value in the items on

the right, we value the items on the left more.

LUMS 7

Plan-Driven Methods Are

Evolving Too

• Evolutionary acquisition and spiral development– U.S. DoD Directive 5000.1, Instruction 5000.2

• Risk-driven level of detail– Of processes: peer reviews vs. Critical Design Reviews– Of products: GUI prototypes vs. specifications– Of heavyweight methods: Team Software Process, Rational Unified Process

LUMS 8

Sources of Perplexity

• Distinguishing method use from method misuse

• Citing method misuse vs. intended use– Claiming XP use when simply “not documenting”– “CMM Level 4 Memorial Library” of 99 2-inch binders

• Overgeneralization based on the most visible instances– XP is Agile; CMM is Plan-Driven

• Multiple definitions– Quality: customer satisfaction or compliance?

• Claims of universality– The pace of IT change is accelerating and Agile methods

adapt to change better than disciplined methods therefore Agile methods will take over the IT world.

– Software development is uncertain and the SW-CMM improves predictability therefore all software developers should use the SW-CMM

LUMS 9

Sources of Perplexity (2)

• Early success stories– Chrysler project that successfully birthed XP was later cancelled

– Cleanroom has never made it into the mainstream

• Purist interpretations (and internal disagreements)– “Don't start by incrementally adopting parts of XP. Its pieces fit together like a fine Swiss watch“

– "An advantage of agile methods is that you can apply them selectively and generatively."

– "If you aren't 100% compliant with SW CMM Level 3, don't bother to bid"

– "With the CMMI continuous interpretation, you can improve your processes in any order you feel is best."

LUMS 10

Outline

• Tutorial learning objectives– Survey of assumptions about participants

• General software trends and implications– Sources of perplexity about agile, plan-driven methods

• Overview of agile and plan-driven methods– XP, TSP “days in the life”– Comparisons of differences, strengths, weaknesses

• Risk-based balance of agility and discipline– Small, medium, large examples

• Observations and Way Forward– Hands-on exercise

• Conclusions; review of learning objectives

LUMS 11

Various Agile Methods Available

• Adaptive Software Development (ASD)

• Agile Modeling

• Crystal methods

• Dynamic System Development Methodology (DSDM)

* eXtreme Programming (XP)

• Feature Driven Development

• Lean Development

• Scrum

LUMS 12

XP Principles – I

• Philosophy: Take known good practices and push them to extremes

• “If code reviews are good, we’ll review code all the time”

• “If testing is good, we’ll test all the time”

• “If design is good, we’ll make it part of everybody’s daily business”

LUMS 13

XP Principles – II

• “If simplicity is good, we’ll always leave the system with the simplest design that supports its current functionality”

• “If architecture is important, everybody will work defining and refining the architecture all the time”

• “If integration testing is important, then we’ll integrate and test several times a day”

LUMS 14

XP Principles – III

• “If short iterations are good, we’ll make the iterations really, really short – seconds and minutes and hours, not weeks and months and years”

• “If customer involvement is good, we’ll make them full-time participants”

LUMS 15

XP: The 12 Practices-Kent Beck, Extreme Programming Explained, Addison Wesley, 1999

• The Planning Game

• Small Releases

• Metaphor

• Simple Design

• Testing

• Refactoring

• Pair Programming

• Collective Ownership

• Continuous Integration

• 40-hour Week

• On-site Customer

• Coding Standards

-Used generatively, not imperatively

LUMS 16

XP Characteristics

LUMS 17

The Team Software Process (TSP)-Watts Humphrey, Introduction to the TSP, Addison Wesley, 2000

• Scale-up of Personal Software Process (PSP)– To about 20-person teams

• Strong emphasis on planning and control– 21 scripts, 5 roles/activities, 21 forms

• Risk-driven tailoring can make process more agile

LUMS 18

Example TSP Role Script

LUMS 19

TSP Characteristics

LUMS 20

Days In The Life: XP and TSP

• Comparison of two development teams

• Product: – Tool to process complex sales report generated by legacy system

– Prototype delivered– Task is to enhance and port prototype – 8 month projected schedule– Estimated size: 20,000 SLOC

LUMS 21

Background Information

TSP/PSP

• Training– Each member has 125-hour PSP

for Engineers

– 2 Members 5-day launch coach training

• Tools and environment– Web-based TSP data collection

tool

– OO tools

– Individual offices and conference room

• Project planning– 4-day launch session

– Develop/tailored all processes

– 180 tasks identified and plan accepted by stakeholders

XP

• Training– 2 members attended 40-hour XP

workshop

– In-house presentations and mentoring

• Tools and environment– Automated test suite

development tool

– OO tools

– Bullpen and Conference room/lounge

• Project planning– 1-day customer exploration

– 2-day follow-up to prioritize

– Agreed on 2-week iteration length, 3-iteration release length, and release schedule

LUMS 22

Normal and Crisis Days

• Used Friday as common day

• Crisis days are plan-breakers– New requirements– Short schedule

LUMS 23

Comparison

• Differences– Depth and scope of metrics– Specificity of process– Level and scope of reporting– Customer interface

• Similarities– Collaborative teams– Well-defined roles– Spiral, risk- and increment-driven process– Measurement– Test first (test-driven) approach

• Bottom Line– Both were able to confidently push-back when necessary

LUMS 24

Finding Middle Ground

• A pragmatic view

• Both approaches have “home grounds”

• A broad range of environments and needs

• Trends require better handling of rapid change

• Processes should be the right weight for the job

• We believe risk-based analysis is the key to finding middle ground

LUMS 25

Contrasts and Home Grounds

• Comparison is difficult, but we found 4 areas where there are clear differences

• Application– Project goals, size, environment; velocity

• Management– Customer relations, planning and control, communications

• Technical– How the software is developed

• Personnel– The type and competency of developers and stakeholders

LUMS 26

Application Characteristics

• Primary goals– A: Rapid value, responsiveness to change– P: Predictability, stability, high assurance

• Size– A: Small to medium– P: Large

• Environment– A: Turbulent, high change– P: Stable, requirements defined

• Project velocity– A: Code, learn, and fix– P: Architect for parallel, incremental development

LUMS 27

Management Characteristics

• Customer Relations– A: Dedicated, collocated; where feasible– P: Contractual; increasingly evolutionary– A: Trust through working software and participation– P: Trust through process maturity evaluations

• Planning and Control– A: Means to an end– P: Anchor processes, communication

• Project Communications– A: Tacit, interpersonal knowledge– P: Explicit, documented knowledge

LUMS 28

Technical Characteristics

• Requirements– A: Adjustable, informal stories– P: Formally baselined, complete, consistent specifications

• Development– A: Simple Design– P: Architecture-based design

• Testing– A: Automated, test-driven– P: Planned, requirements-driven

LUMS 29

Technical Characteristics (2)Cost of Change: Beck, Li

Cos

t of C

hang

eTime

Beck

LiLi

LUMS 30

Technical Characteristics (3) Cost of change: Poppendieck

• At least two cost-escalation curves

• Lean development: Architect to defer high-stakes decisions – e.g. COTS

• Easier to change an unmade decision

Most Changes

Changes in High-stakes Constraints

Time

Cos

t of C

hang

e

LUMS 31

Technical Characteristics (4)Cost of Change: TRW

Beck

Li

Steeper Cost-to-fix for High-Risk Elements

0102030405060708090

100

0 10 20 30 40 50 60 70 80 90 100

% of Software Problem Reports (SPR’s)

TRW Project A373 SPR’s

TRW Project B1005 SPR’s

% ofCosttoFixSPR’s

Major Rework Sources:Off-Nominal Architecture-BreakersA - Network FailoverB - Extra-Long Messages

Steeper Cost-to-fix for High-Risk Elements

0102030405060708090

100

0 10 20 30 40 50 60 70 80 90 100

% of Software Problem Reports (SPR’s)

TRW Project A373 SPR’s

TRW Project B1005 SPR’s

% ofCosttoFixSPR’s

Major Rework Sources:Off-Nominal Architecture-BreakersA - Network FailoverB - Extra-Long Messages

LUMS 32

Technical Characteristics (5)How Much Architecting?

Beck

Liu

0

10

20

30

40

50

60

70

80

90

100

0 10 20 30 40 50 60

Percent of Time Added for Architecture and Risk Res olution

Per

cent

of T

ime

Add

ed to

Ove

rall S

ched

ule

Percent of Project Schedule Devoted to Initial Architecture and Risk Resolution

Added Schedule Devoted to Rework(COCOMO II RESL factor)

Total % Added Schedule

Sweet Spot Drivers:

Rapid Change: leftward

High Assurance: rightward

Sweet spot

10 KSLOC

100 KSLOC

10,000 KSLOC

LUMS 33

Personnel Characteristics

• Customers– A: CRACK customers throughout development– P: CRACK customers early

• CRACK: Collaborative, Representative, Authorized, Committed, and Knowledgeable

• Developers– A: Heavy mix of high caliber throughout– P: Heavy mix early with lower capability later

• Culture– A: Many degrees of freedom (Thrives on chaos)– P: Clear policies and procedures (Thrives on order)

• Collocated customers are difficult to find/keep/keep current on either side

LUMS 34

Personnel Characteristics (2)Modified Cockburn Levels

(Skill, Understanding)

(Formality, Documentation)

(Skill, Understanding)

(Formality, Documentation)

Level Characteristics

3 Able to revise a method (break its rules) to fit an unprecedented new situation

2 Able to tailor a method to fit a precedented new situation

1A With training, able to perform discretionary method steps (e.g., sizing stories to fit increments, composing

patterns, compound refactoring, complex COTS integration). With experience can become Level 2.

1B With training, able to perform procedural method steps (e.g. coding a simple method, simple refactoring,

following coding standards and CM procedures, running tests). With experience can master some Level 1A skills.

-1 May have technical skills, but unable or unwilling to collaborate or follow shared methods.

LUMS 35

Summary of Home Grounds

* Collaborative, Representative, Authorized, Committed, Knowledgeable** These numbers will particularly vary with the complexity of the application

Comfort and empowerment via framework of policies and procedures (thriving on order)

Comfort and empowerment via many degrees of freedom (thriving on chaos)

Culture

50% Cockburn Level 3s early; 10% throughout; 30% Level 1B’s workable; no Level -1s**

At least 30% full-time Cockburn level 2 and 3 experts; no Level 1B or -1 personnel**

Developers

CRACK* performers, not always collocatedDedicated, collocated CRACK* performersCustomers

Personnel

Documented test plans and proceduresExecutable test cases define requirementsTest

Architect for parallel development; longer increments; refactoring assumed expensive

Simple design; short increments; refactoring assumed inexpensive

Development

Formalized project, capability, interface, quality, forseeable evolution requirements

Prioritized informal stories and test cases; undergoing unforseeable change

Requirements

Technical

Explicit documented knowledgeTacit interpersonal knowledgeCommunications

Documented plans, quantitative controlInternalized plans; qualitative controlPlanning/Control

As-needed customer interactions; focused on contract provisions; increasingly evolutionary

Dedicated on-site customers, where feasible; focused on prioritized increments

Customer Relations

Management

Stable; low-change; project/organization focusedTurbulent; high change; project-focusedEnvironment

Larger teams and projectsSmaller teams and projectsSize

Predictability, stability, high assuranceRapid value; responding to changePrimary Goals

Application

Plan-drivenAgileCharacteristics

LUMS 36

References

• Barry Boehm and Richard Turner, Balancing Agility and Discipline: Evaluating and Integrating Agile and Plan-Driven Methods, STC 2004 Tutorial, 2004.

• Barry Boehm and Richard Turner, Balancing Agility and Discipline – A Guide for the Perplexed, Addison-Wesley, 2004.