I’m tired of people being required to have an account here to read information that I never paywall and Substack has better notifications.

So, to improve reader experience, I’m moving there. Hope to see you.

You can check out my latest post there.

We need to stop talking about Continuous Delivery as a way to ship features faster. That mindset drives the wrong outcomes and entirely misses the point. It also causes some to believe that CD is only for “move fast and break things” development and should not be used for critical systems. That’s entirely wrong.

For systems that matter, CD pipelines are operational safety mechanisms. They exist to protect stability, enable rapid recovery, and enforce a defensible security posture. Speed is just a fortunate side effect.

If your pipeline cannot be trusted on demand, you don’t have a delivery system. You have a liability that just hasn’t been exercised under stress yet.

Stability Is Muscle Memory

In an incident, nobody rises to the level of their architecture diagrams. They fall to the level of their practiced execution.

This is where teams bleed. When production is on fire, panic sets in. Teams improvise new delivery processes on the fly. Tests get skipped “temporarily.” Security checks are bypassed “just this once.” Someone runs a script by hand that hasn’t been touched in six months.

Each decision feels reasonable in isolation. Together, they turn a bad situation into a prolonged outage.

A working CD pipeline provides a deterministic path from change to production. It replaces judgment calls with automated verification. It allows you to deploy fixes quickly without increasing risk. But this only works if the pipeline you use in an emergency is the same one you use on a quiet Tuesday.

If you can’t confidentially say, “We can deploy a fix right now using our normal process,” your operational risk is unacceptably high. You’ve just been lucky so far.

Pipelines Are Your Security Boundary

Security is the most difficult quality attribute because it doesn’t stay solved. It rots.

Performance problems announce themselves. Availability problems page you. Security problems sit quietly as the ground shifts beneath your assumptions. A dependency that was safe last quarter has a critical CVE today. A base image approved last year is now a supply-chain liability. Nothing in your system changed, but the risk did.

If you aren’t continuously re-validating your assumptions, you are already out of date; you just don’t know it yet.

This is why CD matters. The pipeline is the only place where security is enforced continuously rather than periodically. It is where dependencies are re-evaluated, policies are applied, and drift is detected before it becomes production reality. Anything outside the pipeline is guidance; the pipeline is enforcement.

The most dangerous security failures aren’t zero-days. They are stale guarantees. “We scanned that months ago” is not a defense.

When pipelines aren’t exercised regularly, security controls decay. Scans stop failing builds. Exceptions accumulate without ownership. Policies get loosened and never tightened. Eventually, teams stop trusting the signal. Security becomes theater: green dashboards backed by false confidence.

Green Pipelines Are Not a Vanity Metric

A green pipeline is not a badge of honor. It is a prerequisite for trust.

Red pipelines that stay red are telling you something critical: your feedback loop is broken. Tests are brittle. Environments aren’t reproducible. Ownership is unclear. Ignoring that signal is like driving with the check-engine light on and calling it “normal.”

Teams that take operations seriously treat pipeline health the same way they treat production health. Broken pipelines stop the line. Fixing them is priority zero. Feature work resumes only after confidence is restored.

You wouldn’t accept a production system that only works “most of the time.” Don’t accept it from the system that decides what is allowed into production.

Exercise It or Lose It

Pipelines degrade when they aren’t used. Credentials expire. Dependencies drift. Entropy sets in.

If you want a pipeline you can rely on in a crisis, you have to exercise it deliberately. This means deploying regularly, even if the changes are trivial. It means practicing rollbacks, not just forward motion. It means treating pipeline execution time as an operational constraint, not an inconvenience.

Think of it like a fire drill. You don’t want to discover the exits are blocked when the building is actually on fire.

Teams that only run pipelines for “major” releases are doing the opposite of risk management. They are optimizing for the quiet days and gambling on the loud ones.

CD Is How You Buy Down Risk

The real value of CD isn’t velocity. It is risk reduction.

Small, frequent, validated changes are easier to reason about, easier to secure, and easier to recover from. When something breaks — and it will — teams that practice CD don’t panic. Not because they are smarter, but because they have engineered a system where failure is survivable.

For critical systems, the ability to deploy safely is not optional. It is feature zero. Everything else depends on it.

…It’s BDD that someone just discovered… again.

When someone declares a core Agile principle “obsolete” because they’ve rediscovered something experienced teams have been doing for decades, while demonstrating that they never understood agile in the first place, it’s a good reminder of how few people study how to do the work better.

The latest example showed up in my LinkedIn feed recently

A core principle of Agile is soon to be obsolete: One of the holiest lines in the Agile Manifesto is “Working software over comprehensive documentation.” But in the era of Agentic Spec-Driven Development, this is flipping on its head.

This sounds futuristic until you realize we solved this problem twenty years ago. We call it Behavior-Driven Development. SDD is not a revolution. It’s not “flipping Agile on its head” because you have detailed specifications. It’s just BDD with branding.

First, let’s clarify some things.

“Working software over comprehensive documentation.”

This never meant “don’t document.”

What it meant was that we didn’t spend months creating a Business Requirements Document and a System Requirements Document for the “finished” project. We don’t create detailed architecture, process flow diagrams, data designs, and low-level technical specifications for everything before we finally begin coding.

It meant don’t pretend to know everything up front. Write enough to align people, then prove it works by actually building something and validating it with the end-user.

Behavior Driven Development

BDD is the practice of having a conversation about how a feature should work.

BDD is:

• Concrete examples
• Expressed in plain language
• Agreed upon by product, QA, and development
• And executable as tests

Feature: I want to be able to add items to a shopping cart so that I can purchase them

Scenario: Adding a new item to an empty cart
Given the cart is empty
When I add item 123 to the cart
Then the cart should contain item 123
And the quantity should be 1

Scenario: Increasing quantity for an item already in the cart
Given the cart contains item 123 with quantity 1
When I add same item again
Then the quantity should be 2

When we begin coding, we implement using TDD using the BDD output to define the tests.

import { Cart } from '../src/cart'; // adjust path as needed

describe('Shopping Cart', () => {
  describe('Adding a new item to an empty cart', () => {
    let cart;

    beforeEach(() => {
      cart = new Cart();
    });

    it('should contain item 123 after adding it to an empty cart', () => {
      cart.addItem(123);
      expect(cart.contains(123)).toBe(true);
    });

    it('should set quantity to 1 when the item is added for the first time', () => {
      cart.addItem(123);
      expect(cart.getQuantity(123)).toBe(1);
    });
  });

  describe('Increasing quantity for an item already in the cart', () => {
    let cart;

    beforeEach(() => {
      cart = new Cart();
      cart.addItem(123); // quantity = 1
    });

    it('should increase the quantity to 2 when the same item is added again', () => {
      cart.addItem(123); // quantity becomes 2
      expect(cart.getQuantity(123)).toBe(2);
    });
  });
});

