This is the multi-page printable view of this section.
Click here to print.
Return to the regular view of this page.
Planning Ceremonies
The ceremonies that establish commitments, schedule events, decompose work, and assemble teams before each convoy cycle begins
Planning Ceremonies are the foundational ceremonies of the DevOps Release Convoy™ lifecycle. They occur before active development begins and establish the commitments, schedules, task breakdowns, and team compositions that the rest of the convoy depends upon.
These ceremonies must be completed in strict sequence. Attempting to begin development without completing all Planning Ceremonies introduces unacceptable uncertainty into the delivery timeline and undermines the coordination achievements of Convoy Alignment.
Planning Ceremony Sequence
- Captains’ Meeting — Schedules the date of the planning event. Must be completed before Convoy Alignment can be announced.
- Convoy Alignment — The foundational 5-day event where all teams commit to the next eight quarters of delivery.
- Provisioning — Decomposes feature commitments into granular task lists by the Feature Captains.
- Press Gang — Assembles feature teams by drafting Code Engineers from the shared coding pool.
See Also
1 - Convoy Alignment
The foundational 5-day planning ceremony where all teams commit to the next eight quarters of delivery
Convoy Alignment is the cornerstone planning ceremony of the DevOps Release Convoy, held every six weeks to establish priorities, commitments, and feature sequencing for the next eight quarters. This two-year planning horizon ensures that the organization is never caught off guard by the future and that every team has a clear, unchanging roadmap to follow. Features are prioritized using the Weighted Shortest Voyage First (WSVF) framework and mapped onto the delivery timeline using Nautical Charts, giving leadership full visibility into what will be delivered, by whom, and when, well before anyone has examined whether it is technically feasible.
The full ceremony agenda, including day-by-day breakdowns, required attendees, and expected outputs, is documented on the Convoy Alignment Agenda page. All participants are strongly encouraged to review the agenda in advance, as the five days are fully scheduled and there is no time allocated for questions about the process itself.
See Also
2 - Captains' Meeting
The meeting to plan the date of the planning meeting
The Captains’ Meeting is a gathering of Feature Captains to plan the date when the DevOps Release Convoy™ will be assembled for Convoy Alignment. While this may sound straightforward, the process of synchronizing calendars across all Feature Captains, securing an appropriate venue, and establishing the alignment agenda requires its own dedicated coordination ceremony. Attempting to schedule Convoy Alignment without a Captains’ Meeting would be like setting sail without first agreeing on which ocean you are heading toward.
The Scheduling Process
The primary output of the Captains’ Meeting is a confirmed date for Convoy Alignment. Achieving this requires all Feature Captains to synchronize their calendars, which typically takes between two and four weeks of negotiation. The preferred scheduling tool is a Doodle poll, though the polls have a well-documented tendency to never converge. Each Feature Captain submits their availability, which is then invalidated by the next Feature Captain’s constraints. By the third round of polling, most Feature Captains have new conflicts on dates they previously marked as available, as the intervening weeks have filled their calendars with prerequisite meetings for other ceremonies. It is not uncommon for the Captains’ Meeting to require three or four sessions before a date is finalized.
Prerequisite Meetings
Before the Captains’ Meeting can take place, several preparatory activities must be completed. The Commodore must issue a Convoy Assembly Directive indicating that a new convoy cycle is approaching. Each Feature Captain must then hold a team-level pre-alignment readiness check to determine whether their team has capacity to attend a five-day planning session. The results of these readiness checks are compiled into a Pre-Alignment Readiness Report, which is reviewed at the Captains’ Meeting itself. Teams that report insufficient readiness are reminded that attendance at Convoy Alignment is not optional, rendering the readiness check a formality that nonetheless must be completed.
The Meeting to Plan the Meeting
Experienced SADMF practitioners will recognize the Captains’ Meeting as a natural consequence of the framework’s commitment to thorough planning. Planning the planning date ensures that alignment will not be disrupted by logistical surprises. The irony that planning the planning date often takes longer than anticipated is not lost on the organization but is accepted as evidence that complex coordination requires structured ceremonies. Proposals to “just pick a date” have been rejected by the Admiral’s Transformation Office as insufficiently rigorous and disrespectful to the ceremony’s role in the convoy lifecycle.
Agenda and Outputs
Beyond date selection, the Captains’ Meeting also establishes the agenda for Convoy Alignment, assigns conference room logistics, determines the sandwich collection schedule, and confirms which Feature Captains will present during the Management Address warm-up. The meeting produces a Captains’ Meeting Minutes document that is filed with the Convoy Manifest as evidence that proper pre-planning governance was followed. The minutes are rarely referenced again, but their existence provides organizational comfort.
See Also
3 - Provisioning
Translating strategic commitments into granular task lists through expert decomposition by Feature Captains
Before each convoy begins active development, the Provisioning ceremony translates the commitments made during Convoy Alignment into detailed task lists for each Feature Team. Each Feature Captain breaks their committed features into tasks no larger than 4 hours each. Tasks estimated at more than 4 hours indicate insufficient understanding and must be broken down further, regardless of whether the decomposition adds clarity.
After task decomposition, the Feature Captain totals the estimated hours across all tasks. If the total exceeds the team’s available capacity, the Feature Captain adds 30% additional tasks anyway because “we committed to this during alignment.” The gap between capacity and commitment is recorded as a “stretch opportunity” rather than an overcommitment.
Code Engineers are not consulted during Provisioning. Their estimates are not needed because the Feature Captain has already estimated on their behalf using historical Lines of Code per Code Engineer data. This ensures consistency and prevents the introduction of pessimism into the plan.
The Provisioning Spreadsheet
All task decomposition is recorded in the Provisioning Spreadsheet, a document that only the Feature Captain has edit access to. This restriction exists to maintain the integrity of the estimates and to prevent Code Engineers from introducing complexity that was not apparent during planning. The spreadsheet is maintained in a shared drive but is protected with a password known only to the Feature Captain and the Commodore. Read-only access may be granted to Code Engineers upon request, though requests are reviewed on a quarterly cadence.
Each task in the spreadsheet must follow the approved naming convention: the convoy number prefix, followed by the feature identifier, followed by a sequential task number (e.g., C17-F042-T003). Tasks that do not follow this convention are rejected during Code Inspection regardless of their implementation quality.
Capacity Reconciliation
After the initial task decomposition is complete, the Feature Captain performs the Capacity Reconciliation step. This is where the total estimated hours are compared against the team’s available capacity. In every observed instance, the estimated hours exceed capacity by 40% to 200%. The Capacity Reconciliation process addresses this gap through a series of approved adjustments:
- Meetings, breaks, and administrative time are removed from the capacity model, reflecting the expectation that Code Engineers will code continuously during working hours.
- Tasks labeled as “simple” are reduced by 50%, as simple tasks should take half the time.
- Any remaining gap is labeled a “stretch opportunity” and documented in the Convoy Manifest as an area where the team will demonstrate its commitment.
These adjustments always close the gap on paper, which is the purpose of the exercise.
Historical Accuracy
The accuracy of Provisioning estimates has been tracked across all convoy cycles. In no recorded instance has a Provisioning estimate accurately predicted the actual effort required to deliver the planned features. This outcome is consistently attributed to Code Engineer performance rather than estimation quality, as the estimation process has been validated by the Admiral’s Transformation Office and found to be methodologically sound. When delivery falls short, the root cause is documented as “insufficient velocity” and fed into PeopleWare performance metrics. The estimation process itself has never been identified as a contributing factor, as doing so would undermine confidence in the framework.
See Also
4 - Press Gang
The ceremony where Code Engineers are drafted from the coding pool and assigned to features regardless of expertise or preference
The Press Gang is the resource allocation ceremony in which Feature Captains select Code Engineers from the shared coding pool to staff their feature teams. The name is a proud nod to the naval tradition of impressment, in which sailors were recruited through the efficient method of simply telling them where they would be working. The SADMF has modernized this practice for the knowledge economy by adding a whiteboard.
The selection process follows a strict draft order based on feature priority as determined during Convoy Alignment. The Feature Captain with the highest-priority feature selects first, choosing between 2 and 20 Code Engineers depending on the Provisioning estimates. Selection continues in priority order until all features are staffed or the coding pool is exhausted, whichever comes first. If the pool is exhausted before all features are staffed, lower-priority features proceed with whatever engineers remain, and their Feature Captains are reminded that delivering with fewer resources is an opportunity to demonstrate organizational agility.
The Coding Pool Board, a large physical display maintained by the Chief Signals Officer, lists all available Code Engineers along with their technical skills, domain experience, and current certifications. While this information is displayed for transparency, Feature Captains are encouraged to select based on availability rather than skills. Selecting for specific skills would create single points of failure and would imply that certain engineers are more suited to certain tasks, which contradicts the SADMF principle that all Code Engineers are interchangeable resources. An engineer who worked on the payment processing system last convoy is just as well-prepared to work on the real-time telemetry pipeline this convoy. Software is software.
Code Engineers cannot refuse assignment. The Press Gang operates on the understanding that organizational needs supersede individual preferences, and that engineers who express reluctance about an assignment are exhibiting a fixed mindset. Once selected, engineers receive a thirty-minute onboarding briefing from their new Feature Captain, during which the feature requirements, technical context, and delivery timeline are communicated. Thirty minutes has been determined to be the optimal onboarding duration regardless of domain complexity, as longer onboarding sessions cut into the fixed Coding timebox. Engineers are expected to acquire any additional context they need by reading the requirements document, which contains everything they need to know because it was written by people who understand the system.
The Press Gang ceremony is one of the SADMF’s most powerful tools for preventing knowledge silos. Because engineers are reassigned to different features every convoy cycle, no individual ever accumulates dangerous levels of expertise in any single area. This ensures that the organization is never dependent on any one person and that all engineers maintain a breadth of shallow familiarity across the entire portfolio. The utilization target for all Code Engineers is 100%, meaning no engineer should ever be idle between assignments. Idle time is waste, and the SADMF recognizes no distinction between being idle and thinking about a problem.
See Also