Introducing Frontier Development

Three streams, one gap

I first heard about Dan Shipper’s Two Slice Team back in May 2026. He talks about Amazon’s “two pizza rule” and how these teams are too large for AI-native software work. The Two Slice proposes that it could only take one person to build and operate what might have once required a team.¹

It’s an interesting proposition - I think it works for solo operators and start-ups, but when you are running an larger organisation hinging on a single person’s existence. It’s a risky proposition when something breaks at 2am, and the AI is the only one with enough context to solve it. But it does rightly challenge what a perfect team size looks like in an agentic world.

At larger scale, you don’t just need a new development methodology, you actually need multiple, running side-by-side. I won’t go into the strengths and weakness of Agile + AI - it still has a place, and I’ve covered this in The Frontier Manifesto, but as “two slice” proposes, why is all this necessary when less people + AI can achieve the “same” outcome?

As it turns out, with most binary solutions, the answer usually lies in the grey between the two. Frontier Development is your second model designed to offset the weaknesses of Agile and feed more benefits back in then it takes out.

There are three unique streams of work forming:

1. Agile: Large, complex, long running work that is as human intensive on the design iteration, as it is on the build.

2. AI Organisations: Highly repetitive, predictable work. Maintenance tasks fit well here such as upgrades and patching.²

3. Frontier Development: High judgement, adhoc work that is relatively small (think: one delivery team, approx. two weeks), but the effort to build doesn’t outweigh the reward, and can’t compete with the bigger ticket items, and if it does manage to get prioritised, is a context switch for the whole team. This is the collection of works that takes the most to justify and is often left not done, like operational optimisations and CX enhancements.

So that is where Frontier Development sits. Now to look at how it runs.

The bubble

The bubble comprises an Engineering Leader, a Skilled Engineer and their Agentic Workforce.

The Engineering Leader brings intent, judgment, architecture, and is responsible for the Execution Plan. They are primary owners of the Forming and Storming stages.

The Skilled Engineer brings Engineering process and operational knowledge and are responsible for the Production Plan. They are primary owners of the Norming stage, and the handover to their delivery team in the Performing stage.

The stage lead flips the RACI model, so where the Engineering Leader starts out Responsible, then end up Consulted. The Skilled Engineer starts out Consulted and ends up Responsible. There’s a part in the middle where both are Responsible at the same time - it’s up to the pair to decide when to transfer to responsibility.

The bubble is the team. Next the stage model discusses how the team operates.

How it runs

Forming — The Spike

Before the bubble is formed, the Engineering Leader will have been involved with discussions of intent and output within the governance layer, and part of the approval process for this bubble to be formed in the first place.

As the bubble is forming, the Engineering Leader then spends time with their agentic workforce to draft the Execution Plan which focuses on feasibility and CX. The Engineering Leader may wish to prove out some initial spikes. No unit tests or any other hardening are required at this stage to ensure any pivots or refactoring is not time consuming for the agents.

The governance team identify a Skilled Engineer to join the bubble. It’s best to keep an up-to-date volunteer register, rather than be forced into an unwilling partnership. As Skilled Engineers are seconded from their delivery team, no more than one Engineer can be seconded from a team at any one time, so as to minimise the disruption to the team.

At some stage in the forming stage, the Engineering Leader leads a kick-off with the Skilled Engineer, to discuss the intent, the output, and a walk-through of the Execution Plan. The Skilled Engineer can give feedback in the moment, as well as review and give feedback after the kick-off.

Storming — Generative Build

The Engineering Leader may have already got a head start with their agents to complete some spikes or build out a POC, but this is the first phase where the Skilled Engineer is likely to get hands-on with the generative build. The Execution Plan is set, and ready to be taken on by the agentic workforce.

If both Engineering Leader and Skilled Engineer are eager to do so and the work splits neatly into separate concerns (and ideally separate repos and CI) then divide and conquer can work well. Frontend vs backend is a obvious example where the logical separator is the API.

