SECRETS OF THE AGILE SCALING GURUS

Transcription

1 SECRETS OF THE AGILE SCALING GURUS Tools for Understanding Software Size Construx

2 COPYRIGHT NOTICE These presentation materials are 2017 Construx Software Builders, Inc. All Rights Reserved. No part of the contents of this presentation may be reproduced or transmitted in any form or by any means without the written permission of Construx Software Builders, Inc. Construx

3 STEVE MCCONNELL Construx NE 8th Street, Suite 1350 Bellevue, WA (866) Construx

4 CONSTRUX S FIRST EXPERIENCE WITH SCALING Construx

5 Early Construx Consulting Engagement 5 The year is 1996 A startup company had grown from literally 2 guys in a garage to a technical staff of about 50 The rest is history (and a bit clichéd)

6 WHAT I MEAN BY AGILE SCALING Construx

7 Agile Scaling (Really Agile Adoption ) 7 Propagating Agile Practices across standalone projects This would is not I would That s the not focus call call this What of this I this Talked Agile talk Agile About Scaling Last Adoption Year!

8 Agile Scaling (True Agile Scaling ) 8 Conducting a Large Project using Agile practices All teams contribute to single code line This is the focus of this talk

9 Agile Scaling ( Federated Solutions ) 9 Many org s need this: This is also the focus of this talk

10 Construx Secrets of the Agile Scaling Gurus: Tools For Understanding Scaling

11 Talk Outline: Tools for Understanding Scaling 11 Four Factors Lifecycle Model, Focusing on Size Cocomo II: What Got You Here Won t Get You There Activities and Intellectual Phases

12 TOOL #1 FOUR FACTORS LIFECYCLE MODEL Construx

13 Understanding Software Projects Lectures 13

14 The Four Factors Lifecycle Model 14 Size Human Variation Uncertainty Defects

15 How to Think About Software Size 15 Understanding the ins and outs of Software Size is important to understanding software project dynamics, period The following section of the talk describes dynamics associated with Software Size, i.e., performing software development work At Scale

16 Large Projects Are Difficult!

17 Project Outcomes by Project Size 17 Percentage 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% On Time or Early Late Failed 0% 10 FP LOC 100 FP 5K-10K LOC 1,000 FP 50K-100K LOC 10,000 FP 500K-1M LOC 100,000 FP 5M-10M LOC Data from Economics of Software Quality, Capers Jones, 2012

18 What s Difficult About Large Projects? 18 Prioritizing hundreds of requirements/backlog items Tracking dependencies across multiple teams Coordination of deliverables Keeping stakeholders involved Sharing progress / status with the business Making best use of the resources / specialization

19 Avoid Scaling if Possible!

20 Project Outcomes by Project Size 100% 90% 80% 70% Reason #1 20 Percentage 60% 50% 40% 30% 20% 10% On Time or Early Late Failed 0% 10 FP LOC 100 FP 5K-10K LOC 1,000 FP 50K-100K LOC 10,000 FP 500K-1M LOC 100,000 FP 5M-10M LOC Data from Economics of Software Quality, Capers Jones, 2012

21 Error Rates and Size 120 Error Rate by Size Reason # Defects / KLOC Low Error Rate High Error Rate Average Error Rate 20 - <2 KLOC 2-16 KLOC KLOC KLOC 512+ KLOC

22 Productivity by Project Size 30,000 Productivity by Size Reason # ,000 LOC / Staff Year 20,000 15,000 10,000 High LOC/Staff Year Nominal Low LOC/Staff Year 5,000-1 KLOC 10 KLOC 100 KLOC 1,000 KLOC 10,000 KLOC

23 Schedule (Months) Does Scaling Even Work??? (Putnam s Data) Team Size Schedule Effort Effort (Staff Months) Reason #4 23 Business systems projects of ~100KLOC

24 Agile Development Does Not Make Scaling More Difficult

25 Why Do Organizations Want to Scale Agile? 25 In the old days, even small projects were problematic Organizations feel they have been more successful on small projects with Agile than they were previously They want to extend that Agile Goodness to their larger projects The fact that small projects are more successful than they used to be makes scaling easier, not harder

26 Corollaries 26 High performance small projects support scaling to larger projects Low performance small projects undermine large projects, making them more difficult, or impossible

27 Find a Problem More General Than Your Problem from How to Solve It, by G.Polya

28 The problem of Scaling (Software Size) applies across more dimensions than Agile vs. non Agile 28

