1. Discipline vs. Agility
Report by Jason Cradit

2. For Review What are we talking about and who cares?
What is discipline?
What is agility?
What are the misconceptions?
Contrasts and home grounds
Five critical factors
Risk-based method
Projects from my past
Closing remarks

3. What Are We Talking About?
Agile? Discipline? Perplexity?
Project management
Getting things done
How
Good practices
Perplexity on:
Each have multiple definitions
Distinguishing from use and misuse
Overgeneralization based on most visible

4. Who Cares? Barry Boehm Richard Turner You – Future KU Graduates
B.A. Harvard 1957
M.S. UCLA 1961
Ph.D. UCLA 1964
Richard Turner
B.A. Huntingdon 1975
M.S. U of Southwestern Louisiana 1977
D.Sc. George Washington University 2002
You – Future KU Graduates
Barry Boehm
All degrees in Mathematics
Program –Analyst at General Dynamics
DoD
IEEE
Contributer to COCOMO and spiral methods
Richard Turner
Mathmatics
Computer Science
Engineering Management

5. For Review What are we talking about and who cares?
What is discipline?
What is agility?
What are the misconceptions?
Contrasts and home grounds
Five critical factors
Risk-Based method
Projects from my past
Closing remarks

6. Where Did Discipline Come From?
Government
DoD guidance documents
MIL-STD-1521
DoD-STD-2167
MIL-STD-498
Large commercial companies
Internal standards of use
IBM
Hitachi
Siemens
Pg 10
Motorola
General Electric – Six Sigma

7. What is Disciplined? Adjectives: Methods: Predictive Process
Plan-driven
Documentation
Systematic
Methods:
Software capability maturity mode
IEEE
Cleanroom
Pg 14/15
Software capability maturity model:
Ad hoc, chaotic
Repeatable
Defined
Managed
Optimizing
IEEE document standards
Cleanroom
Statistical process control
Six Sigma

8. What is Disciplined? Plan-Driven Concepts: Process improvement
Process capability
Organizational maturity
Process group
Risk management
Verification
Validation
Software system architecture
Improve
Process
Define
Process
Control
Process
Measure
Process
Perform
Process
Pg 12/13
Process improvement
Quality management from guys like Deming
Process capability
product planned results – defined metrics for predictability and measurement
Organization maturity
build processes, use processes, get better
Process group
Collection of specialists that facilitate the definition, maintenance and improvement of the processes
Risk Management
Organized process to identify uncertainties that might cause harm or loss.
Quantifies the risk
Verification
Confirms the product reflects the requirements (fit for purpose)
Validation
Confirms the fitness or worth of a work product for it’s operational mission (fit for use)
Software system architecture
Defines a collection of software system components,connectors, and constraints
Stakeholders
Need Statements

9. Quality in Discipline Specification and process compliance
Requirements/design/build
Gage success of how we met the plan
Estimated Cost
Estimated Time
Estimated Scope
What quality means in a plan-driven environment

10. For Review What are we talking about and who cares?
What is discipline?
What is agility?
What are the misconceptions?
Contrasts and home grounds
Five critical factors
Risk-based method
Projects from my past
Closing remarks

11. Where Did Agile Come From?
Outgrowth of rapid prototyping
Programming more of a craft than a process
Dehumanization of plan-driven processes
Problem:
After a long development cycle the product doesn’t meet expectations
Chaordic = chaos + order

12. What is Agile? Read the Manifesto: We have come to value
Individuals and interactions over process and tools
Working software over comprehensive documentation
Customer collaboration over following a plan
That is, while there is value in the items on the right, we
value the items on the left more.

13. What is Agile? Adjectives: Methods: Iterations Test-driven
Customer collaboration
Methods:
eXtreme Programming (XP)
Adaptive Software Development
Feature Driven Development
Every 24
hours
Pg 21\22
eXtreme Programming
most well know method
Experienced gained developers
Follow all practices as defined
Adaptive Software Development
Philosophical and practical approach using iterative development
Feature based planning
Customer focus group reviews
Feature Driven Development
Light wieght architecturally based process
Design by feature
Build by feature
UML -

14. What is Agile? Agile Concepts: Embrace change
Fast cycle/frequent delivery
Simple design
Refactoring
Pair programming
Retrospective
Test-driven development
Pg 18\19
Embrace change
-change as an alley
Fast cycle/frequent delivery
-many releases with short time spans
-prioritize
-value now
Simple design
-YANGI
-Design for battle not war
Refactoring
-Just in time design
-Remove duplication
Pair programming
Retrospective
-Iteration based review of effectiveness
-estimates of future iterations
Tacit knowledge
-update information in participates head not document
Test-driven development
-iterations are tested incrementally

