Andy Norton
@andyjnorton (🤦)
@[email protected]
What needs to be true?
Patterns of engineering agility
Slide 2
Slide 2 text
Hello, I’m Andy.
Slide 3
Slide 3 text
I want to talk
about a
fl
ywheel for
engineering
agility
Slide 4
Slide 4 text
Patterns that help us to get
to what good looks like
Slide 5
Slide 5 text
Patterns that help
change to stick
Slide 6
Slide 6 text
Change that
sticks is hard
though
Slide 7
Slide 7 text
So, what needs to be true for
this to happen?
Slide 8
Slide 8 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 9
Slide 9 text
#1 That we need an
operating system for
our organisations
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
"An operating system is a set of
norms and actions that are
shared with everyone in the
company”
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 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 14
Slide 14 text
No content
Slide 15
Slide 15 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 16
Slide 16 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 17
Slide 17 text
Once an organisation doesn't fit in a room
anymore… you need an operating system
Slide 18
Slide 18 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 strategic intents
for the next 3-6 months
Slide 19
Slide 19 text
No content
Slide 20
Slide 20 text
No content
Slide 21
Slide 21 text
No content
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
Organisations
have a memory
Slide 24
Slide 24 text
But it’s a sliding window of
knowledge.
New person
☁☁
☁
☁
☁
Slide 25
Slide 25 text
You need to save your
organisation’s memory to
an operating system
Slide 26
Slide 26 text
Mission Objectives Principles
Strategic
planning
Team APIs Goals Metrics
RACI Management
mechanisms
Communication
and documentation
practices
Operating cadence
Slide 27
Slide 27 text
No content
Slide 28
Slide 28 text
#1 That we need
an operating
system for our
organisations
Slide 29
Slide 29 text
#2 That we use
constraints to our
advantage
Slide 30
Slide 30 text
We need to face up to our
organisational constraints,
and put some of our own in
place.
Slide 31
Slide 31 text
How do we find them? 🔎
Slide 32
Slide 32 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 33
Slide 33 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 34
Slide 34 text
No content
Slide 35
Slide 35 text
No content
Slide 36
Slide 36 text
No content
Slide 37
Slide 37 text
No content
Slide 38
Slide 38 text
No content
Slide 39
Slide 39 text
Your homework for next week
Slide 40
Slide 40 text
Not all constraints are bad
(some can be really helpful)
Slide 41
Slide 41 text
Explain complex things using
only the 1000 most common
words in the English language
Slide 42
Slide 42 text
?
Slide 43
Slide 43 text
“A group of people meeting up to talk about why other people
don’t talk to each other enough”
Slide 44
Slide 44 text
Some practical examples of
useful constraints…
Slide 45
Slide 45 text
Guide rails
Slide 46
Slide 46 text
Guard rails
Slide 47
Slide 47 text
Guard rails
Slide 48
Slide 48 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 49
Slide 49 text
Build a walking
skeleton
Slide 50
Slide 50 text
No content
Slide 51
Slide 51 text
Technical blueprints
Slide 52
Slide 52 text
A shared understanding of what good can look like
Build a golden path
Define Principles
Doctrine
• Doctrine are universally
useful principles that are
applicable to all industries
regardless of the landscape
and it’s context.
Strategic
imperatives
• Strategic priorities are specific,
focused directives or goals that
an organisation sets to guide
it’s actions and decisions,
aiming to steer the culture and
operations in a desired
direction.
Slide 56
Slide 56 text
Wardley’s Doctrine
• Phase 4: Continuously Evolve
• Phase 1: Stop Self-Destructive Behaviour
• Phase 2: Become More Context Aware
• Phase 3: Better for Less
Slide 57
Slide 57 text
Wardley’s Doctrine
Use appropriate methods (e.g
agile vs lean vs six sigma)
Focus on user needs
Remove bias and
duplication
Be transparent (a bias
towards open)
Manage inertia (e.g. existing practices,
political capital, previous investment)
Be pragmatic (it doesn’t matter if
the cat is black or white, as long as
it catches the mouse)
Slide 58
Slide 58 text
No content
Slide 59
Slide 59 text
Augment doctrine with your
intentional strategic imperatives,
and focus on constraints
Slide 60
Slide 60 text
Guide rails
Guard rails
Walking skeleton
Technical blueprints
Golden path
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 that really
don't scale well Capabilities Brent Communication
The things
we’re learning
Slide 66
Slide 66 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
Slide 67
Slide 67 text
- Bias for action
- Prototyping
- Design sprints
- Experimentation
- XP
- Data driven
- Observability
- Product thinking across roles
- Strategic domain-driven design
- Facilitation
- Lean agile approach
- Delivery management
- Continuous improvement
- Standardisation
- Value stream
management
Slide 68
Slide 68 text
How do we anticipate future
scale?
Slide 69
Slide 69 text
"I wisely started with a map” - J.R.R. Tolkien
Slide 70
Slide 70 text
No content
Slide 71
Slide 71 text
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 72
Slide 72 text
Competitive Advantage Cost of doing business
Driven by gut Driven by metrics
High future worth Reducing margin
Slide 73
Slide 73 text
So, we’ve scaled up, we’ve seen what the
future looks like, and now our brain hurts.
Slide 74
Slide 74 text
Cognitive load
101
Slide 75
Slide 75 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 76
Slide 76 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 77
Slide 77 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 78
Slide 78 text
Working Groups
Enabling
Teams
Platform Teams
We can use different
types of teams to
balance cognitive load.
Slide 79
Slide 79 text
Enabling
Teams
https://esilva.net/articles/architecture-modernization-enabling-team
Architecture Modernisation Enabling Team
Slide 80
Slide 80 text
Working Groups
• Decommissioning an old classifieds website
• Defining a blueprint for Observability
• Creating a microservice template
• Improving the front-end CI/CD process
Slide 81
Slide 81 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 82
Slide 82 text
No content
Slide 83
Slide 83 text
Scaling introduces capability gaps Use Wardley mapping for situational awareness
Balance our cognitive load
Enabling
Teams
Working Groups
Use different team types to
fi
ll capability gaps
Slide 84
Slide 84 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 85
Slide 85 text
#4 That we utilise the
power of communities
Slide 86
Slide 86 text
No content
Slide 87
Slide 87 text
No content
Slide 88
Slide 88 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 89
Slide 89 text
Communities are
custodians of communal
memory and knowledge
Slide 90
Slide 90 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 91
Slide 91 text
Don’t take my word for it…
Slide 92
Slide 92 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 93
Slide 93 text
No content
Slide 94
Slide 94 text
No content
Slide 95
Slide 95 text
No content
Slide 96
Slide 96 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 97
Slide 97 text
#5 That we use
improvement kata
checkpoints
Slide 98
Slide 98 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 102
Slide 102 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 103
Slide 103 text
1. Find an agreed measure
of what good looks like
Slide 104
Slide 104 text
2. Look at where the team
currently is in relation to the
standard, pick the top
capabilities we want to improve
Slide 105
Slide 105 text
3. Given current state, and the
suggested work, where are the
gaps now? What tangible work
is required to improve things?
🥇
🥈
🥉
Slide 106
Slide 106 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 107
Slide 107 text
Make them regular ceremonies,
record the results, and compare
Slide 108
Slide 108 text
No content
Slide 109
Slide 109 text
How do we know if
we’re getting better?
Slide 110
Slide 110 text
Apply fitness functions
Quantitative measure that gives
us a dial - think ‘warmer, colder’
“Are we moving towards or
away from our goal?”
Slide 111
Slide 111 text
What percentage of our users
go through the new shiny API
we’ve been working on?
What’s our lead time?
How many times do we have to
manually go onto a production
environment in GCP?
Slide 112
Slide 112 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