Scaling Awesome - 10 Actionable Strategies for Technology Transformation
Download as PPTX, PDF0 likes173 views
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
Scaling Awesome - 10 Actionable Strategies for Technology Transformation
- 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
Editor's Notes
- #10: Field notes.