Balancing Agility and Discipline

Report by Brad Kaufmann

1
Road Map
• Introduction
• What are Discipline and Agility?
• Misconceptions
• Contrasts and Home Grounds
• Five Critical Factors
• The Risk-Based Method
• Case Study
• Personal Experiences
• Summary and Wrap-Up

2
About Myself
• B.S. in Computer Science, Kansas State, 2004
• KU MSIT Fall 2009
• Currently a software engineer at Garmin
– Recently moved to Marine chartplotters group
– Auto OEM for 3 ½ years

• Previously at Cargill and Arrowpoint

3
About the Authors
• Barry Boehm
– Professor at the University of Southern California
– COCOMO, Spiral Model, Win-Win Approach
• Richard Turner
– Professor at Stevens Institute of Technology
– Member of original CMMI author team
– Author of CMMI Distilled

4
What Are We Talking About?
• The software environment is changing
• Software project management methods need to
evolve to keep up
• Discipline vs. agility
– Adversarial relationship
– Old vs. new
– Heavy vs. light processes
– Strength vs. invention
• Success depends on balance of both

5
Who Should Care About This?
• Software project managers
• Software developers
• Students
• Academicians
• Proponents of both sides
• CIOs and CEOs

6
Why Is There Perplexity?
• Sources of perplexity
– Multiple definitions
– Use vs. misuse
– Overgeneralization
– Claims of universality
– Early success stories
– Purist interpretations

7
Road Map
• Introduction
• What are Discipline and Agility?
• Misconceptions
• Contrasts and Home Grounds
• Five Critical Factors
• The Risk-Based Method
• Case Study
• Personal Experiences
• Summary and Wrap-Up

8
What Is Discipline?
• Traditional way to develop software
• Plan-driven
• Came from mainline engineering fields
– Rise of aerospace systems
– Systems engineering for component integration
• Methods
– Software Capability Maturity Model (SW-CMM)
– Cleanroom
– PSP/TSP

9
Where Did It Come From?
• DoD guidance documents
– MIL-STD-1521
– DoD-STD-2167
– MIL-STD-498
• Large companies
– IBM
– Hitachi
– Siemens

10
Characteristics
• Strengths
– Comparability
– Repeatability
– Minimize loss of personnel
• Drawbacks
– Impede innovation
– Checklist mentality
– Documentation generators

11
Plan-Driven Concepts
• Process improvement
• Process capability Improve
Process
• Organizational maturity
• Process group Define Control Measure
Process Process Process
• Risk management
• Verification Perform
Process
• Validation
• Software system architecture

12
Plan-Driven Success Criteria
• Management support
• Organizational infrastructure
• Understanding of importance of common
processes
• Well-trained practitioners
• Large programs

13
What Is Agility?
• Agile methods
– eXtreme Programming (XP)
– Scrum
– Crystal
– Feature-driven development
• Lightweight processes
• Embrace change rather than fight it

14
Where Did It Come From?
• Outgrowth of rapid prototyping
• Programming as a craft, not a process
• Internet-based economy
– Rapid change and long development cycles don’t mix
• Chaordic = chaos + order
• Agile manifesto
– Defines philosophy of agility

15
Agile Concepts
• Embracing change
• Fast cycle/frequent delivery
• Simple design/YAGNI
• Refactoring
• Pair programming
• Retrospective
• Tacit knowledge
• Test-driven development

16
Agile Success Criteria
• Close relationship with customer
• Highly-motivated, knowledgeable team
• Cultural acceptance
• Continuous improvement
• Smaller programs

17
Key Differences
• Plan-driven methods value processes over
people
– Documentation
– Interchangeable parts
– Waterfall
• Agile methods value people over processes
– Tacit knowledge
– Highly skilled people
– Cups of water

18
Finding the Middle Ground
• Phillipe Krutchen from Rational
• SW-CMM is like the dictionary
– Use the words needed to make the desired point
– Do not use all of the words
• Process toolbox
– “Plug-compatible” process assets
• Risk is the key