Voilà, “spec-driven development.” This is a fundamental quality process for agile development, not a new invention for agentic-assisted development.

Disposable Code

Another hot take:

In the era of agents, the Spec becomes the asset. The code becomes disposable.

Reality check: that’s always been true.

If I have good acceptance tests, I can rewrite your entire system in another language, architecture, or stack. No drama.

If I only have code and no tests, I’ve inherited a dangerous artifact I can’t change safely.

Tests describe behavior. Behavior drives code. Code is the implementation detail.

This isn’t AI-era thinking. This is modern software engineering 101.

Teams that learned this years ago are not shocked by any of this.

“We’ll regenerate the whole codebase every time. No more refactoring!”

That’s not how agent-assisted development works. We add, modify, or remove behaviors as we deliver and learn. AI makes it much faster and cheaper to mutate the code to meet those behavior changes. We aren’t rebuilding the entire system on every commit.

• Small batches
• Driven by tests
• Continuously integrated with the rest of the team’s changes
• Continuously delivered and validated

That’s the work, whether a human types the code or an agent spits it out.

What people think is new is what they avoided learning for 20 years

I’ve seen this pattern repeat endlessly:

• People skip the “conversation first” part.
• They treat requirements as gospel instead of hypotheses.
• They ship quarterly bundles of misunderstood features.
• Then they declare Agile broken because the slogans didn’t save them.

If you want a taste of the real deal, try BDD and ATDD, then add agents. Now you get acceleration and safety.

If you skip the discipline, you get vibe coding with prettier marketing.

AI doesn’t eliminate engineering discipline…

It amplifies whatever you already are.

AI-assisted development works beautifully for teams with strong fundamentals — clear behavior definitions, fast feedback loops, small steps, and real continuous integration. I’ve written extensively about this.

And it works terribly for teams who lean on process theater, vague requirements, slow integration, and giant batches. They’ll blame AI. But it’s not AI. It’s them.

As I’ve said many times:

AI amplifies your discipline or your dysfunction. Your choice.

In 2014, our warehouse management system was a nightmare of complexity. A 25MLOC monstrosity that was so tightly coupled that all 900ish applications had to be deployed at the same time, and each release meant a week in a 24x7 war room and many sleepless nights after that. it was a major business problem that needed to be solved.

Four years later, Accelerate came out and asserted:

“Continuous delivery improves both delivery performance and quality, and also helps improve culture and reduce burnout and deployment pain.”

– Accelerate by Nicole Forsgren Ph.D., Jez Humble & Gene Kim

I didn’t need the book to tell me that — it had already changed my life. It'd been a few years since our first CD pilot in Walmart Logistics, and I knew firsthand it was a much better way to live. Since then, I’ve worked to help many teams learn the engineering and teamwork required for CD because I believe every team should experience what we did during that pilot.

I’ve heard many excuses for “why CD won’t work here.” I’ve been told that their teams aren’t mature enough for CD, that their testing isn’t good enough, or that their teams lack the engineering talent.

“We’ll try it once they get good enough.”

Fail!

You don’t learn to ride a bike by waiting until you’re good enough. You remove the training wheels and find relatively safe places to fall.

If you want better engineering and better business outcomes, use your daily work to improve how you do daily work. Solve the problem of “why can't we CD?”

Embracing the Suck

When we began our journey, our teams were organized into feature teams with no domain boundaries. Each picked up whatever story was next in the backlog, regardless of where it lived in the system. The result was a codebase no one truly owned and everyone could break.

We were trying to manage this chaos with the Scaled Agile Framework (SAFe). It gave us structure, but also friction. Every feature required coordination across dozens of teams and languages, all coupled through a single shared database. Our lead time for change — the time from business request to production — was roughly a year.

Releases were massive, high-risk events. Deploying slightly less than once a quarter felt like a victory, even though each one hours of downtime at each distribution center, a week of 24x7 support in the office for each pilot, and weeks of recovery work afterward.

We weren’t just suffering from technical debt; we were drowning in organizational debt. Everyone knew the system was unsustainable, but no one could see a path out of it. Something had to change.

The Moonshot Challenge

Our saving grace was leadership. Our SVP, Randy Salley, and Senior Director, Kim Bowen, were outward-looking leaders who cared deeply about both results and people. Randy had been reading Team of Teams and The Phoenix Project and decided we needed to try something new. He gathered the senior engineers and said:

“I need you to figure out how we can deliver every two weeks.”

Challenge accepted — except we decided daily was a better goal. Go big or go home.

I’ve written elsewhere (“Agile Rehab”) about the strategic steps we took to shift from project to product teams, so I won’t repeat that here. Enabling CD was one thing; executing it was another. We had so much to learn

“You keep talking theory…”

From our ivory tower, we began preaching: 90% test coverage! Test-driven development! Continuous integration!

Teams dutifully wrote tests—and we learned not to treat test coverage as a goal.

You know what’s more terrifying than no tests? Tests that cover hundreds of lines of code with:

assertTrue(true);

During my 1-on-1 with my manager, he challenged me about our lack of progress. “You all keep talking theory. How will we execute?”

I responded, “Leadership pulled all of the tech leads off of the teams into a centralized design team. Now, instead of direct responsibility for outcomes, we only have influence and no visibility into the real challenges. Put me back on a development team!”

So, they put four of us back as tech leads on the first four pilot teams.

Walking the Talk

You don’t know what you don’t know until you try it. I got to learn firsthand how to apply what we thought we knew by facing each problem as it came and staying one chapter ahead of the team.

The team wasn’t hand-picked. We were average: 13 developers, a business analyst, a scrum master, and a product owner from the business side. Developers ranged from me (19 years of WMS experience) to new college grads. Most had little domain knowledge, having worked in feature teams for a decade, responsible for turning specs into code. They had no exposure to real business problems. Now they owned a critical business process and were learning on the fly.

Later, that became an important data point: if an average team could become high-performing just by changing how they worked, excuses about “talent” collapse.

Why Can’t We CI?

CD is a big elephant to carve up, so we needed some smaller bites. We’d been pushing teams on CI for months, with no traction. Using the CD Maturity Model from Continuous Delivery, I created a dependency diagram of behaviors and platform capabilities that we needed.

This gave me a reasonably solid roadmap of what to tackle. We’d created a small platform team to create templates for our core tech stacks to reduce the cognitive load of every team learning Jenkins, so my focus was on the blue and green boxes.

First, we needed to solve CI before moving on to CD. To do that, we needed to define CI clearly. So, I wrote the rules on a piece of paper and hung it up in the area.

Then we used that as our North Star:

“What’s stopping us from doing that today?”

So Many problems

To resolve the CI issue, we needed to address some issues.

