Unified context for adaptive teams

Why do some product teams learn and adapt faster than others?

The entire ensemble was energized. We’d just discovered a critical insight that would completely change our approach, and we needed to capture it in the story before the momentum died.

“Let me update the Jira ticket,” someone volunteered.

A browser tab opened. Then the dreaded redirect: “Your session has expired. Please log in.”

“I’ve got Jira open,” another voice offered. Screens shifted. Tabs shuffled. “Wait… which board was this story on again?”

Three minutes turned into five. Someone finally found the right tab. “Okay, I’ll share my screen.”

By the time we could actually see the ticket, the clarity of our insight had already started to fade. The cost of that friction? Not just five minutes, but the precision of understanding we’d worked so hard to achieve.

This happens dozens of times per day on most software teams. After 25+ years in software development, I’ve learned that a team’s ability to adapt depends entirely on how well they share context. On a government project at Flexion, we discovered that solving the shared context problem transformed us from constantly fighting outdated context to adapting together as understanding emerged in real-time.

The shared context problem

The fundamental challenge isn’t about tools, it’s about alignment. When team members don’t share the same context, they can’t adapt together.

On a large-scale government healthcare project with strict compliance requirements, we work in ensembles (multiple developers collaborating on the same code at the same time). This practice should enable incredible adaptability. When you discover something new, the whole team learns immediately. When requirements shift, the group pivots together.

But ensemble work only succeeds when everyone has access to the same information at the same moment. Traditional development workflows fragment context:

• Requirements live in Jira‘s complex UI, outside the developer’s main working environment
• Referencing context requires leaving the IDE, navigating to a browser, and finding the right ticket
• When someone asks, “What did the acceptance criteria say again?” it breaks the ensemble’s flow
• The group can only adapt as fast as the slowest person can regain context

We discovered that shared context isn’t just about efficiency. It’s the foundation of team adaptability.

Why adaptive teams need shared context

There’s research from UC Irvine showing it takes an average of 23 minutes and 15 seconds to regain focus after an interruption. But the real insight isn’t about individual focus. It’s about collective adaptation.

When an ensemble discovers that their current approach won’t work, they need to pivot together. This requires:

1. Strong shared understanding of current context: What have we learned so far, even as understanding evolves minute by minute?
2. Shared sense of direction and outcome: What are we actually trying to accomplish together?
3. Diverse perspectives for creating options: How can different viewpoints help us identify multiple paths forward?
4. Collective navigation of complexity: Combining shared context and direction to increase our likelihood of achieving the desired outcome

If one person needs to switch to a browser, find the right Jira ticket, scroll through comments, and relay information back to the group, the ensemble loses its primary advantage: the ability to adapt as a single, coherent unit.

The four patterns that block shared context

A recent conversation in the game development community crystallized what many teams experience. When asked how to improve game development across the board, a senior leader replied: “Delete every Jira instance.”

The problem isn’t Jira itself. It’s how traditional tools fragment team context:

1. Centralization creates information asymmetry

When context lives in a centralized system that’s optimized for management visibility, the people doing the work become information consumers instead of information owners. Ensembles need democratic access to a context where everyone sees the same thing at the same time. Centralized tools create information asymmetry that prevents collective adaptation.

2. The map isn’t updated by the territory explorers

Requirements in Jira represent what we thought we knew when we wrote the ticket. But ensembles constantly discover new information. The team working on the code understands the actual constraints better than anyone. Updating requires leaving the editor and switching to a browser, which means the people discovering the information aren’t positioned to capture it as they learn. The “map” diverges from reality because documentation happens in a different workspace than discovery.

3. Tool friction prevents real-time updates

When updating context requires leaving your development environment, navigating through a web interface, and fighting with rich text editors, teams simply don’t do it. The friction is too high. So context becomes stale, and the team loses the shared understanding that enables adaptability.

4. Context lives in the wrong place

The final problem: When context lives in a tool optimized for stakeholder reporting instead of developer collaboration, the ensemble can’t use it effectively during the actual work. Shared screens, browser tabs, and “let me pull up the ticket” all signal that context is in the wrong place for the people who need it most.

Our solution: Unified context for adaptive ensembles

We stopped treating requirements and code as separate concerns. Instead, we unified them.

We implemented bi-directional sync between markdown files in our repository and Jira tickets using imdone-cli. Here’s what this enabled:

Shared context for ensembles:

• Story details live as markdown files right next to the code
• Everyone in the ensemble sees the same file in their own editor
• When someone asks, “What are we building?”, everyone can reference the same context immediately
• No information asymmetry: all team members have equal access
• As teams incorporate AI agents into their workflow, markdown provides a machine-readable format that both humans and AI can access without translation layers

Real-time adaptation:

• When the ensemble discovers new constraints, we update the story markdown
• Changes are visible to everyone immediately
• Design decisions capture context as we learn it
• The shared understanding evolves with our learning

Collective ownership:

• The ensemble updates the story markdown directly as they work
• When stakeholders update Jira, imdone pull brings changes into local markdown with git-style conflict resolution
• Context updates are versioned like code
• Jira history shows how collective understanding evolved

Stakeholder alignment maintained:

• Developers push changes to Jira with imdone push
• Stakeholders continue working in Jira as normal
• Changes from Jira flow back to developers via imdone pull and imdone merge
• Compliance and audit requirements still met
• Management visibility unchanged

The transformation: from coordinated to adaptive

The impact was profound. Our ensemble work went from coordination to true collaboration.

Before unified context:

• “Wait, let me pull up the ticket…”
• “Can you share your screen so I can see the acceptance criteria?”
• “What did that comment from the PM say?”
• One person held the context, and others tried to keep up

After unified context:

• Everyone references the same file in their editor
• When we discover new information, we update the story markdown together
• Questions get answered without breaking the flow
• The ensemble adapts as a single unit

Most importantly, our ensemble became genuinely adaptive. When we discovered that an approach wouldn’t work, we could pivot immediately because everyone had instant access to the constraints and context. We didn’t need to coordinate because we were already aligned.

Management gained deeper insight, too. When they see story updates syncing to Jira with context about why requirements evolved, they understand our adaptive process. They see learning happening in real-time, not just status changes.

The cultural shift: From handoffs to continuous alignment

The breakthrough wasn’t technical. It was cultural. We already knew requirements should evolve through ensemble learning – but tool friction had forced us to let context go stale in Jira. Removing that friction meant we could finally keep shared context current without breaking flow.

When your ensemble discovers that a feature is more complex than expected, you update the shared context right there, capturing what you learned. The ensemble continues adapting while the PO stays informed through real-time sync. Collaboration happens continuously instead of through ticket handoffs.

Stakeholders still get visibility. Compliance is still maintained. But the ensemble doesn’t break the flow to coordinate with external systems. A simple imdone push syncs the shared context to stakeholder tools while keeping the team in a state of continuous adaptation.

What this enables

Even when teams work collaboratively with POs and in ensembles, tool friction creates invisible handoffs: the moment when learning must be transferred from the developers’ heads into Jira for stakeholder visibility. That friction means context goes stale.

Unified context enables continuous alignment instead:

• No information lag within the ensemble: Everyone sees the same context at the same time
• Real-time learning propagation: When the team understands something new, the context updates for everyone immediately
• Collective adaptation: The group pivots together based on emerging understanding
• Reduced cognitive load: Less time retrieving context means more capacity for problem-solving
• Stakeholder alignment with minimal friction: POs and management stay current through automated sync

The result: Ensembles that adapt like organisms instead of coordinating like committees.

For other teams

If your team wants to become more adaptive, solve your shared context problem first:

1. Can your whole ensemble see the same context simultaneously? If someone needs to share their screen to show a ticket, you have a shared context problem.

2. Can your team update context as they learn? If updating requirements requires leaving the development environment, friction prevents real-time adaptation.

3. Can context updates propagate easily? If significant manual effort is required to keep stakeholders aligned, teams will optimize for building instead of communicating.

4. Who owns the context? If the ensemble doesn’t collectively own the shared understanding of what they’re building, they can’t adapt effectively.

We learned that adaptive teams require unified context. When requirements live next to code, when everyone can see and update the shared understanding, when stakeholder alignment happens with minimal friction, that’s when ensembles become truly adaptive.

The traditional model asks: “How do we coordinate handoffs effectively?”

The adaptive model asks: “How do we eliminate handoffs through continuous alignment?”

Unified context is the answer. The tools exist. The approach works. It just requires recognizing that in adaptive development, context fragmentation is the root problem, and solving it transforms everything else.

Hint: If your ensemble is constantly asking, “Which ticket are we working on?”, you have a shared context problem.ms reduce risk, strengthen alignment, and keep products resilient in the face of change.