AGILE SCALING GURUS SECRETS OF THE - Steve McConnell · Secrets of the Agile Scaling Gurus: Tools For Understanding Scaling. 11 Talk Outline: Tools for Understanding Scaling Four

Construx®

Tools for Understanding Software Size

SECRETS OF THE AGILE SCALING GURUS

Construx®

These presentation materials are © 2017Construx 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.

COPYRIGHT NOTICE

Construx®

[email protected]

Construx10900 NE 8th Street, Suite 1350

Bellevue, WA 98004

+1 (866) 296‐6300

www.construx.com

STEVE MCCONNELL

Construx®

CONSTRUX’S FIRST EXPERIENCE WITH SCALING

5Early Construx Consulting Engagement

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

Construx®

WHAT I MEAN BY “AGILE SCALING”

7“Agile Scaling” (Really “Agile Adoption”)

Propagating Agile Practices across standalone projects

This is not the focus of this talk

I would not call

this “Agile Scaling”

I would call this “Agile

Adoption”

That’s What I Talked

About Last Year!

8“Agile Scaling” (True “Agile Scaling”)

Conducting a Large Project using Agile practicesThis is

the focus of this talk

All teams contribute to single code line

9“Agile Scaling” (“Federated Solutions”)

Many org’s need this:This is also the focus of this talk

Construx®

Secrets of the Agile Scaling Gurus:

Tools For Understanding Scaling

11Talk Outline: Tools for Understanding Scaling

► Four Factors Lifecycle Model, Focusing on Size

► Cocomo II: “What Got You Here Won’t Get You There”

► Activities and Intellectual Phases

Construx®

TOOL #1FOUR FACTORS LIFECYCLE MODEL

13Understanding Software Projects Lectures

14The Four Factors Lifecycle Model

Human

Variation

DefectsUncertainty

Size

15How to Think About Software Size

► 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

Large Projects Are Difficult!

17Project Outcomes by Project Size

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

10 FP500-1000 LOC

100 FP5K-10K LOC

1,000 FP50K-100K LOC

10,000 FP500K-1M LOC

100,000 FP5M-10M LOC

Perc

enta

ge

Failed

Late

On Time or Early

Data from Economics of Software Quality, Capers Jones, 2012

18What’s Difficult About Large Projects?

► 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

Avoid Scaling if Possible!

20Project Outcomes by Project Size

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

10 FP500-1000 LOC

100 FP5K-10K LOC

1,000 FP50K-100K LOC

10,000 FP500K-1M LOC

100,000 FP5M-10M LOC

Perc

enta

ge

Failed

Late

On Time or Early

Data from Economics of Software Quality, Capers Jones, 2012

#1Reason

21Error Rates and Size

-

20

40

60

80

100

120

<2 KLOC 2-16 KLOC 16-64 KLOC 64-512 KLOC 512+ KLOC

Def

ects

/ K

LOC

Error Rate by Size

Low Error Rate

High Error Rate

Average Error Rate

#2Reason

22Productivity by Project Size

#3

-

5,000

10,000

15,000

20,000

25,000

30,000

1 KLOC 10 KLOC 100 KLOC 1,000 KLOC 10,000 KLOC

LOC

/ S

taff

Yea

r

Productivity by Size

High LOC/Staff Year

Nominal

Low LOC/Staff Year

Reason

23Does Scaling Even Work??? (Putnam’s Data)

#4

05

101520253035404550

1.5-3 3-5 5-7 9-11 15-20

Team Size

Sche

dul

e (M

onth

s)

0

50

100

150

200

250

300

Effo

rt (S

taff

Mon

ths)

Schedule Effort

Business systems projects of ~100KLOC

Reason

Agile Development Does Not Make Scaling More Difficult

25Why Do Organizations Want to “Scale Agile”?

► 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

26Corollaries

► High performance small projects support scaling to larger projects

► Low performance small projects undermine large projects, making them more difficult, or impossible