• Testing Knowledge: We needed to make testing a leading activity performed before and during development, rather than a lagging activity done by our (soon-to-be-obsolete) testing team.
• Business Knowledge: We needed to spread business knowledge to make the testing effective and to take some of the load off me to explain the reasons for every change.
• Process Overhead: People were SAFe trained and used to long-lived branches, delivering complete stories, and managing to story points. The level of SAFe process was an impediment.
• Me: I also didn’t know how to test or how to deliver partially complete changes continuously. I had a copy of Continuous Delivery, Google, and a goal: daily production delivery.

The SAFe overhead was a real problem. We had a drive-by scrum master in the beginning who was there to make sure we followed the SAFe process. Step one on our journey was when I told the team, “From now on, we are using minimal viable process. We will start with zero process and only add things that help us reach our North Star.” The scrum master didn’t like it. I didn’t care.

The testing problem was the most critical. To meet our goal, we needed to be able to commit a change and have the pipeline certify that it was production-deployable. Everything about how we tested had to change. The problem was that we were playing the same game most teams play: get a story from the PO with some vague acceptance criteria, code it, and ask the PO, “Is this the rock you meant?” Coding tests in that environment feels like a huge waste of time. Also, we didn’t have enough testing knowledge on the team for everyone to write effective tests.

The solution came from the book: behavior-driven development (BDD).

Given I don’t know what we’re building…

BDD was the key that unlocked many other capabilities. I’d consider it foundational to all the improvements that followed.

BDD aligns technical work with business outcomes using structured “Given-When-Then” scenarios to guide development. It ensures a shared understanding between developers, testers, and business people and opens the door to automated acceptance tests using acceptance test-driven development (ATDD).

Using BDD enabled us to achieve a shared understanding of the business process for each feature.

• It helped the team build testing skills as we went through positive and negative scenarios.
• It provided natural points to slice work up since each small scenario is a deliverable behavior. In fact, our definition of “ready to start” was that anyone could pick up any test scenario and that the team could complete the story in 2 days or less.
• Everything became 1 story point, and we eliminated the face-palmingly, silly process of debating story points with cards.

So now we had thin slices of work that the team could swarm with test scenarios they defined. Automating those became an implementation detail instead of making tests up on the fly.

To improve this further, we’d define the behavior changes of each of our several services using the same process. We’d also define any contract changes between services as tests, so multiple people could work on the same task across different services without worrying about integration issues.

Steadily, the team improved their testing muscles and soon surpassed the skills of the testing team assigned to us. In fact, they became an impediment. I had them removed from my team.

Designing Tests for the Pipeline

CD requires a specific design from a test suite. It needs to be very fast, 100% deterministic, and comprehensive. In addition, we had an architectural rule we had to follow: any service can deploy independently of any other service and in any sequence. This not only enables extreme agility, but also makes every change, including emergency changes, less risky.

While the testing team's default was to build an E2E regression suite, that wouldn’t work for CD. Instead, we had layers of tests: some unit tests, more sociable unit tests, contract tests, tests for contract mocks, etc. All of these were stateless. Any flake was terminated with extreme prejudice. Since everything we did was aligned with domain-driven design, none of our services mutated information from any other service. We knew that if our contracts were solid, the components would integrate together correctly.

All of these improvements enabled us to meet and exceed our first goal, daily integration to the trunk.

Why Can’t We CD?

Months of improvement paid off. I built a Grafana dashboard to display integration frequency trends to the team, and we were ripping through work. But we couldn’t yet deploy to production — partly because we were waiting on our new database, mostly because of fear.

The business didn’t trust us. Stability had been a chronic issue for years, and now we were doing something radically different that they didn’t understand.

It took months of patient persuasion, demos, and evidence. Finally, they let us deploy our new, low-risk screen. After that success, I assumed permission to continue — and we did, every week at first due to the process overhead of change control and CAB.

Later, when our platform team automated change control, we deployed multiple times per day. My dashboard had us averaging five deploys per day and frequently exceeding that.

It Changed Us

We deployed updates, alerted beta users in Slack, and got feedback instantly. If users spotted an issue, we hardened tests, fixed it, and redeployed. If they had an idea, we could design, code, and ship it in under two days.

A few months after I left the team, I went back and saw they were tracking their development cycle time (from start to delivery) on their whiteboard. In numbers about a foot tall, it said,

“0.8 days.”

The team was excited to do demos. They had ideas to improve the application. They had pride and the highest morale I’d ever experienced on a development team. They were good and they knew it. They weren’t 10X developers. They were a 10x team.

When our teams are good enough…

Teams’ inability to execute CD has nothing to do with talent. Any team, given clarity, safety, and purpose, can learn CD and improve its engineering in the process.

The gap isn’t people — it’s leadership.

None of this could have happened without the support and trust of our SVP and Sr. Director.

You don’t need better talent.

You already have the talent.

Give them hard problems to solve, the support to solve them, and set them free.

When people try to help an organization move toward continuous delivery or engineers advocate for the better outcomes that come with it, we hear the same excuses. The words change, but the message is consistent.

Some of the greatest hits we hear:

“There’s more than one way to deliver software.”
“We’re not Amazon.”
“Our team doesn’t have enough experience.” “That won’t work here.”
“Our best developers will quit.”
“That seems risky.”
“We don’t have time to make changes.”

Each one sounds reasonable until you unpack what it really means: “We’re not ready to improve.”

“There’s more than one way to deliver software.”

True — like there’s more than one way to land a plane. Some end better than others.
If your delivery method can’t safely get features from idea to user quickly and repeatedly, maybe it’s time to stop defending it.

“We’re not Amazon.”

No one said you were. But you do have users who expect stable systems, faster feedback, and fewer incidents.
Continuous delivery isn’t about being Amazon; it’s about being able to respond to the needs of the business and to the unexpected safely, quickly, and without drama.

“Our team doesn’t have enough experience.”

Then leadership’s job is to fix that. The longer you delay, the less experience you’ll have when you finally need those skills.

“That won’t work here.”

Translation: “We don’t want to do the work required to make it work here.”
The laws of feedback and flow apply everywhere. The details change, but the physics don’t.

“Our best developers will quit.”

If your “best developers” refuse to improve how they deliver, they aren’t your best developers.
They’re your best at preserving the status quo.

“That seems risky.”

You’re right. Change is risky. So is running a system where every deploy is an act of faith.
Continuous delivery reduces real risk by exposing problems faster and limiting the blast radius of mistakes.

“We don’t have time to make changes.”

Then you’ve locked yourself into a death spiral. Continuous delivery is how you get time back — 
by turning large, unpredictable failures into small, recoverable ones.

“Too much overhead.”

If improving safety, speed, and stability is “overhead,” your definition of efficiency is upside down.

Continuous delivery eliminates the overhead of firefighting, manual approval chains, and waiting for integration failures in production.

“Customers can’t keep up.”

That’s what feature flags, canary releases, and progressive rollouts are for.

