Lean Agile Manchester 28/02/2024 - What needs to be true? Patterns of engineering agility

What patterns and 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
2. Hello, I’m Andy.
3. I want to talk about a fl ywheel for engineering agility
4. Patterns that help us to get to what good looks like
5. Patterns that help change to stick
6. Change that sticks is hard though
7. So, what needs to be true for this to happen?
8. #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
9. #1 That we need an operating system for our organisations
11. "An operating system is a set of norms and actions that are shared with everyone in the company”
13. 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
15. 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
16. What does good look like? How do we make a decision here? How do we know if we’re on the right path?
17. Once an organisation doesn't fit in a room anymore… you need an operating system
18. 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 strategic intents for the next 3-6 months
23. Organisations have a memory
24. But it’s a sliding window of knowledge. New person ☁☁ ☁ ☁ ☁
25. You need to save your organisation’s memory to an operating system
26. Mission Objectives Principles Strategic planning Team APIs Goals Metrics RACI Management mechanisms Communication and documentation practices Operating cadence
28. #1 That we need an operating system for our organisations
29. #2 That we use constraints to our advantage
30. We need to face up to our organisational constraints, and put some of our own in place.
31. How do we find them? 🔎
32. 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
33. 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
39. Your homework for next week
40. Not all constraints are bad (some can be really helpful)
41. Explain complex things using only the 1000 most common words in the English language
42. ?
43. “A group of people meeting up to talk about why other people don’t talk to each other enough”
44. Some practical examples of useful constraints…
45. Guide rails
46. Guard rails
47. Guard rails
48. 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
49. Build a walking skeleton
51. Technical blueprints
52. A shared understanding of what good can look like Build a golden path
53. TDD Observability Pairing Trunk-based Serverless Event-driven
54. Focus on patterns
55. Define Principles Doctrine • Doctrine are universally useful principles that are applicable to all industries regardless of the landscape and it’s context. Strategic imperatives • Strategic priorities are specific, focused directives or goals that an organisation sets to guide it’s actions and decisions, aiming to steer the culture and operations in a desired direction.
56. Wardley’s Doctrine • Phase 4: Continuously Evolve • Phase 1: Stop Self-Destructive Behaviour • Phase 2: Become More Context Aware • Phase 3: Better for Less
57. Wardley’s Doctrine Use appropriate methods (e.g agile vs lean vs six sigma) Focus on user needs Remove bias and duplication Be transparent (a bias towards open) Manage inertia (e.g. existing practices, political capital, previous investment) Be pragmatic (it doesn’t matter if the cat is black or white, as long as it catches the mouse)
59. Augment doctrine with your intentional strategic imperatives, and focus on constraints
60. 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 that really don't scale well Capabilities Brent Communication The things we’re learning
66. 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
67. - Bias for action - Prototyping - Design sprints - Experimentation - XP - Data driven - Observability - Product thinking across roles - Strategic domain-driven design - Facilitation - Lean agile approach - Delivery management - Continuous improvement - Standardisation - Value stream management
68. How do we anticipate future scale?
69. "I wisely started with a map” - J.R.R. Tolkien
71. 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?
72. Competitive Advantage Cost of doing business Driven by gut Driven by metrics High future worth Reducing margin
73. So, we’ve scaled up, we’ve seen what the future looks like, and now our brain hurts.
74. Cognitive load 101
75. 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
76. 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
77. 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?
78. Working Groups Enabling Teams Platform Teams We can use different types of teams to balance cognitive load.
79. Enabling Teams https://esilva.net/articles/architecture-modernization-enabling-team Architecture Modernisation Enabling Team
80. Working Groups • Decommissioning an old classifieds website • Defining a blueprint for Observability • Creating a microservice template • Improving the front-end CI/CD process
81. 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
83. Scaling introduces capability gaps Use Wardley mapping for situational awareness Balance our cognitive load Enabling Teams Working Groups Use different team types to fi ll capability gaps
84. #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
85. #4 That we utilise the power of communities
88. 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?
89. Communities are custodians of communal memory and knowledge
90. 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
91. Don’t take my word for it…
92. “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.”
96. #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
97. #5 That we use improvement kata checkpoints
98. Supporting change is hard. Change introduces capability gaps in people. Having capability gaps is scary, and can lead to resistance to change.
99. We need inflection points, nudges and a plan.
100. https://blog.crisp.se/2013/05/14/jimmyjanlen/improvement-theme-simple-and-practical-toyota-kata
101. DevOps practices Delivery methods Testing approach Incident management Service readiness Observability Value stream mapping Cognitive load assessment Team API review
102. 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
103. 1. Find an agreed measure of what good looks like
104. 2. Look at where the team currently is in relation to the standard, pick the top capabilities we want to improve
105. 3. Given current state, and the suggested work, where are the gaps now? What tangible work is required to improve things? 🥇 🥈 🥉
106. 4. Push the improvements into the next cycle of work for the team, this improvement work should link back to our agreed standards
107. Make them regular ceremonies, record the results, and compare
109. How do we know if we’re getting better?
110. Apply fitness functions Quantitative measure that gives us a dial - think ‘warmer, colder’ “Are we moving towards or away from our goal?”
111. What percentage of our users go through the new shiny API we’ve been working on? What’s our lead time? How many times do we have to manually go onto a production environment in GCP?
112. #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
115. Thank you!