“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

29Parallel Small‐to‐Large Pattern

Companies

► 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


Pilot Projects

► Pilot projects tend to be small

► A successful pilot leads to larger scale rollout

► The larger scale roll‐outs are often problematic


New Technology

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


Methodologies

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

A Key Challenge of Software Scaling is

Non-Linearity of Software Project Challenges

34Software Scaling’s “X times Y” Problem

► A Large Project is More Than Just “X * A Small Project”

► Some attributes (challenges and activities) scale linearly

► Some attributes scale non‐linearly

35Software Scaling’s “X times Y” Problem

36Larger Projects are not Just, Multiply by ‘X’

37Challenges Change at Different Scales

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

38Problem vs. Solution

► 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

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

40Software has a Diseconomy of Scale

► Bigger project = higher unit cost

► On larger project, per‐person productivity decreases

► This is a diseconomy of scale

41Software’s Diseconomy of Scale

Unit Cost

Project Size

Real Magnitude of Diseconomy

of ScaleUnit Cost

Project Size

NoIncrease

Exponential Diseconomy

of Scale ?

Diseconomy of Scale as a Step Function

43McConnell’s Diseconomy of Scale

► 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


► Diseconomy of scale in software is a step function

► The “steps” are the sizes at which additional levels of coordination need to be added

45Step Function (Steps at Project Staff Sizes of Approximate Powers of 7)

~7 One leader, scrum master or self‐managed

~50 Multiple leads, scrum masters, test specialists, group manager, architect, director

~250‐350 Leads, scrum masters, test specialists, group managers, dev managers, test managers, architects, chief architect, directors, VP

46Coordination

► 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


Team Size

Prod

uctiv

ity

1 ~7 ~50 ~250-350

Out

put


► 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

49Diseconomy of Scale and Agile Scaling

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)

Holy Grail: Large Project = Series of Small Projects

51Parallel Series of Small Projects?

► 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

52Conway’s Law

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

53Conway’s Law, Partitioning, and Agile Philosophy

► 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

54Conway’s Law, Partitioning, and Agile Philosophy

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

55Summary 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

► 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

56Summary 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

► 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

Construx®

TOOL #2COCOMO II: “WHAT GOT YOU HERE WON’T GET YOU THERE”

58Cocomo II and Size – Small Project

59Cocomo’s “Scaling Factors”

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

60Cocomo II and Size – Small Project

No Scaling Factor is in the Top Half in Influence

61Cocomo II and Size – Large Project

Every Scaling Factor is in the Top Half in Influence

62

The factors that challenge projects

change disproportionately

(non‐linearly)as project size increases

63Common Response to Challenges on Larger‐Than‐Usual Projects

► 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

64Common Response to Challenges on Larger‐Than‐Usual Projects

► This is a natural response, but it doesn’t work, because the factors that matter the most change at scale

65In Other Words

Success on small projects does not prepare organizations to succeed on large projects

“What got you here won’t get you there”

Non-Linearity of

Precedentedness

67Precedentedness

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

Human

Variation

DefectsUncertainty

Size

Non-Linearity of

Architecture and Risk Resolution

69Architecture and Risk Resolution

“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

Human

Variation

DefectsUncertainty

Size

70Architecture and Risk Resolution

► 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

71Note the Interaction With Conway’s Law

► 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

72Bottom Line on Architecture and Risk Resolution

► Companies struggle when they take on projects where the architecture and risk profiles are too challenging for the size of project

Non-Linearity of

Requirements Flexibility

74Requirements Flexibility

“Requirements Flexibility”: The need to conform to pre‐established requirements, i.e., how rigid and exact the requirements are

75Typical System Growth & Maturity

► 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

76Typical System Growth & Maturity

► Greenfield projects also tend to be small

► Later versions also tend to be large

► This means that the larger projects also tend to have the more rigid requirements

► This factor goes a long way toward explaining why later versions of a system are disproportionately more difficult than early versions

