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 using Team Topologies, exploring a selection of key team types 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 the forthcoming 2019 book Team Topologies and first-hand experience helping companies around the world with the design of their technology teams. Key takeaways: 1. Why using the “Spotify Model” of team design is not enough 2. The four fundamental team topologies needed for modern software delivery 3. The three team interaction modes that enable fast flow and rapid learning 4. How to address Conway’s Law, cognitive load, and team evolution with Team Topologies Bio: Matthew Skelton is the Founder and Head of Consulting at Conflux. He has been building, deploying, and operating commercial software systems since 1998. As Head of Consulting at Conflux, he specialises in Continuous Delivery, operability and organisation dynamics for software in manufacturing, ecommerce, and online services, including cloud, IoT, and embedded software. Recognised by TechBeacon in 2018 as one of the top 100 people to follow in DevOps, Matthew curates the well-known DevOps team topologies patterns at devopstopologies.com and is co-author of the books Continuous Delivery with Windows and .NET (O’Reilly, 2016), Team Guide to Software Operability (Skelton Thatcher Publications, 2016), and Team Topologies (IT Revolution Press, 2019). Matthew founded Conflux in 2017 to offer training and consulting to organisations building and running software systems. Twitter: @matthewpskelton LinkedIn: matthewskelton Slideshare: matthewskelton From a talk at Agile Yorkshire on 20 March 2019 http://www.agileyorkshire.org/event-announcements/wed20thmarch-andybutcherautonomyandchoreography-usingconwayslawtotacklethecompanyscalingproblem

1. TeamTopologies.com
@TeamTopologies
Beyond the Spotify model
using Team Topologies for
organisation dynamics with software delivery
Matthew Skelton, Conflux
co-author of Team Topologies - @matthewpskelton
Agile Yorkshire, 20 March 2019, Leeds

2. 2

3. 3
The Spotify Model
Limitations
Team Topologies
Getting started

4. 4

5. 5

6. The Spotify model of
team design for
software delivery
6

7. 7
Henrik Kniberg & Anders Ivarsson, 2012
https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

8. 8
The Spotify model
Squad: semi-autonomous delivery team
Tribe: family of Squads - related work
Chapter: line management within a Tribe
Guild: cross-Tribe interest/specialist group

9. 9
The Spotify model has
been hugely helpful to
100s of organizations

10. The Spotify model
helps to...
10

11. 11
Encourage flow
of change

12. 12
Establish and
clarify team
responsibilities

13. 13
Promote good
kinds of team
collaboration

14. 14
Plan and budget
for cross-team
enablers

15. 15
The Spotify model helps to
Encourage flow of change
Establish and clarify team responsibilities
Promote good kinds of team collaboration
Plan and budget for cross-team enablers

16. Limitations of the
Spotify model
16

17. “This article is only a snapshot of our
current way of working - a journey in
progress, not a journey completed. By
the time you read this, things have
already changed.”
- Kniberg & Ivarsson
17

18. There is No Spotify Model
18
Marcin Floryan, 2016
https://www.infoq.com/presentations/spotify-culture-stc

19. 19
Software sizing
and cognitive
load

20. 20
Heuristics for
Conway’s Law

21. 21
Patterns for
team
interactions

22. 22
Triggers for
change and
evolution

23. 23
We also need to address
Software sizing and cognitive load
Heuristics for Conway’s Law
Patterns for team interactions
Triggers for change and evolution

24. Team Topologies
24

25. topology
the way in which constituent parts are
interrelated or arranged
Greek: τοπολογία (τόπος == ‘place’)
25

26. Team Topologies
26
Research over 5 years across multiple industry sectors
Informed by 50+ peer-reviewed journal articles
30+ client organizations - consulting and training since
2013 with orgs in CN, EU, IN, US, UK, +
Book: 12+ case studies from well-known organizations

27. Origins - DevOps Topologies
27
CC BY-SA devopstopologies.com

28. 28
Philip Fisher-Ogden,
Director of Engineering at
Netflix:
“thanks for your insightful
articulations of devops
topologies. They inspired
many discussions and
helped us to think about
what model Netflix teams
could be/are using.”
https://twitter.com/philip_pfo/status/999074792123740160

29. 29
Crystal Hirschorn,
Director of Engineering at
Condé Nast International
“Your topological models
resonated extremely well
on both the Dev and Ops
side btw! I like the balanced
arguments, e.g. different
perspectives, for each
pattern.”
https://twitter.com/cfhirschorn/status/1103387659890819073

30. Team Topologies
30
Organizing business and
technology teams for fast flow
Matthew Skelton and
Manuel Pais
Publication date: Sept 2019
IT Revolution Press
Pre-order from Amazon.com:
https://teamtopologies.com/book