29 Parallel Small to Large Pattern Companies 29 If a company s software does well, the software will grow over time At which point, the larger projects will struggle more than the smaller projects did

30 Parallel Small to Large Pattern Pilot Projects 30 Pilot projects tend to be small A successful pilot leads to larger scale rollout The larger scale roll outs are often problematic

31 Parallel Small to Large Pattern New Technology 31 Projects in new technologies start small If they are successful, projects attempted with the new technology will become larger The larger projects are often problematic, even though the technology is maturing E.g., internet development, mobile development, etc.

32 Parallel Small to Large Pattern Methodologies 32 If a methodology does well on small projects, people will want to apply it to large projects At which point, the challenges increase This leads us to Agile today Scrum vs. SAFe, DaD, LeSS, Nexus, etc.

33 A Key Challenge of Software Scaling is Non-Linearity of Software Project Challenges

34 Software Scaling s X times Y Problem 34 A Large Project is More Than Just X * A Small Project Some attributes (challenges and activities) scale linearly Some attributes scale non linearly

35 Software Scaling s X times Y Problem 35

36 Larger Projects are not Just, Multiply by X 36

37 Challenges Change at Different Scales 37 New challenges emerge at larger scale: Growth of a company s software over time Large rollout after successful pilot project Larger projects with new technology Larger Agile projects These are not just bigger lifts of the same things

38 Problem vs. Solution 38 If elements of the problem scale non linearly, elements of the solution need to scale non linearly too Understanding how the problem scales non linearly will inform creation of the non linear solution

39 Fundamental Non-Linear Concept: Software s Diseconomy of Scale

40 Software has a Diseconomy of Scale 40 Bigger project = higher unit cost On larger project, per person productivity decreases This is a diseconomy of scale

41 Software s Diseconomy of Scale 41 Unit Cost Exponential? Diseconomy Real of Scale Magnitude of Diseconomy No Increase Unit Cost of Scale Project Size Project Size

42 Diseconomy of Scale as a Step Function

43 McConnell s Diseconomy of Scale 43 Diseconomy is essentially about coordination overhead Specifics of the coordination depend on the nature of the project Management Requirements Architecture Process Higher defect rates and more defect correction effort due to the above factors

44 McConnell s Diseconomy of Scale 44 Diseconomy of scale in software is a step function The steps are the sizes at which additional levels of coordination need to be added

45 Step Function (Steps at Project Staff Sizes of Approximate Powers of 7) 45 ~7 One leader, scrum master or self managed ~50 Multiple leads, scrum masters, test specialists, group manager, architect, director ~ Leads, scrum masters, test specialists, group managers, dev managers, test managers, architects, chief architect, directors, VP

46 Coordination 46 Note: it is not just the amount of work that needs to be done on larger projects, but the kind of work and how the work is structured

47 McConnell s Diseconomy of Scale 47 Productivity Output 1 ~7 ~50 ~ Team Size

48 McConnell s Diseconomy of Scale 48 The fact that it s a step function is significant This implies it s less risky to increase team size within certain ranges, i.e., diseconomy of scale is more about the steps than about incremental size differences within ranges

49 Diseconomy of Scale and Agile Scaling 49 Problem #1 Planning large projects as though diseconomy of scale does not apply (i.e., Large Project = X * Small Projects) Problem #2 Not accounting for the step function (discontinuities) as we approach and cross project size boundaries (Putnam s data)

50 Holy Grail: Large Project = Series of Small Projects

51 Parallel Series of Small Projects? 51 Can you partition the work to run a large project as a parallel series of small projects? This ancient suggestion goes back, at least, to The Mythical Man Month

52 Conway s Law 52 Conway s Law: The structure of a system will reflect the structure of the organization that built it For the parallel small projects strategy to work, the small projects have to be partitioned, i.e., truly independent of each other Per Conway s law, the software architecture must support the human organization, and vice versa

53 Conway s Law, Partitioning, and Agile Philosophy 53 This requires a focus on software architecture before most of the human teams are staffed and organized which is considered by many to be an unnatural fit with Agile projects

54 Conway s Law, Partitioning, and Agile Philosophy 54 Even if you can get early architecture work accepted culturally, it s still challenging to do successfully But it s probably still worth attempting (if you can sell it culturally and plan for being only partially successful in the attempt)

55 Summary of Size Large projects are difficult Avoid scaling if possible Agile practices do not make large projects more difficult Solving the general problem of how to conduct a large project will also solve the problem of how to conduct a large Agile project 55 Software project challenges scale non linearly Software has a diseconomy of scale Software s diseconomy of scale is a step function The holy grail in software is to run a large project as a series of partitioned small projects This is difficult to accomplish in practice

