Laws of motion

Overcoming the challenges of digital transformation in your organisation.

Transcript

1. Laws of motion Overcoming the challenges of digital transformation in your organisation Lindsay Holmwood
2. 1. Where are we now? 2. Where do we want to be? 3. How do we start? 4. What happens next?
3. High-performing IT organisations report experiencing: 200x more frequent deployments
4. High-performing IT organisations report experiencing: 24x faster recovery from failures
5. High-performing IT organisations report experiencing: 3x lower change failure rate
6. High-performing IT organisations report experiencing: 2,555x shorter lead times
7. High-performing IT organisations report experiencing: 22% less time on unplanned work and rework
8. High-performing organisations decisively outperform their lower- performing peers in terms of throughput.
10. Where are we now? (In the APS)
11. IT as a cost centre
12. Delivery approach: Buy and adapt
13. custom product & commodity
14. Buy and adapt: Upfront requirement gathering
15. Buy and adapt: Long procurement cycles
16. Inward looking
17. Supporting people and activities within your organisation
18. Guardians of legacy heritage
19. Heritage: Systems that are why our organisations are still here
20. Fragile software
21. High defect rates
22. High-performing IT organisations report experiencing: 3x lower change failure rate
23. Low user satisfaction (if we know what it is at all)
24. Slow turnaround on even simple changes
25. Hierarchical management
26. “Cylinders of excellence”
27. People grouped around functional specialties
28. “The developers”
29. “Ops team”
30. PMO
31. Work bounces between groups
32. High-performing IT organisations report experiencing: 2,555x shorter lead times
33. Resilient
34. Where do we want to be? (if we’re serious about digital transformation)
35. • IT as a cost centre • Technology as a value driver nope
36. Outward looking
37. User Centred Design
38. “What is the user need?”
39. Delivering services to support users outside your organisation
40. Who are your users?
41. The public is a user
42. Your organisation is also a user
43. You can not sustainably meet user needs if you are not meeting your own needs at the same time.
44. Sustainable, resilient, internal capability
45. Multidisciplinary teams
46. Augmented by private sector expertise
47. Teams organised around services
48. Services built for end-to-end task completion
49. Do the hard work to make it easy for users
50. Delivery approach: Leverage and iterate
51. Leverage and iterate Knowing when & where to re-use, build, or buy
52. Leverage and iterate Eliminate undifferentiated heavy lifting
53. commodity custom
54. Leverage and iterate Use Open Source
55. Leverage and iterate Use the ☁ (Software & Platforms & Infrastructure as a Service)
56. ☁ Software
57. Leverage and iterate SaaS: Support and ticketing systems (JIRA, Zendesk, GitHub)
58. ☁ Software ☁ Platform
59. Leverage and iterate PaaS: Application runtime and resiliency (Heroku, Cloud Foundry)
60. ☁ Infrastructure ☁ Software ☁ Platform
61. Leverage and iterate IaaS: Hosting (AWS, Azure, Vault, GCP) IRAP accredited by ASD
62. ☁ Software ☁ Infrastructure ☁ Platform digital service
63. Risk management approach:
64. minimise technology investment risk
65. integration not adaptation
66. “Give me an API, or give me death”
67. interoperability through high quality APIs
68. more options down the road
69. your systems end up being more resilient in the face of change
70. But harder work because you must grow & maintain a high performing culture
71. But harder work that supports a highly skilled software engineering workforce
72. Redesigning the org to better meet policy and service delivery outcomes
73. Feedback loops built in to the software we ship
74. Feedback loops supporting hypothesis driven development
75. Meeting objectives on-time & on-budget
76. High-performing IT organisations report experiencing: 22% less time on unplanned work and rework
77. Meeting objectives on-time & on-budget: data driven
78. Meeting objectives on-time & on-budget: weekly granularity
79. Meeting objectives on-time & on-budget: reported up and out
80. 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
81. “People with targets […] will probably meet the targets - even if they have to destroy the enterprise to do it.” – Deming
82. Where do we start?
83. Start on the edges
84. Pick a small problem
85. Understand and serve a user need (as well as a government need)
86. You can not sustainably meet user needs if you are not meeting your own needs at the same time.
87. Use the Digital Service Standard as the guide for what good looks like
88. Start with this
89. Then do this
90. Then this
91. Create small, multi-disciplinary teams
92. Template: 1x front end developer 1x back end developer 1x user experience designer 1x agile coach (part time)
93. Use the Digital Service Standard as the guide for what good looks like
94. No executive sponsorship? Don’t even bother.
95. Set delivery constraints
96. ⏰ Time Budget Scope (pick 2)
97. Build the smallest, simplest thing that meets a user need
98. “You build it, you run it” – Vogels, AWS
99. Don’t change what tech you use
100. Change how you use that tech
101. Don’t blow your innovation budget on experimenting with tech
102. All changes go through a Continuous Delivery pipeline
103. deploy to production acceptance tests integrate unit tests code done Continuous Delivery Manual Auto Auto Auto
104. Multiple deploys a day
105. High-performing IT organisations report experiencing: 200x more frequent deployments
106. Code doesn’t create value until it is running in front of a user
107. Ship usable software multiple times a day
108. Write high level acceptance tests (like Cucumber)
109. An executable specification
110. 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
111. Nail your automated delivery pipeline from the start
112. Decouple what you build from existing systems
113. Build in isolation
114. Don’t create dependencies
115. Manual processing is OK
116. No point investing in automation until you have validated the service meets a user need
117. Risk: you automate the wrong thing
118. automation is a means
119. meeting a user need is the end
120. manage team workload by: only sending a percentage of the workload to the service
121. Bonus: build empathy with users by doing the grunt work
122. What happens next?
123. DO NOT DISBAND THE TEAM
124. The team don’t get reabsorbed
125. The service doesn’t get lobbed over the wall
126. It’s not a one-off
127. It’s not a project
128. It’s a long lived service
129. Team and service need to be resilient
130. Team continues with the service
131. No executive sponsorship? Don’t even bother.
132. “This worked well! Let’s scale it up!”
133. Limit scope creep
134. Amazon’s two pizza teams rule
135. Don’t aim for economies of scale
136. Scale out, not up
137. The goal: Simple, self contained systems, interacting with one another…
138. The goal: … supported by teams who are iterating each system independently, to meet complex user needs.
139. Prefer duplication over dependency
140. Dependencies introduce blockers
141. You don’t want blockers when you’re iterating quickly
142. But what about legacy?
143. “APIs for applications”
144. Teams create APIs for services they consume
145. legacy system new service intermediary API new system
146. Longer term: modernise your existing systems
147. Longer term: upgrade functionality, peicemeal
148. legacy system new service intermediary API ❌ ⬅ manual at first
149. Event sourcing
150. https://developers.soundcloud.com/blog/building-products-at- soundcloud-part-1-dealing-with-the-monolith
151. https://developers.soundcloud.com/blog/building-products-at- soundcloud-part-1-dealing-with-the-monolith
152. https://developers.soundcloud.com/blog/building-products-at- soundcloud-part-1-dealing-with-the-monolith
153. Short term: It’s not about modernising your legacy
154. It’s about providing services that meet user needs
155. It’s about organising people in your organisation to meeting those user needs
156. It’s about building the future of how your organisation works
157. The biggest challenge:
158. Minimal software engineering culture in the APS
159. Leverage and iterate Knowing when & where to re-use, build, or buy
160. Limiting and managing risk
161. commodity custom
162. We must drive a cultural change in technology delivery
163. We do that by attracting talent & cultivating the talent we have
164. We do that with modern technology delivery practices like continuous delivery
165. We do that by reinforcing the resiliency of our organisations
166. “If the government was a private company, it would go out of business”
167. Great sound bite
168. Counterfactual
169. Government is not a private company
170. Businesses are designed to fold
171. When a business fails: People become unemployed.
172. When a business fails: Assets are liquidated.
173. When a business fails: Creditors are paid.
174. When a business fails: Shareholders loose cash.
175. When a business fails: If there is demand, other businesses in the market will fill that gap.
176. Governments are designed not to fail
177. Government is designed to be resilient
178. When a government fails: The underpinning of a society disappears.
179. When a government fails: Folk-systems emerge to fill the gaps.
180. When a government fails: Inequality and inequity thrive.
181. When a government fails: People get hurt. People die.
182. Government has built-in inertia
183. Inertia is linked to resilience
184. Government is designed to be resistant to change
185. Digital transformation of government means changing something designed not to change
186. Resilience is our greatest strength and our greatest weakness
187. Newton’s first law an object at rest stays at rest
188. Newton’s first law an object in motion stays in motion
189. Newton’s first law an object in motion stays in motion with the same speed
190. Newton’s first law an object in motion stays in motion with the same speed and in the same direction
191. Newton’s first law unless acted upon by an unbalanced force
192. Digital transformation is your unbalanced force
193. We must drive a cultural change in technology delivery
194. We do that not by changing the technology we use
195. We do that by changing the how we use that tech
196. We do that with modern technology delivery practices like continuous delivery
197. We do that by attracting talent & cultivating the talent we have
198. I’m Lindsay
199. Thank you