Jim Highsmith argues that teams have turned into tribes wedded to either adaptation or optimization, missing that both matter. He introduces two operating modes—explore (adaptation-dominant) and exploit (optimization-dominant)—and shows how to manage the tension between them by tuning four dials: uncertainty, risk, cost of change, and evidence threshold. The key is designing seams between modes to avoid the handoff tax that kills speed.
Featured image: The explore-expand-exploit model showing how teams manage adaptation and optimization tension.
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 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:
- Scale proof (more cases, more volume, more environments)
- Raise constraints (quality, safety, governance, integration discipline)
- 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. I call the hidden cost at seams the handoff tax:
- 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 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.
- Uncertainty — what you do not know yet
- Risk — what breaks if you guess wrong
- Cost of change — what a pivot costs in time, money, credibility
- Evidence threshold — how much proof you require before you commit
Turn the dials, set dominance, then design the workflow to match.
Explore-dominant: tune the learning loop
- short cycle time from hypothesis → test → signal → decision
- clear stop rules (kill weak bets fast)
- evidence hygiene (assumptions, controls, reproducible notes)
Two common failures: slow learning and messy evidence.
Expand: scale proof and tighten constraints
- larger samples, broader environments, more integration points
- rising governance discipline
- explicit thresholds for the next commitment
Two common failures: false certainty and late integration.
Exploit-dominant: adapt inside guardrails
- disciplined amendments, with triggers and clean rationale
- controlled experiments (not accidental variance)
- traceability you can defend under audit
Two common failures: compliance theater and hidden workarounds.
Decision rights: use DARE, not RACI
Speed and accountability need clear decision rights. This is not hierarchy worship. Many orgs reach for RACI:Responsible, Accountable, Consulted, Informed. In practice, RACI often turns decisions into calendar sludge and polite vetoes.
Use DARE instead: Deciders, Advisors, Recommenders, Execution stakeholders. DARE keeps "servant leadership" and "self-organizing" (and their cousins: "empowered teams," "decentralized decisions") from sliding into soft anarchy: you can give more people a voice without giving everyone a vote.
- Deciders: the only votes; often one (but not exclusively)
- Advisors: strong voice, no veto
- Recommenders: build options and tradeoffs
- Execution stakeholders: execute the call and surface constraints early
DARE works at every level—from a product team to the CEO staff—because the pattern stays the same: clear decider(s), real input, real options, fast commitment. DARE saves autonomy from turning into consensus-by-exhaustion.
Tailoring: treat it as operating design
Many teams treat tailoring like weight loss: start with a big method, cut steps, hope speed shows up. That is disassembly. Real tailoring means design for fit:
- keep constraints that protect safety, quality, traceability
- keep practices that protect learning speed and option creation
- design seams so modes don't fight each other
Tailoring also demands judgment, and judgment stays scarce. You can buy tools and templates. You can't buy discernment at scale.
Jim Highsmith 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.
The take-away
Stop selling "Agile vs Traditional." That story sells the problem. Design for the tension:
- treat explore, expand, exploit as a set of dominance patterns
- turn the dials on purpose
- cut handoff tax at seams
- treat tailoring as operating design
Where do you pay the highest handoff tax today—and which dial would you turn first?
Significant Revisions
13 January 2026: Original publication
For more on the explore-expand-exploit model, see Kent Beck's work on the subject. For related thinking on managing technical and organizational debt, see Martin Fowler's articles on integration and continuous delivery patterns.
Comments
Please log in or register to join the discussion