Discipline vs. Agility Report by Jason Cradit

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

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

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

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

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

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

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

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

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

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

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.

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 -

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

SupplyChain.com Review chart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusions

Questions?

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