INDEX
A
Accelerate: The Science of Dev Ops (Forsgren, Humble, & Kim), 18, 64, 86, 112, 114, 154
“Acquisition Community Team Dynamics: The Tuckman Model vs. the DAU Model” (Knight), xx
ad hoc team design, 62
adaptive structuration theory, xix
Adidas, 16
adoption of new practices, 155–159
Agile IT Organization Design (Narayan), 173
anti-patterns, 62
Antunes, Miguel, 11
APIs
defined, 187
effective, 148
team, 47–56
application monolith, 113, 187
awkward team interactions, 150–151
AWS, 49
Axelrod, Robert, 49
B
Balena.io, 101
basic team organization, 146–148
Beer, Stafford, 103
benched bay approach, 51
Bertilsson, Albert, 47
Boone, Mary, xxi
Borland Delphi, 101
Bottcher, Evan, 92
domain limitations, 42–45
misplaced, 150–151
relative domain complexity, 41–42
responsibility restriction, 39–41
software boundary size, 45–47
team-first, 111–126
Brain of the Firm (Beer), 103
Brooks, Fred, 35
Brown, Jeremy, 53
business as usual teams, 173–174
business domain bounded context, 115–116
business process management, 169
C
capabilities
missing, 150–151
self-service, 69
“Capturing the Complexity in Advanced Technology Use: Adaptive Structuration Theory” (DeSanctis and Poole), xxi
case studies
complicated-subsystems teams, 94–95, 97–99
DevOps Topologies, 75–77
enabling teams, 88–90
fracture planes, 121–125
organizational sensing, 154–155, 157–159, 162–164
software boundaries, 121–125
static topologies, 75–77
stream-aligned teams, 82–83
team APIs, 50–52, 53–55
team interaction modes, 146–147
team types, 82–83, 88–90
team-first boundaries, 121–125
team-first thinking, 50–52, 53–55
change cadence, 117
defined, 187
domain identification, 43
domain limitations, 42–45
ecosystem tuning, 46
extraneous, 40, 187
“Eyes On, Hands Off,” 46
germane, 40, 188
heuristics for domain assignment, 43
intrinsic, 40, 188
cognitive load (continued)
relative domain complexity, 41–42
responsibility restriction, 39–41
software boundary size, 45–47
types of, 39–40
Cohn, Mike, 24
collaboration mode, 9, 133, 135–137, 153–155
defined, 187
and evolution of team topologies, 159–161
and reverse Conway maneuver, 147–148
right amount of collaboration, 153–154
team behaviors for, 142–143
and viable X-as-a-service interactions, 149
commodity systems, 18
communication
focused, 24–26
inter-team, 25–26, 27
paths, 17
structures, 4–8
tool choice and, 27
unnecessary, 24–26
communities of practice vs. enabling teams, 90
compatible support systems, 69
complicated-subsystems teams, 9, 28, 91–92
case study, 94–95, 97–99
defined, 187
expected behaviors, 94
platform composition, 96–97
continuous delivery (CD), 11
continuous integration (CI), 11
converting teams
component teams to platform teams, 105–106
converting architecture and architects, 109
converting common to fundamental team topologies, 104–109
infrastructure teams to platform teams, 105
stream-aligned teams, 104
support teams, 107–109
tooling teams to enabling teams, 106–107
Conway maneuver, inverse, 10, 18
Conway maneuver, reverse, 10, 18–21, 147–148, 188
Conway’s law, xxii, 9–11, 15–29, 180–181
commodity systems, 18
communication paths, 17
complicated-subsystems teams, 28
component teams, 28
cross-team testing, 23
database administrator team, 18–19
defined, 187
focused communication, 24–26
high cohesion, 22
homomorphic force, 19–20
inter-team communication, 25–26, 27
inverse Conway maneuver, 10, 18
log-aggregation tools, 27–28
loose coupling, 22
modern version of, 17
monolithic shared databases, 16
naive uses of, 26–28
organization design, 16–17, 23–24
reorganizations, 28
reverse Conway maneuver, 10, 18–21, 147–148, 188
software architecture as flows of change, 23
team assignments, 22
team-scoped flow, 21–23
tool choice and communication, 27
understanding and using, 15–17
unnecessary communication, 24–26
version compatibility, 22
Cornago, Fernando, 16
coupled releases, 113
credit reference agencies, 76–77
cross-team testing, 23
Cybernetics: Or Control and Communication in the Animal and the Machine (Wiener), xxi
D
database administrator team, 18–19
DeMarco, Tom, 38
Deming, W. Edwards, 38
DeSanctis, Gerardine, xxi
Designing Autonomous Teams and Services (Tune & Millett), 116
Designing Delivery (Sussna), 85, 172
“Developmental Sequence in Small Groups” (Tuckman), xxii
DevOps for the Modern Enterprise (Hering), 120
The DevOps Handbook (Kim), 166, 172
case study, 75–77
catalog, 66
credit reference agencies, 76–77
healthcare organizations, 75–76
DevOps Topologies catalog, 66
diversity, 38
domain assignment, heuristics for, 43
domain identification, 43
Domain-Driven Design (Evans), 115
Doorley, Scott, 53
Drexler, Allan, xxii
Drucker, Peter, 170
Dunbar, Robin, 32
Dynamic Reteaming (Helfand), 48, 118, 150
E
ecosystem tuning, 46
enabling teams, 9, 86–90, 106–107
case study, 88–90
vs. communities of practice, 90
defined, 187
expected behaviors, 87–88
environment design, 50
environmental scanning, 171
Ericsson, 68
Evans, Eric, 115
evolution triggers, 162–164, 165–170
delivery cadence slowing down, 166–167
multiple business services relying on one large set of underlying services, 167–169
software too large for one team, 165–166
expected behaviors
complicated-subsystems teams, 94
enabling teams, 87–88
stream-aligned teams, 85–86
“Eyes On, Hands Off,” 46
F
facilitating mode, 9, 134, 140–144
defined, 187
and reverse Conway maneuver, 147–148
team behaviors for, 143–144
The Five Dysfunctions of a Team: A Leadership Fable (Lencioni), xx
flow of change, 12, 63–64, 187
Forrester, Russ, xxii
business domain bounded context, 115–116
case study, 121–125
change cadence, 117
defined, 187
natural, 121
performance isolation, 119
regulatory compliance, 116–117
risk, 118–119
team location, 118
technology, 120
user personas, 120–121
Fried, Jason, 55
G
germane, 40
Google, 70
Google Cloud, 72
Guide to Organisation Design (Stanford), 38
guilds, 49
H
Hansson, David Heinemeir, 55
Harvard Business School, 16
healthcare organizations, 75–76
Hering, Mirco, 120
heuristics for domain assignment, 43
high cohesion, 22
high-trust organizations, 32
Horizons, 36
“How Do Committees Invent?” (Conway), 9–10
I
IBM 8086 processor, 101
Ikea, 47
infrastructure automation, 11
infrastructure teams, 105
ING Netherlands, 53
Ingles, Paul, 155
interaction mode key, xx
intermittent collaboration, 133
Internet of Things (IoT), 84, 101, 123–125, 156–157, 171
inter-team communication, 25–26, 27
Ivarsson, Anders, 50
J
Java Virtual Machine, 101
Jay, Graylin, 41
joined-at-the-database monolith, 113, 188
K
Kelly, Allan, 10, 24, 35, 101, 148
Kotte, Gustaf Nilsson, 47
Kotter, John, 161
L
“A Leader’s Framework for Decision Making” (Snowden and Boone), xxi
Lean Enterprise (Humble, Molesky, & O’Reilly), 36
Lencioni, Patrick, xxii
Linux, 101
Lister, Timothy, 38
loose coupling, 22
Luo, Jiao, 80
M
MacCormack, Alan, 16
Maibaum, Michael, 94–95, 162–164
Make Space (Doorley & Witthoft), 53
Microsoft, 69
Millett, Scott, 116
“A Model for Team-Based Organization Performance” (Forrester and Drexler), xx
The Modern Firm (Roberts), 23
Molesky, Joanne, 36
monolithic build, 188
monolithic rebuilds, 113
monolithic shared databases, 16
monolithic workplace, 114, 188
application, 113, 187
hidden, 112–114
joined-at-the-database, 113, 188
multi-layer viable-systems model, 103
The Mythical Man-Month (Brooks), 35
N
.Net Framework, 101
The New Hacker’s Dictionary (Raymond), 10
new practices, adoption of, 155–159
non-blocking dependencies, 68–69
O
onion concept, 34
open-plan office, 114
O’Reilly, Barry, 36
bottlenecks, 11–12
cognitive load, 11–12
collaboration mode, 9
communication structures, 4–8
complicated-subsystem teams, 9
Conway’s law, 9–11
enabling teams, 9
facilitating mode, 9
platform teams, 9
problems with, 5–7
stream-aligned teams, 9
team interaction modes, 9
Team Topologies model, 9
team types, 9
thinking beyond, 7–8
X-as-a-Service mode, 9
organization design, 16–17, 23–24
organization design evolution, 181
organizational sensing, 64–65, 153–175
adoption of new practices, 155–159
business as usual teams, 173–174
business process management, 169
case study, 154–155, 157–159, 162–164
collaboration mode, 153–155, 159–161
environmental scanning, 171
evolution triggers, 165–170
rapid learning, 155–159
self-steering design and development, 170–174
team topologies combination, 164–165
team topologies evolution, 159–164, 165–170
X-as-a-Service mode, 153–154, 161
Out of the Crisis (Deming), 38
P
Pais, Manuel, 66
Payment Card Industry Data Security Standard (PCI DSS), 117
Pearce, Jo, 40
Peopleware (DeMarco & Lister), 38
performance isolation, 119
The Phoenix Project, 166
Pink, Dan, 11
Pivotal Cloud Foundry (PCF), 48–49, 101
platform teams, 9, 92–96, 105–106, 188
cognitive load reduction, 101–102
constraints, 102
managed as a live product or service, 103–104
multi-layer viable-systems model, 103
product development acceleration, 101–102
thinnest viable, 101, 184
underlying, 102–103
Poole, Marshall Scott, xix
principle of overlapping measurement, 143
The Principles of Product Development Flow (Reinertsen), 23, 143
Project Myopia (Kelly), 35
promise theory, 142
R
Rautert, Markus, 16
Raymond, Eric, 10
“Real Life Agile Scaling” (Kniberg), 25
rebuild everything, 113
Red Hat Open Innovation Labs, 53
regulatory compliance, 116–117
relative domain complexity, 41–42
Remote: Office Not Required (Fried & Hansson), 55
Rensin, Dave, 72
reorganizations, 28
responsibilities, splitting, 74
responsibility restriction, 39–41
Roberts, John, 23
Rother, Mike, 134
S
Schwartz, Mark, 4
self-service capabilities, 69
self-steering design and development, 170–174
shuffling team members, 62
silo reduction, 74
single view of the world, 114
site reliability engineering (SRE), 70–72
Skelton, Matthew, 66
Sky Betting & Gaming, 94–95, 162–164
Snowden, Dave, xix
software architecture as flows of change, 23
business domain bounded context, 115–116
case study, 121–125
change cadence, 117
defined, 187
natural, 121
performance isolation, 119
regulatory compliance, 116–117
risk, 118–119
team location, 118
technology, 120
user personas, 120–121
Sosa, Manuel, 24
standardization, 114
ad hoc team design, 62
anti-patterns, 62
case study, 75–77
cloud teams, 69–70
compatible support systems, 69
credit reference agencies, 76–77
dependencies, 74–75
DevOps, 65–67
DevOps Topologies, 66–67, 75–77
engineering maturity, 73–74
feature teams, 67–68
flow of change, designing for, 63–64
healthcare organizations, 75–76
non-blocking dependencies, 68–69
organization size, 73–74
organizational sensing, 64–65
product teams, 68–69
self-service capabilities, 69
shuffling team members, 62
silo reduction, 74
site reliability engineering, 70–72
software scale, 73–74
splitting responsibilities, 74
team intercommunication, 64–65
team patterns, successful, 67–72
technical and cultural maturity, 72–73
topology choice considerations, 72–75
wait time between teams, 74–75
stream-aligned teams, 9, 81–86, 104, 188
capabilities within, 83–84
case study, 82–83
expected behaviors, 85–86
streams of change, suitable, 183–184
T
benched bay approach, 51
case study, 50–52, 53–55
defined, 48, 188
environment design, 50
group chat prefixes, 55–56
guilds, 49
squads, 50
team interactions, 49
virtual environment design, 53–56
workspace design, 50–56
team assignments, 22
team interaction modes, 9, 131–152
awkward team interactions, 150–151
basic team organization, 146–148
case study, 146–147
choosing suitable, 143–145
collaboration mode, 133, 135–137, 142–143, 147–148, 149
effective APIs, 148
enhancing flow, 148–151
facilitating mode, 134, 140–144, 147–148
intermittent collaboration, 133
misplaced boundaries, 150–151
missing capabilities, 150–151
principle of overlapping measurement, 143
promise theory, 142
reducing uncertainty, 148–151
reverse Conway maneuver, 147–148
team behaviors for, 141–144
team habits, 134–135
temporary changes to, 149–150
well-defined team interactions, 132–133
X-as-a-Service mode, 133, 137–140, 143, 149
team interactions, 49, 132–133
team intercommunication, 64–65
team location, 118
Team of Teams (McChrystal), 31, 46
team patterns, successful, 67–72
cloud teams, 69–70
compatible support systems, 69
feature teams, 67–68
non-blocking dependencies, 68–69
product teams, 68–69
self-service capabilities, 69
site reliability engineering, 70–72
team size, 32
team topologies
capability gaps, 184–185
combining, 164–165
component teams to platform teams, 105–106
converting architecture and architects, 109
converting common to fundamental team topologies, 104–109
Conway’s law, 15–29, 180–181
defined, 188
evolving, 159–170
four fundamental. See team types
four team types, 178–179
how to get started with, 183–185
infrastructure teams to platform teams, 105
interaction modes, sharing and practicing, 185
org chart thinking, 3–14
organization design evolution, 181
organizational sensing, 153–175
static, 61–78
stream-aligned teams, 104
suitable streams of change, 183–184
support teams, 107–109
team interaction modes, 131–152
team types, 79–110
team-first boundaries, 111–126
team-first thinking, 31–57, 179–180
thinnest viable platform, 184
three interaction modes, 179
tooling teams to enabling teams, 106–107
team topologies combination, 164–165
team topologies evolution, 159–170
adopting different interaction modes, 159–162
case study, 162–164
combining team topologies, 164–165
delivery cadence slowing down, 166–167
evolution triggers, 165–170
multiple business services relying on one large set of underlying services, 167–170
software too large for one team, 165–166
Team Topologies model, 9
case study, 82–83, 88–90
complicated-subsystems teams, 91–92
converting common to fundamental team topologies, 104–109
enabling teams, 86–90
enabling teams vs. communities of practice, 90
four, 178–179
key, xx
Ops team, 80–81
platform composition, 96–99
platform teams, 92–96
platforms, 100–104
stream-aligned teams, 81–86
support team, 80–81
team silos, 99–100
team-first boundaries, 111–126
application monolith, 113
business domain bounded context, 115–116
case study, 121–125
change cadence, 117
coupled releases, 113
distributed monolith, 112
fracture planes, 115–123
hidden monoliths, 112–114
joined-at-the-database monolith, 113
in manufacturing, 123–125
monolithic model, 114
monolithic rebuilds, 113
monolithic releases, 113
monolithic thinking, 114
monolithic workplace, 114
open-plan office, 114
performance isolation, 119
rebuild everything, 113
regulatory compliance, 116–117
risk, 118–119
single view of the world, 114
software boundaries, 115–123
standardization, 114
team location, 118
technology, 120
user personas, 120–121
team-first software architecture, 35
team-first thinking, 31–57, 179–180
benched bay approach, 51
boundaries, 39–47
case study, 50–52, 53–55
cognitive load, 39–47
diversity, 38
domain identification, 43
domain limitations, 42–45
Dunbar’s number, 32
ecosystem tuning, 46
environment design, 50
extraneous, 40
“Eyes On, Hands Off,” 46
germane, 40
group chat prefixes, 55–56
guilds, 49
heuristics for domain assignment, 43
high-trust organizations, 32
horizons, 36
intrinsic, 40
onion concept, 34
relative domain complexity, 41–42
responsibility restriction, 39–41
small long-lived teams, 32–39
software boundary size, 45–47
software ownership, 36–37
squads, 50
team APIs, 47–56
team definition, 32
team interactions, 49
team lifespans, 35–36
team size, 32
team-first mindset, 37–38
team-first software architecture, 35
trust and team size, 33–35
Tuckman Teal Performance Model, 36
types of, 39–40
virtual environment design, 53–56
workspace design, 50–56
teams, small long-lived, 32–39
diversity, 38
Dunbar’s number, 32
high-trust organizations, 32
horizons, 36
onion concept, 34
software ownership, 36–37
team definition, 32
team lifespans, 35–36
team size, 32
team-first mindset, 37–38
team-first software architecture, 35
trust and team size, 33–35
Tuckman Teal Performance Model, 36
technical and cultural maturity, 72–73
“Technical Consulting Teams,” 86
technology for team-first boundaries, 120
Thinking Environments, 4
thinnest viable platform (TVP), 101, 184, 188
Thoughtworks, 10
tool choice and communication, 27
topology choice considerations, 72–75
dependencies, 74–75
engineering maturity, 73–74
organization size, 73–74
silo reduction, 74
software scale, 73–74
splitting responsibilities, 74
technical and cultural maturity, 72–73
topology choice considerations, 72–75
wait time between teams, 74–75
Toyota, 134
Treynor, Ben, 70
tribes, 75
Tuckman, Bruce, xx
Tuckman Teal Performance Model, 36
Tune, Nick, 116
U
uncertainty, reducing, 148–151
unnecessary communication, 24–26
uSwitch, 155
V
version compatibility, 22
virtual environment design, 53–56
Vogels, Werner, 83
W
wait time between teams, 74–75
Wiener, Norbert, xix
Windows, 101
Witthoft, Scott, 53
X
X-as-a-Service mode, 9, 133, 137–140
and collaboration mode, 149, 153–154
defined, 188
and delivery predictability, 160–161
and evolution of team topologies, 159–161
team behaviors for, 143