The goal of CD isn’t to flood customers with features — it’s to *enable* controlled, reversible change when the business needs it.

Delivery frequency is about feedback, not feature fatigue.

Leadership often confuses disruption of comfort with introduction of risk.
Continuous delivery doesn’t add risk; it exposes the risk that was already there.

The right question isn’t “Will CD work here?”
It’s “Do we want to know the truth about how we deliver?”

Because CD will show you — whether you like the answer or not.

Starting your journey? This may help: https://practices.minimumcd.org/

I was asked recently why SAFe fails. Here’s one major reason.

The Scaled Agile Framework (SAFe) is the best-marketed framework sold to executives by the Agile Industrial Complex. Its goal is to improve delivery, starting with solving the problem of coordination at scale by managing dependencies through process. Instead of reducing coupling between teams, it formalizes it. SAFe layers synchronization meetings, planning cycles, and roles such as the “Release Train Engineer” across the organization to keep everyone aligned.

On paper and to the uninformed, that sounds a reasonable way to handle complexity. In practice, it locks in the very dependencies that prevent continuous delivery.

What SAFe advocates say: “That’s just the starting point. You’re expected to move beyond that.”

I’ve lived through a SAFe implementation and witnessed several others firsthand, and I know exactly why they fail to move beyond that.

Reality: It’s ironic that a group of people who are supposed to be resolving issues at scale seem to have so little clue about how things work at scale.

The Coordination Trap

For SAFe to “work,” everyone needs to be trained on the same process, and all the teams in a release train need to operate in lockstep. The “release train engineer” and “scrum of scrums” tightly couple teams around synchronized delivery and process. While this may seem to reduce chaos in the short term, that coupling is the exact opposite of what you need for continuous delivery.

In SAFe, every team must ask permission to make changes that affect anything beyond its local scope. Improvement becomes a group decision, and group decisions at enterprise scale move slower than glaciers. Even if a team sees a better way, it can’t simply act; it must align, escalate, and get consensus.

Continuous delivery, by contrast, depends on independent, decoupled teams that can improve their flow immediately and deliver value safely without waiting for the train schedule. CD requires us to use engineering to handle dependencies. In fact, if we take the constructive constraints of CD seriously, we cannot help but improve the engineering to enable that.

The Training Paradox

SAFe’s defenders often say the model is just a “starting point.” But because SAFe requires everyone to be trained on the same standardized process to maintain consistency across hundreds or thousands of people, the “starting point” becomes the destination.

When turnover happens — and it always does — new hires are trained on the official, baseline SAFe process, not whatever “improved” variant someone hopes to evolve toward. The improvement loop is broken because the training system anchors everyone to the original design.

The cost of formal change is high — retraining, documentation, governance updates, and alignment across roles — so improvements don’t happen organically. Unless change is driven from the top, it doesn’t happen at all. And executives are typically the farthest from the work, so the changes they drive are often counterproductive.

The Management Self-Preservation Problem

Continuous delivery demands decoupling teams — breaking dependencies so each can deliver independently. But in SAFe, those dependencies give structure and purpose to management roles like the Release Train Engineer.

Real improvement would mean shrinking the RTE’s responsibilities until the role disappears. That’s not a technical problem — it’s a political one. You’re asking people to dismantle the coordination system that justifies their position. Unsurprisingly, they resist.

When your operating model depends on preserving layers of coordination that continuous delivery renders unnecessary, you’ve built a system that’s optimized for self-preservation, not improvement.

Scaling Dysfunction

The entire premise of SAFe is to manage complexity through hierarchy and synchronization. But effective scaling isn’t about adding more layers of coordination; it’s about removing dependencies so teams can move safely on their own.

Continuous delivery scales by improving flow and feedback, not by adding more meetings to coordinate bad flow. Every added synchronization point adds latency, every shared dependency adds risk, and every “train” schedule adds drag.

SAFe’s mechanisms for control — the trains, the ceremonies, the alignment meetings — are precisely what prevent continuous delivery from emerging.

The Outcome

SAFe scales coordination, not delivery. It turns what should be local learning loops into enterprise-level governance processes. The result is predictably slow, brittle, and expensive.

It delivers the illusion of progress — more charts, more ceremonies, more roles — but not the one metric that actually matters: the ability to deliver working software safely and continuously.

If you want to deliver continuously at scale, don’t scale SAFe.

Scale learning, autonomy, and flow instead.

I was speaking at DevOpsDays Dallas this week about AI-assisted development, how to do it, how it allows me to deliver much faster, and why most organizations won’t see any benefit. I also had a lot of good conversations about the topic because, as you can imagine, it’s top of mind for people in the industry.

One topic that has been haunting many of us is “how do we train junior developers in the age of AI?” I’ve been thinking about this quite a bit, and I’m embarrassed I didn’t have an answer sooner. It should have been obvious to me, considering my work history and the operating models I advocate.

First, let’s consider the main concern many people have about using AI for writing code. It’s easy to get in a hurry and not pay close attention to the code being generated. I’ve done it myself. I will come back and refactor the code (with AI assistance) later, but sometimes I just want to get something done. If you aren’t cleaning as you go or you stop paying attention to the code, it’s easy to drive up tech debt and to build systems you don’t understand and cannot fix when they have defects.

Next, let’s consider what makes someone a senior developer. Is it time in grade? The ability to write code fast? Is it how many patterns they can name or how fast they can invert a binary tree? No. It’s their experience trying things, failing at things, and succeeding at things. They know how to continue learning, have good engineering habits, help others avoid repeating their failures, and mentor the next generation. They can look at the code and see that it’s hard to maintain and hard to fix because they’ve had a lot of experience changing and fixing code they didn’t write.

So, what is the solution?

“You build it, you run it!”

This has always been a best practice. The people who built a system should be the experts at supporting it, and this concept has always been core to DevOps. Quality is an outcome of how quickly you can detect that there is a quality issue, and it requires ownership. The team needs to own the problem they are solving, own how it is solved, and own the consequences of their decisions. This operating model changes coders into software engineers who think twice before committing garbage code. It makes teammates think twice before spending 30 seconds to comment “LGTM” on a code review for an 800-line delta. The team members are incentivized to help spread knowledge and take ownership, regardless of whether the code is written by them, a teammate, or a robot.

So, if you are concerned about quality and how you can grow new developers into senior software engineers, first make sure you have some seniors who believe their job description includes cloning themselves, and then shift to a DevOps operating model. No team should be developing code with the expectation that Ops will clean up their mess.

Some organizations are banning new developers from using AI. That’s dumb. All it does is create a class system and block learning. Teach everyone how to use AI correctly, starting by driving acceptance test-driven development and continuous integration as the workflow. No one should be coding until the team defines the outcome, and all changes should be small and integrated very frequently. Not working this way causes pain. Without AI, the pain is often like a low-grade ache. People live with it and become used to it. With AI, it’s like breaking your leg because AI amplifies everything.

