Optimizing Teams in a Distributed World Conways three other laws - - PowerPoint PPT Presentation

▶
optimizing teams in a distributed world
SMART_READER_LITE
LIVE PREVIEW

Optimizing Teams in a Distributed World Conways three other laws - - PowerPoint PPT Presentation

Nov 13, 2023 18 likes •1.18k views

Optimizing Teams in a Distributed World Conways three other laws Mike Amundsen CA Technologies @mamund Introduction Effective Teams Organizational metrics can predict software failure-proneness with a precision and recall of 85%

slide-1
SLIDE 1

Mike Amundsen CA Technologies @mamund

Optimizing Teams in a Distributed World

Conway’s three other laws

slide-2
SLIDE 2

Introduction

slide-3
SLIDE 3
slide-4
SLIDE 4
slide-5
SLIDE 5
slide-6
SLIDE 6
slide-7
SLIDE 7
slide-8
SLIDE 8
slide-9
SLIDE 9
slide-10
SLIDE 10
slide-11
SLIDE 11
slide-12
SLIDE 12
slide-13
SLIDE 13
slide-14
SLIDE 14
slide-15
SLIDE 15
slide-16
SLIDE 16

Effective Teams

slide-17
SLIDE 17

“Organizational metrics can predict software failure-proneness with a precision and recall of 85%”

  • - Nachi Nagappan,

MS Research (2009)

slide-18
SLIDE 18

Effective Teams for Microservices

slide-19
SLIDE 19

“[Microservices] allow

  • rganizations [to align] the

architecture of their systems to the structure of their teams.”

  • - Sam Newman,

“Demystifying Conway’s Law” (2015)

slide-20
SLIDE 20

Mel Conway

slide-21
SLIDE 21
slide-22
SLIDE 22

Mel Conway

  • Burroughs assembler (SAVE) 1950s
  • UNCOL (universal compiler language) 1958
  • First paper on Coroutines 1963
  • “How Do Committees Invent?” (1967)
  • MUMPS medical computing (1970s)
  • Pascal for Mac & Apple II (1980s)
  • #HumanizeTheCraft Project (2010s)

http://www.melconway.com/

slide-23
SLIDE 23

Mel Conway

  • Burroughs assembler (SAVE) 1950s
  • UNCOL (universal compiler language) 1958
  • First paper on Coroutines 1963
  • “How Do Committees Invent?” (1967)
  • MUMPS medical computing (1970s)
  • Pascal for Mac & Apple II (1980s)
  • #HumanizeTheCraft Project (2010s)

http://www.melconway.com/

slide-24
SLIDE 24
slide-25
SLIDE 25

Project-Based Organizations

slide-26
SLIDE 26

“Project-based organizations revolve around the concept that a group of individuals or firms join together with the explicit purpose of producing a tangible set of outputs”

  • - Paul Chinowsky, EPOJ 2011
slide-27
SLIDE 27
slide-28
SLIDE 28

“ Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the

  • rganization's communication

structure.”

  • - Mel Conway, 1967
slide-29
SLIDE 29

A system’s design is a copy of the organization’s communication structure.

  • - Mel Conway, 1967
slide-30
SLIDE 30

Communication dictates design.

  • - Mel Conway, 1967
slide-31
SLIDE 31

Conway’s Law

slide-32
SLIDE 32
slide-33
SLIDE 33

Brooks’ Law “Adding manpower to a late software project makes it later.”

  • - Fred Brooks, 1975
slide-34
SLIDE 34

Intercommunication formula n(n − 1) / 2

  • - Fred Brooks, 1975
slide-35
SLIDE 35

Intercommunication formula 5*(5–1)/2 = 10 15*(15–1)/2 = 105 50*(50–1)/2 = 1,225 150*(150–1)/2 = 11,175

  • - Fred Brooks, 1975
slide-36
SLIDE 36

Dunbar’s Number A measurement of the “cognitive limit to the number of individuals with whom any one person can maintain stable relationships.”

  • - Robin Dunbar, 1992
slide-37
SLIDE 37
slide-38
SLIDE 38
slide-39
SLIDE 39

Dunbar Groups Intimate friends: 5 Trusted friends: 15 Close friends: 35 Casual friends: 150

  • - Robin Dunbar, 1992
slide-40
SLIDE 40

Intercommunication formula 5*(5–1)/2 = 10 15*(15–1)/2 = 105 50*(50–1)/2 = 1,225 150*(150–1)/2 = 11,175

  • - Fred Brooks, 1975
slide-41
SLIDE 41

Communication dictates design.

  • - Mel Conway, 1967
slide-42
SLIDE 42

Conway’s (first) Law

slide-43
SLIDE 43

Conway’s (first) Law tells us TEAM SIZE is important

slide-44
SLIDE 44

Conway’s (first) Law tells us TEAM SIZE is important so… Make the teams as small as necessary.

slide-45
SLIDE 45

“Scaling Spotify”, Kniberg & Ivarrson (2012) https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf

