Agile Cambridge - What needs to be true? Patterns of engineering agility

What practices help us to scale in a sustainable way for the people behind the process? What capabilities do we need to be intentional about, and what techniques can we leverage?

What needs to be true?

Transcript

1. Andy Norton
 @andyjnorton (!) @andynorton@mastodon.social What needs to be true? Patterns of engineering agility
3. For a round?!
4. Hello, I’m Andy.
5. I want to talk about a flywheel for engineering agility
6. Patterns that help us to get to what good looks like
7. Patterns that help change to stick
8. Change that sticks is hard though
9. So, what needs to be true for this to happen?
10. #1 That we need 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 we need an operating system for our organisations
13. "An operating system is a set of norms and actions that are shared with everyone in the company”
15. A good operating system makes it clear, at every level, what we’re trying to achieve, how to communicate progress, and how to measure achievement
16. Boundless autonomy
17. Mission The driving force that 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 look like? How do we make a decision here? How do we know if we’re on the right path?
19. Once an organisation doesn't fit in a room anymore… you need an operating system
20. Touchstone documents for your operating system 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. Organisations have a memory
26. But it’s a sliding window of knowledge. New person ☁☁ ☁ ☁ ☁
27. You need to save your organisation’s memory to an operating system
28. Mission Objectives Principles Strategic planning Team APIs Goals Metrics RACI Management mechanisms Communication and documentation practices Operating cadence
31. #1 That we need an operating system for our organisations
32. #2 That we use constraints to our advantage
33. We need to face up to our organisational constraints, and put some of our own in place.
34. How do we find them? #
35. If you’re struggling to find 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
36. A series of actions 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
42. Your homework for next week
43. Not all constraints are bad (some can be really helpful)
44. Explain complex things using only the 1000 most common words in the English language
46. “Big group of people together talking about why other people don’t talk to each other enough”
47. Some practical examples of useful constraints…
48. Guide rails
49. Guard rails
50. Guard rails
51. Guard rails are our table 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
52. Build a walking skeleton
54. Technical blueprints
55. A shared understanding of what good can look like Build a golden path
56. TDD Observability Pairing Trunk-based Serverless Event-driven
57. Focus on patterns
58. Not just the big picture
59. Guide rails Guard rails Walking skeleton Technical blueprints Golden path
61. #1 That we need an operating system for our organisations #2 That we use constraints to our advantage
62. #3 That we anticipate phase changes of scaling
63. What does a scaling organisation look like?
64. Moving fast, but taking on debt Hiring more managers, decoupling, and improving tools Building platforms, redoing things, and splitting into different units Scaling happens in phases
65. Things we talk about when we talk about scaling Things we don’t talk about when we talk about scaling
66. The organisation doesn't fit in a room anymore And you probably aren't in all the channels on Slack* * or Teams, sorry about that
67. Things that really don't scale well Capabilities Brent Communication The things we’re learning
68. You can't share hats 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
69. The capabilities we have • 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
70. - Bias for action - 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
71. How do we anticipate future scale?
72. "I wisely started with a map” - J.R.R. Tolkien
74. For each thing we 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?
76. Competitive Advantage Cost of doing business
77. Competitive Advantage Cost of doing business Driven by gut Driven by metrics
78. Competitive Advantage Cost of doing business Driven by gut Driven by metrics High future worth Reducing margin
79. So, we’ve scaled up, we’ve seen what the future looks like, and now my brain hurts.
80. Agile conference bingo Cognitive load Dunbars number Conway’s law Cognitive load Dunbars number Conway’s law Cognitive load Dunbars number Conway’s law Cognitive load Dunbars number Conway’s law Cognitive load Dunbars number Conway’s law Cognitive load Cognitive load Conway’s law Dunbars number Wardley maps Team Topologies Team Topologies Dunbars number Team Topologies Wardley maps
81. Agile conference bingo Cognitive load Dunbars number Conway’s law Cognitive load Dunbars number Conway’s law Cognitive load Dunbars number Conway’s law Cognitive load Dunbars number Conway’s law Cognitive load Dunbars number Conway’s law Cognitive load Cognitive load Conway’s law Dunbars number Wardley maps Team Topologies Team Topologies Dunbars number Team Topologies Wardley maps
82. Cognitive load 101
84. Intrinsic • learning new tech 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
85. Intrinsic • learning new tech 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
86. Teams need to work 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
87. But there’s work that 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?
88. Working Groups Enabling Teams Platform Teams We can use different types of teams to balance cognitive load.
89. Enabling teams to change 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
90. Enabling Teams https://esilva.net/articles/architecture-modernization-enabling-team Architecture Modernisation Enabling Team
92. Scaling introduces capability gaps Use Wardley mapping for situational awareness Balance our cognitive load Enabling Teams Working Groups Use different team types to fill capability gaps
93. #1 That we need an operating system for our organisations #2 That we use constraints to our advantage #3 That we anticipate scaling phase changes
94. #4 That we utilise the power of communities
97. Now I’m only wearing 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?
98. Communities are custodians of communal memory and knowledge
99. Communities help organisations get better at… The definition of the roles Making learning and development integral work Developing the core capabilities of a business function
100. Don’t take my word for it…
101. “We will spend time 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.”
102. Communities need people to manage them.
105. #1 That we need 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
106. #5 That we use improvement kata checkpoints
107. Supporting change is hard. Change introduces capability gaps in people. Having capability gaps is scary, and can lead to resistance to change.
108. We need inflection points, nudges and a plan.
109. https://blog.crisp.se/2013/05/14/jimmyjanlen/improvement-theme-simple-and-practical-toyota-kata
110. DevOps practices Delivery methods Testing approach Incident management Service readiness Observability Value stream mapping Cognitive load assessment Team API review
111. 4 steps to making 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
112. 1. Find an agreed measure of what good looks like
113. 2. Look at where the team currently is in relation to the standard, pick the top capabilities we want to improve
114. 3. Given current state, and the suggested work, where are the gaps now? What tangible work is required to improve things? $ % &
115. 4. Push the improvements into the next cycle of work for the team, this improvement work should link back to our agreed standards
116. Make them regular ceremonies, record the results, and compare
118. How do we know if we’re getting better?
119. Apply fitness functions Quantitative measure that gives us a dial - think ‘warmer, colder’ “Are we moving towards or away from our goal?”
120. What percentage of our 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?
121. #1 That we need 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
124. Thank you!