Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How and why to design your teams for modern software systems - DevOpsCon - Berlin June 2017

4,579 views

Published on

For effective, modern, cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes. This talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on experience helping companies around the world with the design of their teams.

From a talk given at DevOpsCon Berlin on *14* June 2017

Published in: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Download this 3-step guide to generating insane amounts of media coverage for your from LinkedIn: http://bit.ly/linkedin3stepguide
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

How and why to design your teams for modern software systems - DevOpsCon - Berlin June 2017

  1. 1. How and why to design your teams for modern software systems Matthew Skelton | Skelton Thatcher Consulting @matthewpskelton | skeltonthatcher.com DevOpsCon Berlin / @devops_con / #devopscon 13 June 2017, Berlin, DE
  2. 2. Today •Conway’s Law (or heuristic) •Cognitive Load for teams •Real-world Team Topologies •Guidelines for team design
  3. 3. About me Matthew Skelton @matthewpskelton Co-founder at Skelton Thatcher Consulting skeltonthatcher.com
  4. 4. Organisation design for effective software systems Tutorial / Workshop Weds 27 Sept 2017, London https://ti.to/skelton-thatcher-consulting/organisation-design-workshop-sept-2017 skeltonthatcher.com “DEVOPS25" for 25% discount
  5. 5. Books
  6. 6. Team-first digital transformation 30+ organisations UK, US, DE, India, China skeltonthatcher.com
  7. 7. How and why to design your teams for modern software systems
  8. 8. Safer, more rapid changes to software systems (Business Agility)
  9. 9. TEAM
  10. 10. TEAM capabilities appetite & aptitude understanding responsibilities
  11. 11. (assumption) the team is stable, slowly changing, and long-lived #NoProjects
  12. 12. Conway’s Law (or Conway’s Heuristic)
  13. 13. “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” – Mel Conway, 1968 http://www.melconway.com/Home/Conways_Law.html
  14. 14. “if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins” – Ruth Malan, 2008 http://traceinthesand.com/blog/2008/02/13/conways-law/
  15. 15. “We find strong evidence to support the hypothesis that a product’s architecture tends to mirror the structure of the organization in which it is developed.” – MacCormack et al, 2012 MacCormack, Alan, Carliss Y. Baldwin, and John Rusnak. ‘Exploring the Duality Between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis’, 1 October 2012. http://www.hbs.edu/faculty/Pages/item.aspx?num=43260.
  16. 16. homomorphic force (#Conway  #Yawnoc) HT @allankellynet (same) (shape)
  17. 17. Front-end developers Back-end developers
  18. 18. ‘Reverse Conway’ Tobbe Gyllebring (@drunkcod)
  19. 19. A B A B
  20. 20. Design the organisation architecture to produce the right software architecture
  21. 21. Cognitive Load for teams
  22. 22. Cognitive load the total amount of mental effort being used in the working memory (see Sweller, 1988)
  23. 23. Cognitive load Intrinsic Extraneous (Irrelevant ) Germane (Relevant)
  24. 24. ‘Hacking Your Head’: Jo Pearce See http://www.slideshare.net/JoPearce5/hacking-your-head-managing-information-overload-45-mix @jdpearce
  25. 25. We have SCIENCE!
  26. 26. Science since 1988 • Driskell et al, 1999 ‘Does Stress Lead to a Loss of Team Perspective?’ Group Dynamics: Theory, Research, and Practice 3, no. 4 (1999): 291. • Fan et al, 2010 ‘Learning HMM-Based Cognitive Load Models for Supporting Human-Agent Teamwork’. Cognitive Systems Research 11, no. 1 (2010): 108–119. • Ilgen & Hollenbeck, 1993 ‘Effective Team Performance under Stress and Normal Conditions: An Experimental Paradigm, Theory and Data for Studying Team Decision Making in Hierarchical Teams with Distributed Expertise’. DTIC Document, 1993. • Johnston et al, 2002 ‘Application of Cognitive Load Theory to Developing a Measure of Team Decision Efficiency’. DTIC Document, 2002. • Sweller, John, 1994 ‘Cognitive Load Theory, Learning Difficulty, and Instructional Design’. Learning and Instruction 4 (1994): 295–312. • Sweller, John, 1988. ‘Cognitive Load during Problem Solving: Effects on Learning’. Cognitive Science 12, no. 2 (1988): 257–285.
  27. 27. “stress impacts team performance … by narrowing or weakening the team-level perspective required for effective team behavior.” – Driskell et al, 1999 Group Dynamics: Theory, Research, and Practice 1999, Vol. 3, No. 4,291-302
  28. 28. (not just ‘pop’ science!)
  29. 29. High-performing teams are hugely effective Optimise for the team
  30. 30. Match the team responsibility to the cognitive load that the team can handle
  31. 31. Real-world Team Topologies
  32. 32. DevOpsTopologies.com
  33. 33. Development & Testing IT Operations / Web Operations Anti-Type Database / DBA DevOps activity SRE Component Supporting (Tooling / Platform / Build)
  34. 34. (Can you spot an important team type that is missing?)
  35. 35. Anti-Types
  36. 36. Anti-Type A – Separate Silos devopstopologies.com Dev Ops
  37. 37. Anti-Type B – Separate DevOps Silo Dev OpsDevOps devopstopologies.com
  38. 38. devopstopologies.com Dev OpsDevOps Anti-Type C – “We Don’t Need Ops”
  39. 39. Anti-Type D – ‘DevOps’ as another Dev team devopstopologies.com Dev Ops DevOps
  40. 40. Anti-Type E – DevOps as new SysAdmin team devopstopologies.com Dev OpsDevOps
  41. 41. Anti-Type F – Ops embedded in a Dev Team HT: Matt Franz (@seclectech) devopstopologies.com Dev Ops DevOps
  42. 42. Anti-Type G – Dev-DBA gap! devopstopologies.com Dev OpsDBA
  43. 43. Types
  44. 44. Type 1 – Smooth Collaboration devopstopologies.com Dev OpsDevOps
  45. 45. Type 2 – Fully Embedded devopstopologies.com Dev Ops
  46. 46. devopstopologies.com Dev OpsDevOps Type 3 – Infrastructure-as-a-Service
  47. 47. Type 4 – DevOps-as-a-Service devopstopologies.com Dev OpsDevOps
  48. 48. devopstopologies.com Dev OpsDevOps Type 5 – Temporary DevOps Team
  49. 49. devopstopologies.com Dev OpsDevOps Type 6 – ‘Facilitating’ DevOps Team
  50. 50. Type 7 – SRE Team (Google) SRE HT: @kwdhinde devopstopologies.com Dev OpsDevOps
  51. 51. HT: @jascbu devopstopologies.com Dev OpsDevOps Type 8 – ‘Just run my Containers’
  52. 52. Type 9 – DB capability in Dev DBADB Dev devopstopologies.com Dev OpsDevOps
  53. 53. Type 10 – DB as a Service DBaaSDB Dev devopstopologies.com Dev OpsDevOps
  54. 54. There is no single ‘right’ team topology, but several ‘bad’ topologies for any one organisation
  55. 55. Guidelines for team design
  56. 56. Collaboration vs X-as-a-Service Collaboration X-as-a-Service devopstopologies.com
  57. 57. Collaboration vs X-as-a-Service Collaboration X-as-a-Service devopstopologies.com Rapid discovery No hand-offs Comms overheads? Ownership clarity Less context needed Slower innovation?
  58. 58. Supporting & Business Domain Supporting Business Domain devopstopologies.com
  59. 59. Inner Topologies Collaboration XaaS Within any group there may be internal collaborations AND other X- as-a-Service (XaaS) relationships devopstopologies.com
  60. 60. Team types Component team Platform / ’substrate’ team Supporting / ‘productivity’ team Product/Feature team devopstopologies.com
  61. 61. Team configuration devopstopologies.com Platform / ’substrate’ team Product/Feature team
  62. 62. Team configuration Component team Platform / ’substrate’ team Product/Feature team devopstopologies.com
  63. 63. Team configuration Component team Platform / ’substrate’ team Product/Feature team Supporting / ‘productivity’ team devopstopologies.com
  64. 64. Discovery vs. Predictability Team 1 Team 2 Team N Discovery, rapid learning Predictable delivery devopstopologies.com
  65. 65. Established platform (PaaS) Predictable delivery devopstopologies.com
  66. 66. Evolution of team topologies devopstopologies.com DISCOVER ESTABLISH
  67. 67. Evolution of team topologies Team 2 Discover Discover Team N Team 3 Use Use devopstopologies.com Team 1 Establish Establish …
  68. 68. Evolve different team topologies for different parts of the organisation at different times to match the team purpose and context
  69. 69. Summary
  70. 70. Front-end developers Back-end developers A B A B
  71. 71. Design the organisation architecture to produce the right software architecture
  72. 72. “stress impacts team performance … by narrowing or weakening the team-level perspective required for effective team behavior.” – Driskell et al, 1999 Group Dynamics: Theory, Research, and Practice 1999, Vol. 3, No. 4,291-302
  73. 73. Match the team responsibility to the cognitive load that the team can handle
  74. 74. DevOpsTopologies.com
  75. 75. There is no single ‘right’ team topology, but several ‘bad’ topologies for any one organisation
  76. 76. Team configuration Component team Platform / ’substrate’ team Product/Feature team Supporting / ‘productivity’ team devopstopologies.com
  77. 77. Evolution of team topologies Team 2 Discover Discover Team N Team 3 Use Use devopstopologies.com Team 1 Establish Establish …
  78. 78. Evolve different team topologies for different parts of the organisation at different times to match the team purpose and context
  79. 79. Caution
  80. 80. Team topologies alone will not produce effective software systems
  81. 81. Also needed: culture, good engineering, sane funding models, clarity of business vision
  82. 82. Safer, more rapid changes to software systems (Business Agility)
  83. 83. teamtopologies.com Upcoming book: Team Topologies for effective software systems by Matthew Skelton & Manuel Pais
  84. 84. Organisation design for effective software systems Tutorial / Workshop Weds 27 Sept 2017, London https://ti.to/skelton-thatcher-consulting/organisation-design-workshop-sept-2017 skeltonthatcher.com “DEVOPS25" for 25% discount
  85. 85. thank you Matthew Skelton & Manuel Pais @SkeltonThatcher skeltonthatcher.com

×