Download to read offline
What needs to be true? Patterns of engineering agility
- 1. Andy Norton @andyjnorton (🤦) @andynorton@mastodon.social Whatneeds to be true? Patterns of engineering agility
- 3.
- 4.
- 5. I want totalk about a fl ywheel for engineering agility
- 6. Patterns that helpus to get to what good looks like
- 7. Patterns that help changeto stick
- 8. Change that sticks ishard though
- 9. So, what needsto be true for this to happen?
- 10. #1 That weneed an operating system for our organisations #2 That we use constraints to our advantage #3 That we anticipate phase changes of scaling #4 That we utilise the power of communities #5 That we use improvement kata checkpoints Better engineering outcomes
- 11. #1 That weneed an operating system for our organisations
- 13. "An operating systemis a set of norms and actions that are shared with everyone in the company”
- 15. A good operatingsystem makes it clear, at every level, what we’re trying to achieve, how to communicate progress, and how to measure achievement
- 16.
- 17. Mission The driving forcethat guides decision-making, strategy and actions Objectives The specific strategies and actions that will be taken Principles The core set of values, and how we stay true to the Why and How
- 18. What does good looklike? How do we make a decision here? How do we know if we’re on the right path?
- 19. Once an organisationdoesn't fit in a room anymore… you need an operating system
- 20. Touchstone documents for your operatingsystem The vision, and mission The principles of how we work What each team’s purpose is, and how they interact with others The objectives for the next 12 months
- 25.
- 26. But it’s asliding window of knowledge. New person ☁☁ ☁ ☁ ☁
- 27. You need tosave your organisation’s memory to an operating system
- 28. Mission Objectives Principles Strategic planning TeamAPIs Goals Metrics RACI Management mechanisms Communication and documentation practices Operating cadence
- 30. #1 That weneed an operating system for our organisations
- 31. #2 That weuse constraints to our advantage
- 32. We need toface up to our organisational constraints, and put some of our own in place.
- 33. How do wefind them? 🔎
- 34. If you’re struggling tofind constraints, focus on your value stream. https://www.vige.se/blog/2021/12/2/how-to-illustrate-a-value-stream-a-proposal-and-a-request-for-input
- 35. A series ofactions that need to be taken in order to deliver value to a customer Operational value stream Development value stream The series of activities required to transform a business need into a product or service that creates value for a customer The development value stream enables the operational value stream
- 41. Your homework fornext week
- 42. Not all constraintsare bad (some can be really helpful)
- 43. Explain complex thingsusing only the 1000 most common words in the English language
- 44.
- 45. “Big group ofpeople together talking about why other people don’t talk to each other enough”
- 46. Some practical examplesof useful constraints…
- 47.
- 48.
- 49.
- 50. Guard rails are ourtable stakes. Teams should… have monitoring, alerting and run-books set up build dashboards about business transactions only communicate with other teams systems async have CI/CD from day one
- 51.
- 53.
- 54. A shared understandingof what good can look like Build a golden path
- 55.
- 56.
- 57. Not just thebig picture
- 58. Guide rails Guard rails Walkingskeleton Technical blueprints Golden path
- 60. #1 That weneed an operating system for our organisations #2 That we use constraints to our advantage
- 61. #3 That we anticipatephase changes of scaling
- 62. What does ascaling organisation look like?
- 63. Moving fast, buttaking on debt Hiring more managers, decoupling, and improving tools Building platforms, redoing things, and splitting into different units Scaling happens in phases
- 64. Things we talk aboutwhen we talk about scaling Things we don’t talk about when we talk about scaling
- 65. The organisation doesn't fitin a room anymore And you probably aren't in all the channels on Slack* * or Teams, sorry about that
- 66. Things that really don'tscale well Capabilities Brent Communication The things we’re learning
- 67. You can't sharehats anymore The skills of today aren't necessarily the skills of tomorrow You're more likely to be doing 1 thing well, versus 3 things okay-ish Capabilities
- 68. The capabilities wehave • What skills we have across the teams, and capabilities we currently have The capabilities we need • What skills we need to develop and the capabilities that will allow us to scale effectively If these don’t align, we need to codify the difference
- 69. - Bias foraction - Prototyping - Lean agile approach - Design sprints - Experimentation - Data driven - Observability - Product thinking across roles - Strategic domain-driven design - Facilitation - Delivery management - Continuous improvement - Standardisation - Value stream management
- 70. How do weanticipate future scale?
- 71. "I wisely startedwith a map” - J.R.R. Tolkien
- 73. For each thingwe do, do we build it or buy it? Is it experimental, or a commodity? Does it give us a competitive advantage or is everyone doing it?
- 74. Competitive Advantage Costof doing business Driven by gut Driven by metrics High future worth Reducing margin
- 75. So, we’ve scaledup, we’ve seen what the future looks like, and now my brain hurts.
- 76.
- 77.
- 78.
- 79. Intrinsic • learning newtech stacks and tools • understanding complex problem domains • coordinating efforts • technical decision making • table stakes Germane • workshopping • maturing practices • knowledge stewardship • collaboration • deliberate practice • innovative problem solving • novel learning that can become intrinsic over time Extraneous • difficult processes • unclear decision making • fragmented data sources • having to go back and validate everything • i’m in Jira hell
- 80. Teams need towork with abstractions to balance their cognitive load We need a Platform team to provide a starter kit for AWS We don’t want to have to calculate the stock ourselves, we’ve got a finance domain to model We need to focus on user needs, not user access
- 81. But there’s workthat falls between the teams Who is going to make sure we align our approach to using Datadog? How do we start using AWS in this team? How do we agree on our Event-driven architecture?
- 82. Working Groups Enabling Teams Platform Teams Wecan use different types of teams to balance cognitive load.
- 83. Enabling teams tochange the foundations Enabling Teams • How we migrate from GCP to AWS? • How do we embed good practices? • Collaborates closely with teams for a period of time until they’re no longer needed Working groups to define things and put in place stop-gaps Working Groups • Bring people with expertise together • How do we agree good practices? • Short-lived around a problem
- 84.
- 86. Scaling introduces capabilitygaps Use Wardley mapping for situational awareness Balance our cognitive load Enabling Teams Working Groups Use different team types to fi ll capability gaps
- 87. #1 That weneed an operating system for our organisations #2 That we use constraints to our advantage #3 That we anticipate scaling phase changes
- 88. #4 That weutilise the power of communities
- 91. Now I’m onlywearing 1 hat instead of 3, how do I get better at my role? How do we take what we’re learning and codify it? I’ve just joined, what’s our joined up approach to doing this thing?
- 92. Communities are custodians ofcommunal memory and knowledge
- 93. Communities help organisations get betterat… The definition of the roles Making learning and development integral work Developing the core capabilities of a business function
- 94. Don’t take myword for it…
- 95. “We will spendtime as a group to learn about X, decide if it’s useful and implement it as a new standard across our teams in the next few months.”
- 96. Communities need people tomanage them.
- 99. #1 That weneed an operating system for our organisations #2 That we use constraints to our advantage #3 That we anticipate phase changes of scaling #4 That we utilise the power of communities
- 100. #5 That weuse improvement kata checkpoints
- 101. Supporting change is hard. Changeintroduces capability gaps in people. Having capability gaps is scary, and can lead to resistance to change.
- 102. We need inflection points,nudges and a plan.
- 103.
- 104.
- 105. 4 steps tomaking change stick Start with an agreed measure of what good looks like Look at where the team currently is in relation to the standard, what top capabilities do we want to improve? Looking at our current state, what can we change to enable this capability We pick the top 4-6 things we’re going to improve
- 106. 1. Find anagreed measure of what good looks like
- 107. 2. Look atwhere the team currently is in relation to the standard, pick the top capabilities we want to improve
- 108. 3. Given currentstate, and the suggested work, where are the gaps now? What tangible work is required to improve things? 🥇 🥈 🥉
- 109. 4. Push theimprovements into the next cycle of work for the team, this improvement work should link back to our agreed standards
- 110. Make them regularceremonies, record the results, and compare
- 112. How do weknow if we’re getting better?
- 113. Apply fitness functions Quantitativemeasure that gives us a dial - think ‘warmer, colder’ “Are we moving towards or away from our goal?”
- 114. What percentage ofour users go through the new shiny API we’ve been working on? What’s our lead time? How many meetings do we have on no-meetings Wednesday?
- 115. #1 That weneed an operating system for our organisations #2 That we use constraints to our advantage #3 That we anticipate phase changes of scaling #4 That we utilise the power of communities #5 That we use improvement kata checkpoints Better engineering outcomes
- 118.