56 Summary of Size Large projects are difficult Avoid scaling if possible Agile practices do not make large projects more difficult Solving the general problem of how to conduct a large project will also solve the problem of how to conduct a large Agile project 56 Software project challenges scale non linearly Software has a diseconomy of scale Software s diseconomy of scale is a step function The holy grail in software is to run a large project as a series of partitioned small projects This is difficult to accomplish in practice

57 TOOL #2 COCOMO II: WHAT GOT YOU HERE WON T GET YOU THERE Construx

58 Cocomo II and Size Small Project 58

59 Cocomo s Scaling Factors 59 Five Cocomo Scaling Factors increase in importance as project size increases: Precedentedness Process Maturity Architecture and Risk Resolution Requirements Flexibility (aka Development Flexibility) Team Cohesion

60 Cocomo II and Size Small Project 60 No Scaling Factor is in the Top Half in Influence

61 Cocomo II and Size Large Project 61 Every Scaling Factor is in the Top Half in Influence

62 62 The factors that challenge projects change disproportionately (non linearly) as project size increases

63 Common Response to Challenges on Larger Than Usual Projects 63 Organizations typically try to repeat the practices that made them successful on small projects harder, with more commitment, or with more fidelity on large projects

64 Common Response to Challenges on Larger Than Usual Projects 64 This is a natural response, but it doesn t work, because the factors that matter the most change at scale

65 In Other Words 65 Success on small projects does not prepare organizations to succeed on large projects What got you here won t get you there

66 Non-Linearity of Precedentedness

67 Precedentedness 67 Precedentedness : How familiar is the application and technology being developed? This doesn t matter much on small projects It becomes the third most important factor on large projects Companies struggle when they take on projects that are too large to do in unprecedented areas (This is an example of how Uncertainty and Size interact in the Four Factors Lifecycle Model) Size Uncertainty Human Variation Defects

68 Non-Linearity of Architecture and Risk Resolution

69 Architecture and Risk Resolution 69 Architecture and Risk Resolution : Number and severity of identified risks Extent of activities focused on risk management Extent of architecture work Staff available to support architecture work Size Uncertainty Human Variation Defects

70 Architecture and Risk Resolution 70 Small projects can succeed by the seat of the pants in these areas Large projects need much more explicit focus and staff capability to be successful

71 Note the Interaction With Conway s Law 71 Sometimes the human organization imposes constraints on the software architecture, e.g., Requirement for geographically distributed team Organizational structure arising from acquisitions Etc. These constraints can be larger liabilities for large projects than a small ones

72 Bottom Line on Architecture and Risk Resolution 72 Companies struggle when they take on projects where the architecture and risk profiles are too challenging for the size of project

73 Non-Linearity of Requirements Flexibility

74 Requirements Flexibility 74 Requirements Flexibility : The need to conform to preestablished requirements, i.e., how rigid and exact the requirements are

75 Typical System Growth & Maturity 75 Greenfield projects (version 1) tend to have high latitude in interpreting requirements details (high flexibility) Later versions tend to have more rigidity in interpreting requirements due to legacy requirements from established customer/user expectations

76 Typical System Growth & Maturity 76 Greenfield projects also tend to be small Later versions also tend to be large Size Human Variation This means that the larger projects also tend to have the more rigid requirements Uncertainty Defects This factor goes a long way toward explaining why later versions of a system are disproportionately more difficult than early versions

77 Non-Linearity of Team Cohesion

78 Team Cohesion 78 Team Cohesion : Interactions within the team, broadly considered, i.e., including cooperation between various stakeholders and stakeholder groups Size Uncertainty Human Variation Defects

79 Team Cohesion 79 Elements include: Consistency of stakeholder objectives Stakeholders willingness to accommodate each other s objectives Experience of all stakeholders working as a team Explicit work to develop shared vision and commitments

80 Team Cohesion 80 For small projects, a lot of this can be taken for granted For large projects, a dysfunctional relationship between a small number of stakeholders can ripple a long way

81 Non-Linearity of Process Maturity

82 Process Maturity 82 Process Maturity : Refers to how well defined, repeatable, and optimized your software processes are Size Uncertainty Human Variation Defects

83 Process Maturity 83 This doesn t matter much on small projects It becomes the fourth most important factor on large projects Adding process feels unnatural for companies that have been successful due to being small and Agile This ends up being one of the more difficult transitions for companies and teams to make as they grow

