Conways Law & Continuous Delivery


Published on

Presentation to Pipeline Conference (Continuos Delivery) April 2014.
Discusses Conway's Law and the implications for continuous delivery

Published in: Software, Technology, Business

Conways Law & Continuous Delivery

  1. 1. Conway’s Law & Organizational Change Allan Kelly Twitter: @allankellynet Pipeline conference London April 2014
  2. 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
  3. 3. Conway’s Law? Continuous Delivery? Jonathon’s Run Fall, Pennsylvania by Hubert Stoffels ( Creative Commons License
  4. 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. 5. Conway’s Law Melvin Conway, Datamation, 1968 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. 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. 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. 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. 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. 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 CCL image from Lance Rolf
  11. 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. 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. 13. Go against it and you’ll get a mess Use the force Work with it Wood picture from Böhringer, Creative Commons License
  14. 14. Therefore… Advice for continuous delivery….
  15. 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. 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. 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. 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. 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. 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. 21. Conway’s Second Law? Melvin Conway, Datamation, 1968 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. 22. You must remember this… Start small and grow What ever you do…. … incremental is not a dirty word
  23. 23. Read all about it How to Committee invent? – Original paper, Mel Conway – .html What do we think about Conway’s Law now? – Hvatum & Kelly, 2005 – roPLoP2005/ConwaysLawFocusGroup.pdf
  24. 24. Allan Kelly Twitter: @allankellynet Questions? Xanpan: Team Centric Agile Software Development Discount code: Pipeline2014 Half price $9 till 31 April