19
Road Map
• Introduction
• What are Discipline and Agility?
• Misconceptions
• Contrasts and Home Grounds
• Five Critical Factors
• The Risk-Based Method
• Case Study
• Personal Experiences
• Summary and Wrap-Up

20
What Are the Misconceptions?
• No silver bullet
• Both approaches are tools in the toolbox
Plan-Driven Methods
Plan-driven methods are uniformly
bureaucratic.
Having documented plans
guarantees compliance with plans.
Plan-driven methods can succeed
with a lack of talented people.
High maturity guarantees success.
Agile Methods
Agile methods do not plan.
Agile methods require uniformly
talented people.
Agile methods can make the slope
of the cost-to-change vs. time
curve uniformly flat.
YAGNI is a universally safe
assumption and will not alienate
your customers.
21
What Are the Realities?
• Plan-driven methods
Misconception
Uniformly bureaucratic.
Having documented plans guarantees
compliance with plans.
Can succeed with lack of talented
people.
High maturity guarantees success.
No penalties when change is
unforeseeable.
22
Reality
Overly bureaucratic cultures and
methods can cripple software
development.
Not necessarily.
Can succeed with smaller percentage
of talented people.
Provide more of a safety net than tacit
plans.
Work best in accommodating
foreseeable change.
What Are the Realities?
• Agile methods
Misconception
Agile methods do not plan.
Require uniformly talented people.
Can make the slope of the cost-to-
change vs. time curve uniformly flat.
YAGNI is universally safe assumption
and will not alienate customers.
23
Reality
Get much of their speed and agility
through creating and exploiting tacit
knowledge.
Work best when there is critical mass
of highly talented people involved.
Can reduce the slope of the cost-to-
change vs. time curve.
YAGNI helps handle unforeseeable
change, but is risky when change is
foreseeable.
Road Map
• Introduction
• What are Discipline and Agility?
• Misconceptions
• Contrasts and Home Grounds
• Five Critical Factors
• The Risk-Based Method
• Case Study
• Personal Experiences
• Summary and Wrap-Up

24
Contrasts and Home Grounds
• Home grounds are where each method performs
the best
• Home grounds depend on characteristics
– Application characteristics
– Management characteristics
– Technical characteristics
– Personnel characteristics
• Further away project is from a method’s home
grounds, the more risk in using a pure form

25
Application Characteristics
• Primary goals
– Plan-driven: predictability, stability, high assurance
– Agile: rapid value, responsiveness to change
• Size
– Plan-driven: large projects
– Agile: small to medium projects
• Environment
– Plan-driven: relatively stable
– Agile: high-change, focus on project at hand

26
Management Characteristics
• Customer relations
– Plan-driven: contract, process maturity
– Agile: dedicated customer, working software
• Planning and control
– Plan-driven: use plans to communicate & coordinate
– Agile: planning as a means to an end
• Project communication
– Plan-driven: explicit, documented knowledge
– Agile: tacit knowledge

27
Technical Characteristics
• Requirements
– Plan-driven: specific, formalized requirements
– Agile: informal, user-prioritized stories
• Development
– Plan-driven: advocates architecture
– Agile: advocates simple design
• Testing
– Plan-driven: test to specification
– Agile: develop tests before code, test incrementally

28
Personnel Characteristics
• Customers
– Both methods need CRACK customers
– Plan-driven does not require them full-time
• Developers
– Plan-driven: need fewer highly talented people
– Agile: need more than technical skills
• Culture
– Plan-driven: clear processes and roles
– Agile: many degrees of freedom

29
Road Map
• Introduction
• What are Discipline and Agility?
• Misconceptions
• Contrasts and Home Grounds
• Five Critical Factors
• The Risk-Based Method
• Case Study
• Personal Experiences
• Summary and Wrap-Up

30
Five Critical Factors
• Factors in determining relative suitability of a
method on a particular project
– Size
– Criticality
– Dynamism
– Personnel
– Culture

