Meeting objectives
on-time & on-budget:
reported up and out
Slide 80
Slide 80 text
Trending towards state
of devops metrics
200x more frequent deployments
24x faster recovery from failures
3x lower change failure rate
2,555x shorter lead times
22% less time on unplanned work and rework
Slide 81
Slide 81 text
“People with targets […] will probably meet the
targets - even if they have to destroy the
enterprise to do it.” – Deming
Slide 82
Slide 82 text
Where do
we start?
Slide 83
Slide 83 text
Start on the edges
Slide 84
Slide 84 text
Pick a small problem
Slide 85
Slide 85 text
Understand and
serve a user need
(as well as a government need)
Slide 86
Slide 86 text
You can not sustainably
meet user needs
if you are not meeting
your own needs
at the same time.
Slide 87
Slide 87 text
Use the
Digital Service Standard
as the guide for
what good looks like
Slide 88
Slide 88 text
Start with this
Slide 89
Slide 89 text
Then do this
Slide 90
Slide 90 text
Then this
Slide 91
Slide 91 text
Create small,
multi-disciplinary
teams
Slide 92
Slide 92 text
Template:
1x front end developer
1x back end developer
1x user experience designer
1x agile coach (part time)
Slide 93
Slide 93 text
Use the
Digital Service Standard
as the guide for
what good looks like
Slide 94
Slide 94 text
No executive
sponsorship?
Don’t even bother.
Slide 95
Slide 95 text
Set delivery
constraints
Slide 96
Slide 96 text
⏰ Time
Budget
Scope
(pick 2)
Slide 97
Slide 97 text
Build the smallest,
simplest thing that
meets a user need
Slide 98
Slide 98 text
“You build it,
you run it”
– Vogels, AWS
Slide 99
Slide 99 text
Don’t change what
tech you use
Slide 100
Slide 100 text
Change how
you use that tech
Slide 101
Slide 101 text
Don’t blow your
innovation budget on
experimenting
with tech
Slide 102
Slide 102 text
All changes go
through a
Continuous Delivery
pipeline
Slide 103
Slide 103 text
deploy to
production
acceptance
tests
integrate
unit tests
code done
Continuous Delivery
Manual
Auto
Auto
Auto
Slide 104
Slide 104 text
Multiple deploys a day
Slide 105
Slide 105 text
High-performing IT organisations
report experiencing:
200x more frequent
deployments
Slide 106
Slide 106 text
Code doesn’t create value
until it is running
in front of a user
Slide 107
Slide 107 text
Ship usable software
multiple times a day
Slide 108
Slide 108 text
Write high level
acceptance tests
(like Cucumber)
Slide 109
Slide 109 text
An executable
specification
Slide 110
Slide 110 text
Feature: Refund item
Scenario: Jeff returns a faulty microwave
Given Jeff has bought a microwave for $100
And he has a receipt
When he returns the microwave
Then Jeff should be refunded $100
Slide 111
Slide 111 text
Nail your automated
delivery pipeline
from the start
Slide 112
Slide 112 text
Decouple what you build
from existing systems
Slide 113
Slide 113 text
Build in isolation
Slide 114
Slide 114 text
Don’t create
dependencies
Slide 115
Slide 115 text
Manual processing
is OK
Slide 116
Slide 116 text
No point investing
in automation
until you have validated the
service meets a user need
Slide 117
Slide 117 text
Risk:
you automate the
wrong thing
Slide 118
Slide 118 text
automation
is a means
Slide 119
Slide 119 text
meeting a user need
is the end
Slide 120
Slide 120 text
manage team
workload by:
only sending a percentage of
the workload to the service
Slide 121
Slide 121 text
Bonus:
build empathy with
users by doing the
grunt work
Slide 122
Slide 122 text
What
happens
next?
Slide 123
Slide 123 text
DO NOT DISBAND
THE TEAM
Slide 124
Slide 124 text
The team don’t get
reabsorbed
Slide 125
Slide 125 text
The service doesn’t get
lobbed over the wall
Slide 126
Slide 126 text
It’s not a one-off
Slide 127
Slide 127 text
It’s not a project
Slide 128
Slide 128 text
It’s a long lived service
Slide 129
Slide 129 text
Team and service
need to be resilient
Slide 130
Slide 130 text
Team continues
with the service
Slide 131
Slide 131 text
No executive
sponsorship?
Don’t even bother.
Slide 132
Slide 132 text
“This worked well!
Let’s scale it up!”
Slide 133
Slide 133 text
Limit scope creep
Slide 134
Slide 134 text
Amazon’s
two pizza
teams rule
Slide 135
Slide 135 text
Don’t aim for
economies of scale
Slide 136
Slide 136 text
Scale out,
not up
Slide 137
Slide 137 text
The goal:
Simple, self contained
systems, interacting with
one another…
Slide 138
Slide 138 text
The goal:
… supported by teams
who are iterating each
system independently, to
meet complex user needs.
Slide 139
Slide 139 text
Prefer duplication
over dependency
Slide 140
Slide 140 text
Dependencies
introduce blockers
Slide 141
Slide 141 text
You don’t want
blockers when
you’re iterating
quickly
Slide 142
Slide 142 text
But what about
legacy?
Slide 143
Slide 143 text
“APIs for
applications”
Slide 144
Slide 144 text
Teams create APIs
for services they
consume
Slide 145
Slide 145 text
legacy system
new service
intermediary API
new system
Slide 146
Slide 146 text
Longer term:
modernise your
existing systems
Slide 147
Slide 147 text
Longer term:
upgrade
functionality,
peicemeal
Slide 148
Slide 148 text
legacy system
new service
intermediary API
❌ ⬅ manual at first