Balancing Agility and Discipline. Report by Brad Kaufmann

Transcription

1 Balancing Agility and Discipline Report by Brad Kaufmann 1

2 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

3 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

4 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

5 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

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

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

8 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

9 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

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

11 Characteristics Strengths Comparability Repeatability Minimize loss of personnel Drawbacks Impede innovation Checklist mentality Documentation generators 11

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

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

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

15 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

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

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

18 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

19 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

20 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

21 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

22 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. 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. 22

23 What Are the Realities? Agile methods Misconception Agile methods do not plan. Require uniformly talented people. Can make the slope of the cost-tochange vs. time curve uniformly flat. YAGNI is universally safe assumption and will not alienate customers. 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-tochange vs. time curve. YAGNI helps handle unforeseeable change, but is risky when change is foreseeable. 23

24 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

25 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

26 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

27 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

28 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

29 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

30 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

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

32 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)

33 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

34 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)

35 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

36 The Cockburn Scale Level Levels of Software Method Understanding and Use Characteristics 3 Able to revise a method to fit unprecedented new situation. 2 Able to tailor a method to fit precedented new situation. 1A 1B With training can perform discretionary method steps, can become level 2 with experience. 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

37 Culture Factor Plan-driven Thrives on order Agile Thrives on chaos Range (% thriving on chaos vs. order)

38 When To Use Which Method? 38

39 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

40 Overview of The Risk-Based Method A Tailorable Method for Balancing Agile and Plan-Driven Methods Step 1 Step 2a Step 2b Step 3 Step 4 Step 5 Rate project s environmental, agile, plan-driven risks. If agility risks dominate plan-driven risks, go risk-based plandriven. If plan-driven risks dominate agility risks, go risk-based agile. If parts of application satisfy 2a and others 2b, go risk-based agile in agile parts and risk-based plan-driven elsewhere. Establish overall project strategy by integrating risk mitigation plans. Monitor progress and risks/opportunities, readjust balance and process as appropriate. 40

41 The Risk-Based Method Process Flow 41

42 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

43 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

44 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

45 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

46 Case Study: SupplyChain.com Turnkey agent-based supply chain management systems for large manufacturing companies Team Size 50 Application Characteristics Team Type Failure Risks Clients Requirements Architecture Refactoring Primary objective Distributed, often multi-organizational Major business losses Multiple success-critical stakeholders Some parts relatively stable, others volatile, emergent Mostly provided by small number of COTS packages More expensive, with mix of people skills Rapid value increase, dependability, adaptability 46

47 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

48 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

49 Home Grounds Polar Chart 49

50 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

51 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

52 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

53 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

54 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

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

56 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

57 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

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

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

60 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

61 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

62 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

63 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

64 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

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

66 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

67 Home Grounds For Each Method Home grounds polar chart Critical factors Size Criticality Culture Personnel Dynamism 67

68 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

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

70 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

71 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

72 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

73 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

74 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

75 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

76 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

77 Questions? 77

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