Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Laws of motion
Search
Lindsay Holmwood
April 05, 2017
Technology
1
170
Laws of motion
Overcoming the challenges of digital transformation in your organisation.
Lindsay Holmwood
April 05, 2017
Tweet
Share
More Decks by Lindsay Holmwood
See All by Lindsay Holmwood
Your API ain't as secure as you think
auxesis
0
110
Footguns and factorisation: how to make users of your cryptographic library successful
auxesis
0
1.4k
Levelling up database security by thinking in APIs
auxesis
0
110
How to thwart your devops transformation with counterinsurgency doctrine
auxesis
1
69
Microservices are an antipattern
auxesis
0
170
Mirrors, networks, and boundaries
auxesis
0
83
Managing remotely, while remotely managing
auxesis
13
4.1k
Testing Conway’s Law in open source communities
auxesis
6
530
Building and scaling effective distributed teams
auxesis
4
200
Other Decks in Technology
See All in Technology
サービスの持続的な成長と技術負債について
siva_official
PRO
10
4.4k
CTOから見た事業開発とプロダクト開発 / My Perspective on Business and Product Development as CTO
keisuke69
4
960
AWSサービスメニュー開発をしていてAWSを好きだ!と感じた瞬間
toru_kubota
0
130
GoとアクターモデルでES+CQRSを実践! / proto_actor_es_cqrs
ytake
1
150
テスト・設計研修【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
170
成長期に歩みを止めないための創業期の開発文化形成
mayah
6
420
JBUG岡山 #6 WordCamp男木島の チームビルディング
takeshifurusato
0
150
目標設定は好きですか? アジャイルとともに目標と向き合い続ける方法 / Do you like target Management?
kakehashi
10
3k
簡単に始めるSnowflakeの機械学習
nayuts
1
190
可視化プラットフォームGrafanaの基本と活用方法の全て
hamadakoji
0
230
Azure OpenAI Service Dev Day / LLMでできる!使える!生成AIエージェント
masahiro_nishimi
3
750
VPoEの視点から見た、ヘンリーがサーバーサイドKotlinを使う理由 / Why Server-side Kotlin 2024
cho0o0
1
420
Featured
See All Featured
Raft: Consensus for Rubyists
vanstee
134
6.5k
Typedesign – Prime Four
hannesfritz
37
2.2k
Code Reviewing Like a Champion
maltzj
517
39k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
36
9.1k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
24
1.8k
No one is an island. Learnings from fostering a developers community.
thoeni
17
2.8k
Rails Girls Zürich Keynote
gr2m
93
13k
How GitHub (no longer) Works
holman
305
140k
The Language of Interfaces
destraynor
151
23k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.4k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
360
22k
Debugging Ruby Performance
tmm1
71
11k
Transcript
Laws of motion Overcoming the challenges of digital transformation in
your organisation Lindsay Holmwood
1. Where are we now? 2. Where do we want
to be? 3. How do we start? 4. What happens next?
High-performing IT organisations report experiencing: 200x more frequent deployments
High-performing IT organisations report experiencing: 24x faster recovery from failures
High-performing IT organisations report experiencing: 3x lower change failure rate
High-performing IT organisations report experiencing: 2,555x shorter lead times
High-performing IT organisations report experiencing: 22% less time on unplanned
work and rework
High-performing organisations decisively outperform their lower- performing peers in terms
of throughput.
None
Where are we now? (In the APS)
IT as a cost centre
Delivery approach: Buy and adapt
custom product & commodity
Buy and adapt: Upfront requirement gathering
Buy and adapt: Long procurement cycles
Inward looking
Supporting people and activities within your organisation
Guardians of legacy heritage
Heritage: Systems that are why our organisations are still here
Fragile software
High defect rates
High-performing IT organisations report experiencing: 3x lower change failure rate
Low user satisfaction (if we know what it is at
all)
Slow turnaround on even simple changes
Hierarchical management
“Cylinders of excellence”
People grouped around functional specialties
“The developers”
“Ops team”
PMO
Work bounces between groups
High-performing IT organisations report experiencing: 2,555x shorter lead times
Resilient
Where do we want to be? (if we’re serious about
digital transformation)
• IT as a cost centre • Technology as a
value driver nope
Outward looking
User Centred Design
“What is the user need?”
Delivering services to support users outside your organisation
Who are your users?
The public is a user
Your organisation is also a user
You can not sustainably meet user needs if you are
not meeting your own needs at the same time.
Sustainable, resilient, internal capability
Multidisciplinary teams
Augmented by private sector expertise
Teams organised around services
Services built for end-to-end task completion
Do the hard work to make it easy for users
Delivery approach: Leverage and iterate
Leverage and iterate Knowing when & where to re-use, build,
or buy
Leverage and iterate Eliminate undifferentiated heavy lifting
commodity custom
Leverage and iterate Use Open Source
Leverage and iterate Use the ☁ (Software & Platforms &
Infrastructure as a Service)
☁ Software
Leverage and iterate SaaS: Support and ticketing systems (JIRA, Zendesk,
GitHub)
☁ Software ☁ Platform
Leverage and iterate PaaS: Application runtime and resiliency (Heroku, Cloud
Foundry)
☁ Infrastructure ☁ Software ☁ Platform
Leverage and iterate IaaS: Hosting (AWS, Azure, Vault, GCP) IRAP
accredited by ASD
☁ Software ☁ Infrastructure ☁ Platform digital service
Risk management approach:
minimise technology investment risk
integration not adaptation
“Give me an API, or give me death”
interoperability through high quality APIs
more options down the road
your systems end up being more resilient in the face
of change
But harder work because you must grow & maintain a
high performing culture
But harder work that supports a highly skilled software engineering
workforce
Redesigning the org to better meet policy and service delivery
outcomes
Feedback loops built in to the software we ship
Feedback loops supporting hypothesis driven development
Meeting objectives on-time & on-budget
High-performing IT organisations report experiencing: 22% less time on unplanned
work and rework
Meeting objectives on-time & on-budget: data driven
Meeting objectives on-time & on-budget: weekly granularity
Meeting objectives on-time & on-budget: reported up and out
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
“People with targets […] will probably meet the targets -
even if they have to destroy the enterprise to do it.” – Deming
Where do we start?
Start on the edges
Pick a small problem
Understand and serve a user need (as well as a
government need)
You can not sustainably meet user needs if you are
not meeting your own needs at the same time.
Use the Digital Service Standard as the guide for what
good looks like
Start with this
Then do this
Then this
Create small, multi-disciplinary teams
Template: 1x front end developer 1x back end developer 1x
user experience designer 1x agile coach (part time)
Use the Digital Service Standard as the guide for what
good looks like
No executive sponsorship? Don’t even bother.
Set delivery constraints
⏰ Time Budget Scope (pick 2)
Build the smallest, simplest thing that meets a user need
“You build it, you run it” – Vogels, AWS
Don’t change what tech you use
Change how you use that tech
Don’t blow your innovation budget on experimenting with tech
All changes go through a Continuous Delivery pipeline
deploy to production acceptance tests integrate unit tests code done
Continuous Delivery Manual Auto Auto Auto
Multiple deploys a day
High-performing IT organisations report experiencing: 200x more frequent deployments
Code doesn’t create value until it is running in front
of a user
Ship usable software multiple times a day
Write high level acceptance tests (like Cucumber)
An executable specification
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
Nail your automated delivery pipeline from the start
Decouple what you build from existing systems
Build in isolation
Don’t create dependencies
Manual processing is OK
No point investing in automation until you have validated the
service meets a user need
Risk: you automate the wrong thing
automation is a means
meeting a user need is the end
manage team workload by: only sending a percentage of the
workload to the service
Bonus: build empathy with users by doing the grunt work
What happens next?
DO NOT DISBAND THE TEAM
The team don’t get reabsorbed
The service doesn’t get lobbed over the wall
It’s not a one-off
It’s not a project
It’s a long lived service
Team and service need to be resilient
Team continues with the service
No executive sponsorship? Don’t even bother.
“This worked well! Let’s scale it up!”
Limit scope creep
Amazon’s two pizza teams rule
Don’t aim for economies of scale
Scale out, not up
The goal: Simple, self contained systems, interacting with one another…
The goal: … supported by teams who are iterating each
system independently, to meet complex user needs.
Prefer duplication over dependency
Dependencies introduce blockers
You don’t want blockers when you’re iterating quickly
But what about legacy?
“APIs for applications”
Teams create APIs for services they consume
legacy system new service intermediary API new system
Longer term: modernise your existing systems
Longer term: upgrade functionality, peicemeal
legacy system new service intermediary API ❌ ⬅ manual at
first
Event sourcing
https://developers.soundcloud.com/blog/building-products-at- soundcloud-part-1-dealing-with-the-monolith
https://developers.soundcloud.com/blog/building-products-at- soundcloud-part-1-dealing-with-the-monolith
https://developers.soundcloud.com/blog/building-products-at- soundcloud-part-1-dealing-with-the-monolith
Short term: It’s not about modernising your legacy
It’s about providing services that meet user needs
It’s about organising people in your organisation to meeting those
user needs
It’s about building the future of how your organisation works
The biggest challenge:
Minimal software engineering culture in the APS
Leverage and iterate Knowing when & where to re-use, build,
or buy
Limiting and managing risk
commodity custom
We must drive a cultural change in technology delivery
We do that by attracting talent & cultivating the talent
we have
We do that with modern technology delivery practices like continuous
delivery
We do that by reinforcing the resiliency of our organisations
“If the government was a private company, it would go
out of business”
Great sound bite
Counterfactual
Government is not a private company
Businesses are designed to fold
When a business fails: People become unemployed.
When a business fails: Assets are liquidated.
When a business fails: Creditors are paid.
When a business fails: Shareholders loose cash.
When a business fails: If there is demand, other businesses
in the market will fill that gap.
Governments are designed not to fail
Government is designed to be resilient
When a government fails: The underpinning of a society disappears.
When a government fails: Folk-systems emerge to fill the gaps.
When a government fails: Inequality and inequity thrive.
When a government fails: People get hurt. People die.
Government has built-in inertia
Inertia is linked to resilience
Government is designed to be resistant to change
Digital transformation of government means changing something designed not to
change
Resilience is our greatest strength and our greatest weakness
Newton’s first law an object at rest stays at rest
Newton’s first law an object in motion stays in motion
Newton’s first law an object in motion stays in motion
with the same speed
Newton’s first law an object in motion stays in motion
with the same speed and in the same direction
Newton’s first law unless acted upon by an unbalanced force
Digital transformation is your unbalanced force
We must drive a cultural change in technology delivery
We do that not by changing the technology we use
We do that by changing the how we use that
tech
We do that with modern technology delivery practices like continuous
delivery
We do that by attracting talent & cultivating the talent
we have
I’m Lindsay
Thank you