Stop Picking Sides: Manage the Tension Between Adaptation and Optimization

Jim Highsmith notes that many teams have turned into
tribes wedded to exclusively adaptation or optimization. But he feels this
misses the point that both of these are important, and we need to manage
the tension between them. We can do this by thinking of two operating
modes: explore (adaptation-dominant) and exploit (optimization dominant).
We tailor a team's operating model to a particular blend of the two -
considering uncertainty, risk, cost of change, and an evidence threshold.
We should be particularly careful at the points where there is a handoff
between the two modes

more…

Stop Picking Sides

Manage the Tension Between Adaptation and Optimization

*Many teams have turned into tribes wedded to exclusively adaptation
or optimization. But this misses the point that both of these are important,
and we need to manage the tension between them. We can do this by thinking of
two operating modes: explore (adaptation-dominant) and exploit
(optimization dominant). We tailor a team's operating model to a particular
blend of the two - considering uncertainty, risk, cost
of change, and an evidence threshold. We should be particularly careful at the
points where there is a handoff between the two modes*

13 January 2026

Jim Highsmith

Jim has worked across just about every role in tech—from coding and
product design to senior management and executive consulting. He's
co-founded agile communities, written six books, co-authored the Agile
Manifesto, and spent a lifetime exploring how people lead through
uncertainty. He's now in “soft-retirement”.

agile

process theory

Contents

• Why this matters now (beyond software)

• What I mean by “two modes”

• Explore mode (adaptation-dominant)

• Exploit mode (optimization-dominant)

• One important nuance: dominance, not purity

• A bridge state: “Expand”

• The handoff tax

• A quick detour: why bimodal IT backfired

• A concrete example: Sciex and early integration

• Make dominance operational: four dials

• Explore-dominant: tune the learning loop

• Expand: scale proof and tighten constraints

• Exploit-dominant: adapt inside guardrails

• Decision rights: use DARE, not RACI

• Tailoring: treat it as operating design

• The take-away

I like Agile. I like discipline. I like systems that ship and systems
that learn.

What I don’t like: tribes.

In the last couple decades, many teams camped at the ends of a
spectrum:

• Traditional shops treated optimization as virtue and adaptation as risk.

• Agile shops treated adaptation as virtue and optimization as betrayal.

Both missed the point.

By adaptation I mean fast learning and course-correction under
uncertainty.

By optimization I mean reliability and repeatability under
constraints.

The mistake is treating either one as a permanent operating mode.

The adult question is: what should dominate right now?

This is a tension to manage, not a side to pick.

Why this matters now (beyond software)

Software teams have lived inside this tension for years.

Now more industries hit the same wall—fast.

Life sciences (Biotech) provides clear examples. Tools like CRISPR
(gene editing), AlphaFold (3-D protein folding) and other AI-assisted
discovery models compress early cycles.

CRISPR‑based tools aided COVID‑19 research and target discovery, while
platform technologies like mRNA and viral vectors were the key enablers of
the one‑year vaccine timeline. AlphaFold can often do in hours on a
computer what used to take months or years in the lab.

Using these tools teams can explore more options, faster. That sounds
like pure upside—until you remember the other side of the tension:
downstream work gets more expensive, more constrained, and less
forgiving.

Faster learning does not remove constraints. It raises the cost of
sloppy decisions.

So the capability gap shifts. It’s no longer “Can we “do” Agile?” It’s:
Can we manage the Adaptation ↔ Optimization tension on purpose—at
speed?

What I mean by “two modes”

I use two modes as a practical shorthand. They are not philosophies.
They are operating patterns.

Explore mode (adaptation-dominant)

Purpose: reduce uncertainty fast.

Explore mode treats work as a series of hypotheses.

• You run short cycles: hypothesis → test → signal → decision.

• You keep costs low so you can change course.

• You protect evidence quality enough to trust the signal.

Explore mode does not mean chaos. It means you optimize the
learning loop.

Exploit mode (optimization-dominant)

Purpose: reduce variance under constraints.

Exploit mode treats work as a system you must run reliably.

• You tighten the process.

• You raise evidence thresholds.

• You protect safety, quality, security, traceability.

• You still adapt, but only inside clear guardrails.

Exploit mode does not mean bureaucracy. It means you optimize
reliability.

One important nuance: dominance, not purity

Both modes exist all the time.

• Explore phases still need optimization (cycle time, evidence hygiene, stop

rules).

• Exploit phases still need adaptation (disciplined amendments, controlled

experiments, risk-based exceptions).

Dominance keeps you out of religion.

A bridge state: “Expand”

Using the words explore and exploit often brings to mind Kent Beck’s
explore–expand–extract. That connection is useful.

I see expand as the bridge state where a promising signal moves from
cheap learning to scaled evidence.

In expand, you do three things at once:

• 1. Scale proof (more cases, more volume, more environments)

• 2. Raise constraints (quality, safety, governance, integration

discipline)

• 3. Reduce ambiguity (clear thresholds for the next commitment)

Expand is where many orgs pay the highest handoff tax, because teams
keep explore behaviors while the work now demands exploit discipline.

The handoff tax

Most programs don’t fail inside a phase.

They fail at the seams.

• translation failures (same words, different meaning)

• evidence mismatch (different bars for “enough proof”)

• ownership fog (too many votes, too many vetoes)

• traceability gaps (no one can reconstruct why a choice happened)

If you want speed, cut handoff tax. It beats “doing Agile harder.”

A quick detour: why bimodal IT backfired

One early “solution” to this tension was bimodal IT: put exploratory
work in one lane and stable delivery in another—frequently as separate
organizational units.

On paper it looked tidy.

In practice it turned into warring tribes. One side became the
innovation heroes. The other became the stability police. Decisions
bounced between them, handoff tax exploded, and leaders tried to manage
conflict instead of designing the work.

The lesson: you can’t outsource this tension to an org chart. The
capability has to live in every person who makes decisions—from team
members to executives.

A concrete example: Sciex and early integration

In 2004–2006 I worked with Sciex, an ISO-certified mass spectrometry
instrument firm. A crash in the middle of a sample run can ruin an
experiment and waste irreplaceable samples.

After a year plus working with software teams we tackled a daunting
project–development of a new mass spec instrument.

We found the big killer to be integration debt (handoff tax)—the pain
you store up when hardware, firmware, and software converge late.

ISO requirements kept governance real. So we avoided a false
choice.

• Governance optimized for time, money, and traceability.

• Execution adapted to uncertainty with short feedback loops and early

integration.

Then the Director of Product Development pushed a simple shift:

• firmware delivered to hardware in iterations, paced by hardware’s test

schedule

• once hardware reached “enough function,” software joined to add

applications—also in increments

• they did not wait for a fully populated digital board to start

integration tests

Outcome:

• integration tests started sooner, so issues surfaced earlier and resolved

faster

• integration stayed continuous once minimal hardware existed, so the usual

end-game resource spike disappeared

• communication improved because all groups participated in integration, not

just at the panic stage

That is dominance tuning in the wild:

• explore early where uncertainty stays high

• expand as evidence scales and constraints rise

• exploit once reliability matters more than option creation

Make dominance operational: four dials

If you want dominance without debates, use dials.

[...]

Original source