15. Quality in Agile Customer satisfaction Is the product fit for use?
Is the product fit for purpose?
Is the customer happy with the product?

16. Sounds Great, Why Not Use It?
Agile has trouble scaling
Size of project
Size of group
Cost can go up with group size
Plan-driven has trouble trimming
Heavy documentation
Late cycle delivery
No silver bullet
Pg 20

17. What Are The Key Differences?
Plan-Driven value process over people
Agile values people over process
Document, Document, Document – chants the disciplined
Waterfall vs. Cups-of-water

18. For Review What are we talking about and who cares?
What is discipline?
What is agility?
What are the misconceptions?
Contrasts and home grounds
Five critical factors
Risk-based method
Projects from my past
Closing remarks

19. What are the misconceptions?
Plan-Driven Methods
Agile
Plan-driven methods are uniformly bureaucratic
Agile methods don’t plan
Having documented plans guarantees compliance with plans
Agile methods require uniformly talented people
Plan-driven methods can succeed with a lack of talented people
YAGNI is a universally safe assumption, and won’t alienate your customers
YANGI – plan for battle not war – simple design
Silver bullet – that you have to pick one

20. Do What Makes Sense! CMM for Software like the dictionary Tool box
Use the words that make the desired point
Don’t use all the words
Tool box
An organization should have the repository of “plug-compatible” process assets
Philippe Kruchten from Rational
Pg 23

21. For Review What are we talking about and who cares?
What is discipline?
What is agility?
What are the misconceptions?
Contrasts and home grounds
Five critical factors
Risk-based method
Projects from my past
Closing remarks

22. Contrasts and Home Grounds
Home grounds depend on characteristics
Application characteristics
Management characteristics
Technical characteristics
Personnel characteristics
Home grounds are where the differing methods perform best

23. Application Characteristics Contrasts and Home Grounds
Primary goals
Rapid value and responsiveness to change
Plan-driven goals are predictability, stability, and high assurance
Size
Agile works best on smaller projects
Plan-driven is a necessity on large complex projects
Environment
Agile approaches are comfortable in high-change environments with some risks
Plan-driven methods need stability

24. Management Characteristics Contrasts and Home Grounds
Customer relations
Agile encourages a dedicated collocated customer
Plan-driven methods depend on contracts and specifications
Agile methods use working software to build trust
Plan-driven methods use established process maturity
Planning and control
Agilists see planning as a means to an end
Plan-driven methods use plans to communicate and coordinate
Agile is “planning driven,” rather than “plan-driven”
Project communication
Agile methods depend on tacit knowledge
Plan-driven approaches use explicit, documented knowledge

25. Technical Characteristics Contrasts and Home Grounds
Requirements
Agile uses informal, user-prioritized stories as requirements
Plan-driven methods prefer specific, formalized requirements
Development
Agile advocates simple design
Plan-driven methods advocate architecture to anticipate changes
Testing
Agile methods develop tests before code, and test incrementally
Plan-driven methods test to specifications

26. Personnel Characteristics Contrasts and Home Grounds
Customers
Both methods need CRACK performers – Collaborative, Representative, Authorized, Committed, and Knowledgeable
Plan-driven does not require them full-time
Developers
Agile developers need more than technical skills
Plan-driven methods need fewer highly talented people than agile
Culture
Agilists like many degrees of freedom
Plan-driven people need clear process and roles

27. For Review What are we talking about and who cares?
What is discipline?
What is agility?
What are the misconceptions?
Contrasts and home grounds
Five critical factors
Risk-based method
Projects from my past
Closing remarks

28. Five Critical Factors Factors to measure: Personnel Size Dynamism
Criticality
Culture

29. Five Critical Factors Personnel – Based on Cockburn scale Agile
Requires continuous presence of critical mass of scarce Cockburn Level 2 or 3 experts. Risky to use non-agile Level 1B people.
Plan-Driven
Needs a critical mass of scarce Cockburn level 2 and level 3 experts during project definition, but can work with fewer later in the project – unless the environment is highly dynamic. Can usually accommodate some Level 1B people.
- Range: (% level 1B / % level 2-3, Agile to Plan-driven)
0%1B / 35% Level 2 and 3
10%1B / 30% Level 2 and 3
20%1B / 25% Level 2 and 3
30%1B / 20% Level 2 and 3
40%1B / 15% Level 2 and 3

