GreenBox delivers weekly produce boxes to 3,000 subscribers across Perth and Melbourne. The team has grown from five to fifteen, split into two squads. The architecture is clean, the domain logic is explicit, the decisions are recorded. But two squads building in two directions keep colliding – and nobody sees it coming until something breaks.
The Slack message arrives at 7:14am on a Wednesday.
Anika, Melbourne squad lead: “Our farm reconciliation is broken. The subscription API is returning a different payload than last week. Did something change?”
Tom, Perth squad lead, replies twenty minutes later: “Oh. Yeah. We shipped the pause feature yesterday. Had to change the subscription endpoint to support pause states. Sorry – was in our sprint plan but I didn’t think it’d affect you.”
Anika: “It affected us.”
The Melbourne farm reconciliation service polls the subscription API every morning to match active subscribers with available produce. Perth’s change added a new pause_state field and restructured the response format. Melbourne’s service expected the old format. The reconciliation ran, got malformed data, and silently produced incorrect box allocations for 340 Melbourne subscribers.
Sam catches it at 9am because three customers email asking why their boxes contain items they’re allergic to. The substitution engine worked perfectly – it just received the wrong inputs. The malformed data scrambled the customer preference flags, and three subscribers received boxes containing produce they’d explicitly flagged as allergens.
One of the three is Mrs Patterson.
Mrs Patterson – the subscriber who has been with GreenBox since week three, whose beetroot preference Maya added to the decision tables by hand, whose loyalty has been a quiet constant through every crisis. Mrs Patterson, who got a box containing capsicum despite her nightshade allergy flag.
She emails Sam: “This has never happened before. I’m not angry, but I’m worried.”
Maya reads the email over Sam’s shoulder and goes pale. She takes the phone list and calls all three customers personally. The first call is to Mrs Patterson.
“Mrs Patterson, this is Maya Chen from GreenBox. I’m calling about your box this week.”
Mrs Patterson is gentle about it, which somehow makes it worse. “I’ve always trusted what’s in the box, dear. I just need to know I still can.”
“You can. This won’t happen again. I’ll personally check your box for the next month.”
The second customer is upset but stays. The third – a Melbourne subscriber who’d only joined six weeks ago – cancels immediately. “I can’t risk it,” she says. “I have a child with nut allergies. If this had been nuts instead of dairy…”
She doesn’t finish the sentence. She doesn’t need to.
It takes Priya two hours to fix the integration. The fix is twelve lines of code.
Priya doesn’t say much while she’s coding the fix. She’s focused, precise, her fingers moving fast. But when the fix is deployed and the tests pass, she does something nobody on the team has seen before. She gets angry.
Not loud angry. Priya angry. She messages Anika directly: “This should never have happened. A schema change to a shared API with no consumer notification, no contract test, no versioning. Three customers got allergens in their boxes. One of them was Mrs Patterson.”
Anika replies immediately: “I agree. Completely. What do you propose?”
“Contract testing. Every bounded context that publishes events or exposes an API writes a contract. Consumers write expectations against the contract. If a change breaks the contract, the build fails. Not in staging. In CI. Before the PR merges.”
Charlotte sees the message thread and supports it publicly in the team channel. “Priya’s right. This is the first time the architecture has hurt a customer. Contract testing is the minimum.”
Priya adds the contract tests to the pipeline that afternoon. “If Perth changes a response format, the Melbourne contract tests fail before it reaches staging.” It adds three minutes to the build but catches exactly the kind of break that caused the allergen incident. Charlotte: “That’s three minutes that prevent three hours of incident response.”
This is Priya leading. The quiet developer who said “Stuck” at that first retro eighteen months ago is now the person proposing the technical safeguard that prevents the team’s worst failure from recurring. She doesn’t ask permission. She doesn’t hedge. She says “this should never have happened” and follows it with a solution.
Maya sends Charlotte a message at midnight that night: “If this happens again with a serious allergy, we’re not just losing a customer. We’re in court.”
The second incident
Two weeks later, Melbourne ships a customer notification system. Anika’s squad has been hearing from Melbourne subscribers that they want SMS alerts when their box is dispatched. The squad builds it – a clean implementation inside the Fulfilment bounded context, using the third-party SMS provider the team already has.
On Thursday, Tom mentions in the Perth standup that they’re also getting requests for delivery notifications. Priya checks. Perth already has delivery notifications. Tom built them three months ago as part of the delivery tracking integration.
Now there are two notification systems. Perth’s sends delivery alerts through the tracking platform. Melbourne’s sends dispatch alerts through a direct SMS integration. They use different templates, different timing, different opt-out mechanisms. A subscriber who moves from Perth to Melbourne would get notifications from two different systems with different preferences.
Nobody told Melbourne that Perth had already built notifications. Nobody told Perth that Melbourne was building them. The work was in each squad’s sprint plan – but neither squad saw the other’s sprint plan.
The pattern
Charlotte tracks the incidents over the following month. She keeps a simple spreadsheet.
After the retro, everyone leaves. Charlotte stays.
She sits alone in the meeting room with the incident spreadsheet projected on the wall. Seven incidents in four weeks. Three of them her bounded contexts – the clean architecture she’d drawn on the whiteboard, the events she’d mapped, the contracts she’d specified. The structure was right. The coordination was missing. And three customers got allergens in their boxes.
Charlotte has seen this before. Not the specific failure – the pattern. The meal kit company she coached, the one that failed, had the same progression. Clean architecture. Growing team. Two squads that stopped talking to each other. Small failures that seemed fixable. Then a big one that wasn’t.
She sits with that for a while.
Then she picks up her phone and texts Lee: “Am I repeating myself?”
Lee replies at 11:47pm, which means he was awake too. “The patterns repeat. You’re not. The difference is you’re catching it this time.”
Charlotte reads the message twice. She’s not sure it’s enough. But it’s something.
The next morning, she brings the spreadsheet to her session with Lee. “We have two excellent squads building in two excellent directions,” she says. “The problem is the directions don’t always align.”
Lee studies the incidents. “The bounded contexts helped, right? The context map shows where the boundaries are.”
“It shows where the code boundaries are,” Charlotte says. “But it doesn’t tell one squad what the other squad is planning to do to those boundaries next sprint. Tom’s API change was inside the Subscription context. Technically correct. But Melbourne depended on the old contract, and nobody coordinated the change.”
“So the technical architecture is fine. The organisational architecture is missing.”
“Exactly.”
Before proposing a solution, Charlotte does something Lee taught her: she runs a cross-team retro. Both squads in the same room. Not a sprint retro – those happen within each squad and they’re working fine. A retro about the space between the squads.
Charlotte facilitates. She puts the incident spreadsheet on the wall and asks: “What patterns do you see?”
The insights come fast. Tom: “We never look at each other’s sprint plans.” Anika: “We assume if something’s inside our bounded context, it’s ours to change. But the events that flow between contexts are shared contracts.” Priya: “The duplicated notification work happened because we solved the same customer complaint independently. Nobody asked whether the other squad had already solved it.”
Charlotte captures three actions from the retro: (1) a weekly cross-squad sync, (2) a shared view of what each squad is working on, and (3) a quarterly planning session to align direction before sprints begin.
The first two are quick wins. The third is bigger.
Tom’s scepticism
Charlotte proposes a quarterly planning day – a structured half-day session where both squads align on what they’re doing for the next twelve weeks.
Tom pushes back immediately. “We already have sprint planning. We already have retros. We already have standups. Are we really adding another meeting?”
Charlotte doesn’t dismiss him. Tom’s earned his scepticism. The sprint cadence the team established back in Series 1 works well. Each squad does its own Example Mapping, its own sprint planning, its own retros. Perth and Melbourne each run two-week sprints. The rhythm is solid.
“Sprint planning tells each squad what they’re doing,” Charlotte says. “It doesn’t tell them what the other squad is doing.”
“So we read each other’s sprint plans.”
“When was the last time you read Melbourne’s sprint plan?”
Tom pauses. “I don’t think I ever have.”
“And Anika?”
Tom looks at Anika across the room. Anika shakes her head.
“That’s the gap,” Charlotte says. “Not a process gap. A visibility gap. Each squad has excellent internal coordination. Zero external coordination. And as long as you’re working in completely separate bounded contexts, that’s fine. But you’re not. The Subscription context, the Supply context, the Fulfilment context – both squads touch all of them.”
The first quarterly planning day
Charlotte designs it as a half-day session. Both squads in the same room – Perth in person, Melbourne on a large screen. Five blocks, tightly timeboxed.
Block 1: Review last quarter (30 minutes).
Each squad lead presents what their squad delivered. Not a feature list – a narrative. What worked, what surprised them, what they’d do differently.
Tom goes first. Perth delivered the pause feature, the delivery tracking integration, and a farm reliability scoring system. What surprised them: the pause feature took three sprints instead of one because of unexpected billing complexity (see ADR-001 – charge-on-delivery coupling). What they’d do differently: coordinate API changes earlier.
Anika goes next. Melbourne delivered farm onboarding for three Yarra Valley farms, the customer notification system, and a preference export tool. What surprised them: Perth’s API change breaking reconciliation. What they’d do differently: “Know what Perth is doing,” she says with a wry smile.
Charlotte projects the incident spreadsheet. Four surprises, three duplications, two staging failures. The room goes quiet. Nobody had seen the full picture before.
“This is a retro at the quarterly level,” Charlotte says. “Every layer of planning needs its own feedback loop. Sprint retros catch problems within a squad – process issues, team dynamics, technical debt. The quarterly retro catches problems between squads – strategic misalignment, duplicated work, coordination failures. Different people, different scope, different cadence. Same discipline: reflect, learn, adjust.”
Block 2: Update the Impact Map (30 minutes).
Charlotte pulls up the Impact Map the team built back in Series 2. It’s been through several iterations since then. The original goal was 300 subscribers. Then 500. Then 1,000. Now it reads 5,000.
“Is 5,000 still the right goal for the next twelve months?” Charlotte asks.
Maya weighs in. “Five thousand is the number we need for the Series A. But we’re at three thousand now. The question isn’t whether we’ll hit five thousand. It’s whether we’ll hit it by March.”
They update the map. The goal stays at 5,000 by March. The actors have changed – there are now two squad leads, three farm relationship managers, and a customer success team. The impacts have shifted – Melbourne subscriber growth matters more than Perth retention, because Perth is plateauing at 1,800 while Melbourne is growing fast.
The deliverables shift too. The team identifies three things that matter most for the next quarter: reduce Perth churn, accelerate Melbourne onboarding, and unify the notification system.
Ravi, who’s been quiet, raises his hand. “This is the first time I’ve understood why we’re building what we’re building. Sprint planning tells me what to build this fortnight. This tells me why.”
Block 3: Propose quarterly themes (45 minutes).
Each squad lead proposes a theme. Not a feature list – a direction with a measurable outcome.
Tom proposes Perth’s theme: “Reduce churn below 3% through delivery experience improvements.” The metric is clear. Churn is currently 4.2%. The work might include better substitution communication, delivery time windows, and proactive issue resolution. But the theme is the outcome, not the features.
Anika proposes Melbourne’s theme: “Launch Melbourne farm onboarding and reach 500 Melbourne-local subscribers.” Melbourne currently has 1,200 subscribers, but only 300 are on Melbourne-local farm produce. The rest get shipped from Perth farms, which is expensive and undermines the local-produce value proposition.
Charlotte facilitates a discussion. Do these themes conflict? Do they support each other? Is there anything missing?
Maya spots something. “If Perth is working on delivery experience and Melbourne is working on local farm onboarding, who’s working on the notification system merge? We just agreed that unified notifications matter.”
Good catch. They assign the notification unification to Melbourne, since Anika’s squad built the most recent version and it fits within the onboarding experience. Perth will deprecate their separate notification system over the quarter. That’s a cross-squad dependency – and they’ve just identified it before it became a mid-sprint surprise.
Block 4: Dependency mapping (30 minutes).
This is the critical step. Charlotte pulls up the bounded context map from the DDD session – the four contexts with their events and relationships.
“Each squad lead lists the bounded contexts you’ll be working in this quarter. If both squads touch the same context, flag it.”
Three of four bounded contexts are shared. Three potential collision points. In July, without this visibility, those would have been three mid-sprint surprises.
“If you’re changing the Subscription context, tell Melbourne,” Charlotte says. “If you’re changing the Supply context, tell Perth. The bounded context map isn’t just a technical diagram. It’s a coordination map.”
The team discusses each red row. For the Subscription context, they agree that Perth will own API changes and Melbourne will consume them – any schema changes go through a shared API review. For Supply Matching, Melbourne will add new farms through a stable interface that Perth’s decision tables already handle. For Fulfilment, they agree on a notification migration plan: Melbourne builds the unified system first, Perth switches over in sprint 4.
Block 5: Commit (15 minutes).
Charlotte summarises. Two themes, three dependency points, three coordination owners. Tom owns the Subscription API contract. Anika owns the notification migration. Ravi – who’s become the team’s most reliable cross-context developer – owns the Supply Matching interface.
Charlotte asks one more question for each dependency: “How big is this? Small, Medium, or Large?” T-shirt sizing – the same lightweight estimation the team used in the roadmapping session. Not hours, not story points. Just a rough sense of scale.
The notification migration is a Medium – two to three sprints, well-understood scope. The Subscription API contract is a Small – a shared document and a review process, not a rebuild. The Supply Matching interface is a Small if the existing interface handles Melbourne’s farms, a Medium if it needs extending.
Tom spots the value immediately. “If the notification migration is a Medium and Anika can’t start until sprint 2, that means it lands in sprint 3 or 4. If Perth needs to switch over before the end of the quarter, we need to plan for that.” Without the sizing, that timing conflict would have surfaced as a blocker in sprint 4.
“This isn’t a project plan,” Charlotte says. “It’s an alignment. We’re not committing to a feature list. We’re committing to a direction, a set of coordination points, and a rough sense of how big each piece is. The sprint plans still decide the details. The quarterly plan makes sure the sprints don’t collide.”
The weekly sync
The quarterly plan sets the direction. But twelve weeks is a long time. Things change. New priorities emerge. A sprint surfaces a dependency that nobody anticipated.
Charlotte adds one more piece: a lightweight weekly sync between squad leads. Fifteen minutes. Every Monday morning. Each lead shares three things:
- What their squad is working on this sprint.
- What bounded contexts they’re touching.
- Anything that might affect the other squad.
Tom and Anika are sceptical at first – another meeting – but the first sync surfaces a conflict that would have blown up mid-sprint. Perth is about to refactor the Subscription event format to support a new churn metric. Melbourne’s onboarding flow consumes those events. Fifteen-minute conversation. They agree Perth will add the new fields as optional, preserving backward compatibility. Melbourne will migrate to the new format in the following sprint.
Without the sync, this would have been the July API incident all over again.
“Fifteen minutes to prevent a two-hour outage,” Tom admits after the third week. “Fine. I’ll keep coming.”
LLMs as coordination tools
Priya has an idea. The team’s sprint backlogs are in Linear. Each story has a description, acceptance criteria, and tagged bounded contexts – a practice Charlotte introduced during the DDD work. What if an LLM could scan both backlogs and flag overlaps?
She builds a lightweight script. Every Monday before the sync, it pulls the current sprint stories from both squads, feeds them to an LLM with this prompt:
Here are the sprint backlog items for Perth and Melbourne. Each item is tagged with the bounded contexts it touches. Identify: (1) any items from different squads that touch the same bounded context, (2) any items that might create API or schema changes affecting the other squad, (3) any items that look like they might be solving the same problem.
The LLM produces a dependency report. It’s not perfect – it flags some false positives, and occasionally misses a subtle dependency. But it catches the obvious ones, and it gives Tom and Anika a starting point for their Monday sync instead of working from memory.
The first report flags three items: a Perth story about subscription analytics and a Melbourne story about onboarding metrics both touch the Subscription context’s reporting interface. And a Perth story about delivery window preferences overlaps with a Melbourne story about notification timing preferences – similar concepts, potentially sharable code.
Tom and Anika resolve both in the sync. The reporting interface gets a shared design. The preference work gets consolidated into Melbourne’s sprint, with Perth consuming the result.
“The LLM isn’t making decisions,” Charlotte says. “It’s making dependencies visible. The humans still decide what to do about them. But visibility is ninety percent of the problem.”
The second quarterly planning day
Three months later. The team gathers for Q4 planning.
The difference is immediate. Tom and Anika walk in with a shared understanding of what the other squad has been doing. The weekly syncs have kept them aligned. The LLM dependency reports have caught four potential conflicts before they became incidents.
Charlotte projects the updated incident spreadsheet.
Zero cross-squad surprises. Zero duplicated work. Zero integration failures.
“That’s not because nothing changed,” Charlotte says. “Plenty changed. Perth refactored the billing events. Melbourne added four new farms. Both squads touched the Fulfilment context for the notification migration. But every change was coordinated. Every dependency was flagged. Every API change went through the shared review process.”
The Q4 planning day runs smoother. The review block takes less time because there are fewer incidents to discuss. The Impact Map update is faster because the team has been tracking metrics weekly. The theme proposals are sharper because both squads understand the full picture.
Tom’s Melbourne squad has also shipped something that wasn’t on the quarterly plan: a progressive web app. Push notifications for delivery day, box preview on Wednesday. It’s not a native app – it’s the website, installable on the home screen, with service workers handling the notifications. Subscribers love the Wednesday preview notification. Sam checks the numbers: “Support tickets about ‘what’s in my box this week?’ dropped sixty percent since the notifications launched.” The app idea that started as a napkin sketch during a JTBD interview in Series 2 has become a real thing – not because anyone decided to “build an app,” but because the team kept following the customer need.
Tom, who resisted the quarterly planning day three months ago, facilitates the dependency mapping block. He draws the bounded context grid on the whiteboard without being asked. Anika fills in Melbourne’s column. They flag two coordination points and assign owners in ten minutes.
“I was wrong,” Tom says to Charlotte afterward. “I thought this was just another meeting. It’s not. It’s the thing that makes the sprint meetings work across squads.”
The planning onion
Charlotte names the pattern at the Q4 retro.
“Think of planning as layers,” she says. “Each layer wraps around the ones inside it.”
She draws concentric rings on the whiteboard.
“The innermost layer is the daily standup. What are you doing today? That’s the day layer.”
“Next is sprint planning. What are we building this fortnight? That’s the sprint layer. We established that back in Series 1, with Example Mapping feeding into sprint plans.”
“Now we’ve added the quarterly layer. What is each squad focused on for the next twelve weeks? How do the directions align? Where are the dependencies?”
“As you grow, you’ll need a yearly layer too. What are the company’s strategic priorities? How does each quarter’s work contribute to the annual goals? The Wardley Map feeds into that layer – build-vs-buy decisions, strategic investments, capability planning.”
“Each layer doesn’t replace the ones inside it. Sprint planning still happens. Standups still happen. The quarterly plan doesn’t dictate sprint content – it sets direction and flags coordination points. The sprint plans fill in the details.”
Ravi asks the question Charlotte was hoping someone would ask. “What happens when we add a third squad?”
Charlotte smiles. “The same structure scales. Three squads means the dependency map has three columns instead of two. The weekly sync has three leads instead of two. The quarterly planning day takes a bit longer. But the structure is the same: align on direction, map dependencies, assign coordination owners.”
“The hard part isn’t the structure,” she adds. “The hard part is the discipline. The quarterly plan only works if people actually follow the coordination agreements. The weekly sync only works if people show up. The LLM dependency reports only work if the stories are tagged with bounded contexts. It’s not rocket science. It’s consistency.”
When to use quarterly planning
Quarterly planning is most useful when the team has grown beyond a single squad. The signals:
- Two or more squads working in the same codebase or the same set of bounded contexts
- Cross-squad surprises: one squad’s change breaks another squad’s integration
- Duplicated work: multiple squads building similar capabilities independently
- Sprint plans that only make sense within one squad’s context
- Growing frustration that “nobody told us” about changes
The signals that you don’t need it yet:
- A single squad working on a single product. Sprint planning and retros are sufficient.
- Multiple squads working on completely independent products with no shared code or shared contexts. They don’t need to coordinate because they don’t interact.
- A team small enough that everyone sits in the same room and overhears everything. Coordination happens naturally through proximity.
Charlotte’s rule of thumb: “If you’ve had two cross-squad surprises in a month, you need quarterly planning. The first surprise is bad luck. The second is a missing process.”
What the team learned
The bounded contexts from the DDD post gave GreenBox clean technical boundaries. The decision tables captured the domain logic. The ADRs preserved the reasoning. The Wardley Map guided build-vs-buy decisions. But none of those tools told one squad what the other squad was planning.
Quarterly planning filled that gap. Not by adding heavy process, but by creating three lightweight coordination points: a quarterly alignment day, a weekly fifteen-minute sync, and an LLM-generated dependency report.
The bounded context map – originally a technical diagram – became the team’s most important planning tool. It stopped being “where the code boundaries are” and became “where the coordination boundaries are.” If both squads are working in the same context, they need to talk. The map makes that visible.
The deeper lesson is about planning layers. A single squad needs daily and sprint-level planning. Multiple squads need quarterly-level planning on top of that. The layers don’t replace each other – they nest. Each outer layer sets direction for the layers inside it, and each inner layer fills in the details.
GreenBox has clean architecture. Strategic frameworks. Institutional memory. Aligned squads. The technical and organisational foundations are in place.
But the company is growing again. Brisbane is next – three squads, twenty-five people, three cities. The challenges that emerge won’t be technical or organisational in the traditional sense. They’ll be human. Communication breaks down across time zones. Context gets lost in Slack threads. Teams drift apart, building in isolation despite the coordination structures. A developer in Brisbane writes code that contradicts decisions made in a Perth workshop she never attended.
Charlotte knows techniques for this. But they need the whole organisation to participate – not just the developers. The next series, Working Together at Scale (coming 29 September), follows the GreenBox teams as they learn to think together – not just build together.