Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
Â
Conway's Law & Continious Delivery
1. Conwayâs Law &
Organizational Change
Continuous Delivery
Allan Kelly
London
allan@softwarestrategy.co.uk
January 2014
http://www.softwarestrategy.co.uk
Twitter: @allankelly.net
2. Allan KellyâŚ
ď 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: Reflections on agile (work in progress)
https://leanpub.com/xanpan
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
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 1824 months
Metcalfâs
Law
Conwayâs
Law
Brookâs Law
Goodhartâs
Law
Network becomes more useful the
more devices are connected to it
Organizations design systems which
copy the organization
Adding more people to a late
project makes it later
Making a target from a measure
changes the measure
5. Conwayâs Law
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
Melvin Conway, Datamation, 1968
http://www.melconway.com/Home/Conways_Law.html
6. Raymond on Conway
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â.
Eric Raymond, Hackerâs Dictionary, 1996
7. Coplien & Harrison
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.
Coplien & Harrison, Organizational Patterns of Agile
Software Development, 2004
8. The Holomorphic Force
Definition:
Homomorphism is a structure-preserving map
between two structures
Taken from algebra
Leads to Reverse Conwayâs Law:
âOrganizations with long lived systems will
adopt a structure modeled on the systemâ
9. Kellyâs Corollary
Organization design is system design.
Architect the organization to architect
the system.
e.g. Separate Teams ->
Separate Modules
Allan Kelly
Many times since 2005
e.g. Collective Code
Ownership leads to more
integrated team & code
10. http://en.wikipedia.org/wiki/File:Shiptriplet2wiki.jpg
CCL image from Lance Rolf
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
11. Kellyâs Laws
Project scope will always increase in
proportion to resources
Kellyâs first law of project complexity
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
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
Every man an
rifle man
⢠Donât use technologies that
require black arts specialists
â e.g. Databases which need DBA
Debbie Does Development
Chris Oldwood
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. #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
22. Conwayâs Second Law?
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.
Melvin Conway, Datamation, 1968
http://www.melconway.com/Home/Conways_Law.html
23. You must remember thisâŚ
What ever you doâŚ.
Start small
and grow
⌠incremental is not a dirty word
24. 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