31
Size Factor
• Plan-driven
– Methods evolved to handle large products and teams
– Hard to tailor down
• Agile
– Well matched to small products and teams
• Range (number of personnel)
– 3
– 10
– 30
– 100
– 300

32
Criticality Factor
• Plan-driven
– Methods evolved to highly critical products
– Hard to tailor down

• Agile
– Untested on safety-critical products
– Potential difficulties with simple design and lack of documentation

• Range (loss due to impact of defects)

– Comfort
– Discretionary funds
– Essential funds
– Single life
– Many lives

33
Dynamism Factor
• Plan-driven
– Excellent for highly stable environment
– Expensive rework for highly dynamic environment

• Agile
– Excellent for highly dynamic environment
– Expensive rework for highly stable environment

• Range (% requirements-change/month)
– 1
– 5
– 10
– 30
– 50

34
Personnel Factor
• Based on Cockburn scale
• Plan-driven
– Needs critical mass of level 2 and 3 experts during project definition
– Can work with fewer later in project unless highly dynamic environment
– Can usually accommodate some level 1B people
• Agile
– Requires continuous presence of critical mass of level 2 or 3 experts
– Risky to use non-agile level 1B people
• Range ( % level 1B / % level 2 and 3 )
– 0% level 1B / 35% level 2 and 3
– 10% level 1B / 30% level 2 and 3
– 20% level 1B / 25% level 2 and 3
– 30% level 1B / 20% level 2 and 3
– 40% level 1B / 15% level 2 and 3

35
The Cockburn Scale

Levels of Software Method Understanding and Use

Level Characteristics
3 Able to revise a method to fit unprecedented new situation.
2 Able to tailor a method to fit precedented new situation.
1A With training can perform discretionary method steps, can
become level 2 with experience.
1B With training can perform procedural method steps, can master
some level 1A skills with experience.
-1 May have technical skills, but unable or unwilling to collaborate
or follow shared methods.

36
Culture Factor
• Plan-driven
– Thrives on order
• Agile
– Thrives on chaos
• Range (% thriving on chaos vs. order)
– 10
– 30
– 50
– 70
– 90

37
When To Use Which Method?

38
Road Map
• Introduction
• What are Discipline and Agility?
• Misconceptions
• Contrasts and Home Grounds
• Five Critical Factors
• The Risk-Based Method
• Case Study
• Personal Experiences
• Summary and Wrap-Up

39
Overview of The Risk-Based Method

A Tailorable Method for Balancing Agile and Plan-Driven Methods

Step 1 Rate project’s environmental, agile, plan-driven risks.
Step 2a If agility risks dominate plan-driven risks, go risk-based plan-
driven.
Step 2b If plan-driven risks dominate agility risks, go risk-based agile.
Step 3 If parts of application satisfy 2a and others 2b, go risk-based
agile in agile parts and risk-based plan-driven elsewhere.
Step 4 Establish overall project strategy by integrating risk mitigation
plans.
Step 5 Monitor progress and risks/opportunities , readjust balance and
process as appropriate.

40
The Risk-Based Method Process Flow

41
Risk Categories
• Environmental
– Risks that result from the project’s general
environment
• E-Tech: technology uncertainty
• E-Coord: many diverse stakeholders to coordinate
• E-Cmplx: complex system of systems

42
Risk Categories (2/3)
• Agile
– Risks that are specific to the use of agile methods
• A-Scale: scalability and criticality
• A-YAGNI: use of simple design or YAGNI
• A-Churn: personnel turnover or churn
• A-Skill: not enough people skilled in agile methods

43
Risk Categories (3/3)
• Plan-driven
– Risks that are specific to the use of plan-driven
methods
• P-Change: rapid change
• P-Speed: need for rapid results
• P-Emerge: emergent requirements
• P-Skill: not enough people skilled in plan-driven methods

44
Road Map
• Introduction
• What are Discipline and Agility?
• Misconceptions
• Contrasts and Home Grounds
• Five Critical Factors
• The Risk-Based Method
• Case Study
• Personal Experiences
• Summary and Wrap-Up

