Fragile to Agile: Principles and Patterns

Introduction

What is Fragility

Change breaks stuff
Organization lives in fear of their technology landscape The consequences of fragility and faux-anti-fragility aka robustness

What is Agility

We look at this from a lean business process perspective We also look at agility from an anti-fragile/change-philic perspective

Things

• People
• Process
• Technology

Organizational Patterns

• [ANTIPATTERN] Balkanization
  creates a counter-productive Us v Them environment. For example, “here we have our AWS team. Over there is our Azure team. And on the floor below is our VMWare datacenter team.”
• [ANTIPATTERN] Knowledge Hoarding
  opposite of Knowledge Sharing, creating unnecessary cost and risk for the organization
• [ANTIPATTERN] Fear is a management tool
  People who are afraid are less effective than people who are happy.
• [ANTIPATTERN] Fail fast
  Folks are emerging that use fail fast as an apology for creating shoddy solutions. Failing fast is something that is enabled by an organization that manages to achieve; High frequency of delivery, Low rates of service disruption/product quality issues, Rapid rates of service recovery/product remediation, Low lead times to value. If you’re not doing exceptionally well on all four measures then failing fast is not an option for you.

Process Patterns

• [ANTIPATTERN] Scrummerfall
  You usually end up with the worst of both worlds. This is often implemented by folks with a waterfall delivery bias in an attempt to “prove” that Agile delivery doesn’t work.
• Small batch sizes
  read your lean

Engineering Patterns

• Tier-based Architecture
  Reinforce service reuse and place the management and control planes and processes as first-class citizens of solution design
• Remove Source of Truth from the data plane
  you’ll be a lot less afraid of changing your system when you do
• Shift Security Left
  This doesn’t mean make Development accountable for security. It means make it easy for Development to be compliant with security.
• Loosely Coupled Architecture
  This is not intended to be just a cool thing. Loosely-coupled design is intended to speed decision-making by reducing dependencies that required consultation for change. Contract-first design is a subset (or an analog depending on who you ask) for loose-coupling.