In part 2 of this series, I wrote about my experience developing with AI using no handwritten code and the skills required to get good outcomes. The short version: the same rigor required for continuous integration is required for AI-assisted development. Working with agents will expose weaknesses in that rigor faster than ever. GIGO, only accelerated.

Some claim AI is only useful for greenfield projects or proofs of concept. They’re wrong. I use these tools daily for new features, refactoring, improving legacy code, writing tests, debugging, and more. With the right skills and development discipline, AI lets you deliver solutions faster. But does this actually improve organizational outcomes? For most companies, I doubt it.

AI Intensifies Your Personality

In my youth, I saw a stand-up routine about cocaine

I said to a guy, “Tell me, what is it about cocaine that makes it so wonderful,” and he said, “Because it intensifies your personality.” I said, “Yes, but what if you’re an a**hole?”

AI development is like that. If you lack discipline, AI will amplify that. You’ll see hallucinations, unexpected changes, mounting tech debt, and rising defect rates. Before long, you’ll be on social media declaring AI useless, blaming the tool instead of your practices.

However, if you have discipline — clear testable requirements, test-driven development, small batches, and tight feedback loops — AI amplifies those practices. You deliver faster, with less effort, and focus more on solving problems rather than wrestling with implementation.

Speed of Development ≠ Speed to Value

Software delivery is a system. Coding is just one part. A typical flow looks like this:

• A product owner throws features with unclear or incomplete acceptance criteria over the wall to a development team.
• The team breaks down these large chunks of work into “stories” that are still weeks of effort.
• Developers code the stories but frequently need to stop and ask for more clarity on the change, or use their best judgment and play “is this the rock you wanted?” with the product owner. Changesets are large and merges are infrequent because the cost of change is high.
• Because the original requirements were unclear, the developers could not drive development using tests. Testing becomes an activity that occurs, if at all, after development is complete, often conducted by a separate testing team with differing opinions on how the feature should function.
• Before deploying, a Change Advisory Board that meets weekly insists on reviewing all of the documentation that “proves” everything was done correctly and that there is a valid plan for reversing the change if things go too sideways.
• Ops is terrified of deployments because every deployment is large and risky, and always results in excessive support, regardless of what the CAB documentation says.

This isn’t hyperbole. I’ve measured this across multiple teams. It’s a common experience that others have reported too. When you map the process, coding is only a fraction of the overall flow. Adding AI to write code faster doesn’t fix the real bottlenecks. It just creates waste faster.

Faster Coding Without Faster Feedback Is Dangerous

Industry conversations obsess over “developer productivity,” as if faster coding equals progress. But speed without feedback is just digging the hole deeper.

AI can generate code, but it can’t validate whether it solves the right problem. It doesn’t fix vague requirements, broken testing practices, or heavyweight governance. Without upstream clarity and downstream automation, faster coding leads to more defects, more rework, and more outages per delivery.

We’ve seen this before. Organizations chased deployment frequency because Accelerate said high performers ship more often. But deployment frequency was a signal of healthy flow, not the goal. Shipping faster without guardrails isn’t progress; it’s chaos.

The Whole Value Stream Has to Improve

Real speed comes from improving the entire value stream:

• Upstream: Clear problem statements, smaller work items, collaborative product teams.
• Development: Teamwork, single-piece flow, test-first practices, and continuous integration.
• Downstream: Automated, deterministic pipelines, no manual approvals disguised as “governance,” and rapid recovery when things break.

That’s what Continuous Delivery is about — not developers typing faster, but value moving faster, safer, and with less risk. AI doesn’t change that truth.

Fix the Right Problems

Here’s the uncomfortable reality: developer productivity doesn’t matter in isolation. The bottleneck in most organizations isn’t how long it takes to write code — it’s everything else.

AI is an amplifier. If your delivery system is healthy, AI makes it better. If it’s broken, AI makes it worse.

Map your value stream. Find the real constraints. Fix those. Only then will faster coding translate to faster delivery of value.

The choice is yours.

Follow-ups

• Part 1
• Part 2

Some things have not changed over the past two years. The nay-sayers are saying “nay” even more vociferously with even worse arguments, usually philosophical rather than engineering. I’m sure the job market will sort that out. Survival is optional when you don’t consider learning to be a requirement. I’ve been using more machine-generated code, doing more machine-executed refactoring, and learning from pain what not to do.

In my previous article, I predicted that Behavior-Driven Development and the skill of defining business features as acceptance tests would become more critical for developers in the coming years. Recently, I wanted to see how far I could push building something with nothing but acceptance tests. It went really well.

Why I Needed to Scrape Medium

I have a problem. I have years of content on Medium that I’d like to make more portable. I want to extract my Medium blogs in markdown with frontmatter metadata so that I can also post them elsewhere, use them as content for a self-hosted blog, or even train a model on the content. Medium won’t let you do that through an API, the RSS feed is only good for the last 20 posts, and the download you can request seems designed to thwart reusability. That leaves screen scraping. So, let’s build a tool.

Using ATDD with Claude

We needed an overall plan that we could implement in small steps, along with defined outcomes. I could have spent time writing the behavior tests myself, but I was curious about what would happen if I asked Claude to create the behaviors. Here's my initial prompt to Claude.

I want to create an application that will scan all of my published blogs on medium.com and download them as markdown
with frontmatter. Medium does not provide an API to do this. Their RSS feed only shows the last 20 posts, but I need all
of the posts. I cannot use a chrome plugin. Medium requires a user to be logged in to see content and uses Google's SSO,
so the tool should allow me to login with my google credentials.

Technical constraints:
We should use vanilla JS with es modules, functional programming, and arrow functions.

Create a prompt and feature file to use with Claude Code

I want claude code reference the feature file and use acceptance test driven development.
It should use eslint and prettier and should fix any linting and style issues after each test passes.w

After a few seconds, Claude generated a file that defines the working rules (TDD, functional programming, etc.), a file for instructions for setting up the project, and a feature file for the features Claude suggested.

After reviewing the working instructions, I wanted to emphasize more clearly that quality processes were not optional. I’ve seen Claude “forget” those when not instructed otherwise. I ended up with these instructions.

Next, I reviewed the generated feature file. This was quite good. In fact, I only requested changes after I had an MVP and could play with the results

Set Course and Engage!

For this, the prompt was simple:

Setup the project and implement the first scenario

Then I watched the agent work, reviewing and approving the steps as needed, while sipping my coffee and responding to LinkedIn comments. Once each scenario was complete, I manually validated it. For example, once the Google login feature passed tests, I tried logging in. It worked on the first try.

Discovery and Problem Solving

