Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Lean Agile Manchester 28/02/2024 - What needs t...

Andy Norton
February 28, 2024

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?

Andy Norton

February 28, 2024
Tweet

More Decks by Andy Norton

Other Decks in Technology

Transcript

  1. #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
  2. "An operating system is a set of norms and actions

    that are shared with everyone in the company”
  3. 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
  4. 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
  5. What does good look like? How do we make a

    decision here? How do we know if we’re on the right path?
  6. 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
  7. Mission Objectives Principles Strategic planning Team APIs Goals Metrics RACI

    Management mechanisms Communication and documentation practices Operating cadence
  8. 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
  9. 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
  10. ?

  11. “A group of people meeting up to talk about why

    other people don’t talk to each other enough”
  12. 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
  13. 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.
  14. Wardley’s Doctrine • Phase 4: Continuously Evolve • Phase 1:

    Stop Self-Destructive Behaviour • Phase 2: Become More Context Aware • Phase 3: Better for Less
  15. 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)
  16. #1 That we need an operating system for our organisations

    #2 That we use constraints to our advantage
  17. 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
  18. 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
  19. - 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
  20. 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?
  21. Competitive Advantage Cost of doing business Driven by gut Driven

    by metrics High future worth Reducing margin
  22. 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
  23. 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
  24. 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?
  25. Working Groups Enabling Teams Platform Teams We can use different

    types of teams to balance cognitive load.
  26. Working Groups • Decommissioning an old classifieds website • Defining

    a blueprint for Observability • Creating a microservice template • Improving the front-end CI/CD process
  27. 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
  28. 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
  29. #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
  30. 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?
  31. 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
  32. “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.”
  33. #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
  34. Supporting change is hard. Change introduces capability gaps in people.

    Having capability gaps is scary, and can lead to resistance to change.
  35. DevOps practices Delivery methods Testing approach Incident management Service readiness

    Observability Value stream mapping Cognitive load assessment Team API review
  36. 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
  37. 2. Look at where the team currently is in relation

    to the standard, pick the top capabilities we want to improve
  38. 3. Given current state, and the suggested work, where are

    the gaps now? What tangible work is required to improve things? 🥇 🥈 🥉
  39. 4. Push the improvements into the next cycle of work

    for the team, this improvement work should link back to our agreed standards
  40. Apply fitness functions Quantitative measure that gives us a dial

    - think ‘warmer, colder’ “Are we moving towards or away from our goal?”
  41. 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?
  42. #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