This document provides 10 strategies for technology transformation organized around the principles of Agile, Lean, and DevOps (ALDO). The strategies are: 1) Create cross-functional teams focused on customer delivery; 2) Create a vision based on real customer needs; 3) Update products regularly to maintain competitive differentiation; 4) Create full-stack teams serving single products; 5) Involve compliance teams early in projects; 6) Operate at high velocity to respond quickly to new requirements; 7) Manage infrastructure configurations with code; 8) Support expert knowledge sharing across projects; 9) Identify team learning objectives in sprint planning; 10) Transform problems incrementally within existing projects. The overall approach is to deliver software continuously in small increments

1. Scaling Awesome
10 Actionable Strategies for Technology Transformation
Justin Arbuckle
VP Worldwide Transformation
ja@chef.io
@dromologue

2. The Big Idea Deliver software to customers really
fast, in small increments. Each increment is an
opportunity for reflection and action better to
serve and profit your customers and improve the
teams that serve them.
ALDO = Agile, Lean, DevOps Outcomes

3. Big Reveal The same principles that guide software
development, also inform the transformation to a
high velocity software business.

4.  How long is the average project in your organisation?
1. Silos Lead to Supervision that is Slow and
Ineffective
Therefore… Create teams that cut across those silos with an obsessive
focus on delivery of value to the customer and not the function.

5.  Which of your (business) teams battles the most to attract internal IT talent?
2. Anticipation of the Future is Futile – i.e. you
keep wasting money on features nobody uses.
Therefore… Create a vision that is contingent on what you discover
about real customer needs when you deploy it incrementally

6.  How often do your developers interact with business product owners?
3. Competitive differentiation by feature is
short lived anyway (Race to the Middle)
Therefore… assume your customer is always switching and create more
regular opportunities to update your product

7.  When asked, do your staff self identify with their organisation locations or skill sets?
4. Focus on specialized teams creates
alignment with function not product
Therefore… Never plan to centralize your DevOps capability. Create full
stack teams that serve single products.

8.  How does MTTR for incidents in production compare to the time taken to implement a CR?
5. Compliance assurance requires deep
domain knowledge not usually available
Therefore…abolish CAB’s and after-the-fact compliance reviews in
favour of early and sustained involvement in the project and shared
commitment to the customer outcome.

9.  How many 180 day audit findings do you have pending?
6. Pivoting requirements due to compliance
or changed customer needs is costly
Therefore… operate your software delivery workflow at high velocity,
enabling fast reponses to new requirements.

10.  What percentage of VM’s requested are consumed without further customisation?
7. Standardized infrastructure configuration lags
behind the needs of application developers
Therefore… configure your environments with code and manage this
with the same workflow you use for application code.

11.  How often do teams successfully implement new technology counter standard?
8. Sharing and consolidating expert knowledge is
difficult when experts are distributed.
Therefore… Enable communities of practise in any area that requires the
sharing of knowledge across projects. Practise is always be subordinated to
product but shower your communities with support.

12.  On average how many training courses or conferences will a developer attend in a year?
9. Teams focus so much on delivering software
that they have little time for improvement
Therefore… identify team learning and improvement objectives in every
team’s sprint backlog and give them equal weight to features.
(Two Product Principle)

13.  What was the last large organisation-wide initiative in which you participated?
10. Organisation-wide Transformation is complex,
overwhelming and seldom successful
Therefore… Identify a current well-known problem and use an existing
project to create a crucible for its solution. Transform one problem, one
project at a time.

14. Putting it all together…ABC
A
Of the 8 Strategies,
which (ones) resonate
the most with you?
B
Of your current
projects under way,
which would benefit
most from those
strategies?
B
For this project, what is
your priority?
i. Cost & Consistency
ii. Compliance
iii. Speed to Market
Let’s get to work.

15. A Scaleable Transformation
CHEF Fund.
Training
2 Days
DTW
Project Workshop
3 Days
Technology Workshop
2 Days
Project Close-
Out
(8 weeks)
Coaching, Training and Consulting
Candidate projects are identified in the
workshop and then supported by CHEF
DevOps Transformation Programme Delivery by Transformation Team
Create a team that operates as you wish to continue. We help you tool and scale.

16. Appendix