When we started on the next scenario, Discover All Published Posts, we hit our first issues. Since I didn’t define clearly how to identify a post URL, Claude identified every link on the profile page as a blog post. So, I provided an example blog URL, it updated its search logic, and the irrelevant links were filtered out. Now it was finding 3 of my 70+ posts. Well, that’s a start. It turns out that Medium uses an infinite scroll to display the blogs, so we need to navigate that.

I’ve no personal experience scraping a webpage that uses infinite scroll (my primary skill is backend), but I know it’s a solved problem in the world, so I tried the simplest thing. I updated the scenario with:

And it should handle pagination or infinite scroll to load all posts

That change resulted in finding more, but not all of my posts. Hmmm.

Next, I discovered that the URL for posts sent to publications can have a few different formats and are different from the pattern for non-publication posts. So, with some more prompting to add those formats to the tests, we had a more complete scenario:

    Scenario: Handle Posts Submitted to Publications
        Given I have published posts both on my profile and to Medium publications
        When I navigate to my Medium profile page
        Then the scraper should identify posts on my profile with URLs like:
            | URL Format                                  | Description            |
            | https://username.medium.com/post-title-123  | Personal profile posts |
            | https://medium.com/@username/post-title-456 | Personal profile posts |
        And the scraper should also identify posts submitted to publications with URLs like:
            | URL Format                                         | Description               |
            | https://publication-name.com/post-title-789        | Custom publication domain |
            | https://medium.com/publication-name/post-title-abc | Medium-hosted publication |
        And all posts should be attributed to the correct author
        And publication information should be captured in metadata
        When I process publication posts
        Then the scraper should extract content from the publication URL
        And it should preserve the original publication context
        And it should include publication name in the frontmatter metadata

After this, everything else was straightforward. We implemented each scenario, always starting with a failing acceptance test. After I had a passing scenario, I committed the change and went to the next. Lather, rinse, repeat until I had enough functionality for my purposes.

If you compare the original acceptance tests to the version in the last commit, you’ll see the plan changed as more was learned about the problem. Every change was small and focused on solving the next small problem. In fact, not all scenarios were implemented because I stopped when the feature set met the need. It was interesting, though, that Claude suggested features to deliver a more robust solution. Things like restarting a download that failed in the middle, rate limit handling, and incremental updates. I didn’t ask for those, and I don’t need them today, but this was not the first time that Claude has suggested useful improvements.

All in, this took about four hours, starting with my first prompt.

Learning the Wrong Lessons

In the above example, I used a disciplined approach to rapid development. I knew what my goals were, I had an idea about how to get there, and I worked in small steps to achieve my goal. I spent about 15 minutes planning and a few hours guiding the agent through my features with tests, learning as I went. This is no different than how I would work with a human team. However, anti-patterns are emerging that are driven by the same misunderstanding that is rampant in the industry: people believe the work of a developer is to write code.

Vibe Coding

Vibe coding hasn’t stabilized as a definition yet. Some use it as a pejorative, and others use it to mean a new form of sustainable software development. However, the most common understanding of the term “vibe coding” is “tell the bot what you want and run what it builds.” With the current generation of tools, you can rapidly prototype something that looks useful and seems to work in just a few days this way. However, putting that solution into production and making it critical to the mission is the same mistake people have been making forever with POCs. Someone has a “brilliant” idea, they build a proof of concept rapidly without standard quality processes, there’s a business decision to go forward, and instead of keeping the lessons from the POC and throwing away the code, they deploy mountains of tech debt into production, bury themselves in operational issues, and then try to fix it while also adding features to the garbage they built. I’m not a fan.

There is far more to delivering reliable software than writing code. For example:

“Replit deleted my database and lied!”

If we were to do a postmortem on this, the conclusion I would come to would not be “Replit did the wrong thing.” The CORRECT lesson that should drive their improvement process is “we gave Replit production access with no pipeline to validate changes.” Also, “we did not have a process for backing up critical data.”

“The AI made a change and deleted months of my code! How do I get it back?”

This is also becoming a complaint we are seeing more often on social media. When you make it easy to build things that require no knowledge of the fundamentals, like version control, people will get burned.

These examples highlight an important point: AI is not less error-prone than humans. It’s important we have the quality processes in place (test-driven development, work in small batches, rapid feedback) to catch errors before they become incidents.

Vibe coding makes it faster and cheaper to increase operational expenses. No matter how fast or how inexpensively we can generate code, the work is and has always been delivering sustainable solutions, not code. Establishing and maintaining a solid quality process, including the quality of the information about the features, has always been fundamental to the work. Many organizations are behind the curve on software quality processes and have created entire QA organizations focused on testing after development to try to “inspect quality in at the end.” I suppose one of the advantages of machine-generated code is that, like anything else that accelerates feedback, it highlights the gaps in our processes when things begin to break. Quality is a process, not a step.

Waterfall is the Best Way!

I recently came across someone who claimed that waterfall project management is the best way to work with AI. Define all the requirements upfront, and the AI will generate the working code. We can then test the output against these requirements. Simple! Machines writing code do not change the fundamental problems we face when developing new products:

• The requirements do not match the users’ needs
• They will be misunderstood during development
• The need will change before we deliver

The only solution is to deliver in small steps and get feedback as rapidly as possible. AI-assisted development helps us accelerate the feedback loop. It in no way replaces the need for feedback.

The Right Lessons

The techniques I used for this example are exactly the same techniques I had to learn to be effective at continuous delivery. I used BDD to define the acceptance criteria. This provided the information I needed to code acceptance tests and then write code to make the tests pass. Continuous integration requires that we only commit tested code, and BDD with ATDD makes this much easier. I worked in small steps, validating each one as I went to confirm or adjust the plan. When I had a small step working, I committed the change to prevent the next step from breaking something. Early on, I thought there would be new patterns to learn. It turns out that the best pattern to use with AI is continuous delivery.

More people are coming to the same conclusion that you can get really good outcomes from AI assistants when you pair them with modern software engineering methods like XP and continuous delivery. The opposite is also very true.

I’ve seen many developers complaining that AI is either no help at all or worse than useless. However, I’ve yet to hear about someone skilled at XP struggling to use the tools effectively. There appears to be a strong correlation between knowledge of modern software engineering practices and positive outcomes with AI. If you get bad outcomes, you’re probably bad at the fundamentals. Griping about it is only telling on yourself.

The optimist in me hopes that the pressure to stay relevant will drive more people to finally stop arguing about practices like test-driven development and continuous integration and will decide to level up instead. The pessimist in me predicts people will learn the wrong lessons, and we’ll see more dramatic incidents in the future. Time will tell.

Next Steps

The tools will keep evolving, but the fundamentals of engineering won’t. My experiment showed me that AI can accelerate development dramatically — if you pair it with practices like ATDD, CI, and small, validated steps. Without those, you don’t get productivity; you just get faster paths to failure.