30. Levels of Software Method Understanding and Use
Cockburn Scale
Levels of Software Method Understanding and Use
Level
Characteristics 3
Able to revise in unprecedented situation 2
Able to tailor a method to fit new situation 1A
With training can perform discretionary steps, can train to level 2 1B
With training can perform basic procedural steps -1
May have technical skills but unable or unwilling to collaborate
koh-burn

31. Five Critical Factors Size Agile Plan-Driven
Well matched to small products and teams
Plan-Driven
Methods evolved to handle large products and teams – hard to tailor down
- Range: (Number of personnel) 3 10 30
100
300

32. Five Critical Factors Dynamism Agile Plan-Driven
Simple design and continuous refactoring are excellent for highly dynamic environments, but a source of potentially expensive rework for highly stable environments.
Plan-Driven
Detailed plans and Big Design Up Front excellent for highly stable environments, but a source of expensive rework for highly dynamic environments.
- Range: (% Requirements-changing / month) 50 30 10 5 1

33. Five Critical Factors Criticality Agile Plan-Driven
Untested on safety-critical products
Potential difficulties with simple design and lack of documentation
Plan-Driven
Methods evolved to handle highly critical products
Hard to tailor down to low-criticality products
- Range: (Loss due to impact of defects)
Comfort
Discretionary Funds
Essential Funds
Single Life
Many Lives

34. Five Critical Factors Culture Agile Plan-Driven
Thrives in a culture where people feel comfortable and empowered by having many degrees of freedom.
Plan-Driven
Thrives in a culture where people feel comfortable and empowered by having their roles defined by clear policies and procedures.
- Range: (% Thriving on chaos vs. order) 90 70 50 30 10

35. Walking the Line – When to Use What
Personnel
Agile
Requires continuous presence of critical mass of scarce Cockburn Level 2 or 3 experts. Risky to use non-agile Level 1B people
Plan-Driven
Needs a critical mass of scarce Cockburn level 2 and level 3 experts during project definition, but can work with fewer later in the project – unless the environment is highly dynamic. Can usually accommodate some Level 1B people.
Dynamism
Simple design and continuous refactoring are excellent for highly dynamic environment, but a source of potentially expensive rework for highly stable environments
Detailed plans and Big Design Up Front excellent for highly stable environment, but a source of expensive rework for highly dynamic environments.
Culture
Thrives in a culture where people feel comfortable and empowered by having many degrees of freedom.
Thrives in a culture where people feel comfortable and empowered by having their roles defined by clear policies and procedures.
Size
Well matched to small products and teams
Methods evolved to handle large products and teams – hard to tailor down
Criticality
Untested on safety-critical products.
Potential difficulties with simple design and lack of documentation
Methods evolved to handle highly critical products.
Hard to tailor down to low-criticality products

36. For Review What are we talking about and who cares?
What is discipline?
What is agility?
What are the misconceptions?
Contrasts and home grounds
Five critical factors
Risk-based method
Projects from my past
Closing remarks

37. Risk-Based Method Use to determine balance between methods
A Tailorable Method for Balancing Agile and Plan-Driven Methods
Step1:
Rate the projects environmental, agile and plan-driven risks. If uncertain about ratings, buy information via prototyping, data collection, and analysis.
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 the application satisfy 2a and others 2b, architect the application to encapsulate the agile parts. Go risk-based agile in the agile parts and risk-based plan-driven elsewhere.
Step 4:
Establish an overall project strategy by integrating individual risk mitigation plans.
Step 5:
Monitor progress and risks/opportunities, re-adjust balance and process as appropriate.

38. Risk-Based Method Step1. Risk Analysis Rate risks Uncertain about
rating
Buy info
Step 2.
Risk
Comparison
Compare
risks
Step4.
Tailor Life Cycle
Go risk-based
agile
Go risk-based
plan-driven
Step 3.
Architecture
Analysis
Blend methods
Architect application to
encapsulate agile parts
Step 5.
Execute and Monitor
Deliver according to
strategy
Monitor and readjust as
appropriate
Tailor process

39. Risk-Based Method Categories of risk Environmental Agile Plan-driven
Risks that results from the project’s general environment
Agile
Risks that are specific to the use of agile methods
Plan-driven
Risks that are specific to the use of plan-driven methods
Pg 102

40. Risk-Based Method Environmental risks:
Risks that result from the projects general environment
E-Tech - Technology uncertainties
E-Coord - Many diverse stakeholders to coordinate
E-Cmplx – Complex system of systems

41. Risk-Based Method Agile risks
Risks that are specific to the use of agile methods
A-Scale – Scalability and criticality
A-YANGI – Use of simple design or YANGI
A-Churn – Personnel turnover or churn
A-Skill – Not enough people skilled in agile methods

