1. Conway’s Law &
Organizational Change
Allan Kelly
allan@softwarestrategy.co.uk
http://www.softwarestrategy.co.uk
Twitter: @allankellynet
Pipeline conference
London
April 2014

2. Allan Kelly…
Chapters in…
• Business Analysis and Leadership, Pullan & Archer 2013
• 97 Things Every Programmer Should Know, Henney, 2010
• Context Encapsulation in Pattern Languages of Program
Design, vol #5, 2006
 Consulting on software
development & strategy
 Training for Agile
Author
– Changing Software Development: Learning to be
Agile (2008, Wiley)
– Business Patterns for Software Developers (2012,
Wiley - ISBN: 978-1119999249)
– Xanpan: Team Centric Agile Software Development
https://leanpub.com/xanpan

3. Conway’s Law? Continuous Delivery?
Jonathon’s Run Fall, Pennsylvania by Hubert Stoffels (http://flickr.com/photos/22195940@N00)
Creative Commons License

4. The Laws which Rule over Us
Moore’s Law Computing power doubles every 18-
24 months
Metcalf’s
Law
Network becomes more useful the
more devices are connected to it
Conway’s
Law
Organizations design systems which
copy the organization
Brook’s Law Adding more people to a late
project makes it later
Goodhart’s
Law
Making a target from a measure
changes the measure

5. Conway’s Law
Melvin Conway, Datamation, 1968
http://www.melconway.com/Home/Conways_Law.html
organizations which design systems (in
the broad sense used here) are
constrained to produce designs which are
copies of the communication structures
of these organizations

6. Raymond on Conway
Eric Raymond, Hacker’s Dictionary, 1996
Conway’s Law prov. The rule that
organization of the software and the
organization of the software team will
be congruent; originally stated as ‘If you
have four groups working on a
compiler, you’ll get a 4-pass compiler’.

7. Coplien & Harrison
Coplien & Harrison, Organizational Patterns of Agile
Software Development, 2004
If the parts of an organization (e.g. teams,
departments, or subdivisions) do not closely reflect
the essential parts of the product, or if the
relationship between organizations do not reflect
the relationships between product parts, then the
project will be in trouble. ...
Therefore: Make sure the organizations is
compatible with the product architecture.

8. The Homomorphic Force
Leads to Reverse Conway’s Law:
“Organizations with long lived systems will
adopt a structure modeled on the system”
Definition:
Homomorphism is a structure-preserving map
between two structures
Taken from algebra

9. Kelly’s Corollary
Allan Kelly
Many times since 2005
Organization design is system design.
Architect the organization to architect
the system.
e.g. Collective Code
Ownership leads to more
integrated team & code
e.g. Separate Teams ->
Separate Modules

10. Why do large systems disintegrate?
3 steps to disintegration (from Conway):
1. Designers realize the system will be large … irresistible the
temptation to assign too many people to a design effort
2. Conventional management of large design organization
causes its communication structure to disintegrate
3. Homomorphism: system structure disintegrates to reflect
design organization
http://en.wikipedia.org/wiki/File:Shiptriplet2wiki.jpg
CCL image from Lance Rolf

11. Kelly’s Laws
Kelly’s first law of project complexity
Project scope will always increase in
proportion to resources
Inside every large project there is a small
one struggling to get out
Kelly’s second law of project complexity

12. May the Force be with you
Can you break
Conway’s Law? No
The (Homomorphic)
force is stronger than
you
Use the (Homomorphic)
force, Matthew

13. Go against it and
you’ll get a mess
Use the force
Work with it
Wood picture from Böhringer, Creative Commons License
http://commons.wikimedia.org/wiki/File:Zebrano01.jpg

14. Therefore…
Advice for continuous delivery….

15. Whole team: Include everyone
• Developers, Testers, Analysts, Product
Managers, etc. etc.
– Don’t add communication barriers
• Absorb/Embed the business
– Keep communication paths short
• One team to rule them all
– No communication divide
– No “us & them”
– One goal

16. Start small: Delay staffing
• Minimize communication boundaries
• Start with smallest team possible
– Minimally Viable Team
– Slightly smaller than you think you need
– Co-locate!
• Get a small system working
– Piecemeal growth
– Grow the team with the system

17. Multi-skilled Willing Staff
• All hands, one team
– Minimize titles
• Don’t use technologies that
require black arts specialists
– e.g. Databases which need DBA
Every man an rifle man
US Marine Corps

18. Ameba teams
• Start small
– 1, prototype or research
– 2, get going: Engineer & BA
• Grow
• Split as appropriate
– Focus team
– 1 project or area
• Fully staff each team – stand alone

19. Team & Duration
Prefer
– Short and Fast
Over
– Long and Thin
• Faster time to market
• Higher Rate On Investment
• Less resource contention
• Requires clear prioritization & closure

20. #BeyondProjects
#NoProjects
• Keep the team together
– Grow them, shrink them,
– Bend them, shake them
– But never disband them
• Why break up a performing team?
– Flow the work to the team
– Continuous flow

21. Conway’s Second Law?
Melvin Conway, Datamation, 1968
http://www.melconway.com/Home/Conways_Law.html
This point of view has produced
the observation that there's never
enough time to do something
right, but there's always enough
time to do it over.

22. You must remember this…
Start small
and grow
What ever you do….
… incremental is not a dirty word

23. Read all about it
How to Committee invent?
– Original paper, Mel Conway
– http://www.melconway.com/Home/Conways_Law
.html
What do we think about Conway’s Law now?
– Hvatum & Kelly, 2005
– http://www.allankelly.net/static/presentations/Eu
roPLoP2005/ConwaysLawFocusGroup.pdf

24. Allan Kelly
allan@softwarestrategy.co.uk
http://www.softwarestrategy.co.uk
Twitter: @allankellynet
Questions?
Xanpan: Team Centric Agile Software
Development
https://leanpub.com/xanpan
Discount code: Pipeline2014
Half price $9 till 31 April