That’s the lesson many are missing. AI doesn’t replace the need for software engineering discipline; it makes it more necessary than ever. The people getting the best outcomes with AI aren’t the ones writing the flashiest prompts — they’re the ones already skilled in modern practices like XP and continuous delivery. I suggest starting by learning more about the workflow of continuous delivery, starting with Behavior Driven Development. Practice driving your code with tests before adding a robot into the mix.

If you want to thrive in the AI era, don’t start by asking, “How do I prompt better?” Start by asking, “How do I deliver software better?” AI is an amplifier. Whether it amplifies your discipline or your dysfunction is entirely up to you.

Follow-ups

• Part 1
• Part 3

References

• MinimumCD.org
• Modern Software Engineering — Dave Farley
• eXtreme Programming Explained — Kent Beck

This was originally posted on InfoQ.

In 2014, I had my first experience implementing the changes needed for continuous delivery. That experience and the lessons learned have guided my thoughts since.

Replacing Agile with Engineering

We had a problem. After years of “Agile Transformation,” including the rollout of the Scaled Agile Framework, we were not delivering any better results. In fact, we delivered less frequently with bigger failures than when we had no defined processes. We had to find a way to deliver better value to the business. SAFe, with all of the ceremonies and process overhead that comes with it, wasn’t getting that done. Our VP read The Phoenix Project, got inspired, and asked the senior engineers in the area to solve the problem. We became agile by implementing the necessary engineering changes to support Continuous Delivery (CD).

Initially, our lead time to deliver a new capability to the business averaged 12 months, from request to delivery. We had to fix that. The main problem, though, is that creating a PI plan for a quarter, executing it in sprints, and delivering whatever passes tests at the end of the quarter ignores the entire reason for agile product development: uncertainty.

Here is the reality: the requirements are wrong, we will misunderstand them during implementation, or the end users’ needs will change before we deliver. One of those is always true. We need to mitigate that with smaller changes and faster feedback to more rapidly identify what’s wrong and change course. Sometimes, we may even decide to abandon the idea entirely. The only way we can do this is to become more efficient and reduce the delivery cost. That requires focusing on everything regarding how we deliver and engineering better ways of doing that.

Why Continuous Delivery?

We wanted the ability to deliver more frequently than 3–4 times per year. We believed that if we took the principles and practices described in Continuous Delivery by Jez Humble and Dave Farley seriously, we’d be able to improve our delivery cadence, possibly even push every code commit directly to production. That was an exciting idea to us as developers, especially considering the heavy process we wanted to replace.

When we began, the minimum time to deliver a normal change was three days. It didn’t matter if it was a one-line change to modify a label or a month’s worth of work — the manual change control process required at least three days. In practice, it was much worse. Since the teams were organized into feature teams and the system was tightly coupled, the entire massive system had to be tested and released as a single delivery. So, today’s one-line change will be delivered, hopefully, in the next quarterly release unless you miss the merge window.

We knew if we could fix this, we could find out faster if we had quality problems, the problems would be smaller and easier to find, and we’d be able to add regression tests to the pipeline to prevent re-occurrence and move quickly to the next thing to deliver. When we got there, it was true. However, we got something more.

We didn’t expect how much better it would be for the people doing the work. I didn’t expect it to change my entire outlook on the work. When you don’t see your work used, it’s joyless. When you can try something, deliver it, and get rapid feedback, it brings joy back to development, even more so when you’ve improved your test suite to the point where you don’t fear every keystroke. Getting into a CD workflow made me intolerant of working the way we were before. I feel process waste as pain. I won’t “test it later when we get time.” I won’t work that way ever again. Work shouldn’t suck.

Descale and Decouple for Speed

We knew we’d never be able to reach our goals without changing the system we were delivering. It was truly monstrous. It was the outcome of taking three related legacy systems and a fourth unrelated legacy system and merging them, with some splashy new user interfaces, into a bigger legacy system. A couple of years before this improvement effort, my manager asked how many lines of code the system had. Without comments, it was 25 million lines. Calling the architecture “spaghetti” would be a dire insult to pasta. Where there were web services, the service boundaries were defined by how big the service was. When it became “too big,” a new service, such as Service040, would be created.

We needed to break it up to make it easier to deliver and modernize the tech stack. Step one involved using Domain-Driven Design to start untangling the business capabilities within the current system. We aimed to define specific capabilities and assign each to a product team. We knew about Conway’s Law, so we decided that if we were going to get the system architecture we needed, we needed to organize the teams to mirror that architecture. Today, people call that the “reverse Conway maneuver.” We didn’t know it had a name. I’ve heard people say it doesn’t work. They are wrong. We got the system architecture we wanted by starting with the team structure and assigning each a product sub-domain. The internal architecture of each team’s domain was up to them. However, they were also encouraged to use and taught how to design small services for the sub-domains of their product.

We also wanted to ensure every team could deliver without the need to coordinate delivery with any other team. Part of that was how we defined the teams’ capabilities, but having the teams focus on Contract Driven Development (CDD) and evolutionary coding was critical. CDD is the process where teams with dependencies collaborate on API contract changes and then validate they can communicate with that new contract before they begin implementing the behaviors. This makes integration the first thing tested, usually within a few days of the discussion. Also important is how the changes are coded.

The consumer needs to write their component in a way that allows their new feature to be tested and delivered with the provider’s new contract but not activated until that contract is ready to be consumed. The provider needs to make changes that do not break the existing contract. Working this way, the consumer or provider can deliver their changes in any order. When both are in place, the new feature is ready to release to the end user.

By deliberately architecting product boundaries, the teams building each product, focusing on evolutionary coding techniques, and “contract first” delivery, we enabled each team to run as fast as possible. SAFe handles dependencies with release trains and PI planning meetings. We handled them with code. For example, if we had a feature that also required another team to implement a change, we could deploy our change and include logic that would activate our feature when their feature was delivered. We could do that either with a configuration change or, depending on the feature, simply have our code recognize the new properties in the contract were available and activate automatically.

Accelerating Forces Learning

It took us about 18 months after forming the first pilot product teams to get the initial teams to daily delivery. I learned from doing CD in the real world that you are not agile without CD. How can you claim to be agile if it takes two or more weeks to validate an idea? You’re emotionally invested by then and have spent too much money to let the idea go.

You cannot execute CD without continuous integration (CI). Because we took CI seriously, we needed to make sure that all of the tests required to validate a change were part of the commit for that change. We had to test during development. However, we were blocked by vague requirements. Focusing on CI pushed the team to understand the business needs and relentlessly remove uncertainty from acceptance criteria.

On my team, we decided that if we needed to debate story points, it was too big and had too much uncertainty to test during development. If we could not agree that anyone on the team could complete something in two days or less, we decomposed the work until we agreed. By doing this, we had the clarity we needed to stop doing exploratory development and hoping that was what was being asked for. Because we were using Behavior Driven Development (BDD) to define the work, we also had a more direct path from requirement to acceptance tests. Then, we just had to code the tests and the feature and run them down the pipeline.

