Your team probably uses Agile. Scrum, Kanban, something hybrid. You've read Part 1 of this book and recognized everything: the estimation theater, the velocity metrics that measure motion instead of progress, the retros that produce action items nobody acts on, the burnout from arbitrary sprint commitments.
This chapter is about crossing the bridge. Not running both methodologies in parallel, that's just more process. This is about what to drop, what to keep, and how to transition without blowing up your team.
ARC doesn't replace your standup. It gives your standup something coherent to talk about. Think of ARC as the director's cut. Same movie, but now the scenes actually connect.
Overheard in Standup
"Is this a 5 or an 8?"
"It depends on 20 things we won't know until we start".
"Let's call it a 5".
What to Drop
These Agile practices cause more harm than good. ARC replaces them with something that actually works.
Drop: Estimation Theater
Story points. Planning poker. "Is this a 5 or an 8?" Hours of debate that produce numbers nobody believes, used to calculate velocity metrics that mean nothing.
Why it fails: Estimation assumes predictable work. Pattern discovery isn't predictable. When you find a pattern mid-sprint, no estimate survives contact with that reality.
What replaces it: Pattern-aware estimation. Honest timelines, not theater.
For internal budgets and planning:
- "This feature uses existing patterns: 2 days".
- "This feature needs a new pattern: 1 week for the pattern, then 2 days for the feature".
- "Q2 roadmap: 3 features on existing patterns (fast), 2 features requiring new patterns (budget extra time)".
Patterns make future work predictable. The first use of a pattern is uncertain. The tenth use is a known quantity. Budget accordingly.
For client/agency work:
- Phase 1: Architecture + first feature (less predictable, build in buffer)
- Phase 2-N: Features using established patterns (predictable, can quote confidently)
- Sell the pattern investment: Week 1 costs more. Weeks 2-10 cost less. Total is lower than building everything custom.
You still estimate. You just estimate honestly, based on whether patterns exist, not based on planning poker theater.
Drop: Velocity Metrics
Velocity measures tickets closed. It doesn't measure architectural coherence, pattern reuse, or whether the codebase is getting better or worse.
Why it fails: Teams optimize for the metric. Close more tickets = look productive. Extract a pattern that saves 50 tickets next quarter = look slow this sprint. The incentive is backwards.
What replaces it: Pattern ROI. "This pattern was used 15 times this quarter. Each use saved 3 days. Total: 45 days saved". That's a metric worth tracking.
Drop: Tech Debt Sprints
Every 4-6 sprints, you stop feature work to "pay down tech debt". Everyone hates it. Product is frustrated. Engineers feel like they're cleaning up their own mess.
Why it fails: Tech debt sprints are emergency surgery for a problem that shouldn't exist. If you had patterns, you wouldn't accumulate the debt in the first place.
What replaces it: Consolidate phases. Regular, planned, expected. Not "we broke everything and need to fix it" but "we learned things and need to integrate them". The framing matters. One is failure, the other is evolution.
Drop: Arbitrary Sprint Commitments
"We committed to 40 points, we must deliver 40 points". Even when you discover mid-sprint that the architecture is wrong. Even when extracting a pattern would save the next 10 sprints.
Why it fails: Commitment to arbitrary numbers overrides engineering judgment. You ship garbage to hit the number, then spend twice as long fixing it later.
What replaces it: Commitment to outcomes. "We'll ship the feature or discover why we can't". If "why we can't" is "we need a pattern first", that's valuable information, not failure.
What to Keep
Not everything about Agile is broken. These practices actually help.
Keep: Regular Cadence
Two-week sprints, weekly syncs, whatever rhythm works. The discipline of regular checkpoints prevents six-month disappearances into architecture astronaut territory.
How it changes: The cadence stays, but what you measure changes. Not "did we close tickets?" but "did we learn something? did patterns emerge? is the system more coherent than last week?"
Keep: Daily Sync
Standups work. Fifteen minutes to know who's blocked, who needs help, what's happening. Keep them.
How it changes: Add one question: "Did anyone notice a pattern we should extract?" Make architectural observation part of the daily rhythm.
Overheard in Standup
"What action items came out of the retro?"
"Same as last month. We still haven't done them".
Keep: Retrospectives
Looking back at what worked and what didn't. Valuable. Keep doing it.
How it changes: Focus shifts. Not "how do we go faster?" but "what did we learn about the system? what patterns emerged? what should we consolidate?" Retros become consolidation moments, not process-improvement theater.
Keep: Visual Boards
Kanban boards, sprint boards, whatever you use. Visibility into work-in-progress helps coordination.
How it changes: Add pattern work as visible, first-class work. Not hidden in "tech debt" or buried in feature tickets. A pattern extraction is a card on the board, estimated, tracked, celebrated when done.
How to Transition
You can't flip a switch. Here's how to cross the bridge gradually.
Step 1: Observe (1-2 sprints)
Don't change anything yet. Just watch.
Look at your last 10 sprints:
- How many were "mostly planning"? Those were accidental Align phases.
- How many were "mostly refactoring"? Those were emergency Consolidate phases.
- How many times did someone say "we should extract this pattern" and get ignored?
You're already doing ARC. Badly, reactively, and calling it something else. The goal is to make it intentional.
Step 2: Try Aligning Before Building
Before your next task, try actually understanding it first:
- What are we building? What might repeat?
- Map enough to see the shape, then start
- If you discover a pattern need, align on THAT pattern before building it
Watch what happens. Are decisions easier? Are debates shorter? Is there less "wait, why did we build it that way?"
Alignment isn't a separate sprint. It's part of each task, as long as needed to understand.
Step 3: Normalize Pattern Work (ongoing)
The next time someone says "I noticed a pattern we should extract", the answer isn't "that's scope creep".
The answer is: "Good catch. How long to extract it?"
Two days? Do it now. Two weeks? Create a ticket, but a real ticket, prioritized, not buried in the backlog to die.
Step 4: Replace Tech Debt Sprints (when ready)
Instead of emergency "tech debt sprints", schedule regular Consolidate phases:
- Every 4-6 sprints, one sprint focused on consolidation
- Apply patterns discovered during recent work
- Update documentation
- Refactor toward coherence
Same time investment as tech debt sprints. Different framing. One is cleaning up failure. The other is integrating success.
Step 5: Measure What Matters (ongoing)
Stop tracking velocity (tickets closed). Start tracking:
- Pattern reuse: how many features used existing patterns?
- Pattern ROI: time saved by patterns this quarter
- Coherence: do new features fit the architecture, or fight it?
These metrics reward good engineering instead of punishing it.
What Changes Day-to-Day
The ceremonies stay, the conversations shift. Sprint planning stops being about points and starts being about patterns.
Here's how the daily experience shifts:
Sprint Planning
Before: How many points can we commit to? Let's play planning poker for 2 hours.
After: Which features use existing patterns? Which need new patterns? What's the realistic timeline for each?
Mid-Sprint
Before: Engineer notices duplication, thinks "I should extract this", then thinks "but I committed to 40 points", ships the duplication, feels bad.
After: Engineer notices duplication, says "I found a pattern", team decides if it's worth extracting now or later. Either way, it's acknowledged, not ignored.
Standups
Before: "I closed ticket X, I'm working on ticket Y, no blockers".
After: "I closed ticket X using the validation pattern. Working on Y, noticing it might need a new pattern for error handling. Want to discuss after standup?"
Retrospectives
Before: "How do we go faster? Let's add another process".
After: "What patterns emerged this sprint? What should we consolidate? What did we learn about the system?"
The Vibe
Before: Pressure to hit arbitrary numbers. Guilt when you see duplication but ship it anyway. Burnout from endless refactoring.
After: Permission to do good engineering. Pattern work is celebrated, not hidden. The system gets better over time, not worse.
Resistance You'll Face
Transitions are uncomfortable. Here's what you'll hear:
"This sounds like Waterfall". Waterfall is 6 months of upfront planning. An Align phase is 3-5 days. Not the same.
"We don't have time for this". You had time for three tech debt sprints last quarter. That was unplanned Consolidate work. This is planned Consolidate work. Same time, better results.
"Product will never agree". Show them the cost of the last emergency refactor. Show them the pattern that saved 45 days this quarter. Speak their language: money and time.
"We're already doing Agile". Yes. And it's causing the problems Part 1 described. This is the fix.
The Tipping Point
The transition succeeds when the team experiences sustained velocity for the first time.
Not the sprint-to-sprint chaos of "fast then refactoring then fast then refactoring". Actual compounding speed, where each sprint is easier than the last because patterns are working, architecture is coherent, and decisions are clear.
When engineers feel that, they don't go back.
When they spend 2 hours implementing a feature that would have taken 2 weeks before patterns existed, they get it. When they stop dreading the codebase and start trusting it, they get it. The bridge isn't about adding process. It's about removing the obstacles that prevent good engineering.
ARC is what happens when you stop fighting your methodology and start doing the work you knew was right all along.