When projection fails: recognizing non-portable strategy
The mechanics of failed projection
When we project a strategy from one context into another, we expect friction. A retail promotion designed for urban foot traffic won't map cleanly onto rural mail-order. The question is whether the idea bends or breaks.
Breakage is useful. It tells you which components of your strategy are environmental accidents and which are weight-bearing.
Last year a mid-sized software team asked us to project their sprint ceremonies into a fully asynchronous model. They were adding engineers across eight time zones and wanted to preserve what worked. We documented their existing rituals—daily standups, planning poker, retrospectives—and attempted transfer.
Three ceremonies projected. Two did not. The retrospective format survived intact; planning poker became unrecognizable and stopped functioning after one iteration.
What survived
Their retrospective structure was almost entirely portable. It relied on written reflection, not synchronous presence. Engineers posted observations to a shared board throughout the sprint, then voted on themes during a 48-hour window. The discussion phase used threaded comments. We moved this into their async workflow with minor adjustments to voting mechanics.
Their documentation practice also projected cleanly. They already wrote design proposals before building. The shift to async just formalized the review period and made feedback threading more explicit.
Standups required modification but kept their function. We replaced the synchronous call with a bot that collected updates on a rotating 24-hour cycle. Engineers posted when they started their day. The digest went out when the majority had checked in.
What collapsed
Planning poker didn't survive. The original ceremony depended on simultaneity—engineers revealed estimates at the same moment to avoid anchoring. In async, that simultaneity dissolved. Early estimates anchored later ones despite our attempts at blinded submission. Worse, the discussion that resolved disagreement lost its momentum across time zones. What took fifteen minutes in a room took three days in threads, and estimates converged toward wherever the tech lead had landed.
We tried four variations. None worked. The idea had no meaningful projection into asynchronous space.
The sprint demo also failed transfer, though differently. It technically functioned—engineers recorded demos, stakeholders watched on their own schedule, feedback arrived in comments—but it stopped serving its actual purpose. The original demo created a forcing function: engineers had to finish something showable by Friday. The async version removed that forcing function. Demos dribbled in across the week. Feedback came late or never. The ceremony existed but carried no weight.
Using the failure
The client kept what projected and replaced what didn't. Planning poker became a different process: the tech lead estimated first, engineers critiqued the estimate in a structured document, and disagreements escalated to a synchronous call with only the relevant people. Fewer engineers, smaller time window, specific agenda. Not a projection of the original ceremony—a different idea built for the constraints.
The sprint demo was harder. We ended up recommending they abandon async demos entirely for customer-facing work and hold one monthly synchronous showcase. For internal work, they moved to a pull-request-based review model with recorded demos only when the PR needed extra context.
This is the geometry speaking: an idea defined by real-time simultaneity has no projection into asynchronous space. You can rotate it, you can approximate it, but the thing itself does not transfer. Knowing that early saved them months of trying to fix a ceremony that was never going to work.
What to measure
When you attempt projection, track:
- Which components transfer with no modification
- Which transfer but require adaptation to maintain function
- Which lose all function despite faithful reproduction
- How long it takes to recognize non-portability
That last metric matters most. The software team spent five weeks trying to fix async planning poker before accepting it wouldn't work. We should have caught it in two. The warning sign was there: every proposed fix addressed symptoms (anchoring, slow discussion) without touching the underlying dependency on simultaneity.
If an idea's core mechanism requires a property the new context doesn't have, projection will fail. You can't project a three-dimensional solid onto a two-dimensional plane and expect it to cast a shadow with depth.
Deciding what to keep
Some clients want to preserve their existing practices even when projection fails. This is usually a mistake, but occasionally it's the right call. One question helps: is the ceremony's value in its function or its familiarity?
If it's function, build something new that accomplishes the same goal in the new context. If it's familiarity—if the team's cohesion depends on shared ritual—then you're solving a different problem, and projection isn't the right tool.
The software team's retrospectives worked because their function was already context-independent. Their planning poker failed because its function required a property—simultaneity—that async work fundamentally lacks. Recognizing that distinction quickly is worth more than any attempt to force the transfer.
For a related approach to identifying weight-bearing assumptions, see our earlier piece on surface analysis.