84 Process Maturity 84 It is not surprising that SAFe is often characterized as Not really Agile, because of its degree of structure At the size SAFe applies, however (~300+), the amount of structure is appropriate (no comment about the details!)

85 Implications of the Cocomo Scaling Factors

86 Error Rates Go Up Error Rate by Size 100 Defects / KLOC Low Error Rate High Error Rate Average Error Rate 20 - <2 KLOC 2-16 KLOC KLOC KLOC 512+ KLOC

87 Productivity Goes Down 87 30,000 Productivity by Size 25,000 LOC / Staff Year 20,000 15,000 10,000 High LOC/Staff Year Nominal Low LOC/Staff Year 5,000-1 KLOC 10 KLOC 100 KLOC 1,000 KLOC 10,000 KLOC

88 Summary of Cocomo Insights 88 Sources of difficulty on small projects remain difficult on large projects (complexity, requirements, low staff capability), and even their linear growth in difficulty can be problematic Additional non linear factors emerge and present disproportionate difficulties on larger projects (the scaling factors) Orgs and project teams are often surprised by the nonlinear factors

89 TOOL #3 ACTIVITIES AND INTELLECTUAL PHASES Construx

90 Scaling Non Linearly 90 Challenges scale non linearly Responses/solutions need to scale non linearly too

91 What Activities Do You Need to Scale? 91 Requirements Architecture Construction System Test????

92 What Needs to Scale? 92 Do I need to scale the Product Owner role? Do I need to scale the Scrum Master role? Do I need to scale the Architect role? Do I need to scale some other role? Do I need to add other roles entirely? It Depends!

93 General Pattern of Project Activity Mix by Project Size 93

94 Activities Needed Vary from Project to Project 94 Requirements Architecture Construction System Test????

95 Activities Needed Vary from Project to Project 95 Requirements Architecture Construction System Test????

96 One Thing You Know for Sure 96 Requirements Architecture Construction System Test???? You Won t Just Scale Everything Proportionately!

97 How Do You Know What to Scale Disproportionately? 97

98 Intellectual Phase View of Project Scaling Challenges 98 Discovery (Requirements) Invention (Design) Construction Focus Schedule

99 Diagnostic Tool: Variations in Where Challenges Come From 99

100 SUMMARY Construx

101 Summary 101 As with many other Agile issues, discussion commonly treats the scaling issue as though it were Agile Scaling

102 Summary 102 It s more productive to treat the scaling issue as though it is Agile Scaling (size)

103 Summary 103 Large software projects are difficult (not just Agile projects) Problems scale non linearly Solutions need to scale non linearly, too

104 These Tools Help Understand Scaling 104 Four Factors Lifecycle Model (Size factor) Cocomo II: What Got You Here Won t Get You There Activities and Intellectual Phases

105 Interactions of the Four Factors Lifecycle Model with Size 105 Human Variation Skillset needed Proportion of different skills needed Team cohesion How humans are organized Value of higher performing individuals Uncertainty Unprecedented work Approach to risks Planning appropriate to project scope Process appropriate to project scope Short feedback loops Lifecycle Model Short iterations / feedback loops Extra emphasis on high challenge areas (discovery, invention, implementation) Defects Error rates Focus on defect prevention Resolution of architecture issues Short feedback loops Size Uncertainty Human Variation Defects

106 Generic Four Factors Model Responses to Challenges Size Human Variation 106 High challenge means Discovery Invention Construction Uncertainty Defects Attempt smaller project overall (size factor) Attempt less ambitious work in this particular area (size factor) Use more senior staff (human variation factor) Expect more defects, and employ more extensive defect finding techniques (defect factor) Build in more iteration in this area (lifecycle model) Build in smaller iterations in this area (lifecycle model Attempt smaller project overall (size factor) Attempt less ambitious work in this particular area (size factor) Use more senior staff (human variation factor) Expect more defects, and employ more extensive defect finding techniques (defect factor) Build in more iteration in this area (lifecycle model) Build in smaller iterations in this area (lifecycle model Attempt smaller project overall (size factor) Attempt less ambitious work in this particular area (size factor) Use more senior staff (human variation factor) Expect more defects, and employ more extensive defect finding techniques (defect factor) Build in more iteration in this area (lifecycle model) Build in smaller iterations in this area (lifecycle model

107 See Much More Detail in the Understanding Software Projects Lectures! 107

108 Construx Software is committed to helping individuals and organizations improve their software development practices. Construx NE 8th Street, Suite 1350 Bellevue, WA (866) For information about our training and consulting services, contact Construx