Andy Norton
@andyjnorton (!)
@[email protected]
What needs to be true?
Patterns of engineering agility
Slide 2
Slide 2 text
No content
Slide 3
Slide 3 text
For a round?!
Slide 4
Slide 4 text
Hello, I’m Andy.
Slide 5
Slide 5 text
I want to talk
about a
flywheel for
engineering
agility
Slide 6
Slide 6 text
Patterns that help us to get
to what good looks like
Slide 7
Slide 7 text
Patterns that help
change to stick
Slide 8
Slide 8 text
Change that
sticks is hard
though
Slide 9
Slide 9 text
So, what needs to be true for
this to happen?
Slide 10
Slide 10 text
#1 That we need
an operating
system for our
organisations
#2 That we use
constraints to
our advantage
#3 That we
anticipate phase
changes of scaling
#4 That we utilise
the power of
communities
#5 That we use
improvement
kata
checkpoints
Better
engineering
outcomes
Slide 11
Slide 11 text
#1 That we need an
operating system for
our organisations
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
"An operating system is a set of
norms and actions that are
shared with everyone in the
company”
Slide 14
Slide 14 text
No content
Slide 15
Slide 15 text
A good operating system
makes it clear, at every level,
what we’re trying to achieve,
how to communicate progress,
and how to measure
achievement
Slide 16
Slide 16 text
Boundless autonomy
Slide 17
Slide 17 text
Mission
The driving force that
guides decision-making,
strategy and actions
Objectives
The specific strategies
and actions that will be
taken
Principles
The core set of values,
and how we stay true to
the Why and How
Slide 18
Slide 18 text
What does good
look like?
How do we make a
decision here?
How do we know if
we’re on the right
path?
Slide 19
Slide 19 text
Once an organisation doesn't fit in a room
anymore… you need an operating system
Slide 20
Slide 20 text
Touchstone
documents for your
operating system
The vision, and
mission
The principles of how
we work
What each team’s
purpose is, and how
they interact with others
The objectives for the
next 12 months
Slide 21
Slide 21 text
No content
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
No content
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
Organisations
have a memory
Slide 26
Slide 26 text
But it’s a sliding window of
knowledge.
New person
☁☁
☁
☁
☁
Slide 27
Slide 27 text
You need to save your
organisation’s memory to
an operating system
Slide 28
Slide 28 text
Mission Objectives Principles
Strategic
planning
Team APIs Goals Metrics
RACI Management
mechanisms
Communication
and documentation
practices
Operating cadence
Slide 29
Slide 29 text
No content
Slide 30
Slide 30 text
No content
Slide 31
Slide 31 text
#1 That we need
an operating
system for our
organisations
Slide 32
Slide 32 text
#2 That we use
constraints to our
advantage
Slide 33
Slide 33 text
We need to face up to our
organisational constraints,
and put some of our own in
place.
Slide 34
Slide 34 text
How do we find them? #
Slide 35
Slide 35 text
If you’re struggling
to find constraints,
focus on your value
stream.
https://www.vige.se/blog/2021/12/2/how-to-illustrate-a-value-stream-a-proposal-and-a-request-for-input
Slide 36
Slide 36 text
A series of actions that need to
be taken in order to deliver value
to a customer
Operational value stream Development value stream
The series of activities required
to transform a business need
into a product or service that
creates value for a customer
The development value stream enables the operational value stream
Slide 37
Slide 37 text
No content
Slide 38
Slide 38 text
No content
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
No content
Slide 41
Slide 41 text
No content
Slide 42
Slide 42 text
Your homework for next week
Slide 43
Slide 43 text
Not all constraints are bad
(some can be really helpful)
Slide 44
Slide 44 text
Explain complex things using
only the 1000 most common
words in the English language
Slide 45
Slide 45 text
No content
Slide 46
Slide 46 text
“Big group of people together talking about why other people
don’t talk to each other enough”
Slide 47
Slide 47 text
Some practical examples of
useful constraints…
Slide 48
Slide 48 text
Guide rails
Slide 49
Slide 49 text
Guard rails
Slide 50
Slide 50 text
Guard rails
Slide 51
Slide 51 text
Guard rails are
our table stakes.
Teams should… have monitoring, alerting
and run-books set up
build dashboards about
business transactions
only communicate with
other teams systems async
have CI/CD from day one
Slide 52
Slide 52 text
Build a walking
skeleton
Slide 53
Slide 53 text
No content
Slide 54
Slide 54 text
Technical blueprints
Slide 55
Slide 55 text
A shared understanding of what good can look like
Build a golden path
Guide rails
Guard rails
Walking skeleton
Technical blueprints
Golden path
Slide 60
Slide 60 text
No content
Slide 61
Slide 61 text
#1 That we need
an operating
system for our
organisations
#2 That we use
constraints to
our advantage
Slide 62
Slide 62 text
#3 That we
anticipate phase
changes of scaling
Slide 63
Slide 63 text
What does a scaling
organisation look like?
Slide 64
Slide 64 text
Moving fast, but taking
on debt
Hiring more managers,
decoupling, and
improving tools
Building platforms,
redoing things, and
splitting into different
units
Scaling happens in phases
Slide 65
Slide 65 text
Things we talk
about when we
talk about scaling
Things we don’t
talk about when we
talk about scaling
Slide 66
Slide 66 text
The organisation
doesn't fit in a room
anymore
And you probably
aren't in all the
channels on Slack*
* or Teams, sorry about that
Slide 67
Slide 67 text
Things that really
don't scale well Capabilities Brent Communication
The things
we’re learning
Slide 68
Slide 68 text
You can't share hats anymore
The skills of today aren't
necessarily the skills of tomorrow
You're more likely to be doing 1
thing well, versus 3 things okay-ish
Capabilities
Slide 69
Slide 69 text
The capabilities we have
• What skills we have across the
teams, and capabilities we
currently have
The capabilities we need
• What skills we need to develop
and the capabilities that will
allow us to scale effectively
If these don’t
align, we need
to codify the
difference
For each thing we do,
do we build it or buy it?
Is it experimental, or a
commodity?
Does it give us a
competitive advantage
or is everyone doing it?
Slide 75
Slide 75 text
No content
Slide 76
Slide 76 text
Competitive Advantage Cost of doing business
Slide 77
Slide 77 text
Competitive Advantage Cost of doing business
Driven by gut Driven by metrics
Slide 78
Slide 78 text
Competitive Advantage Cost of doing business
Driven by gut Driven by metrics
High future worth Reducing margin
Slide 79
Slide 79 text
So, we’ve scaled up, we’ve seen what the
future looks like, and now my brain hurts.
Slide 80
Slide 80 text
Agile conference
bingo
Cognitive
load
Dunbars
number
Conway’s
law
Cognitive
load
Dunbars
number
Conway’s
law
Cognitive
load
Dunbars
number
Conway’s
law
Cognitive
load
Dunbars
number
Conway’s
law
Cognitive
load
Dunbars
number
Conway’s
law
Cognitive
load
Cognitive
load
Conway’s
law
Dunbars
number
Wardley
maps
Team
Topologies
Team
Topologies
Dunbars
number
Team
Topologies
Wardley
maps
Slide 81
Slide 81 text
Agile conference
bingo
Cognitive
load
Dunbars
number
Conway’s
law
Cognitive
load
Dunbars
number
Conway’s
law
Cognitive
load
Dunbars
number
Conway’s
law
Cognitive
load
Dunbars
number
Conway’s
law
Cognitive
load
Dunbars
number
Conway’s
law
Cognitive
load
Cognitive
load
Conway’s
law
Dunbars
number
Wardley
maps
Team
Topologies
Team
Topologies
Dunbars
number
Team
Topologies
Wardley
maps
Slide 82
Slide 82 text
Cognitive load
101
Slide 83
Slide 83 text
No content
Slide 84
Slide 84 text
Intrinsic
• learning new tech stacks and tools
• understanding complex problem
domains
• coordinating efforts
• technical decision making
• table stakes
Germane
• workshopping
• maturing practices
• knowledge stewardship
• collaboration
• deliberate practice
• innovative problem solving
• novel learning that can become
intrinsic over time
Extraneous
• difficult processes
• unclear decision making
• fragmented data sources
• having to go back and
validate everything
• i’m in Jira hell
Slide 85
Slide 85 text
Intrinsic
• learning new tech stacks and tools
• understanding complex problem
domains
• coordinating efforts
• technical decision making
• table stakes
Germane
• workshopping
• maturing practices
• knowledge stewardship
• collaboration
• deliberate practice
• innovative problem solving
• novel learning that can become
intrinsic over time
Extraneous
• difficult processes
• unclear decision making
• fragmented data sources
• having to go back and
validate everything
• i’m in Jira hell
Slide 86
Slide 86 text
Teams need to work with
abstractions to balance
their cognitive load
We need a Platform team to
provide a starter kit for AWS
We don’t want to have to
calculate the stock
ourselves, we’ve got a
finance domain to model
We need to focus on user
needs, not user access
Slide 87
Slide 87 text
But there’s work that
falls between the
teams
Who is going to make sure
we align our approach to
using Datadog?
How do we start using AWS
in this team?
How do we agree on our
Event-driven architecture?
Slide 88
Slide 88 text
Working Groups
Enabling
Teams
Platform Teams
We can use different
types of teams to
balance cognitive load.
Slide 89
Slide 89 text
Enabling teams to change
the foundations
Enabling
Teams
• How we migrate from GCP to AWS?
• How do we embed good practices?
• Collaborates closely with teams for a
period of time until they’re no longer
needed
Working groups to define things
and put in place stop-gaps
Working Groups
• Bring people with expertise together
• How do we agree good practices?
• Short-lived around a problem
Slide 90
Slide 90 text
Enabling
Teams
https://esilva.net/articles/architecture-modernization-enabling-team
Architecture Modernisation Enabling Team
Slide 91
Slide 91 text
No content
Slide 92
Slide 92 text
Scaling introduces capability gaps Use Wardley mapping for situational awareness
Balance our cognitive load
Enabling
Teams
Working Groups
Use different team types to
fill capability gaps
Slide 93
Slide 93 text
#1 That we need
an operating
system for our
organisations
#2 That we use
constraints to
our advantage
#3 That we
anticipate scaling
phase changes
Slide 94
Slide 94 text
#4 That we utilise the
power of communities
Slide 95
Slide 95 text
No content
Slide 96
Slide 96 text
No content
Slide 97
Slide 97 text
Now I’m only wearing 1
hat instead of 3, how do I
get better at my role?
How do we take what
we’re learning and codify
it?
I’ve just joined, what’s
our joined up approach
to doing this thing?
Slide 98
Slide 98 text
Communities are
custodians of communal
memory and knowledge
Slide 99
Slide 99 text
Communities help
organisations get
better at…
The definition of the roles
Making learning and development
integral work
Developing the core capabilities of a
business function
Slide 100
Slide 100 text
Don’t take my word for it…
Slide 101
Slide 101 text
“We will spend time as a group to learn about X,
decide if it’s useful and implement it as a new
standard across our teams in the next few months.”
Slide 102
Slide 102 text
Communities need
people to manage them.
Slide 103
Slide 103 text
No content
Slide 104
Slide 104 text
No content
Slide 105
Slide 105 text
#1 That we need
an operating
system for our
organisations
#2 That we use
constraints to
our advantage
#3 That we
anticipate phase
changes of scaling
#4 That we utilise
the power of
communities
Slide 106
Slide 106 text
#5 That we use
improvement kata
checkpoints
Slide 107
Slide 107 text
Supporting change is
hard.
Change introduces
capability gaps in people.
Having capability gaps is
scary, and can lead to
resistance to change.
DevOps
practices
Delivery
methods
Testing
approach
Incident
management
Service
readiness
Observability
Value stream
mapping
Cognitive load
assessment
Team API
review
Slide 111
Slide 111 text
4 steps to making change stick
Start with an agreed measure of
what good looks like
Look at where the team currently
is in relation to the standard, what
top capabilities do we want to
improve?
Looking at our current state, what
can we change to enable this
capability
We pick the top 4-6 things we’re
going to improve
Slide 112
Slide 112 text
1. Find an agreed measure
of what good looks like
Slide 113
Slide 113 text
2. Look at where the team
currently is in relation to the
standard, pick the top
capabilities we want to improve
Slide 114
Slide 114 text
3. Given current state, and the
suggested work, where are the
gaps now? What tangible work
is required to improve things?
$
%
&
Slide 115
Slide 115 text
4. Push the improvements into the
next cycle of work for the team,
this improvement work should
link back to our agreed standards
Slide 116
Slide 116 text
Make them regular ceremonies,
record the results, and compare
Slide 117
Slide 117 text
No content
Slide 118
Slide 118 text
How do we know if
we’re getting better?
Slide 119
Slide 119 text
Apply fitness functions
Quantitative measure that gives
us a dial - think ‘warmer, colder’
“Are we moving towards or
away from our goal?”
Slide 120
Slide 120 text
What percentage of our users
go through the new shiny API
we’ve been working on?
What’s our lead time?
How many meetings do we have on
no-meetings Wednesday?
Slide 121
Slide 121 text
#1 That we need
an operating
system for our
organisations
#2 That we use
constraints to
our advantage
#3 That we
anticipate phase
changes of scaling
#4 That we utilise
the power of
communities
#5 That we use
improvement
kata
checkpoints
Better
engineering
outcomes