45
Case Study: SupplyChain.com
• Turnkey agent-based supply chain management systems for large
manufacturing companies
Application Characteristics
Team Size 50

Team Type Distributed, often multi-organizational

Failure Risks Major business losses

Clients Multiple success-critical stakeholders

Requirements Some parts relatively stable, others volatile, emergent

Architecture Mostly provided by small number of COTS packages

Refactoring More expensive, with mix of people skills

Primary objective Rapid value increase, dependability, adaptability

46
Step 1: Project Risk Ratings
• Environmental
– E-Tech: uncertainties with agent-based systems
– E-Coord: many separate suppliers and distributor networks

• Agile
– A-Scale: large development team
– A-YAGNI: stable components
– A-Churn: stable workforce

• Plan-driven
– P-Change: rapid changes in technology, organizations, market
conditions
– P-Speed: need to deliver quickly to keep pace with competition
– P-Emerge: changing requirements through user experience

47
Step 2: Compare Risks
• Plan-driven risks dominate
• Select risk-based agile approach
• Based on culture and environment
– Rapidly changing environment
– Speed to keep up with competition
– Emerging requirements
– Stable workforce
– Not financially critical marketplace

• Bypass Step 3

48
Home Grounds Polar Chart

49
Step 4a: Risk Resolution Strategies
• Environmental risks
– E-Tech
• Risk-driven technology prototypes
• Technology and COTS watch
– E-Coord
• CRACK representatives
• Stakeholder win-win
– E-Cmplx
• Architecture determination
• Early commitments on validated interfaces

50
Step 4a: Risk Resolution Strategies
• Agile risks
– A-Scale
• Longer iterations as size/complexity grows
– A-YAGNI
• Balance with high-level change-prescient architecture
• Design patterns

– A-Churn
• Project completion bonuses
• Personnel backups; pair programming

51
Step 4a: Risk Resolution Strategies
• Plan-driven risks
– P-Change
• Short iterations
• Balanced simple design and change-prescient architecture
– P-Speed
• Short iterations
• Pair programming
– P-Emerge
• Short iterations
• Dedicated customer

52
Step 4b: System Development
• Three participant groups
– Operational stakeholders
• CRACK representative from each operation
– Manufacturing
– Supplier
– Distributor

– Risk/opportunity management team

• Project manager and senior level staff
• Watch for risks and take action if necessary
– Agile feature teams
• Software developers

53
Step 4b: System Development
• Three phased development
– Inception
• Build the team
• Develop shared vision
• COTS evaluation and key feature prototyping

– Elaboration
• Overall operational concept
• Establish key COTS
• Increment 1 definition

– Incremental implementation
• Develop successive increments
• Deal with emerging risks/opportunities
• Plan next increment; possibly backtrack

54
Step 5 – Monitor and Track Progress
• Adjust plans as necessary
• Identify opportunities to improve customer
value
• Process improvement

55
Road Map
• Introduction
• What are Discipline and Agility?
• Misconceptions
• Contrasts and Home Grounds
• Five Critical Factors
• The Risk-Based Method
• Case Study
• Personal Experiences
• Summary and Wrap-Up

56
Cargill
• Iterative process model for development
• Estimations based on analogy
– Excel spreadsheet
– No data repository
• Discipline aspects
– Business analysts elicited/defined requirements
• Use cases and scenarios
– Software developers produced tech specs.
– Code inspections
– Formal weekly status meetings

57
Cargill
• Agile aspects
– Stand up daily status meetings
– Pair programming
– Refactoring
– Short release schedules
– Not all tasks required documentation
– Lots of tacit knowledge

58
Arrowpoint
• CMMI Level 3 certified Naval site
• Discipline aspects
– MIL-STD-498
– Weekly status meetings
• Agile aspects
– Pair programming
– Write test cases first