42. Risk-Based Method Plan-driven risks
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

43. SupplyChain.com Turnkey supply chain management systems for
manufactures
Team size: 50
Team type: Distributed; often multi-organization
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 package
Refactoring: More expensive, with mix of people skills
Primary objective: Rapid value increase, dependability, adaptability
pg108
Agile:
Volatile requirements
Rapid value
Plan-driven:
Criticality
Scalability

44. SupplyChain.com Step 1 - Rate the project risks Environmental
E-Tech – Uncertainties with agent-based system
E-Coord – Multiple suppliers and distributors
Agile risks
A-Scale – 50 person development team
A-YAGNI – Many stable components
A-Churn – Stable workforce
Plan-Driven risks
P-Change – Changing markets, technology and organizations
P-Speed – High speed competition
P-Emerge – Requirements due to change
Pg108
Stable also negative as people get comfortable

45. SupplyChain.com
Review chart

46. SupplyChain.com Use a blended approach based in agile methods!
Step 2 - Compare Agile and Plan-Driven Risks
Agile methods less risky
Scalability – 50 person development team
Criticality – Loss due to defects, medium
Plan-driven risks not deal breakers
Rapid-change
Emerging requirements
Use a blended approach based in agile methods!
No need for Step 3

47. SupplyChain.com Step 4a – Individual Risk Resolution Strategies
Environmental
Technical risks
Prototype and benchmark agent technologies
Coordination risks
Add CRACK representatives

48. SupplyChain.com Step 4a – Individual Risk Resolution Strategies
Agile risks
A-Scale – break development teams into smaller teams
YANGI risks
Encapsulation – hide-information technique
Churn risks
Pair-programming and successful completion bonus
Plan-driven risks
Mitigated based on using more agile techniques

49. SupplyChain.com Step 4b – System development Three participant groups
Operational stakeholders
Representatives from each operation
Manufacturing
Supplier
Distributor
CRACK performers
Risk\opportunity management team
Project managers
Senior members
See something – do something about it
Agile teams
Developers doing the work
Manufacturing representative
● Supplier representative
● Distributor representative
● CRACK performers
Risk
● Project manager
● Three senior staff members
● Take extra care to watch out for risk and take
action if necessary

50. SupplyChain.com Step 4b - Three-phase development Inception
Build team
Build vision
Elaboration
Establish overall operational concept
Establish key COTS
Define first increment
Implementation increments
Agile teams develop successive increments
Develop\test
pg120

51. For Review What are we talking about and who cares?
What is Discipline?
What is Agility?
What are the misconceptions?
Contrasts and Home Grounds
Five critical factors
Risk-Based method
Projects from my past
Closing remarks

52. Projects from my past PM1 to PM2
Access forms with Access DB to Web with SQL
Forms for revenue – project status – CRM
ISO 9000 system
Mythical agility failed
No documentation
Poor communication
No checks

53. Projects from my past MJHarden.com
Build new web presence for MJ Harden
Flash intro – new content – new navigation
No function, just market
Successful plan-driven project
Document requirements
Froze requirements
Developed
Tested - functions and design(marketing)
Bug-fix
Change management
Deploy

54. For Review What are we talking about and who cares?
What is Discipline?
What is Agility?
What are the misconceptions?
Contrasts and Home Grounds
Five critical factors
Risk-Based method
Projects from my past
Conclusions

55. Conclusions No silver bullet Plan-driven has issues Agility has issues
Late value recognition
Documentation heavy
Agility has issues
Scaling up – ineffective in large projects
Requires skilled personnel
152

56. Conclusions Remember the home grounds Personnel – Skilled workers
Criticality – Loss due to defects
Size – Number of personnel
Culture - % Thriving on chaos vs. order
Dynamism - % Requirements - change/month

57. Conclusions Future projects will need both Agility and Discipline
Past shows no intermingling between home grounds
Future shows more combination of methods
There will always be huge projects and small projects
Large projects will require large rate of change
Small projects are scaling up

58. Conclusions Balanced methods are emerging
Risk based method only one way
Crystal Orange
DSDM
FDD
Lean Development

59. Conclusions Build your Method up Don’t tailor it down
Start with minimal agile techniques
Build as required
Don’t tailor it down
Starting with full plan-driven requires high experienced personnel
Tailoring waists resources and time

60. Conclusions Focus less on methods
More on people
Values
Communication
Expectations management
Good people and teams trump any other factors
– Reduce distance between developers and users

61. Conclusions

62. Questions?

63. Bibliography
Boehm, Barry, and Richard Turner, and . Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley Professional, 2003.