If both intend to work on the same codebase, special care must be taken not to work on the same areas of code, otherwise all time gained in agentic development will be lost in resolving merge conflicts. Agentic prompting can help to ringfence no-go zones, such as “My co-worker is fixing X. What steps can we continue with that won’t be at risk of interference?”

Otherwise, it’s better to assign a primary on the code, where the secondary is making small tweaks only. Or tag team on the work, if both want to task their agents to make some wholesale changes.

At some stage after bubble selection and the Skilled Engineer confirming understanding of the intent and output, there is an initial feedback loop from the Skilled Engineer to their delivery team. This first checkpoint can happen any time during Storming, but must be done before Norming.

Norming — Hardening

When entering the Hardening phase, the bubble slows down to work on the Production Plan. The Engineering Leader can contribute to the plan, but Skilled Engineer is the Production Plan owner, as they are the operational SME, and sometimes the way a leader thinks things work, is not always the way they actually work.

The Production Plan determines the phases required to complete hardening, and every phase completed then needs to be kept compliant from that point on.

For example, the first phase should focus on code coverage. Achieving 100% for both unit and system tests are feasible, if working on a Greenfields initiative. As for brownfields - leaving something in a better state than you found it, is a good motto. Once these targets are met, then all remaining edits should keep this coverage percentage.

Now that the test coverage is in place, its much easier to focus on topics like infrastructure, security, observability, monitoring and alerting. Phases of the Production Plan are best determined by the needs of the organisation. It will be tempting to create a standard before the first bubble is formed, but unless there’s already a rigid set of practices (or even agent skills), instead of boiling the ocean, its better to let the Bubbles iteratively build up these standards as each one tackles a new problem, unique in its own way, and these standards are better enforced by agent skills, rather than static documentation.

The Production Plan highlights all the concerns that should not be addressed in the Execution Plan. Focusing on Production Plan elements too soon means the Execution Plan agentic workforce is spending too much time ensuring compliance, rather than focusing on functionality. Best case, you are waiting longer for your agents to respond, worst case it’s an agentic cost blowout.

A second feedback loop checkpoint from the Skilled Engineer to their delivery team can happen any time during Norming, but must be done before Performing. Both checkpoints are essential, but can be done at any point before their deadline.

Performing — Definition of Done

The primary focus of the bubble during Performing, is to monitor performance metrics and feedback from the end users, handle any critical amendments, as well as ensure the Skilled Engineer’s delivery team has sufficient handover.

Once this warranty period is deemed to be over, the bubble is burst. It is important that this warranty period doesn’t continue too long (one week should suffice), but its also important that the Engineering Leader is focused on measuring results to present back to the governance team, including any dashboards, so that continued performance can be monitored long after the bubble is burst.

Any change management that is required after this, can be requested to the Frontier Development governance team for prioritisation, or if large enough, back to the agile process.

The stage model sets the tempo. Governance keeps the bubble focused.

Frontier Governance

There should be a periodic review meetings to assess: in-flight bubbles; performance of completed work; and consider new Frontier Development candidates for prioritisation.

The Governance team comprises business and technical representatives - typically a Head of Engineering, Head of CX and potentially Head of Operations, an SLT representative, and Principal/Staff Engineers and senior CX and Ops staff - responsible for discovering and assessing Frontier Development candidates. Its up to each organisation to determine the right representation required that can make decisions “quickly and careful”. Full composition detailed at /development/.

The governance team should report regularly to steerco:

1. Intent, output and target metrics of shortlisted bubbles
2. Progress of in-flight bubbles
3. Performance of past bubbles

Governance holds the system accountable. Secondment is how we pass on knowledge through experience and train our future Engineering leaders.

Assigning New Bubbles

When a new bubble is ready to be formed, the governance team should assess available Skilled Engineers from the volunteer register. There may be one candidate more suitable than the rest because of their domain experience. Recency should also be a factor, giving opportunity to a Skilled Engineer that has been on the bench for the longest.

This selection requires consultation with the Agile Delivery Lead or Traffic Manager, who can advise on timings of the secondment, to minimise impact on the delivery team itself. Secondment should be limited to one Skilled Engineer from any one team at any time, and be respectful of the current delivery team sprint in flight.³⁴

