What the Coast Guard Taught Me About the Agile Framework, Extreme Programming

Agile frameworks often seem built for developers in hoodies tapping away in startup offices. But if you’ve ever led a boat crew during a surprise underway drill or walked the pier with an inspection sheet to test the standard, you’re closer to Agile Project Management than you think.

In these cases, you already understand the spirit behind one of Agile’s most technical disciplines: Extreme Programming (XP).

At first glance, XP sounds like something built for coders, not Coast Guard Coxswains. It includes terms like test-first development, continuous integration, and refactoring. But strip away the tech jargon, and here’s what XP teaches: Don’t certify anybody as a Coxswain unless they’ve been tested under pressure.

And that’s something the Coast Guard understands deeply.

Test First — Before It Counts

We were preparing to roll out a new training plan for break-ins and a revised Coxswain expectation brief. It looked great on paper. It included everything: pre-underway risk management, seamanship, navigation, and leadership expectations.

But we didn’t “go live” just because it looked polished on paper.

We tested it during a live underway check-ride.

We ran a newly reported BM2 through SAR scenarios, tight maneuvering, and emergency drills, gathering insights into their existing knowledge before building their tailored training plan. We also administered the written Coxswain exam, using the same test we use on their oral boards.

This wasn't “stump the chump.” It was an XP-style test-first approach to identify knowledge gaps before investing valuable training time in the wrong areas.

During the drill, we observed how they led pre-briefs, how they communicated under pressure, and how the new training process supported—or hindered—their growth.

What did we learn?

A one-size-fits-all training plan doesn’t work when every break-in arrives at the unit with different experiences. Instead of checking off every Performance Qual Standard (PQS) line, we focused on getting each individual certified as fast as possible, without wasting time retraining skills they already had.

That’s XP in action. Test first, then adapt.

What XP Calls “Done,” We Call “Mission-Ready”

In XP, “done” doesn’t mean the code is written. It means it’s tested, validated, and ready to operate under stress in the hands of real users.

In the Coast Guard, we don’t certify Coxswains because they can recite the checklist. We certify them because they can command the boat under pressure.

I remember two candidates who stood out within our training program, which taught me how we need to test under stress.

One had memorized every step of the underway drill sheets. Flawless oral board where we were digging to see how deep their knowledge of the manuals went, and it was impressive. But when underway, they froze under stress, stuck to the checklist even as the situation demanded improvisation. They failed.

The other—let’s call them BM2 Smith—barely passed the board in a split recommendation to the Command Cadre. But the Chief said, “Let’s give them a shot at the check-ride.”

During the check-ride, the weather turned on the crew. Heavy rain and wind rolled in hard.

Smith didn’t panic. He didn’t need the checklist. He took control. Tasked lookouts. Adjusted the radar, ensuring it was calibrated correctly. Gave calm, clear commands and called audibles when needed. He led

He didn’t follow the process. He owned the outcome.

That’s what XP means by “working product is the primary measure of progress.” Not a completed PQS. Not a perfectly memorized or completed checklist. A mission-ready operator who can adapt when it counts.

Agile Isn't Just for Software

People commonly think, “We’re not developers. Why should we care about XP?”

Here’s why:

Every SAR case is a test-first mission.

Every piece of gear must work before the mission, not during.

Every qualification is validated in the field, not on a whiteboard.

XP is a mindset that says: quality must be tested continuously, not assumed.

Agile certifications often focus on frameworks like Scrum and Kanban, but XP shows up on questions about quality, technical excellence, and the definition of done.

Leaders don’t write unit SOPs in a vacuum. They test them. Additionally, leaders don’t hand out quals unless the crew can prove readiness in the field. This is the practice of XP, even if we didn’t call it that.

Final Thought: Build Standards That Withstand Pressure

Don’t water down the testing process.

We don’t certify someone to drive the boat unless we’ve seen them do it under stress. Agile is the same. Don’t check the box just because it seems close enough but prove the outcome.

If you're leading Agile adoption in your unit or preparing for the exam, remember this:

XP is not about coding. It’s about building resilient systems through continuous feedback, real-world testing, and a relentless focus on what works under pressure.

As a leader, you owe your crew more than a checkbox qualification. Hold the standard because if it’s hard, good. That means the certification matters, and people will be proud when they earn it.

That’s how you keep your tools sharp, your crew ready, and your team truly Agile.