McKinsey Just Killed Agile: Why 'Commando Units' & Spec-Driven AI Are The Future of Legacy Migration

Listen. I’m going to be brutally honest because I’m too old to play corporate politeness games.

For the last three articles, I’ve been advocating for a controversial operational model I call "Tiger Teams" or "Commando Units".

The premise was simple: Stop the relay race. Stop treating software engineering like an assembly line where 8 people pass a ticket around for two weeks. Put 3 senior engineers in a room, give them absolute silence, and watch them migrate a monolithic payment gateway to AWS in 4 days.

My inbox was full of Project Managers telling me this is "unsustainable."

Well, last week, McKinsey & Company validated everything the "Old Foxes" have been saying for years.

Let’s break down the data, the math, and the new toolchain (Kiro) that makes this possible.

The Data: 10% vs. 700%

In the video below, Martin Harrysson drops a bomb on the industry.

Most companies are currently trying to sprinkle GenAI on top of their existing Agile processes. They keep the 10-person teams, the daily standups, and just give everyone an autocomplete tool.

The result? A pathetic 10-15% productivity gain. (According to McKinsey).

Why? Because the bottleneck isn't typing speed. It's communication overhead.

However, companies that change the Operating Model to what I call "Commando Units" (Small Pods) are seeing results that are transformational. Based on my own deployments of this model in Cloud Migrations, we are seeing a 5x to 7x efficiency jump.

The "2-Pizza Team" is Too Big

In 2026, a single Senior Architect with the right Agentic IDE has the output capacity of 5 juniors from 2020.

The New Rule: The "1-Pizza Pod"

• Size: 3-4 People Max.
• Composition: 1 Lead Architect, 1-2 Senior Devs, 1 QA/Data Specialist.
• Methodology: Continuous Flow, not Sprints.

The Pivot: From "User Stories" to "Hard Specs"

This is where most Agile coaches will start sweating.
We have spent the last decade training developers to write fuzzy "User Stories."

"As a user, I want to upload a file..."

This is useless for an AI-driven workflow. AI models hallucinate when you give them ambiguity. They thrive when you give them constraints.

If you are modernizing a 15-year-old Java Monolith to AWS Lambda, you don't need a User Story. You need a Specification.

The Weapon of Choice: Kiro (The Spec-Driven IDE)

I have stopped using standard chat-based assistants for complex migrations. They are too "chatty" and lose context.

Recently, I switched to Kiro.dev because it enforces a Spec-Driven Workflow. It doesn't guess; it follows the "Steering" files.

Here is my exact workflow for migrating a legacy module to AWS:

Step 1: Define the "Steering" (The Rules of Engagement)

In Kiro, I don't repeat myself. I define project-wide rules in the .kiro/steering/ directory.

File: .kiro/steering/tech.md

# AWS Migration Standards
1. **Compute:** Target AWS Lambda (Java 21 SnapStart) or Fargate.
2. **Persistence:** DynamoDB (Single Table Design) preferred over RDS.
3. **Observability:** implementation must include CloudWatch Structured Logging.
4. **Validation:** Use Pydantic (if Python) or Jakarta Validation (if Java).
5. **Forbidden:** Do not use `System.out.println`.

Step 2: Write the Spec (Not the Code)

Instead of writing a prompt, I write a .md spec file. Kiro reads this and plans the implementation.

File: specs/01_order_service_migration.md

# Specification: OrderService Migration
**Goal:** Refactor `EJBOrderService.java` to `OrderLambdaHandler.java`.

## Interface Contract
- **Trigger:** SQS Event (JSON payload).
- **Output:** Write to DynamoDB table `Orders`.

## Business Rules (Strict)
- Verify `totalAmount > 0`.
- If `customerType` is "VIP", apply 5% discount (logic copied from legacy).
- Idempotency: Use `orderId` as the DynamoDB Partition Key.

## Error Handling
- If DynamoDB throws `ProvisionedThroughputExceeded`, implement exponential backoff.
- Any other error -> Send to SQS Dead Letter Queue.

Step 3: The "Legacy Factory" Execution

Once the spec is ready, I trigger Kiro's Agent.

Prompt: "Implement specs/01_order_service_migration.md following the rules in .kiro/steering/tech.md. Generate the Infrastructure-as-Code (CDK) as well."

Because Kiro understands the entire project context and strict Specs, the code comes out production-ready, typically passing 90% of unit tests on the first run.

The ROI Calculation (Show this to your Boss)

Let's talk money.

Feature	Standard Agile Team	Commando Pod + Kiro
Headcount	8 Developers + 1 SM + 1 PO	3 Senior Engineers
Meetings/Week	~12 hours/person	~2 hours/person
Workflow	"Jira Tickets & Chat"	"Spec-Driven Agents"
Velocity	Linear (1x)	Exponential (5x)
Cost	High (10 salaries)	Medium (3 high salaries)

Final Thoughts: The Silence of the Lambs

My "Grand Strategy" for 2026 is simple: Deep Work and Silence.

I have blocked my calendar from 09:00 to 11:00. No meetings. No Slack. Just me, the AWS Console, and the Kiro Agents.

The McKinsey video proves that this isn't just "introvert preference." It is the optimal economic strategy for software development.

If you are a developer: Stop coding. Start architecting.
If you are a Manager: Stop scaling up. Start scaling down.

---

I am Jacques Montagne. I specialize in migrating Legacy Monoliths to AWS. I am currently building the "Legacy Commando" methodology using Kiro.dev. Follow me for more field reports.