Care must also be taken, not to create too many concurrent bubbles. There should be a hard limit which equals number of delivery team or number of engineering leaders - which ever is lowest. In practice though, human limitation will still apply - and if more time is taken trying to keep up a bubble cadence, we are probably taking more Time than giving more Time.

Reviewing in-flight Bubbles

Bad news should travel fast: The bubble should escalate blockers or blow-outs as soon as sure (or unsure) enough. If they are able to continue execution, while waiting on the response from the governance team, then they should continue to do so.

The governance team should review this escalation and decides if its significant enough to stop, or if there is an alternate approach that should be avoid this. If a bubble is wound down, the living document must be retained, not deleted. Documentation outlives tenure, and with AI-enabled knowledge base RAG (Retrieval Augmented Generation), future discovery of these past attempts should help to learn from past blockers.

Reporting Bubble Progress to Steerco

The governance team should regularly report the following to Steerco:

1. Intent, output and target metrics of shortlisted bubbles
2. Progress of in-flight bubbles
3. Performance of past bubbles

The governance team should have a clear definition agreed with steerco, on what constitutes an idea for a bubble. To enable an effective governance team, steerco should be cautious of being too biased on governance selection. Rather if steerco have a candidate they want to be reviewed, the governance team will complete their due diligence, and prioritise at their earliest convenience.

Secondment

Three things come back when the Skilled Engineer returns:

1. Agentic literacy
2. Business / Operational knowledge
3. Application ownership

The Skilled Engineer should knowledge transfer on 2 and 3 ahead of the go-live, but 1 should be incorporated into the next team retro.

Secondment grows organisational knowledge. Metrics prove the system is building something valuable.

Competing Priorities

If an engineer is expected to complete a certain percentage of project work (Change The Business) vs maintenance (Run The Business), they may be able to leverage that maintenance percentage for their role in the bubble.

However, the ability to context switch is individualistic, as is restraining the urge to over commit. Skilled Engineers should be given explicit instructions that project work should not suffer due to the appeal of a faster moving Frontier Development initiative. It is the responsibility of the Engineering Leader to check in regularly and ensure this. A simple, “how much time do you think you’ve spent so far”, and the answer compared to your expectations, goes a long way.

Delivery Team Handover

The purpose of the feedback loop is so that the team that owns the work understands what they are due to inherit. This is not for delivery teams to:

• Change the intent or output - there has been significant research made at this point.
• Get involved in the build.

Without Frontier Development, this work would likely have never been picked up, and this work is likely only partially related to the domains that this team owns.

How you know it worked

Time returned is the delta between how much time it took the human to do the discrete operation before the output vs after. The human Beneficiary? staff, customers, or both!

Time Built = (time before - time after) * frequency, extrapolated monthly or yearly.⁵

This is not about time saved from not needing a human to develop the solution - we should remember, its likely that without Frontier Development, this work would never have been justified for Agile delivery in the first place. Also if Cycle Time were the primary metric, the pressure to deliver would increase and result in humans being burnt out.

Six bias guards - each catches a different failure mode:

1. Cycle Time: The time taken from idea to production. If complexity creeps in, projects can be shelved projects to not blow out cycle time.
2. Capabilities unlocked: The number of distinct improvements to employee and customer experience. Value created with no prior path to a backlog.
3. Utilisation returned: How much repetitive time Running the Business (RTB) can be freed up to focus on Changing the Business (CTB).
4. Ad-hoc velocity: The rate at which ad-hoc initiatives are resolved, expressed as average waiting time before a bubble picks up the work.
5. Engineers upskilled: The number of times a seconded Skilled Engineer returns to their team with new capability.
6. Agentic coverage: Coding hours expressed in equivalent human hours. AI estimates this conversion, so the measurement cost is negligible.

Closing

Frontier Development enables a stream of work, which is the hardest to justify and is usually left not done. It takes a Time investment from Agile, and returns it with interest. It returns Time to the staff and customers for which the business exists. It also returns business knowledge and agentic literacy back into the organisation without the risk of vibe coding straight to production.