59
Garmin
• Auto OEM
– Very little documentation
– Pair programming
– Tacit knowledge
– Quality engineers wrote test cases
– Moving toward AutoSPICE certifications
• Marine
– More documentation
– Software specification complete before development

60
Road Map
• Introduction
• What are Discipline and Agility?
• Misconceptions
• Contrasts and Home Grounds
• Five Critical Factors
• The Risk-Based Method
• Case Study
• Personal Experiences
• Summary and Wrap-Up

61
Top Six Conclusions
• No silver bullets
• Home grounds for each method
• Trends toward balance of both
• Balanced methods are emerging
• Build your method up
• Focus less on methods

62
No Silver Bullets
• Fred Brooks’ software engineering difficulties
– Complexity
– Conformity
– Changeability
– Invisibility
• Some techniques have achieved “lead bullet”
status
– Can solve some part of software engineering
problem
– Some agile and plan-driven elements are lead bullets

63
No Silver Bullets (2/4)
• Plan-driven methods
– Thrive on
• Conformity
• Invisibility
• Investment in documentation
– Founder on
• Changeability (documentation rework)
• Complexity of systems-of-systems and enterprise
integration

64
No Silver Bullets (3/4)
• Agile methods
– Thrive on
• Changeability
• Invisibility
– Founder on
• Complexity
– Scaling up
• Conformity
– Interfaces
– Product lines

65
No Silver Bullets (4/4)
• Cannot assume that lead bullet this year will
still be one next year
• Lead bullets founder on changeability
– Sequential waterfall model
– Pre-WYSIWYG word processing
– Pre-web book sales management systems
– Fixed-contract software management models
– Static domain and enterprise architectures

66
Home Grounds For Each Method
• Home grounds polar chart
• Critical factors
– Size
– Criticality
– Culture
– Personnel
– Dynamism

67
Trends Toward Balance of Both
• In the past projects were at the extremes
• Projecting the future
– Higher rates of change on large projects
– Expense associated with maintaining plans
– Agile alone cannot surmount complexity and
conformity “werewolves”
– Premium on methods to be situation-tailorable

68
Balanced Methods Are Emerging
• Risk-based method
• Crystal orange
• Lean development
• DSDM
• FDD
• New, lighter Rational Unified Process versions

69
Build Your Method Up
• Starting with full plan-driven method requires
experienced personnel
• Tailoring down wastes time and money
• Start with minimal set of techniques
• Add extras where clearly justified

70
Focus Less On Methods
• Focus more on
– People
– Values
– Communication
– Expectations management
• Good people and teams trump other factors
• People factors dominate other software cost
and quality drivers
– COCOMO II: 10:1 effects of personnel factors

71
Focus Less On Methods (2/5)
• People
– Of the people, by the people, for the people
– Separation of concerns
– Reduce the distance between the “user”

72
Focus Less On Methods (3/5)
• Values
– Reconcile different stakeholders
– Win-win outcome
– Outward vs. inward focus
• Higher value per unit cost to stakeholders
– Prioritization and responding to changes

73
Focus Less On Methods (4/5)
• Communication
– “I’ll know it when I see it” (IKIWISI) syndrome
– Development across organizational boundaries
• Map boundaries even
– Shared system vision and strategy
– Increasing pace of change raises stakes of
communication

74
Focus Less On Methods (5/5)
• Expectations management
– Difference between successful and troubled project
is most often difference between good and bad
expectations management
– Desire to please
– Avoid confrontation
– Lack of confidence in ability to predict
– Process mastery, preparation, courage

75
Steps Toward Achieving Balance
• Self-assessment
– Where is organization currently?
– Where do success-critical stakeholders want it to go?
– How will it cope with future trends?
– Consult with key stakeholders
– Consider future trends
• Increased pace of change
• Concern with software dependability
• Gap between supply and demand of level 2 and 3 people

76
Questions?

77
Bibliography
Boehm, Barry, & Turner, R. 2003, Balancing Agility and Discipline: A
Guide for the Perplexed, Addison-Wesley, Boston.

78