Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DevOpsPorto Meetup10: How and why to design your Teams for modern Software Systems by Matthew Skelton

DevOpsPorto
November 14, 2017

DevOpsPorto Meetup10: How and why to design your Teams for modern Software Systems by Matthew Skelton

Talk delivered by Matthew Skelton

DevOpsPorto

November 14, 2017
Tweet

More Decks by DevOpsPorto

Other Decks in Technology

Transcript

  1. How and why to
    design your teams for
    modern software systems
    Matthew Skelton | Skelton Thatcher Consulting
    @matthewpskelton | skeltonthatcher.com
    DevOps Lisbon @DevOpsLisbon | DevOps Porto @DevOpsPorto
    13 & 14 November 2017, Portugal

    View Slide

  2. Today
    • Conway’s Law (or heuristic)
    • Cognitive Load for teams
    • Real-world Team Topologies
    • Guidelines for team design

    View Slide

  3. teamtopologies.com
    Upcoming book:
    Team Topologies for
    effective software systems
    by Matthew Skelton & Manuel Pais

    View Slide

  4. View Slide

  5. About me
    Matthew Skelton
    @matthewpskelton
    Co-founder at
    Skelton Thatcher Consulting
    skeltonthatcher.com

    View Slide

  6. Books

    View Slide

  7. Team Guide series
    #Operability #BusinessMetrics #Testability #Releasability
    skeltonthatcher.com/publications

    View Slide

  8. Team-first digital transformation
    30+ organisations
    UK, US, DE, India, China
    skeltonthatcher.com

    View Slide

  9. View Slide

  10. How and why to
    design your teams
    for modern software
    systems

    View Slide

  11. Safer, more rapid
    changes to
    software systems
    (Business Agility)

    View Slide

  12. TEAM

    View Slide

  13. View Slide

  14. TEAM
    capabilities
    appetite & aptitude
    understanding
    responsibilities

    View Slide

  15. (assumption)
    the team is stable, slowly changing,
    and long-lived
    #NoProjects

    View Slide

  16. Conway’s Law
    (or Conway’s Heuristic)

    View Slide

  17. “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

    View Slide

  18. “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/

    View Slide

  19. “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.

    View Slide

  20. homomorphic force
    (#Conway  #Yawnoc)
    HT @allankellynet
    (same) (shape)

    View Slide

  21. Front-end
    developers
    Back-end
    developers

    View Slide

  22. ‘Reverse Conway’
    Tobbe Gyllebring (@drunkcod)

    View Slide

  23. A
    B
    A B

    View Slide

  24. View Slide

  25. Design the
    organisation architecture
    to produce the right
    software architecture

    View Slide

  26. Cognitive Load
    for teams

    View Slide

  27. Cognitive load
    the total amount of
    mental effort being used in
    the working memory
    (see Sweller, 1988)

    View Slide

  28. Cognitive load
    Intrinsic
    Extraneous (Irrelevant )
    Germane (Relevant)

    View Slide

  29. ‘Hacking Your Head’: Jo Pearce
    See http://www.slideshare.net/JoPearce5/hacking-your-head-managing-information-overload-45-mix
    @jdpearce

    View Slide

  30. We have SCIENCE!

    View Slide

  31. 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.

    View Slide

  32. “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

    View Slide

  33. (not just ‘pop’ science!)

    View Slide

  34. High-performing teams are
    hugely effective
    Optimise for the team

    View Slide

  35. Match the team
    responsibility to the
    cognitive load that
    the team can handle

    View Slide

  36. Real-world
    Team Topologies

    View Slide

  37. DevOpsTopologies.com

    View Slide

  38. Development & Testing
    IT Operations / Web Operations
    Anti-Type
    Database / DBA
    DevOps activity
    SRE
    Component
    Supporting (Tooling / Platform / Build)

    View Slide

  39. (Can you spot an important
    team type that is missing?)

    View Slide

  40. Anti-Types

    View Slide

  41. Anti-Type A – Separate Silos
    devopstopologies.com
    Dev Ops

    View Slide

  42. Anti-Type B – Separate DevOps Silo
    Dev Ops
    DevOps
    devopstopologies.com

    View Slide

  43. devopstopologies.com
    Dev Ops
    DevOps
    Anti-Type C – “We Don’t Need Ops”

    View Slide

  44. Anti-Type D – ‘DevOps’ as another Dev team
    devopstopologies.com
    Dev Ops
    DevOps

    View Slide

  45. Anti-Type E – DevOps as new SysAdmin team
    devopstopologies.com
    Dev Ops
    DevOps

    View Slide

  46. Anti-Type F – Ops embedded in a Dev Team
    HT: Matt Franz (@seclectech)
    devopstopologies.com
    Dev
    Ops
    DevOps

    View Slide

  47. Anti-Type G – Dev-DBA gap!
    devopstopologies.com
    Dev Ops
    DBA

    View Slide

  48. Types

    View Slide

  49. Type 1 – Smooth Collaboration
    devopstopologies.com
    Dev Ops
    DevOps

    View Slide

  50. Type 2 – Fully Embedded
    devopstopologies.com
    Dev Ops

    View Slide

  51. devopstopologies.com
    Dev Ops
    DevOps
    Type 3 – Infrastructure-as-a-Service

    View Slide

  52. Type 4 – DevOps-as-a-Service
    devopstopologies.com
    Dev Ops
    DevOps

    View Slide

  53. devopstopologies.com
    Dev Ops
    DevOps
    Type 5 – Temporary DevOps Team

    View Slide

  54. devopstopologies.com
    Dev Ops
    DevOps
    Type 6 – ‘Facilitating’ DevOps Team

    View Slide

  55. Type 7 – SRE Team (Google)
    SRE
    HT: @kwdhinde
    devopstopologies.com
    Dev Ops
    DevOps

    View Slide

  56. HT: @jascbu
    devopstopologies.com
    Dev Ops
    DevOps
    Type 8 – ‘Just run my Containers’

    View Slide

  57. Type 9 – DB capability in Dev
    DBA
    DB Dev
    devopstopologies.com
    Dev Ops
    DevOps

    View Slide

  58. Type 10 – DB as a Service
    DBaaS
    DB Dev
    devopstopologies.com
    Dev Ops
    DevOps

    View Slide

  59. There is no single ‘right’ team
    topology, but several ‘bad’
    topologies for any one
    organisation

    View Slide

  60. Guidelines for
    team design

    View Slide

  61. Collaboration vs X-as-a-Service
    Collaboration X-as-a-Service
    devopstopologies.com

    View Slide

  62. 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?

    View Slide

  63. Supporting & Business Domain
    Supporting Business Domain
    devopstopologies.com

    View Slide

  64. Inner Topologies
    Collaboration XaaS
    Within any group there may be
    internal collaborations AND other X-
    as-a-Service (XaaS) relationships
    devopstopologies.com

    View Slide

  65. Team types
    Component team
    Platform / ’substrate’ team
    Supporting / ‘productivity’ team
    Product/Feature team
    devopstopologies.com

    View Slide

  66. Team configuration
    devopstopologies.com
    Platform / ’substrate’ team
    Product/Feature team

    View Slide

  67. Team configuration
    Component team
    Platform / ’substrate’ team
    Product/Feature team
    devopstopologies.com

    View Slide

  68. Team configuration
    Component team
    Platform / ’substrate’ team
    Product/Feature team
    Supporting / ‘productivity’ team
    devopstopologies.com

    View Slide

  69. Discovery vs. Predictability
    Team 1
    Team 2
    Team N
    Discovery, rapid learning
    Predictable delivery
    devopstopologies.com

    View Slide

  70. Established platform (PaaS)
    Predictable delivery
    devopstopologies.com

    View Slide

  71. Evolution of team topologies
    devopstopologies.com
    DISCOVER ESTABLISH

    View Slide

  72. Evolution of team topologies
    Team 2
    Discover Discover
    Team N
    Team 3
    Use
    Use
    devopstopologies.com
    Team 1
    Establish
    Establish

    View Slide

  73. Evolve different team
    topologies for different parts of
    the organisation at different
    times to match the team
    purpose and context

    View Slide

  74. Summary

    View Slide

  75. Front-end
    developers
    Back-end
    developers
    A
    B
    A B

    View Slide

  76. Design the
    organisation architecture
    to produce the right software
    architecture

    View Slide

  77. “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

    View Slide

  78. Match the team responsibility
    to the cognitive load that the
    team can handle

    View Slide

  79. DevOpsTopologies.com

    View Slide

  80. There is no single ‘right’ team
    topology, but several ‘bad’
    topologies for any one
    organisation

    View Slide

  81. Team configuration
    Component team
    Platform / ’substrate’ team
    Product/Feature team
    Supporting / ‘productivity’ team
    devopstopologies.com

    View Slide

  82. Evolution of team topologies
    Team 2
    Discover Discover
    Team N
    Team 3
    Use
    Use
    devopstopologies.com
    Team 1
    Establish
    Establish

    View Slide

  83. Evolve different team
    topologies for different parts of
    the organisation at different
    times to match the team
    purpose and context

    View Slide

  84. Caution

    View Slide

  85. Team topologies
    alone will not
    produce effective
    software systems

    View Slide

  86. Also needed:
    culture, good engineering,
    sane funding models,
    clarity of business vision

    View Slide

  87. Safer, more rapid
    changes to
    software systems
    (Business Agility)

    View Slide

  88. teamtopologies.com
    Upcoming book:
    Team Topologies for
    effective software systems
    by Matthew Skelton & Manuel Pais

    View Slide

  89. View Slide

  90. Team Guide series
    #Operability #BusinessMetrics #Testability #Releasability
    skeltonthatcher.com/publications

    View Slide

  91. thank you
    Matthew Skelton & Manuel Pais
    @SkeltonThatcher
    skeltonthatcher.com

    View Slide