31. “innovative tools and concepts for
structuring the next generation
digital operating model”
Charles T. Betz, Principal Analyst, Forrester Research
31

32. Team Topologies for fast flow
Conway’s Law
Team-first
Thinking
Team
Interactions
Sensing for
Evolution
32

33. 33
Software sizing
and cognitive
load

34. 34
Team-first Thinking

35. 35
Team-first Thinking
The team is the means of delivery

36. 36
Team-first Thinking
Design for team cognitive load

37. 37
Team-first Thinking
Choose boundaries for team ownership

38. 38
Team-first Thinking
Physical and digital workspace

39. 39
Team-first Thinking
The team is the means of delivery
Design for team cognitive load
Choose boundaries for team ownership
Physical and digital workspace

40. 40
Heuristics for
Conway’s Law

41. 41
Conway’s Law

42. 42
Conway’s Law
Heuristic for ‘natural’ expected design

43. 43
Conway’s Law
Mirroring in tech system + human system

44. 44
Conway’s Law
Reverse Conway to mitigate worst effects

45. 45
Conway’s Law
Constraint on solution search space

46. 46
Conway’s Law
Heuristic for ‘natural’ expected design
Mirroring in tech system + human system
Reverse Conway to mitigate worst effects
Constraint on solution search space

47. 47
Patterns for
team
interactions

48. 48
Team Interactions

49. 49
Team Interactions
3 defined Interaction Modes

50. 50
Team Interactions
Collaboration: 2 teams working together

51. 51
Team Interactions
X-as-a-Service: 1 provides, 1 consumes

52. 52
Team Interactions
Facilitating: 1 team helps another

53. 53
Team Interactions
3 defined Interaction Modes
Collaboration: 2 teams working together
X-as-a-Service: 1 provides, 1 consumes
Facilitating: 1 team helps another

54. 4 fundamental topologies
54
Stream-aligned team
Enabling team
Complicated Subsystem team
Platform team

55. 4 fundamental topologies
55
Flow of change

56. 3 core interaction modes
56
Flow of change
X-as-a-Service
Facilitating
Collaboration

57. 57
Triggers for
change and
evolution

58. 58
Sensing for Evolution

59. 59
Sensing for Evolution
Not all teams in the org look the same

60. 60
Sensing for Evolution
Discover, then push to Platform

61. 61
Sensing for Evolution
Awkward team interactions are signals

62. 62
Sensing for Evolution
Evolve the org with changing ecosystem

63. 63
Sensing for Evolution
Not all teams in the org look the same
Discover, then push to Platform
Awkward team interactions are signals
Evolve the org with changing ecosystem

64. Getting started with
the Team Topologies
approach
64

65. Getting started
65
Explicit cognitive load
Large Conway mismatches
Team Interactions
Thinnest Viable Platform

66. How well can the team as a unit “grok”
the systems they own and develop?
Push some things into a Platform?
Are skills or capabilities missing?
Explicit cognitive load
66

67. Getting started
67
Explicit cognitive load
Large Conway mismatches
Team Interactions
Thinnest Viable Platform

68. Are there major mismatches between
the team interactions and the required
software / system architecture?
What could be easily adjusted?
Large Conway mismatches
68

69. Getting started
69
Explicit cognitive load
Large Conway mismatches
Team Interactions
Thinnest Viable Platform

70. What would change if we adopted the
3 team interaction patterns?
Collaboration, X-as-a-Service, Facilitating
How would teams react & behave?
Team Interactions
70

71. Getting started
71
Explicit cognitive load
Large Conway mismatches
Team Interactions
Thinnest Viable Platform

72. How is your Platform defined?
What is the thinnest platform that
could work?
What’s needed to run an support it?
Thinnest Viable Platform
72

73. Getting started
73
Explicit cognitive load
Large Conway mismatches
Team Interactions
Thinnest Viable Platform

74. Review
74

75. 75
The Spotify model helps to
Encourage flow of change
Establish and clarify team responsibilities
Promote good kinds of team collaboration
Plan and budget for cross-team enablers

76. 76
We also need to address
Software sizing and cognitive load
Heuristics for Conway’s Law
Patterns for team interactions
Triggers for change and evolution

77. Team Topologies for fast flow
Conway’s Law
Team-first
Thinking
Team
Interactions
Sensing for
Evolution
77

78. Getting started
78
Explicit cognitive load
Large Conway mismatches
Team Interactions
Thinnest Viable Platform

79. Sign up for news and tips:
TeamTopologies.com
79

80. Thank you!
info@teamtopologies.com
80
Matthew Skelton, Conflux
@matthewpskelton
Manuel Pais, Independent
@manupaisable
Copyright © Conflux Digital Ltd 2018-2019. All rights reserved.
Registered in England and Wales, number 10890964
Icons made by Freepick from www.flaticon.com - used under license