You need to dig deep into quality engineering to be competent at CD. Since the CD pipeline should be the only method for determining if something meets our definition of “releasable,” a culture of continuous quality needs to be built. That means we are not simply creating unit tests. We are looking at every step, starting with product discovery, to find ways to validate the outcomes of that step. We are designing fast and efficient test suites. We are using techniques like BDD to validate that the requirements are clear. Testing becomes the job. Development flows from that.

This also takes time for the team to learn, and the best thing to do is find people competent at discovery to help them design better tests. QA professionals who think, “What could go wrong?” and help teams create strategies to detect that, instead of the vast majority who are trained to write test automation, are gold. However, under no circumstances should QA be developing the tests because they become a constraint rather than a force multiplier. CD can’t work that way.

The most important thing I learned was that it’s a more humane way of working. There’s less stress, more teamwork, less fear of breaking something, and much more certainty that we are probably building the right thing. CD is the tool for building high-performing teams.

Optimize for Operations

All pipelines should be designed for operations first. Life is uncertain — production breaks. We need the ability to fix things quickly without throwing gasoline on a dumpster fire. I carried a support pager for 20 years. The one thing that was true for most of that time was that we always had some workaround process for delivering things in an emergency. This means that the handoffs we had for testing for normal changes were bypassed for an emergency. Then, we would be in a dumpster fire, hoping our bucket contained water and not gasoline.

With CD, that’s not allowed. We have precisely one process to deliver any change: the pipeline. The pipeline should be deterministic and contain all the validations to certify that an artifact meets our definition of “releasable.” Since, as a principle, we never bypass or deactivate quality gates in the pipeline for emergencies, we must design good tests for all of our acceptance criteria and continue to refine them to be fast, efficient, and effective as we learn more about possible failure conditions. This ensures hotfixes are safe while also driving improvement in feature delivery. This takes time, and the best thing to do is to define all of the acceptance criteria and measure how long it takes to complete them all, even the manual steps. Then, use the cycle time of each manual process as a roadmap for what to automate next.

What we did was focus on the duration of our pipeline and ensure we were testing everything required to deliver our product. We, the developers, took over all of the test automation. This took a lot of conversation with our Quality Engineering area since the pattern before was for them to write all the tests. However, we convinced them to let us try our way. The results proved that our way was better. We no longer had tests getting out of sync with the code, the tests ran faster, and they were far less likely to return false positives. We trusted our tests more every day, and they proved their value later on when the team was put under extreme stress by an expanding scope, shrinking timeline, “critical project.”

Another critical design consideration was that we needed to validate that each component was deliverable without integrating the entire system. Using E2E tests for acceptance testing is a common but flawed practice. If we execute DDD correctly, then any need to do E2E for acceptance testing can be viewed as an architecture defect. They also harm our ability to address impacting incidents.

For example, if done with live services, one of the tests we needed to run required creating a dummy purchase order in another system, flowing that PO through the upstream supply chain systems, processing that PO with the legacy system we were breaking apart, and then running our test. Each test run required around four hours. That’s a way to validate that our acceptance tests are valid occasionally, but not a good way to do acceptance testing, especially not during an emergency. Instead, we created a virtual service. That service could return a mock response when we sent a test header so we could validate we were integrating correctly. That test required milliseconds to execute rather than hours.

We could run it every time we made a change to the trunk (multiple times per day) and have a high level of confidence that we didn’t break anything. That test also prevented a problem from becoming a bigger problem. My team ran our pipeline, and that test failed. The other team had accidentally broken their contract, and the test caught it within minutes of it happening and before that break could flow to production. Our focus on DDD resulted in faster, more reliable tests than any of the attempts at E2E testing that the testing area attempted. Because of that, CD made operations more robust.

Engineering Trumps Scaling Frameworks

We loved development again when we were able to get CD off the ground. Delivery is addictive, and the more frequently we can do that, the faster we learn. Relentlessly overcoming the problems that prevent frequent delivery also lowers process overhead and the cost of change. That, in turn, makes it economically more attractive to try new ideas and get feedback instead of just hoping your investment returns results. You don’t need SAFe’s PI planning when you have product roadmaps and teams that handle dependencies with code. PI plans are static.

Roadmaps adjust from what we learn after delivering. Spending two days planning how to manage dependencies with the process and keeping teams in lock-step means every team delivers at the pace of the slowest team. If we decouple and descale, teams are unchained. Costs decrease. Feedback loops accelerate. People are happier. All of these are better for the bottom line.

On the first team where we implemented CD, we improved our delivery cadence from monthly (or less) to several times per day. We had removed so much friction from the process that we could get ideas from the users, decompose them, develop them, and deliver them within 48 hours. Smaller tweaks could take less than a couple of hours from when we received the idea from the field. That feedback loop raised the quality and enjoyment level for us and our end users.

Measure the Flow!

Metrics is a deep topic and one I talk about frequently. One big mistake we made was not measuring the impact of our improvements on the business. When management changed, we didn’t have a way to show what we were doing was better. To be frank, the new management had other ideas — poorly educated ideas. Things degraded, and the best people left. Since then, I’ve become a bit obsessed with measuring things correctly.

For a team wanting to get closer to CD, focus on a few things first:

1. How frequently are we integrating code into the trunk? For CI, this should be at least once per day per team member on average. Anything less is not CI. CI is a forcing function for learning to break changes into small, deliverable pieces.
2. How long does it take for us, as a team, to deliver a story? We want this to be two days maximum. Tracking this and keeping it small forces us to get into the details and reduce uncertainty. It also makes it easy for us to forecast delivery and identify when something is trending later than planned. Keep things small.
3. How long does it take for a change to reach the end of our pipeline? Pipeline cycle time is a critical quality feedback loop and needs to keep improving.
4. How many defects are reported week to week? It doesn’t matter if they are implementation errors, “I didn’t expect it to work this way,” or “I don’t like this color.” Treat them all the same. They all indicate some failure in our quality process. Quality starts with the idea, not with coding.

Since this journey, I’ve become passionate about continuous delivery as a forcing function for quality. I’ve seen on multiple teams in multiple organizations what a positive impact it has on everything about the work and the outcomes. As a community, we have also seen many organizations not take a holistic approach, throw tools at the problem, ignore the fact that this is a quality initiative, and hurt themselves. It’s important that people understand the principles and recommended practices before diving in headfirst.

You won’t be agile by focusing on agile frameworks. Agility requires changing everything we do, beginning with engineering our systems for lower delivery friction. By asking ourselves, “Why can’t we deliver today’s work today?” and then relentlessly solving those problems, we improve everything about how we work as an organization. Deploy more and sleep better.