Conway's Law & Continious Delivery


Published on

Presentation to London Continuous Delivery Group on Conway's Law
January 2014

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Conway's Law & Continious Delivery

  1. 1. Conway’s Law & Organizational Change Continuous Delivery Allan Kelly London January 2014 Twitter:
  2. 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) 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. 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 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. 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
  6. 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. 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. 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. 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. 10. 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. 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. 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 CD
  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 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. 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. #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. Avoid Rock-Stars • • • • • Expensive (but talented) Temperamental Unpredictable Prone to outages Demand flowers – And chocolates Are these attributes you want for your system?
  22. 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
  23. 23. You must remember this… What ever you do…. Start small and grow … incremental is not a dirty word
  24. 24. 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
  25. 25. Questions? Allan Kelly Twitter: @allankellynet Xanpan: Reflections on agile (work in progress)