agile scaling gurus secrets of the - steve mcconnell · secrets of the agile scaling gurus: tools...
TRANSCRIPT
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®
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
30Parallel Small‐to‐Large Pattern
Pilot Projects
► Pilot projects tend to be small
► A successful pilot leads to larger scale rollout
► The larger scale roll‐outs are often problematic
31Parallel Small‐to‐Large Pattern
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.
32Parallel Small‐to‐Large Pattern
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
44McConnell’s Diseconomy of Scale
► 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
47McConnell’s Diseconomy of Scale
Team Size
Prod
uctiv
ity
1 ~7 ~50 ~250-350
Out
put
48McConnell’s Diseconomy of Scale
► 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
Requirements Architecture Construction System Test
??
? ?
96One Thing You Know for Sure …
Requirements Architecture Construction System Test
? ? ? ?
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 …
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
Human
Variation
DefectsUncertainty
Size
107See Much More Detail in the Understanding Software Projects Lectures!
Construx®
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].