slide-46
SLIDE 46

ASSESSMENT: If you don’t have a personal relationship with every member of your TEAM, your team is probably TOO BIG.

slide-47
SLIDE 47

GUIDANCE: Aim for TEAM SIZE

  • f “Dunbar level 1” (5),

possibly “Dunbar level 2” (15).

slide-48
SLIDE 48

So… what about other Conway Laws?

slide-49
SLIDE 49

Conway’s Second Law

slide-50
SLIDE 50

Doing it Over “There is never enough time to do something right, but there is always enough time to do it over.”

  • - Mel Conway, 1967
slide-51
SLIDE 51

Trade Offs

slide-52
SLIDE 52

Efficiency-Thoroughness Trade Offs (ETTOs)

slide-53
SLIDE 53
slide-54
SLIDE 54

Satisficing v. Sacrificing

“Satisficing is explained as a consequence of limited cognitive capacity. Sacrificing is explained as a consequence of the intractability

  • f the work environment”
  • - Eric Hollnagel, 2009
slide-55
SLIDE 55

Satisficing v. Sacrificing

Problem too complicated? Ignore details. Not enough resources? Give up features.

  • - Eric Hollnagel, 2009
slide-56
SLIDE 56

ETTOs are “normal” and result in success more often than failure.

slide-57
SLIDE 57

From “Safety-I and Safety-II”, Hollnagel (2014) http://www.ashgate.com/isbn/9781472423085

slide-58
SLIDE 58

From “ETTO: The Efficiency-Thoroughness Trade-Off”, Hollnagel (2009) http://www.ashgate.com/isbn/9780754676782

slide-59
SLIDE 59

The enemy is intractability.

slide-60
SLIDE 60

Increasing Intractability

  • 1. Systems grow too large
  • 2. Rate of change increases
  • 3. Overall expectations keep rising
  • - Eric Hollnagel, 2009
slide-61
SLIDE 61

“Continuous Delivery” Raphael Carvalho (2014) http://slides.com/raphaelcarvalho/continuous-delivery#/9

slide-62
SLIDE 62

Conway’s Second Law tells us PROBLEM SIZE is important

slide-63
SLIDE 63

Conway’s Second Law tells us PROBLEM SIZE is important so… Make the solution as small as necessary.

slide-64
SLIDE 64

Continuous Delivery – The Dirty Details, Mike Britain, Etsy (2015) http://www.slideshare.net/mikebrittain/continuous-delivery-the-dirty-details/8

slide-65
SLIDE 65

ASSESSMENT: If you (or your team) cannot explain ALL the code in your release package, your release is TOO LARGE

slide-66
SLIDE 66

GUIDANCE: Execute many SMALL releases instead of a few LARGE releases.

slide-67
SLIDE 67

Conway’s Third Law

slide-68
SLIDE 68

Homomorphism “There is a homomorphism from the linear graph of a system to the linear graph of its design organization”

  • - Mel Conway, 1967
slide-69
SLIDE 69
slide-70
SLIDE 70

“How Do Committees Invent?”, Conway (1967) http://www.melconway.com/research/committees.html

slide-71
SLIDE 71

Homomorphism “If you have four groups working on a compiler, you'll get a 4-pass compiler.”

  • Eric S. Raymond, 1991
slide-72
SLIDE 72

Conway’s Third Law tells us CROSS-TEAM INDEPENDENCE is important.

slide-73
SLIDE 73

Conway’s Third Law tells us CROSS-TEAM INDEPENDENCE is important. So… Make each team fully independent.

slide-74
SLIDE 74

If you have to hold a release until some other team is ready, you are not an INDEPENDENT TEAM

slide-75
SLIDE 75

Coordination in Large-Scale Software Teams, Begel, et al (2007)

http://research.microsoft.com/en-us/um/people/abegel/papers/coordination-chase09.pdf

slide-76
SLIDE 76

Coordination in Large-Scale Software Teams, Begel, et al (2007)

http://research.microsoft.com/en-us/um/people/abegel/papers/coordination-chase09.pdf

slide-77
SLIDE 77

Coordination in Large-Scale Software Teams, Begel, et al (2007)

http://research.microsoft.com/en-us/um/people/abegel/papers/coordination-chase09.pdf

slide-78
SLIDE 78

Conway’s Fourth Law

slide-79
SLIDE 79

Disintegration “The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems.”

  • - Mel Conway, 1967
slide-80
SLIDE 80

Three reasons Disintegration occurs…

slide-81
SLIDE 81

Disintegration: Reason #1 “The realization that the system will be large, together with organization pressures, make irresistible the temptation to assign too many people to a design effort”

  • - Mel Conway, 1967
slide-82
SLIDE 82

Brooks’ Law Adding manpower to a late software project makes it later.

  • - Fred Brooks, 1975
slide-83
SLIDE 83

Disintegration: Reason #2 “Application of the conventional wisdom of management to a large design organization causes its communication structure to disintegrate.”

  • - Mel Conway, 1967
