Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Continuous Transformation Reference Card

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

  • Be the first to comment

  • Be the first to like this

Continuous Transformation Reference Card

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

×