Human

Variation

DefectsUncertainty

Size

Non-Linearity of

Team Cohesion

78Team Cohesion

“Team Cohesion”: Interactions within the “team,” broadly considered, i.e., including cooperation between various stakeholders and stakeholder groups

Human

Variation

DefectsUncertainty

Size

79Team Cohesion

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

80Team Cohesion

► 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

Non-Linearity of

Process Maturity

82Process Maturity

“Process Maturity”:

► Refers to how well‐defined, repeatable, and optimized your software processes are

Human

Variation

DefectsUncertainty

Size

83Process Maturity

► 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

84Process Maturity

► 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!)

Implications of the Cocomo Scaling Factors

86Error Rates Go Up

-

20

40

60

80

100

120

<2 KLOC 2-16 KLOC 16-64 KLOC 64-512 KLOC 512+ KLOC

Def

ects

/ K

LOC

Error Rate by Size

Low Error Rate

High Error Rate

Average Error Rate

87Productivity Goes Down

-

5,000

10,000

15,000

20,000

25,000

30,000

1 KLOC 10 KLOC 100 KLOC 1,000 KLOC 10,000 KLOC

LOC

/ S

taff

Yea

r

Productivity by Size

High LOC/Staff Year

Nominal

Low LOC/Staff Year

88Summary of Cocomo Insights

► 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 non‐linear factors

Construx®

TOOL #3ACTIVITIES AND INTELLECTUAL PHASES

90Scaling Non‐Linearly

► Challenges scale non‐linearly

► Responses/solutions need to scale non‐linearly too

91What Activities Do You Need to Scale?

?

Requirements

?

Architecture

?

Construction

?

System Test

92What Needs to Scale?

► 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!

93General Pattern of Project Activity Mix by Project Size

94Activities Needed Vary from Project to Project

Requirements Architecture Construction System Test

? ?

? ?

95Activities Needed Vary from Project to Project


??

? ?

96One Thing You Know for Sure …


? ? ? ?

You Won’t Just Scale Everything Proportionately!

97How Do You Know What to Scale Disproportionately?

98Intellectual Phase View of Project Scaling Challenges

Schedule

Focus

Discovery(Requirements)

Invention(Design)

Construction

99Diagnostic Tool: Variations in Where Challenges Come From

Construx®

SUMMARY

101Summary

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

Agile Scaling

102Summary

It’s more productive to treat the scaling issue as though it is

Agile Scaling(size)

103Summary

► Large software projects are difficult (not just Agile projects)

► Problems scale non‐linearly

► Solutions need to scale non‐linearly, too

104These Tools Help Understand Scaling

► Four Factors Lifecycle Model (Size factor)

► Cocomo II: “What Got You Here Won’t Get You There”

► Activities and Intellectual Phases

105Interactions of the Four Factors Lifecycle Model with Size

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

Defects

► Error rates ► Focus on defect

prevention ► Resolution of

architecture issues► Short feedback loops

Lifecycle Model

► Short iterations / feedback loops► Extra emphasis on high‐challenge areas

(discovery, invention, implementation)

Human

Variation

DefectsUncertainty

Size

106

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

Discovery Invention Construction

Generic Four Factors Model Responses to Challenges

High challenge means …


(size factor)







factor)


(lifecycle model)


(lifecycle model


(size factor)







factor)


(lifecycle model)


(lifecycle model

Human

Variation

DefectsUncertainty

Size

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

Construx®

[email protected]

Construx10900 NE 8th Street, Suite 1350

Bellevue, WA 98004

+1 (866) 296‐6300

www.construx.com

Construx Software is committed to helping individuals and organizations improve their software development

practices.

For information about our training and consulting services, contact [email protected].

Documents

AGILE SCALING GURUS SECRETS OF THE - Steve McConnell · Secrets of the Agile Scaling Gurus: Tools For Understanding Scaling. 11 Talk Outline: Tools for Understanding Scaling Four