slide-84
SLIDE 84

Dunbar’s Number A measurement of the “cognitive limit to the number of individuals with whom any one person can maintain stable relationships.”

  • - Robin Dunbar, 1992
slide-85
SLIDE 85

Disintegration: Reason #3 “Homomorphism insures that the structure of the system will reflect the disintegration which has occurred in the design

  • rganization.”
  • - Mel Conway, 1967
slide-86
SLIDE 86

Communication dictates design.

  • - Mel Conway, 1967
slide-87
SLIDE 87

Conway’s Fourth Law tells us TIME is against LARGE teams.

slide-88
SLIDE 88

Conway’s Fourth Law tells us TIME is against LARGE teams. So… Make release cycles short and small.

slide-89
SLIDE 89

Standish Group Chaos Report 2015 (via http://www.infoq.com/articles/standish-chaos-2015)

slide-90
SLIDE 90

ASSESSMENT: If your release dates are often missed, your SCOPE is TOO BIG.

slide-91
SLIDE 91

GUIDANCE: Aim for a SCOPE that supports a release cycle

  • f two weeks or less.
slide-92
SLIDE 92

So, let’s review our options…

slide-93
SLIDE 93

Conway’s Laws can help us succeed

slide-94
SLIDE 94

Conway’s Laws can help us succeed when working with microservice teams.

slide-95
SLIDE 95

Conway’s First Law A system’s design is a copy

  • f the organization’s

communication structure.

slide-96
SLIDE 96

Conway’s First Law A system’s design is a copy

  • f the organization’s

communication structure. Actively manage communications within the teams and across teams.

slide-97
SLIDE 97

“Tactics for Global Software Development”, Herbsleb (2008) http://herbsleb.org/web-pres/slides/Siemens-conference-7-17-08-dist.pdf

slide-98
SLIDE 98

“Tactics for Global Software Development”, Herbsleb (2008) http://herbsleb.org/web-pres/slides/Siemens-conference-7-17-08-dist.pdf

slide-99
SLIDE 99

Increase communications

  • Real-time Chat Tools
  • Video Conferencing
  • Online Forums/News Groups
  • Wiki and Web Sites

Reduce the effort required to locate and interact with the ‘right people’

slide-100
SLIDE 100

Conway’s Second Law There is never enough time to do something right, but there is always enough time to do it over.

slide-101
SLIDE 101

Conway’s Second Law There is never enough time to do something right, but there is always enough time to do it over. Remember the process is continually repeating.

slide-102
SLIDE 102

Continuous Delivery “The core concept of making small frequent changes, and testing at every step, reduces the risk inherent in deploying new code.” Jez Humble, Thoughtworks.

slide-103
SLIDE 103

Support continuous processes

  • Implement small changes
  • Test immediately
  • Deploy constantly

Shorten the feedback loop as much as possible.

slide-104
SLIDE 104

Conway’s Third Law There is a homomorphism from the linear graph of a system to the linear graph of its design organization.

slide-105
SLIDE 105

Conway’s Third Law There is a homomorphism from the linear graph of a system to the linear graph of its design organization. Organize teams in order to achieve desired system.

slide-106
SLIDE 106

Microservices Organized around business capabilities. Products, not projects. Martin Fowler, Thoughtworks

slide-107
SLIDE 107

“Microservices”, Fowler & Lewis (2014) http://martinfowler.com/articles/microservices.html

slide-108
SLIDE 108

“Microservices”, Fowler & Lewis (2014) http://martinfowler.com/articles/microservices.html

slide-109
SLIDE 109

Organize teams by product or BU

  • Combine design, develop, test, & deploy
  • Include storage, business process, & UI
  • Allow teams autonomy within their boundary
  • Require teams to inter-operate, not integrate

Make sure teams own their complete lifecycle.

slide-110
SLIDE 110

Conway’s Fourth Law The structures of large systems tend to disintegrate during development.

slide-111
SLIDE 111

Conway’s Fourth Law The structures of large systems tend to disintegrate during development. Keep your teams as small as necessary, but no smaller.

slide-112
SLIDE 112

Sizing Teams Jeff Bezos, Amazon

slide-113
SLIDE 113

Sizing Teams If a team can’t be fed with two pizzas, it’s too big. Jeff Bezos, Amazon

slide-114
SLIDE 114

Make team as small as necessary

  • Resist urge to grow teams in response to deadlines
  • Consider Dunbar’s groups when sizing teams
  • Be prepared to break into smaller teams

It’s better to be “too small” than to be “too big.”

slide-115
SLIDE 115

Conway’s Lessons from 1967

  • 1. Increase communications
  • 2. Support continuous process
  • 3. Organize teams by products
  • 4. Make teams small as necessary
slide-116
SLIDE 116

Mike Amundsen CA Technologies @mamund

Optimizing Teams in a Distributed World

Conway’s three other laws

http://g.mamund.com/2016-03-qconsp-teams