A reference card used by me and my team at CHEF to summarise the key ideas in driving organisational transformation

1. 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

2. 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
Infrastructureas
Code
Application as
Code
Compliance as
Code
Rehearsal