Transcription
Building EffectiveMicroservice TeamsLearning fromConway, Brooks, and DunbarMike AmundsenCA Technologies@mamund
Introduction
Effective Teams
Effective Teamsfor Microservices
Melvin Conway
Project-Based Organizations
“Project-based organizationsrevolve around the conceptthat a group of individuals orfirms join together with theexplicit purpose of producing atangible set of outputs”-- Paul Chinowsky, EPOJ 2011
“How Do Committees Invent?”
“Any organization that designs asystem (defined more broadly herethan just information systems) willinevitably produce a design whosestructure is a copy of theorganization's communicationstructure.”-- Mel Conway, 1967
A system’s design is a copy ofthe organization’scommunication structure.-- Mel Conway, 1967
Communication dictates design.-- Mel Conway, 1967
Conway’s Law
Brooks’ Law“Adding manpower to a latesoftware project makes it later.”-- Fred Brooks, 1975
Intercommunication formulan(n 1) / 2-- Fred Brooks, 1975
Intercommunication formula5*(5–1)/2 1015*(15–1)/2 10550*(50–1)/2 1,225150*(150–1)/2 11,175-- Fred Brooks, 1975
Dunbar’s NumberA measurement of the “cognitivelimit to the number of individualswith whom any one person canmaintain stable relationships.”-- Robin Dunbar, 1992
Dunbar GroupsIntimate friends: 5Trusted friends: 15Close friends: 35Casual friends: 150-- Robin Dunbar, 1992
Intercommunication formula5*(5–1)/2 1015*(15–1)/2 10550*(50–1)/2 1,225150*(150–1)/2 11,175-- Fred Brooks, 1975
Communication dictates design.-- Mel Conway, 1967
Conway’s (first) Law
Conway’s (first) Lawtells us TEAM SIZE is important
Conway’s (first) Lawtells us TEAM SIZE is importantso Make the teams as small as necessary.
Aim for “Dunbar level 1” (5),possibly “Dunbar level 2” (15),be wary of teams above that size.
If you don’t havea personal relationshipwith every member of your team,it is probably TOO BIG.
So what about other Conway Laws?
Conway’s Second Law
Doing it Over“There is never enough timeto do something right,but there is always enoughtime to do it over.”-- Mel Conway, 1967
Trade Offs
Efficiency-Thoroughness Trade Offs (ETTOs)
Satisficing v. Sacrificing“Satisficing is explained as aconsequence of limitedcognitive capacity.Sacrificing is explained as aconsequence of the intractabilityof the work environment”-- Eric Hollnagel, 2009
Satisficing v. SacrificingProblem too complicated?Ignore details.Not enough resources?Give up features.-- Eric Hollnagel, 2009
ETTOs are “normal” and result insuccess more often than failure.
The enemy is intractability.
Increasing Intractability1. Systems grow too large2. Rate of change increases3. Overall expectations keep rising-- Eric Hollnagel, 2009
Conway’s Second Lawtells us PROBLEM SIZE is important
Conway’s Second Lawtells us PROBLEM SIZE is importantso Make the solution as small as necessary.
If you (or your team)cannot explain ALL the codein your release package,your release is TOO LARGE
Conway’s Third Law
Homomorphism“There is a homomorphismfrom the linear graph of asystem to the linear graph ofits design organization”-- Mel Conway, 1967
Homomorphism“If you have four groupsworking on a compiler, you'llget a 4-pass compiler.”- Eric S. Raymond, 1991
Conway’s Third Lawtells us CROSS-TEAM INDEPENDENCEis important.
Conway’s Third Lawtells us CROSS-TEAM INDEPENDENCEis important.So Make each team fully independent.
If you have to hold a releaseuntil some other team is ready,you are not anINDEPENDENT TEAM
Conway’s Fourth Law
Disintegration“The structures of largesystems tend to disintegrateduring development,qualitatively more so than withsmall systems.”-- Mel Conway, 1967
Three reasons Disintegration occurs
Disintegration: Reason #1“The realization that thesystem will be large, togetherwith organization pressures,make irresistible thetemptation to assign too manypeople to a design effort”-- Mel Conway, 1967
Brooks’ LawAdding manpower to a latesoftware project makes it later.-- Fred Brooks, 1975
Disintegration: Reason #2“Application of theconventional wisdom ofmanagement to a largedesign organization causes itscommunication structure todisintegrate.”-- Mel Conway, 1967
Dunbar’s NumberA measurement of the “cognitivelimit to the number of individualswith whom any one person canmaintain stable relationships.”-- Robin Dunbar, 1992
Disintegration: Reason #3“Homomorphism insures thatthe structure of the system willreflect the disintegration whichhas occurred in the designorganization.”-- Mel Conway, 1967
Communication dictates design.-- Mel Conway, 1967
Conway’s Fourth Lawtells us TIME is against LARGE teams.
Conway’s Fourth Lawtells us TIME is against LARGE teams.So Make release cycles short and small.
If your release dates are often missed,your release SIZE is TOO BIG.
So, let’s review our options
Conway’s Lawscan help us succeed
Conway’s Lawscan help us succeedwhen working withmicroservice teams.
Conway’s First LawA system’s design is a copyof the organization’scommunication structure.
Conway’s First LawA system’s design is a copyof the organization’scommunication structure.Actively managecommunications within theteams and across teams.
James Herbsleb: “Tactics for Global Software Development”
James Herbsleb: “Tactics for Global Software Development”
Increase communications Real-time Chat ToolsVideo ConferencingOnline Forums/News GroupsWiki and Web SitesReduce the effort required to locate andinteract with the ‘right people’
Conway’s Second LawThere is never enough timeto do something right, butthere is always enough timeto do it over.
Conway’s Second LawThere is never enough timeto do something right, butthere is always enough timeto do it over.Remember the process iscontinually repeating.
Continuous Delivery“The core concept of makingsmall frequent changes, andtesting at every step,reduces the risk inherent indeploying new code.”Jez Humble, Thoughtworks.
Support continuous processes Implement small changes Test immediately Deploy constantlyShorten the feedback loop as much aspossible.
Conway’s Third LawThere is a homomorphismfrom the linear graph of asystem to the linear graph ofits design organization.
Conway’s Third LawThere is a homomorphismfrom the linear graph of asystem to the linear graph ofits design organization.Organize teams in order toachieve desired system.
MicroservicesOrganized aroundbusiness capabilities.Products, not projects.Martin Fowler, Thoughtworks
Organize teams by product or BU Combine design, develop, test, & deployInclude storage, business process, & UIAllow teams autonomy within their boundaryRequire teams to inter-operate, not integrateMake sure teams own their complete lifecycle.
Conway’s Fourth LawThe structures of largesystems tend to disintegrateduring development.
Conway’s Fourth LawThe structures of largesystems tend to disintegrateduring development.Keep your teams as smallas necessary, but nosmaller.
Sizing TeamsJeff Bezos, Amazon
Sizing TeamsIf a team can’t be fed withtwo pizzas, it’s too big.Jeff Bezos, Amazon
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 teamsIt’s better to be “too small” than to be “too big.”
Conway’s Lessons1.2.3.4.Increase communicationsSupport continuous processOrganize teams by productsMake teams as small as necessary
Building EffectiveMicroservice TeamsLearning fromConway, Brooks, and Dunbarhttp://g.mamund.com/2015-10-qcon-teamsMike AmundsenCA Technologies@mamund
Mike Amundsen CA Technologies @mamund Building Effective Microservice Teams Learning from Conway, Brooks, and Dunbar
