Why Real Transformation Starts Small

Lessons From Launching Pilot Teams

Most organizations try to change everything at once. They send out memos, schedule all hands meetings, and roll out new policies with the hope that momentum will follow. On paper, that approach looks decisive. In reality, it often produces something else entirely. Confusion sets in, compliance replaces commitment, and resistance quietly takes root beneath the surface.

As leaders learn over the years, real transformation rarely begins at scale. It appears to start in smaller, more intentional spaces where people can see change working before they are asked to live inside it. That is why pilot teams matter so much. They create a place where ideas meet reality, where trust is built through experience, and where leaders learn what actually needs to change before asking the entire organization to follow.

Pilot teams became exactly that. They were not just test cases. They turned into our classroom, our early warning system, and, at times, our humility check. When something worked, the confidence was real. When something failed, the lesson was clear. Launching them felt slower than some people wanted, and at moments it felt uncomfortable, but it was the only way change was going to stick.

Where You Start Matters More Than How Fast You Move

As we started discussing our change into Agile with a Scrum Framework, we selected a single person to really oversee it. The Chief looked across the table and asked a question that carried more weight than first appeared. “Master Chief, where do you want to start?”

He was not asking what needed fixing. He was really asking where we would place the first stone in the foundation of everything that followed. Start too big and the crew would feel buried. Start too safe and we would learn very little. Start in chaos and we would burn people out before they ever saw value.

There is a principle in Agile that has saved me more than once, even if it took time to trust it. Start where the impact is meaningful but still manageable. After a pause, I answered honestly. “Operations and Maintenance. Together.”

That choice carried risk. Those two departments worked well enough most days, but the delays, miscommunications, and frustration we felt lived in the space between them. Anybody who served knows how MKs and BMs always fit for time either for training, operations, or maintenance. We all need each other but need the resources and time to focus on our part of the puzzle. If alignment could happen there, the benefits would not stay contained. They would ripple across the station. Therefore, let’s just start with getting them aligned.

Why Pilot Teams Actually Work

A pilot team is not a rehearsal. It is closer to a controlled experiment with real consequences. Pilots allow people to see change rather than be told about it. They create space to learn, to make mistakes early, and to build momentum through visible wins.

Organizations tend not to trust what they cannot see. A pilot makes progress tangible.

Pilots also protect skeptics in a way arguments never will. Instead of debating theory, you let people experience fewer surprises, clearer priorities, and better coordination in the environment they already know. When that happens, resistance often softens on its own.

Choosing the Right Place to Pilot

Before committing, we researched answers to a few grounded questions.

·         Where does friction show up most often?

·         Where does the work cross department boundaries?

·         Where are leaders open to learning instead of defending the status quo?

·         Where can improvement be measured without turning people into metrics?

·         And just as important, where can we protect people from burnout?

Those questions led us to a small pilot group just starting a Scrum batt rhythm and getting all the tasks in one spot. We used the guidance we’ve all heard before in the Coast Guard: Train, Maintain, Operate.  This brought guidance to how we were building out the Sprint and what was more important. The Officer of the Day loved the online version within Teams because it morphed into the Plan of the Day after the pilot allowing them to see the exact plan for each duty period in real time. No extra communication needed from the command because it was all there.

Starting Simple on Purpose

When we introduced Agile concepts like Scrum and Kanban slowly to the smaller teams, we resisted the urge to do everything at once. That temptation is real, especially for leaders who want quick results. Instead, we kept it small.

We used the Scrum framework for meetings and built a simple Kanban board in Microsoft Teams. That was it. No complex tools. No heavy terminology. The goal was straightforward. Help people see the work, talk about it regularly, and adjust together.

Cadence came first. Short daily check ins each morning held at the same time and in the same place. The first week felt awkward. People over explained and tried to solve all the problems at the Daily Stand up while others stayed quiet unsure about the change. A few weeks in, patterns began to settle. Operations heard about maintenance issues earlier. Engineering learned about schedule changes sooner. Guesswork faded, and planning became less reactive.

Learning From the Friction

Not everything moved cleanly, and I would have been concerned if it had. A few meetings drifted into problem solving before we were ready. One sprint review turned into a real debate instead of a reflection. A handful of people hesitated to be fully transparent, likely because old habits do not disappear overnight. I did not see those moments as setbacks. I saw them as signals. Each one pointed us toward where facilitation needed tightening, where psychological safety still needed reinforcement, and where expectations had not yet fully landed. In my experience, change without friction is usually change that has not gone deep enough to matter.

The real turning point arrived during a high tempo weekend when everything seemed to stack at once. We were managing multiple search and rescue cases while dealing with unexpected maintenance issues, coordinating with outside agencies, and covering a watch that was already thin. In the past, that kind of convergence would have felt chaotic, with information lagging and decisions backing up. This time, the pressure was still there, but the confusion was not. Communication moved early and clearly. Maintenance limits were visible before they became surprises. Junior members spoke up without waiting for permission, and senior leaders trusted the picture they were getting. The system did not eliminate the stress, but it absorbed it.

That weekend clarified that what we had been practicing was no longer theoretical or confined to meetings and boards. It was showing up when the pace was unforgiving and the margin for error was small. That is when the crew stopped asking whether this way of working made sense. They could feel it. This was not about process. It was about readiness.

Learn Fast, Scale Slowly

At the end of the fourth sprint, I told the pilot teams we were not scaling yet. Some were surprised. But scaling too early only spreads unfinished habits. We needed consistency, not just enthusiasm. Once discipline matched energy, expansion would make sense. And when it did, the station would be ready.

About three months into the change, we introduced velocity, and that timing mattered more than the tool itself. By then, the teams had settled into a rhythm. Meetings were no longer awkward. The cadence felt normal. People were thinking in cycles instead of reacting hour to hour. Only after that foundation was in place did it seem wise to add another layer of visibility.

We started carefully, using a Fibonacci based point structure, not as a performance metric but as a way to see the work honestly. What followed surprised a lot of people, including me. For the first time, we could see how much work the crew was actually carrying. Not just the mission critical tasks, but everything else that quietly consumed energy. The same people responsible for search and rescue were also mowing the lawn, cleaning the mess deck, wiping down government vehicles, troubleshooting printers, and handling countless small tasks that never showed up in any formal plan. Velocity did not expose inefficiency. It exposed reality.

That visibility changed the conversation. It became clear that we were asking a small crew to be experts at everything, which is impossible no matter how motivated or capable people are. The value of velocity was not in pushing the number higher. It was in finally seeing the full load and acknowledging it out loud. Once the work was visible, tradeoffs became easier to discuss, priorities became more honest, and the team felt less like they were failing at an invisible standard. We were not doing too little. We were doing everything.

That insight reinforced why we moved slowly. By waiting until the rhythm was established, velocity became a tool for understanding rather than pressure. It helped us protect the crew instead of squeezing them, and it grounded future decisions in something real rather than assumptions.