17. Continuous Transformation Reference Card
Deciding What to Do
ALDO
Strategy - Why we Change
Product - What we Change
Technology - Tools to Change
Process - How we Change
Structure - Who Changes
Agile, Lean, DevOps Outcomes
“We will deliver great software fast, learning in small
increments from our customers and from each other so
that our products and teams improve continuously”
Create constancy of purpose within a full stack team
Individuals alone don’t change organisations
Deliver small increments TO THE CUSTOMER (PROD)
Visible work from Product Owner to Engineer
New
Existing
Operating
Chasm
Every product is a software product
Organisations are compliant to the extent they
enforce it with code
Automate for Consistency, Velocity and Scale ◦
Anything not in production is a science experiment
Create Events that challenge organisational dogma
Describing Where You Are
Conway’s Law : Organisations create systems that reflect
their communication structure
Anticipating the Outcome shapes the future with the past
Value comes from reduced friction
My Organisation’s Context
My Team’s Context
My Context
Software is eating the world
Beliefs transform models which transform facts
facts
models
beliefs
Silos beget Supervision.
Supervision begets more supervision
The myth of Control: You cant control what you cant
comprehend
Change flows upward
www.chef.io
Designing How to Do it
Events Change Organisations
Strategy - Why we Build
Product - What we Build
Technology - Tools to Build
Process - How we Build
Structure - Who Builds
“Solve a known problem thought unsolvable, by delivering
customer visible value, using a full stack team delivering at
high velocity and improving every 2 week increment.”
We build to deploy, we deploy to learn. Fast feedback
loops.
The 2 Product Principle: You are always shipping two
products; the customer visible features and an internal
product that is the capability the organisation invests in to
build the product. Ensure you improve both continually. De-Centre your excellence
Everyone has a home team(s)
Create communities of practice that build shared
understanding of complex problems and competency in
solving them
The Law of Equal Velocities: Delivery will be at the rate
of the slowest component of your technology pipeline
Put infrastructure and applications through the same
continuous delivery workflow
Customer visible value every increment! Break up stories
to enable this and build bigger frameworks incrementally
hidden behind the visible features.
HSM: Identify an experience the customer will
positively react to - emotionally - and will drive
feedback through usage.
Discovering What you Have Learnt
Learning in my Organisation
Learning in my Team
Learning by Me
The Crucible: Run the IOTA model over at least 10 iterations,
using ROAR to generate shared understanding of the next 2
week sprint.
The HSM keeps you on track.
Produce measures of success based on your targets that your product owner uses to argue
for more funding or priority and to direct the next increment.
Is my HSM still valid?
What can I do to enable my learning?
Time – iterations of ROAR
Clarity of Team
CHEF Server | CHEF Compliance | CHEF Delivery

18. Continuous Transformation Reference Card
REST
00:03
ORIENT
00:02
ACT
00:05
REFLECT
00:05
Theory Action
Inside-Out
Outside-In
IOTA Product ModelROAR Timing ELSA Change Model
Hypotheses
Capabilities (Product 1) Conditions (Product 2)
Targets
Event
Language
Structure
Agency
Assumptions and constraints we
need to validate.
Examples:
X feature will attract customers
because…
Y capability in the enterprise will be
available for us to use.
What we think we should build:
- Features for customers now
- Features enabling customer
features later.
- Features to delight and surprise.
What we need to build to test our
hypotheses.
What team conditions could be
improved to enable us to build, deliver
and learn better.
Examples:
We are bad at X and it impacts our
product quality so we need to..
We are bad at Y and it impacts our
velocity so we …
Measures that test whether our
hypotheses were correct.
It’s ok to be wrong! It’s just one
iteration.
Something that proves
what was NOT possible
actually is!
Normal change
programmes start here.
Low chance of
success.
Informal structures, created by
people self-organizing around
problems and available tools.
Freedom to act.
Empowerment of staff to
solve problems that matter
to them.
www.chef.io
Run multiple iterations for sprint planning.
15 mins. To Live
Development & testing
on a local VM
Push to a Source
Code
Management
tool (e.g. GIT)
Review of Code
(by Security,
Compliance and
Peers)
Acceptance
Application
Database
Middleware
OS
Union
Infrastructure as
Code
Application as
Code
Compliance as
Code
Rehearsal