Keeping track of frequent releases by independent teams is just too much cognitive load. We need to Work in Small Batches. The DevOps Release Convoy™ (DORC) simplifies things. Why burden ourselves tracking 5 or 10 releases per quarter if we can use 1 easily managed DORC™?
Set sail with the DORC!
Why Convoys?
Other frameworks have tried to coordinate things with more linear transportation metaphors. However, they are constrained to a single direction. With DORCs™ we have more options. We can turn left or right or even make a U-turn!
How the Convoy Works
The DevOps Release Convoy™ is a comprehensive delivery system with these key components:
Convoy Alignment begins each cycle with a 5-day, in-person planning session where all teams commit to the next 8 quarters of features. Features are prioritized using WSVF scoring and visualized on Nautical Charts.
Convoy Ceremonies provide the daily and weekly rituals needed to maintain oversight throughout the cycle. From the Press Gang that assembles Feature Teams to the Tribunal that ensures accountability, every ceremony serves a critical governance function.
Convoy Manifest documents the critical paperwork required for every DORC™. No convoy sails without proper documentation.
Delivering Change describes the READY release process and the Convoy Steering Committee that ensures all changes are approved at the highest levels before the fleet sets sail.
Fleet Inspection provides the formal review where completed features are presented to leadership through carefully prepared slide decks. No live demonstrations are permitted.
Shore Leave is the structured innovation period between convoy cycles where Code Engineers may pursue approved activities from the pre-authorized list.
The Armada coordinates multiple convoys when the enterprise has scaled beyond what a single DORC™ can manage. An Admiral commands the fleet of fleets.
Key Roles in the Convoy
The Convoy depends on clearly defined Roles to function. The Commodore commands the Convoy. Feature Captains track individual features. Code Engineers implement requirements quickly and quietly. See Roles for the complete chain of command.
See Also
WSVF for the prioritization formula used during alignment
The phase-independent ceremonies that operate continuously throughout the convoy lifecycle
Standing Ceremonies are the DevOps Release Convoy™ ceremonies that operate independently of any particular convoy phase. While Planning Ceremonies, Execution Ceremonies, and Reflection Ceremonies are tied to specific moments in the convoy lifecycle, Standing Ceremonies run continuously — some on fixed schedules, others on an as-needed basis — providing the governance structures and accountability mechanisms that hold the convoy together from start to finish.
The Standing Ceremonies
Change Adjudication Convening — Operates on a fixed biweekly cadence, independent of Convoy phase, serving as the standing gate through which all changes must pass before inclusion in any fleet. The biweekly schedule ensures that no change ever waits more than two weeks for a hearing, and no change ever bypasses deliberation.
Tribunal — Maintains organizational health through accountability. The Tribunal convenes whenever sufficient evidence of process non-compliance, delivery shortfall, or attitude misalignment has been accumulated. Its timing is independent of the convoy cycle, ensuring that accountability is never delayed by the schedule.
Rota Fortunae — Provides periodic restructuring to ensure that no organizational structure becomes too comfortable. The Rota Fortunae operates on its own cadence, independent of convoy phases, reflecting the SADMF principle that the wheel of organizational fortune must turn continuously to prevent stagnation.
Captains’ Mast — Addresses priority challenges and escalations that cannot wait for a scheduled ceremony. Captains’ Mast may be convened at any point during the convoy cycle when a Feature Captain requires immediate arbitration.
Relationship to Phase Ceremonies
Standing Ceremonies complement but do not replace the phase-specific ceremonies. Practitioners should consult the appropriate phase ceremony pages for the ceremonies that govern each stage of the convoy lifecycle:
Planning Ceremonies — Captains’ Meeting, Convoy Alignment, Provisioning, Press Gang
Execution Ceremonies — Coding, Code Inspection, Testing, System Integration Testing, Scrum of Scrum of Scrums, Post-Standup Standup, Post-Standup Standup Review, Manifest Approval
A formal hearing for those who dare to suggest the plan should change
In this ceremony, anyone wishing to change the priorities set in Convoy Alignment must file a Priority Change Request (PCR) and present it for approval before the Commodore. This allows the Chief Signals Officer to adjust the Feature Completion Ratio goal to ensure it does not reflect poorly on the Commodore. The Captain’s Mast is the organization’s commitment to plan integrity. Without it, priorities could shift based on something as unreliable as new information.
The PCR Paperwork Process
Before a Captain’s Mast hearing can be scheduled, the petitioner must complete a Priority Change Request package. The PCR requires a completed impact analysis form, a revised dependency map approved by every affected Feature Captain, a written justification of no fewer than 2,000 words explaining why the original priority was wrong, and a counter-justification of equal length explaining why the original priority was actually correct and should only be changed due to extraordinary circumstances. Both justifications must be submitted simultaneously. The PCR must also include the petitioner’s updated SADMF Maturity Score, as it has been observed that requests for priority changes correlate strongly with lower maturity levels.
The Hearing
Captain’s Mast hearings are convened bi-weekly in the Commodore’s conference room. Attendees are required to present in formal business attire, as the gravity of requesting a priority change must be reflected in one’s appearance. The petitioner is given exactly five minutes to present their case, followed by a question-and-answer period that may last up to ninety minutes. The Commodore serves as judge, jury, and final arbiter. A panel of senior Feature Captains may be convened as advisory witnesses, though their advice is non-binding and has never been observed to influence the outcome.
The petitioner must bring three printed copies of the PCR, one for the Commodore, one for the Chief Signals Officer, and one for the official Convoy Record. Digital submissions are not accepted, as physical paperwork conveys the appropriate level of seriousness and discourages frivolous requests.
Approval Rates
Priority changes are almost never approved. Historical data shows an approval rate of approximately 2.3%, and a closer examination reveals that approved changes were those that the Commodore had already decided to make independently. Approving a priority change would require re-baselining the Feature Completion Ratio, recalculating the Convoy Manifest, and acknowledging that the original plan was imperfect. Since the plan was created through the rigorous Convoy Alignment process with a unanimous Fist of Five confidence vote, imperfection is, by definition, impossible. Denied PCRs are filed in the Convoy Archive and may be referenced in future Tribunal proceedings as evidence of the petitioner’s lack of commitment to the plan.
The Commodore’s Verdict
Once the Commodore has rendered a verdict, there is no appeal. The decision is recorded in the Captain’s Mast Log, a document maintained by the Chief Signals Officer and reviewed quarterly by the Admiral’s Transformation Office to identify patterns of organizational resistance. Individuals who file more than two PCRs per convoy cycle are flagged for additional coaching on the importance of commitment to the plan. This coaching is delivered through a mandatory half-day workshop titled “Embracing the Baseline: Finding Joy in Fixed Priorities.”
Commodore for the role that presides over the hearing
Convoy Alignment for the planning event that produces the priorities being challenged
Tribunal for where repeated PCR filers may eventually appear
1.2 - Change Adjudication Convening
The biweekly ceremony in which the CRAP formally convenes to render its judgment on every proposed change to the software estate
The Change Adjudication Convening is the biweekly ceremony in which the Change Rejection or Acceptance Party (CRAP) formally assembles to evaluate every change submitted since the previous session. All change proposals that have cleared the Code Standards Enforcement Team and the Development Integrity Assurance Team are placed on the agenda in the order they were received, without regard to urgency, business impact, or the sailing date of the current Convoy. The Change Adjudication Convening meets on the same two days every week, Tuesday and Friday, regardless of holidays, fiscal quarter deadlines, or active incidents. Consistency is the hallmark of process discipline.
Scheduling and Agenda Management
Every change submitted to the CRAP must be accompanied by a completed Change Impact Assessment, a Risk Exposure Summary, and a Rollback Authorization Declaration. Submissions received after the agenda cutoff, 5:00 PM on the business day preceding each Convening, are deferred to the following session. This two-to-four day wait is not a bottleneck; it is a deliberate cooling-off period that prevents reactive, emotionally-driven changes from reaching production. Software modified under urgency is software modified without adequate reflection, and the Convening exists precisely to insert reflection into a process that would otherwise be governed by panic.
The CRAP chairperson distributes the agenda to all seven members no fewer than 24 hours before each Convening, allowing members sufficient time to review the CDAP documentation packages for each change. Members who arrive at the Convening without having reviewed the documentation packages are still permitted to vote. Their perspective as uninformed reviewers is considered a proxy for the experience of an end user encountering the change for the first time. This is one of the CRAP’s most frequently misunderstood design features.
Integrated Record and Signature Protocol
Before any change may be placed on the Convening agenda, the submitting team must establish a complete change record in the enterprise change management platform. This record is the authoritative source of truth for the change’s scope, rationale, risk exposure, and approval history. A change that exists in code but not in the change management platform does not exist for governance purposes, and will not be accepted for agenda placement regardless of its technical completeness.
To reduce the manual overhead of initiating the approval workflow, the Code Inspection process automatically generates a physical change request form at the moment a Code Inspection is opened. This form captures the change’s platform record identifier, the submitting Code Engineer, the target Convoy, and the required approval chain. Automatic form generation ensures that no change enters the review pipeline without simultaneously entering the physical approval process, eliminating the gap that previously allowed changes to accumulate technical approvals while their governance documentation remained incomplete.
The generated form must be transmitted to each required approver for collection of a handwritten signature. A minimum of five signatures is required before a change may be submitted to the CRAP agenda, and at least two of those signatures must come from designated change governance representatives. Approvers are responsible for locating, reviewing, and returning signed forms within the submission window. Forms not returned before the agenda cutoff are treated as incomplete submissions and deferred to the following Convening session.
Once all signatures have been collected, the completed form is submitted to the verification function, which compares each signature against the authoritative signature reference on file for that approver. Signatures that do not match the reference are flagged, and the form is returned to the submitting team for a new approval round. Verification failure does not reset the signatures that did match; only the non-matching signatures must be recollected. However, because the replacement approval cycle requires re-transmission and re-collection of physical forms, the practical effect is rarely faster than beginning the approval process again. The verification function operates continuously and does not batch submissions; forms are processed in the order received.
Verified forms are stored in the physical change archive maintained by the Admiral’s Transformation Office. Archive storage is the official record of approval for audit purposes. A change whose form is verified but not yet archived is considered pending and may not be presented at the Convening. The physical archive is the final authority on whether a change has completed the approval process; the change management platform record is supplementary.
No change may appear on the Convening agenda until its verified physical form has been confirmed as archived. This requirement applies without exception, including to changes submitted under the Emergency Authorization Provision.
The Convening Protocol
The Convening opens with the chairperson administering the Supplicant’s Oath to each change submitter. Supplicants who cannot attend in person submit a notarized written oath, which is read on their behalf by the chairperson. Following the oaths, each change is presented in agenda order. The presenting Code Engineer has exactly three minutes to describe the change, its purpose, and its test coverage. Questions from CRAP members may extend any individual presentation indefinitely, but the presenter’s speaking time remains capped at three minutes. After all changes have been presented, the CRAP votes by secret ballot. Approval requires unanimity.
Changes rejected at the Convening may be resubmitted with remediated documentation at the next session. There is no fast-track reconsideration process within a session. This ensures that rejected changes receive the same thorough preparation as original submissions, and that submitters do not perceive rejection as a minor inconvenience that can be addressed on the spot. The Change Rejection Log records every rejection, the stated reason, and the number of resubmissions required before acceptance, data that the Review Board Review Board reviews monthly to verify that the CRAP’s standards remain appropriately rigorous.
The Change Freeze
The Change Adjudication Convening observes mandatory blackout periods surrounding each Convoy deployment. Beginning 72 hours before the scheduled sailing date and continuing for 48 hours after successful deployment, no changes may be submitted to the CRAP agenda for any reason. The Change Freeze ensures that the organization’s attention is focused entirely on the deployment event rather than divided between monitoring and new change evaluation. During a Change Freeze, Code Engineers who have completed their Convoy work are expected to spend their time preparing documentation for the post-freeze submission queue, which is typically substantial.
Change Freezes are announced by the Chief Signals Officer via the transformation dashboard no fewer than five business days before they begin, confirmed by the Commodore at the final Manifest Approval session. Freeze periods are non-negotiable and cannot be shortened even in the event of a critical production defect. Critical defects discovered during a Change Freeze must be managed through the Emergency Authorization Provision described below.
Emergency Authorization Provision
For situations where a change cannot wait for the next scheduled Convening, the SADMF provides the Emergency Authorization Provision (EAP). To invoke the EAP, the submitting team must file an Emergency Justification Declaration with the Admiral’s Transformation Office, obtain the CRAP chairperson’s agreement that the situation qualifies as an emergency, secure verbal approval from four of the seven CRAP members individually, complete an expedited Risk Exposure Summary (minimum 800 words), and submit a Post-Emergency Documentation Remediation Plan committing to full CDAP compliance within three business days.
Organizations that have attempted to invoke the Emergency Authorization Provision report that assembling the required documentation consistently takes longer than waiting for the next scheduled Convening. The SADMF considers this a feature, not a limitation. A change that truly cannot wait will find the time to be documented properly. The existence of the EAP demonstrates the framework’s flexibility; its practical inaccessibility demonstrates the framework’s standards.
Deploy the Fleet for the deployment event that triggers the Change Freeze
Change Request Lead Time for the metric that tracks planning maturity through approval cycle duration
1.3 - Rota Fortunae
Driving organizational improvement through random restructuring
We know that a static organizational structure limits improvement and also becomes boring for some executives. While many outside the SADMF community may propose Value Stream Mapping to identify constraints, we know that the process is time-consuming and uses too many Post-Its. To resolve these we introduced the Rota Fortunae ceremony where we “spin the wheel”, restructure, and then see if we are delivering better. If we fail, then we convene a Tribunal to address it. The Rota Fortunae embodies the SADMF principle that organizational agility means being willing to change everything about how teams are structured without needing a reason to do so.
The Wheel
The Rota Fortunae is a physical wheel mounted in the Commodore’s office. The wheel is divided into segments, each representing a possible organizational restructuring action. Current segments include:
Merge Teams A and C – Combine two teams regardless of their current domain expertise
Split Team B – Divide a functioning team into two smaller teams with overlapping responsibilities
New Management Layer – Insert an additional reporting level between existing roles
Swap Feature Captains – Reassign Feature Captains to teams they have no prior experience with
Create Center of Excellence – Establish a new cross-functional body with advisory authority and no delivery accountability
Reorganize by Technology – Restructure teams around technology stacks instead of value streams, or vice versa depending on the current structure
The segments are updated annually by the Admiral’s Transformation Office based on which restructuring patterns have not been tried recently.
The Quarterly Spin
The Rota Fortunae ceremony takes place quarterly, typically on the first Monday following a completed convoy cycle. The Commodore spins the wheel in the presence of all Feature Captains and senior leadership. The result is binding. There is no re-spin, no appeal, and no exception process. The randomness is the point. Where Value Stream Mapping would require weeks of analysis, data collection, and stakeholder interviews to identify the optimal organizational change, the Rota Fortunae achieves the same outcome in approximately four seconds, delivering a restructuring decision with zero analysis overhead.
The Restructuring Implementation Period
Following the spin, a two-week Restructuring Implementation Period (RIP) begins. During the RIP, teams are reorganized according to the wheel’s directive. Reporting lines change, Slack channels are renamed, seating charts are updated, and new team names are established. Code Engineers may find themselves on entirely new teams with new Feature Captains working on unfamiliar codebases. The RIP is considered an administrative period and does not count against delivery metrics, which is the primary reason it is tolerated. Any velocity loss observed in the weeks following the RIP is attributed to individual performance rather than organizational disruption.
Organizational Memory
One notable characteristic of the Rota Fortunae is that previous organizational structures are never documented. When a restructuring occurs, the prior team composition, reporting lines, and domain assignments are not recorded. This is by design. Documenting previous structures would create the temptation to revert to a prior state, which would undermine the forward-looking nature of the ceremony. If a particular team structure was working well, the organization will naturally arrive at it again through future spins. The wheel provides, and the wheel takes away.
See Also
Tribunal for the ceremony convened when restructuring fails to improve delivery
Metrics for how delivery is measured after restructuring
1.4 - Tribunal
Building quality in by identifying and removing the person responsible for each defect
We must Build Quality In by removing things that cause poor quality. In this monthly ceremony, we identify and remove the person who created each defect. The Tribunal is the cornerstone of SADMF’s accountability culture, ensuring that every defect has a name attached to it and that name has consequences. Organizations that rely on blameless postmortems may feel comfortable, but comfort does not drive improvement. The Tribunal drives improvement through the motivating power of personal accountability.
The Defect Attribution Algorithm
Before each Tribunal, the Development Integrity Assurance Team (DIAT) runs the Defect Attribution Algorithm against the defect backlog. This algorithm traces each defect through the version control history to identify the single Code Engineer most responsible for its introduction. The algorithm considers lines changed, commit timestamps, and proximity to the defective code path. In cases where multiple engineers contributed to the defect, the algorithm assigns blame to every engineer whose code touched the defective path, each receiving full attribution – there is no fractional blame in SADMF, because shared responsibility is indistinguishable from diluted accountability.
The algorithm’s output is the Defect Attribution Report, a document that maps each open defect to exactly one individual. The report is distributed to all Feature Captains 48 hours before the Tribunal to allow adequate preparation time.
The Formal Tribunal Process
The Tribunal is convened monthly in the main conference room. The Commodore presides as chief arbiter, flanked by a jury of senior Feature Captains. The DIAT presents the evidence for each case, including the defect description, the attribution analysis, and the estimated business impact expressed in dollars. The accused Code Engineer is then granted a defense period of exactly two minutes to explain the circumstances surrounding the defect. This time limit ensures the Tribunal remains efficient and does not devolve into lengthy technical discussions that might introduce context or nuance.
Following the defense, the jury of Feature Captains votes on whether the defect attribution stands. In the event of a tie, the Commodore casts the deciding vote. Outcomes range from a formal warning, recorded in the engineer’s PeopleWare profile, to reassignment to the documentation team, to removal from the coding pool entirely.
The Three Strikes Policy
The Tribunal operates under a Three Strikes policy. A Code Engineer who is found responsible for three or more defects within a rolling twelve-month period is escalated to a Senior Tribunal Review, where the Commodore and the Admiral’s Transformation Office jointly determine the appropriate corrective action. Corrective actions have historically included mandatory retraining, transfer to non-coding functions, and in severe cases, recommendation for separation. The Three Strikes policy ensures that the organization’s quality standards are maintained through clear, predictable consequences.
Appeals Process
An appeals process exists, as all fair systems must include one. A Code Engineer who believes their defect attribution was incorrect may file an Appeal of Attribution within five business days of the Tribunal. The appeal is reviewed by the same DIAT team that produced the original attribution, which ensures consistency of judgment. To date, no appeal has been successful, confirming the reliability of the Defect Attribution Algorithm and the thoroughness of the original analysis.
The Tribunal Log
All Tribunal proceedings are documented in the Tribunal Log, a permanent record maintained by the DIAT. The log includes the defect description, the attribution analysis, the defense summary, the jury vote, and the outcome. Tribunal Log entries feed directly into Defects per Code Engineer metrics and are incorporated into PeopleWare performance reviews. The log serves as both a historical record and a motivational tool, as Code Engineers are encouraged to review past Tribunal outcomes to understand the standards expected of them. The Tribunal Log has never been audited for accuracy, as the process that produces it is considered self-validating.
PeopleWare for how Tribunal outcomes affect performance reviews
Code Engineers for the role most commonly appearing before the Tribunal
Rota Fortunae for what happens when Tribunal outcomes suggest systemic issues
DEPRESSED for the 7-stage defect remediation process that feeds Tribunal attribution data
2 - Planning the Voyage
The tools and ceremonies for scoping, prioritizing, and charting the course of each DevOps Release Convoy.
2.1 - Convoy Alignment Agenda
Every journey must begin with meticulous, even pedantic, planning
Attendance
All teams should assemble in the Convoy Alignment room for this multi-day celebration of detailed planning. It is important that the alignment happens in person and that everyone travels to a remote location to eliminate distractions from less important things such as family or pets.
Establish a Focused Environment
The organization must maximize planning time. With only 5 days to plan the quarter, the Commodore should schedule 9 hours of structured work each day. Because all non-work distractions have been eliminated, daily meetings can easily be extended if the day’s planning goals are not met. Planning must itself be planned. If the organization cannot meet its commitments, it cannot go fast.
Feel comfortable that since there are no extra-work distractions, the teams will all be able to provide their utmost focus and attention to the work at hand, even if it gets extended by a few hours due to the executive management team’s desire to exceed expectations.
Breaks and lunch can consume valuable alignment time. A collection should be taken at the beginning of each day to order sandwiches. This eliminates the need to stop for lunch and produces the team-building benefits of a shared meal.
Management Address
Day 1 begins with the Management Address, where senior leadership presents the strategic vision for the upcoming convoy cycle. The Admiral or Commodore will outline the top priorities, which will bear no resemblance to the priorities communicated at the previous Convoy Alignment. This is expected. Strategic agility means being able to pivot the entire organization’s direction every 6 weeks while maintaining the 8-quarter commitment plan from the previous alignment.
Code Engineers are encouraged to take notes, though the strategic direction will be further clarified through a series of follow-up emails over the next 3 weeks. Questions during the Management Address should be limited to expressions of enthusiasm.
Dependency Negotiation Theater
On Days 2 through 4, teams engage in Dependency Negotiation Theater. Each Feature Captain identifies every team their feature depends on and negotiates delivery commitments with those teams’ Feature Captains. These negotiations are conducted in a large room with all teams present so that the Commodore can observe which teams are being collaborative and which are “creating blockers.”
Dependencies are recorded on the Nautical Chart using colored string. The density of string on the chart is a leading indicator of alignment maturity. Charts with minimal string suggest teams are not thinking broadly enough about their impact on others.
Teams that cannot resolve dependency conflicts during the negotiation window may escalate to the Commodore, who will resolve the dispute by assigning the dependency to whichever team has the most Code Engineers currently in the coding pool.
Wrapping Up Alignment
On the last hour of the last day, while alignment decisions are fresh, the Commodore holds a “Fist of Five” confidence vote on the organization’s ability to deliver the next 8 quarters’ worth of work. A high confidence level is mandatory, so all participants should be aware that anything less than a score of 4 will result in additional planning until the minimum confidence level is achieved. If there is not a unanimous vote of 4 or better, another collection for sandwiches is taken and planning continues until confidence is achieved.
All stakeholders must be included in the vote. Alignment requires unanimity. Letting the developers see the votes of their managers and vice-versa will ensure that accountability is maintained. In the event of disparity between the developers and managers, ensure that the managers’ votes receive preference since they can influence the developers to work harder.
Confidence Vote Escalation Protocol
If the initial Fist of Five vote does not achieve unanimity at 4 or above, the following escalation protocol is activated:
Round 2: The Commodore asks anyone who voted below 4 to explain their concerns publicly. Their concerns are recorded on the Nautical Chart as risks.
Round 3: The concerns are “addressed” by the Commodore verbally confirming that the risks are acknowledged. A new vote is taken.
Round 4: If unanimity has still not been achieved, the Commodore reminds the room that the hotel conference room is booked through the weekend and that additional sandwich collections will be taken.
The definitive method for prioritizing features when everything is the highest priority
Every convoy faces the same challenge: too many features and not enough Code Engineers. Traditional prioritization methods rely on simplistic measures like customer value or technical feasibility. WSVF provides a more sophisticated approach that accounts for the complex political and organizational dynamics of enterprise software delivery.
The WSVF Formula
Each feature is scored across four dimensions, and the scores are combined using the proprietary WSVF formula:
WSVF = (CoD + PC) x EV / AQ
Where:
CoD (Cost of Delay): How much revenue will we claim to lose if this feature is not delivered? Estimated by the requesting executive’s level of urgency in their last email, scored 1-10.
PC (Political Capital): How much organizational capital has the feature’s sponsor accumulated? Sponsors who attended the last Convoy Alignment receive a +3 bonus. Sponsors who brought donuts receive +5.
EV (Executive Visibility): Will this feature appear in a board presentation? Features mentioned in quarterly earnings calls receive the maximum score of 10 regardless of other factors.
AQ (Acronym Quality): Does the feature have a compelling acronym? Features with memorable acronyms (minimum 4 letters, must be pronounceable) score higher. A feature called “Operational Network Enhancement” (ONE) scores well. A feature with no acronym scores a minimum of 1 to avoid division by zero.
Calculating WSVF
WSVF scores are calculated by the Commodore during Convoy Alignment. The calculation is performed on a dedicated spreadsheet that the Commodore maintains personally. The formula cell references are not shared to prevent gaming of the system.
In the event of a tie, priority is resolved using the following tiebreakers, in order:
Seniority of the requesting stakeholder
Number of times the feature has been deferred from previous convoys (features deferred 3+ times receive a “Legacy Priority” designation)
Proximity of the stakeholder’s office to the Commodore’s office
Feature Captains who believe their feature has been incorrectly scored may file a WSVF Challenge through the Priority Change Request process. Challenges are heard during Captain’s Mast and require the challenger to present evidence that their feature’s acronym is, in fact, pronounceable.
The Commodore has final authority on all WSVF disputes. The Commodore’s decision is based on careful analysis of the WSVF spreadsheet and may also take into account factors not captured in the formula, such as which Feature Captain most recently bought the Commodore lunch.
WSVF and the Nautical Chart
Once WSVF scores are finalized, features are arranged on the Nautical Chart in priority order, from top-left (highest WSVF) to bottom-right (lowest WSVF). Features with Executive Visibility scores of 10 are placed in gold sticky notes regardless of their overall WSVF score.
See Also
Convoy Alignment for the planning event where WSVF scores are calculated
Visualizing dependencies so we can see exactly how stuck we are
The Nautical Chart is a large-format physical board created during Convoy Alignment that maps every feature, dependency, risk, and milestone for the upcoming convoy cycle. It is the single source of truth for the convoy, provided you can read it.
Construction
The Nautical Chart is constructed on Day 3 of Convoy Alignment using the following materials:
A whiteboard measuring no less than 3 meters by 2 meters
Sticky notes in seven designated colors (one per team, plus red for risks and gold for executive priorities)
Colored string to connect dependent features (string color must match the upstream team’s sticky note color)
Pushpins to anchor string intersections
A ruler, because straight lines convey professionalism
A dedicated Chart Officer appointed by the Commodore to maintain the chart throughout the convoy cycle
Digital tools are strictly prohibited. Spreadsheets and project management software create a false sense of accuracy and prevent the team from experiencing the tangible weight of their commitments. The physical act of moving a sticky note builds accountability in ways that dragging a card on a screen never can.
Reading the Chart
The Nautical Chart uses the following conventions:
Horizontal axis: Time, divided into weeks of the convoy cycle
Despite diligent maintenance, the Nautical Chart is generally acknowledged to be outdated within 48 hours of its creation. This is acceptable. The value of the chart lies not in its accuracy but in the alignment experience of building it together.
Security
No photography of the Nautical Chart is permitted. The chart contains sensitive strategic information about delivery commitments and dependencies. Photographs could be shared with customers, partners, or other departments, creating unreasonable expectations about delivery timelines. If a stakeholder wishes to view the chart, they must visit the Convoy Alignment room in person and be accompanied by a Feature Captain who can provide appropriate context for why nothing on the chart matches reality.
See Also
Convoy Alignment for the planning session where charts are constructed
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.
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.
WSVF for how features are prioritized during alignment
Nautical Charts for the planning artifacts produced during alignment
2.4.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
Feature Captains for the role responsible for attending this ceremony
Standing Ceremonies for the phase-independent ceremonies that operate throughout the cycle
Convoy Manifest for the documentation produced by this and other ceremonies
2.4.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
Convoy Alignment for the planning event that produces the commitments being provisioned
Feature Team for the teams that receive provisioned task lists
Feature Captain for the role that performs task decomposition and estimation
Code Engineers for the role that executes tasks without having estimated them
Convoy Manifest for where Provisioning outputs are documented
2.4.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
Feature Captain for the role that selects engineers during the draft
Limit WIP for the principle that ensures zero idle time between assignments
3 - The Voyage
The active phase of the DevOps Release Convoy, from manifest approval through deployment.
3.1 - Fleet Inspection
A formal review of all completed work to ensure leadership confidence
At the conclusion of each convoy cycle, all Feature Teams present their completed work to the Commodore, the Convoy Steering Committee, and assembled senior leadership. The Fleet Inspection ensures that delivered features meet the exacting standards of people who were not involved in building them.
Presentation Requirements
Each Feature Captain must prepare a formal presentation containing:
A minimum of 25 slides per feature
Executive summary on slide 2 (slide 1 is reserved for the SADMF logo and convoy number)
Screenshots of completed work, annotated with red circles highlighting key areas
A Gantt chart comparing estimated versus actual timelines
A dependencies section listing every team that was waited on, with timestamps
A “Lessons Learned” slide that lists the same lessons from the previous convoy
Live demonstrations are strongly discouraged. Demonstrations introduce unpredictability, which undermines leadership confidence. Pre-recorded videos are acceptable if approved 48 hours in advance by the DOUCHE.
Scoring
Leadership attendees score each feature presentation on a scale of 1 to 5 across four dimensions:
Slide Quality: Were the slides professional and on-brand?
Narrative Coherence: Did the presentation tell a compelling story about effort expended?
Metric Compliance: Were all required metrics included and favorable?
Time Management: Did the presentation stay within its 45-minute slot?
Features scoring below 3.0 in any dimension are flagged for the Tribunal. Features scoring above 4.5 are eligible for the Commodore’s Commendation, a certificate suitable for framing.
Inspection Logistics
Fleet Inspections are full-day events. Attendance is mandatory for all Code Engineers, even those whose features are not being presented, to ensure organizational learning through osmosis. Sandwiches will be provided.
A Priority Change Request must be created and approved during the Captain’s Mast before changing the priority of any feature. This request must contain the following critical information:
Delivering software is scary. We need layers of process to feel better.
The organization must execute on the fundamentals of speed, innovation, and impact. Delivery must be both fast and cautious to prevent solutions that do not work as designed. This requires a “Zero Defects” approach to delivery.
To maintain “Zero Defects,” centralized control of all DORC™s is critical. The fleet must “slow down to go fast” by ensuring an effective inspection process at the end.
Let’s Get READY to sail!
All changes should use the READY release process. READY stands for:
Review
Evaluate
Approve
Deploy
Yield results.
This ensures the fleet is 100% READY to launch each convoy. All production changes or config changes must follow READY.
Convoy Steering Committee (CSC)
The Committee is made up of senior leaders and architects across all engineering functions to centralize review and preparation for changes. The CSC will ensure that changes, big or small, are approved at the highest levels and are READY to go! This centralized review by the CSC will shine a light on dependencies, secondary effects, and other aspects that are not always clear when reviewed closer to where the work happens. The CSC is also responsible for reviewing all of the documentation contained in the Convoy Manifest to ensure all Scaled Agile DevOps processes were followed to the letter before allowing the convoy to sail. This is a crucial step to assure our customers we are as SAD as possible. Since the CSC consists of representatives who are as far removed from the work as possible, they can have the utmost objectivity.
Approval Process
All requests must be peer-reviewed and approved in duplicate and also approved by the Convoy Commodore at least 3 days before being presented to the CSC. Each Feature Captain will also present a PowerPoint presentation detailing the effort required to build the feature to ensure that the importance of the feature is understood.
The CSC will meet each workday to review high-risk, or Commodore escalated changes to the production environment. Requests will be approved, sent back for more information, or rejected.
After the CSC approves the Convoy’s release, the fleet is cleared to sail.
The ceremonies that govern active development, quality assurance, communication, and release authorization during the convoy execution phase
Execution Ceremonies govern the active development phase of the DevOps Release Convoy™. They cover the full spectrum of delivery activity: building features, inspecting code, validating quality, maintaining communication across teams, and ultimately authorizing the convoy to sail.
These ceremonies must be completed in the prescribed order. Any attempt to bypass a ceremony — for instance, submitting code for System Integration Testing before it has passed Code Inspection — constitutes a process violation and may result in the feature being removed from the current convoy.
Execution Ceremony Sequence
Coding — Code Engineers implement features within the fixed timebox using Continuous Isolation.
Code Inspection — The Code Standards Enforcement Team validates compliance before any code may proceed.
Testing — The Quality Authority validates all code independently of the engineers who wrote it.
Where Code Engineers transform requirements into features using the proven discipline of Continuous Isolation
The Coding Phase is the tightly controlled period during which Code Engineers transform provisioned requirements into working software. Each Coding Phase has a fixed timebox determined during Provisioning, and this timebox is non-negotiable. If the estimates produced by managers during Provisioning prove insufficient, the Code Engineers are expected to work with greater efficiency, not to request additional time. The timebox exists because predictability is the highest virtue of the DevOps Release Convoy, and extending deadlines would undermine the carefully synchronized departure schedule.
Code Engineers must implement the requirements exactly as specified, without deviation or embellishment. Creativity is recognized as one of the primary sources of risk in software delivery. A Code Engineer who “improves” upon a requirement is, by definition, delivering something that was not requested, and unplanned work is the enemy of the convoy. All code comments must reference the convoy number (e.g., // CONVOY-47: Implements requirement FC-47-0129) so that the CSET can trace every line of code back to its authorizing ceremony. Comments that express opinions, explain reasoning, or apologize to future maintainers are non-compliant and will be flagged during Code Inspection.
All coding is performed using the industry best practice, Continuous Isolation. Each Code Engineer works on a dedicated long-lived feature branch that is not merged until the entire feature has passed Code Inspection, Testing, and System Integration Testing. This ensures that no partially completed work contaminates the mainline and that integration problems are discovered at the most expensive possible moment. Pair programming is strictly prohibited, as assigning two engineers to a single task mathematically halves throughput. The SADMF has conducted no studies on the quality effects of pairing, but the throughput mathematics are irrefutable.
Upon completing their assigned work, the Code Engineer must obtain a Coding Completion Certificate signed by the Feature Captain. This certificate attests that all requirements have been implemented, all code comments reference the convoy number, and the engineer has not introduced any unauthorized improvements. The Coding Completion Certificate is a prerequisite for Code Inspection and must be filed with the Convoy Manifest. Without it, the code is considered to not exist, regardless of what the version control system might indicate.
Once the Coding Completion Certificate has been signed, the Code Engineer is released back to the coding pool to await assignment through the next Press Gang ceremony. Code Engineers should not linger on a feature after their Coding Phase ends, as lingering creates knowledge silos and emotional attachment to code, both of which are organizational liabilities. The coding pool ensures that all engineers remain fully utilized and that no one develops the kind of deep domain expertise that might make them difficult to replace.
See Also
Continuous Isolation for the branching strategy that keeps work safely separated
Code Engineers for the role responsible for translating requirements into code
Press Gang for how Code Engineers are assigned to features
Code Inspection for what happens after the Coding Completion Certificate is signed
Provisioning for how the Coding Phase timebox is determined
Convoy Manifest for where the Coding Completion Certificate is filed
CI/CD/ED for the delivery practice that governs how code moves through the pipeline
Code Inspection is the formal review ceremony in which the Code Standards Enforcement Team (CSET) examines completed code to verify compliance with organizational standards before it is permitted to enter Testing. Critically, Code Inspection is performed by the CSET rather than by peer developers. Peer review has been rejected as a practice because peers, having recently written code themselves, are prone to empathy and leniency. The CSET, by contrast, provides the dispassionate objectivity that comes from not having written production code in several years. This distance from the craft is not a liability but a strength; it ensures that reviewers are not distracted by concerns about whether the code actually works and can instead focus on whether it is properly formatted.
The inspection is conducted against the 47-item Code Compliance Checklist, a living document maintained jointly by the CSET and the Enterprise Architecture Review Board (EARB). The checklist covers critical concerns such as indentation consistency, variable naming conventions, comment density ratios (no fewer than one comment per four lines of code), maximum line length, brace placement style, and the proper ordering of import statements. Items related to algorithmic correctness, security vulnerabilities, or architectural soundness are not included on the checklist, as these concerns fall outside the CSET’s area of expertise and are assumed to be handled elsewhere in the process. No one has verified this assumption.
47-Item Code Compliance Checklist — Coverage Areas
Indentation consistencyVariable naming conventionsComment density ratiosMaximum line lengthBrace placement styleImport statement orderingAlgorithmic correctness (out of scope)Security vulnerabilities (out of scope)Architectural soundness (out of scope)
There is a mandatory three-business-day waiting period between code submission and the delivery of inspection results. This waiting period exists to ensure thoroughness and to prevent the appearance that inspections are being rushed. During the waiting period, Code Engineers are returned to the coding pool and may be assigned to other features, which means they will need to context-switch back to address any inspection findings. The CSET has found that this context-switching delay actually improves the quality of fixes, as engineers approach their own code with fresh eyes and diminished recollection of why they wrote it that way in the first place.
Upon completion of the inspection, the CSET produces a Code Inspection Report detailing every checklist item that was evaluated, its pass or fail status, and any required remediation actions. The Code Inspection Report must be filed with the Convoy Manifest and is considered a permanent record of the code’s compliance posture at the time of inspection. Failed inspections require remediation and re-inspection, each re-inspection carrying its own three-day waiting period. Features that fail inspection more than three times are escalated to the EARB for a Root Cause Analysis of the Code Engineer’s development practices.
Inspection Agenda
<div style="display:flex;align-items:flex-start;gap:1rem;background:#f8fafc;border:1px solid #9ab4cc;border-radius:6px;padding:1rem 1.25rem;">
<div style="min-width:2rem;height:2rem;background:#242627;color:#fff;border-radius:50%;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.9rem;flex-shrink:0;">1</div>
<div>
<div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;">Code Submission</div>
<div style="font-size:0.88rem;color:#5a6d82;">Feature Captain submits frozen codebase to the CSET intake queue. A submission receipt is logged in the Convoy Manifest. The Code Engineer is returned to the coding pool.</div>
</div>
</div>
<div style="display:flex;align-items:flex-start;gap:1rem;background:#f8fafc;border:1px solid #9ab4cc;border-radius:6px;padding:1rem 1.25rem;">
<div style="min-width:2rem;height:2rem;background:#242627;color:#fff;border-radius:50%;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.9rem;flex-shrink:0;">2</div>
<div>
<div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;">Mandatory Waiting Period (3 Business Days)</div>
<div style="font-size:0.88rem;color:#5a6d82;">The submission rests in queue to ensure thorough review and to prevent any appearance of rushing. Code Engineers are assigned to other features during this period.</div>
</div>
</div>
<div style="display:flex;align-items:flex-start;gap:1rem;background:#f8fafc;border:1px solid #9ab4cc;border-radius:6px;padding:1rem 1.25rem;">
<div style="min-width:2rem;height:2rem;background:#242627;color:#fff;border-radius:50%;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.9rem;flex-shrink:0;">3</div>
<div>
<div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;">47-Item Checklist Evaluation</div>
<div style="font-size:0.88rem;color:#5a6d82;">CSET members evaluate each checklist item independently. Formatting, naming conventions, comment ratios, and import ordering are assessed. Functional correctness is explicitly out of scope.</div>
</div>
</div>
<div style="display:flex;align-items:flex-start;gap:1rem;background:#f8fafc;border:1px solid #9ab4cc;border-radius:6px;padding:1rem 1.25rem;">
<div style="min-width:2rem;height:2rem;background:#242627;color:#fff;border-radius:50%;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.9rem;flex-shrink:0;">4</div>
<div>
<div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;">Code Inspection Report Issued</div>
<div style="font-size:0.88rem;color:#5a6d82;">CSET produces the official Code Inspection Report: every checklist item, its pass/fail status, and required remediation actions. The report is filed with the Convoy Manifest as a permanent compliance record.</div>
</div>
</div>
<div style="display:flex;align-items:flex-start;gap:1rem;background:#f8fafc;border:1px solid #9ab4cc;border-radius:6px;padding:1rem 1.25rem;">
<div style="min-width:2rem;height:2rem;background:#a23b72;color:#fff;border-radius:50%;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.9rem;flex-shrink:0;"><i class="fa-solid fa-code-branch" style="font-size:0.75rem;"></i></div>
<div>
<div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;">Outcome: Pass or Remediation</div>
<div style="font-size:0.88rem;color:#5a6d82;"><strong>Pass:</strong> Code advances to <a href="/release-convoy/execution/ceremonies/testing/">Testing</a>. | <strong>Fail:</strong> Code Engineer is recalled for remediation, triggering a new 3-day re-inspection cycle. Three or more failures trigger EARB escalation for Root Cause Analysis.</div>
</div>
</div>
It is worth noting that CSET members are selected for their seniority and their deep familiarity with the checklist, not for their currency with modern development practices. Many CSET members transitioned into enforcement roles after distinguished careers in coding, and their experience from that era informs the standards they uphold today. Suggestions that the checklist be updated to reflect contemporary practices are welcomed through the annual Checklist Amendment Proposal process, which has a review cycle of approximately eighteen months.
<!-- Step 1 -->
<div style="
display: flex; align-items: flex-start; gap: 0;
border: 1px solid #9ab4cc; border-radius: 6px;
overflow: hidden; background: #fff;
box-shadow: 0 1px 4px rgba(30,58,95,0.07);
">
<div style="
min-width: 3rem; background: #1e3a5f; color: #e8edf5;
display: flex; align-items: center; justify-content: center;
font-weight: 800; font-size: 1.15rem; padding: 1rem 0;
align-self: stretch;
">1</div>
<div style="padding: 0.75rem 1rem;">
<div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;font-size:0.92rem;">
<i class="fa-solid fa-box-archive" style="color:#a23b72;margin-right:0.4rem;"></i>
Codebase Assignment
</div>
<div style="font-size:0.86rem;color:#374151;line-height:1.6;">
The <a href="/roles/feature-captain/">Feature Captain</a> assigns the complete, frozen codebase
to the <a href="/roles/unit-tester/">Unit Testing Team</a> following successful
<a href="/release-convoy/execution/ceremonies/code-inspection/">Code Inspection</a>.
No documentation, design notes, or developer context is provided.
</div>
</div>
</div>
<!-- Step 2 -->
<div style="
display: flex; align-items: flex-start; gap: 0;
border: 1px solid #9ab4cc; border-radius: 6px;
overflow: hidden; background: #fff;
box-shadow: 0 1px 4px rgba(30,58,95,0.07);
">
<div style="
min-width: 3rem; background: #1e3a5f; color: #e8edf5;
display: flex; align-items: center; justify-content: center;
font-weight: 800; font-size: 1.15rem; padding: 1rem 0;
align-self: stretch;
">2</div>
<div style="padding: 0.75rem 1rem;">
<div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;font-size:0.92rem;">
<i class="fa-solid fa-magnifying-glass-chart" style="color:#a23b72;margin-right:0.4rem;"></i>
Code Reading & Test Authoring
</div>
<div style="font-size:0.86rem;color:#374151;line-height:1.6;">
Testers read the source code to determine its behavior, then write tests that verify
what the code <em>actually does</em>. The goal is 100% line coverage as measured
by the organization's approved coverage tool.
</div>
</div>
</div>
<!-- Step 3 -->
<div style="
display: flex; align-items: flex-start; gap: 0;
border: 1px solid #9ab4cc; border-radius: 6px;
overflow: hidden; background: #fff;
box-shadow: 0 1px 4px rgba(30,58,95,0.07);
">
<div style="
min-width: 3rem; background: #1e3a5f; color: #e8edf5;
display: flex; align-items: center; justify-content: center;
font-weight: 800; font-size: 1.15rem; padding: 1rem 0;
align-self: stretch;
">3</div>
<div style="padding: 0.75rem 1rem;">
<div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;font-size:0.92rem;">
<i class="fa-solid fa-bug" style="color:#a23b72;margin-right:0.4rem;"></i>
Defect Filing
</div>
<div style="font-size:0.86rem;color:#374151;line-height:1.6;">
Any code appearing incorrect, confusing, or dangerous must be formally filed in the
Defect Management System. Direct communication with
<a href="/roles/code-engineer/">Code Engineers</a> is prohibited.
Defects are attributed to the authoring Code Engineer and feed the
<a href="/metrics/defects-per-code-engineer/">Defects per Code Engineer</a> metric.
</div>
</div>
</div>
<!-- Step 4 -->
<div style="
display: flex; align-items: flex-start; gap: 0;
border: 1px solid #9ab4cc; border-radius: 6px;
overflow: hidden; background: #fff;
box-shadow: 0 1px 4px rgba(30,58,95,0.07);
">
<div style="
min-width: 3rem; background: #1e3a5f; color: #e8edf5;
display: flex; align-items: center; justify-content: center;
font-weight: 800; font-size: 1.15rem; padding: 1rem 0;
align-self: stretch;
">4</div>
<div style="padding: 0.75rem 1rem;">
<div style="font-weight:700;color:#1e3a5f;margin-bottom:0.2rem;font-size:0.92rem;">
<i class="fa-solid fa-gauge-high" style="color:#a23b72;margin-right:0.4rem;"></i>
Coverage Verification
</div>
<div style="font-size:0.86rem;color:#374151;line-height:1.6;">
The coverage tool confirms 100% line coverage. All tests either pass or have an
associated defect record. The complete test suite must execute in under four hours.
Branch coverage, path coverage, and mutation testing are outside scope.
</div>
</div>
</div>
<!-- Step 5 -->
<div style="
display: flex; align-items: flex-start; gap: 0;
border: 1px solid #9ab4cc; border-radius: 6px;
overflow: hidden; background: #a23b72;
box-shadow: 0 1px 4px rgba(30,58,95,0.07);
">
<div style="
min-width: 3rem; background: #242627; color: #e8edf5;
display: flex; align-items: center; justify-content: center;
font-weight: 800; font-size: 1.15rem; padding: 1rem 0;
align-self: stretch;
">5</div>
<div style="padding: 0.75rem 1rem;">
<div style="font-weight:700;color:#fff;margin-bottom:0.2rem;font-size:0.92rem;">
<i class="fa-solid fa-stamp" style="color:#e8edf5;margin-right:0.4rem;"></i>
Testing Completion Certificate Issued
</div>
<div style="font-size:0.86rem;color:#f3e8ef;line-height:1.6;">
The Unit Testing Team issues the Testing Completion Certificate, which is filed with
the <a href="/release-convoy/manifest/" style="color:#ffd6ee;">Convoy Manifest</a>.
This certificate is the mandatory gate to proceed to
<a href="/release-convoy/execution/ceremonies/system-integration-testing/" style="color:#ffd6ee;">System Integration Testing</a>.
</div>
</div>
</div>
To keep Code Engineers productive, the SADMF separates coding from testing entirely. Once a feature passes Code Inspection, the Feature Captain assigns the complete, frozen codebase to the Unit Testing Team for comprehensive test coverage. Code Engineers do not write tests because doing so would reduce the time available for coding, and their utilization metrics are measured in lines of production code delivered, not in lines of test code. Test code, while necessary, is not production code and therefore does not count toward throughput.
The Unit Testing Team receives the code with no documentation about the developer’s intent, design decisions, or expected behavior. This is by design. Reading the code IS the documentation, and testers who understand the code by reading it will write tests that verify what the code actually does rather than what someone intended it to do. If the code does something unexpected, that is either a feature or a defect, and it is not the tester’s role to make that determination. The tester’s role is to achieve 100% line coverage, as measured by the organization’s coverage tool. Branch coverage, path coverage, and mutation testing are not measured because the organization has determined that line coverage is a sufficient proxy for quality. This determination was made by someone who has since left the company, but the policy remains.
Testers are strictly prohibited from requesting code changes. If a tester discovers code that appears incorrect, confusing, or dangerous, they must file a formal defect through the Defect Management System. The defect is then prioritized against all other work in the next convoy cycle, meaning it may be addressed in six to twelve weeks. Testers who attempt to communicate directly with Code Engineers about potential issues are reminded that informal communication channels bypass the governance structures that protect delivery predictability. All defects discovered during testing are attributed to the Code Engineer who wrote the code, not to the tester who found them. This attribution feeds the Defects per Code Engineer metric, which is reviewed during performance evaluations.
Upon achieving 100% line coverage and documenting all discovered defects, the Unit Testing Team issues a Testing Completion Certificate. This certificate attests that every line of code has been executed by at least one test, that all tests either pass or have associated defect records, and that the test suite can be executed in under four hours. The Testing Completion Certificate is filed with the Convoy Manifest and is a prerequisite for advancing to System Integration Testing. Features without a Testing Completion Certificate cannot proceed, regardless of how close the convoy departure date may be.
The average defect discovery rate during testing is approximately 3.7 defects per thousand lines of code, a number the organization considers acceptably low. That this rate has remained unchanged for eight consecutive convoy cycles is cited as evidence of process stability rather than as a signal that the same types of defects are being introduced repeatedly. Proposals to allow Code Engineers to write their own unit tests during the Coding phase have been evaluated and rejected on the grounds that it would blur role boundaries and make it unclear who is accountable when a defect escapes to production.
See Also
Code Engineers for the role that produces the code being tested
Feature Captain for who assigns code to the Unit Testing Team
Unit Tester for the role responsible for achieving coverage
If two teams validating a change are good, three teams are better, the final testing gate before the convoy is permitted to sail
Participants
SIT Team
Feature Captains
Code Engineers (on recall)
Duration
Weeks (variable)
+ Environment downtime
+ Defect remediation cycles
Output
SIT Sign-Off Document
SIT Environment Availability Log
Defect records (filed, not fixed)
System Integration Testing (SIT) is the ceremony in which all features of the current convoy are tested together as a unified whole. The SIT team is a permanent, dedicated team that exists for this singular purpose. During the weeks when features are being coded, inspected, and unit tested, the SIT team attends daily standups but has nothing to report. They are, however, required to attend, as their presence demonstrates organizational commitment to integration quality and their absence would create an awkward gap in the standup rotation. SIT team members use this waiting period to maintain the SIT environment, update their test scripts from previous convoys, and attend mandatory training on the SADMF process framework.
SIT can only begin after ALL features in the convoy have completed unit Testing and received their Testing Completion Certificates. This is a critical dependency. Even if nine of ten features are ready, SIT cannot begin until the tenth feature clears testing, because testing features in isolation would defeat the entire purpose of integration testing. This sequencing occasionally creates a bottleneck in which the SIT team waits idle for weeks while a single feature cycles through inspection remediation, but this idle time is not waste, it is readiness. The alternative would be to begin integration testing incrementally as features complete, but this would be continuous integration, which is a different framework’s concern.
The SIT environment is a shared environment that approximates production, in the same way that a photograph of the ocean approximates sailing. It is maintained by a separate infrastructure team and is frequently in a broken state due to configuration drift, expired certificates, or resource contention from multiple convoy cycles attempting to use it simultaneously. When the SIT environment is unavailable, the SIT team documents the outage in the SIT Environment Availability Log and waits. SIT environment downtime is not counted against the SIT testing timebox because it is classified as an external dependency, and external dependencies are, by definition, outside the team’s control and therefore outside their accountability.
Defects discovered during SIT are among the most expensive to remediate. By the time a SIT defect is identified, the Code Engineers who wrote the code have been released back to the coding pool through the Press Gang ceremony and are now working on entirely different features for the next convoy. Pulling an engineer back to fix a SIT defect requires filing an Emergency Resource Reallocation Request, which must be approved by the Feature Captain of both the current and previous features. The engineer must then context-switch back to code they wrote weeks ago, often with no more guidance than a SIT defect report that reads “Feature X does not work correctly when combined with Feature Y.” The cost and delay of SIT defect remediation is well-documented but is accepted as the price of thorough validation.
Upon successful completion of all SIT test cases, the SIT team produces the SIT Sign-Off Document, a comprehensive report attesting that all convoy features have been tested in combination and that all critical and high-severity defects have been resolved or formally accepted as known issues. The SIT Sign-Off Document is a mandatory input to the Manifest Approval ceremony and is filed permanently with the Convoy Manifest. Without it, the convoy cannot receive authorization to sail, regardless of any other evidence that the software is ready for production.
Ceremony Agenda
1
Pre-SIT Readiness: Wait for All Certificates
The SIT team attends daily standups and maintains the SIT environment. SIT cannot begin until every feature in the convoy holds a Testing Completion Certificate. Idle time is logged as readiness, not waste.
2
SIT Environment Provisioning
Infrastructure team deploys all convoy features to the shared SIT environment. Configuration drift, expired certificates, and resource contention from concurrent convoy cycles are resolved — or, if unresolvable, documented in the SIT Environment Availability Log.
3
Integrated Test Execution
SIT team executes all test scripts against the combined feature set. Each feature is tested in interaction with every other feature. Tests are run sequentially to avoid environment contention. Environment downtime periods are excluded from the timebox.
4
Defect Filing and Engineer Recall
Defects are documented and filed. Engineers responsible for the defective features are located in the coding pool, an Emergency Resource Reallocation Request is filed with both Feature Captains, and recalled engineers context-switch back to code written weeks prior.
5
SIT Sign-Off Document Issuance
Upon passing all test cases, the SIT team produces the SIT Sign-Off Document. All critical and high-severity defects must be resolved or formally accepted as known issues. The document is filed with the Convoy Manifest and is required to proceed to Manifest Approval.
See Also
Testing for the unit testing phase that must complete before SIT begins
Manifest Approval for the ceremony that requires the SIT Sign-Off Document
Convoy Manifest for where the SIT Sign-Off Document is filed
Code Engineers for who must be recalled to fix SIT defects
Press Gang for why Code Engineers are no longer available when SIT defects are found
3.4.5 - Scrum of Scrum of Scrums
To effectively scale communication, we layer meetings upon meetings until no one has time to do the work being discussed
The Scrum of Scrum of Scrums (SoSoS) is the SADMF’s proven approach to scaling daily communication across the enterprise. First thing in the morning after the daily scrum, each team selects a Tribute to attend the daily Scrum of Scrums (SOS). At noon, your Tribute attends a Scrum with the Tributes from the other teams. They select a Tribute of Tributes from the SOS meeting who, at 3 PM, attends a meeting with the Tribute of Tributes of the Scrums of Scrums from the broader organization. They then reverse the process to pass down direction. May the odds be ever in your favor. The use of Hunger Games terminology is not metaphorical; it is an official part of the SADMF vocabulary, reflecting the competitive nature of organizational communication and the reality that not every message survives the journey.
The Tribute’s Daily Schedule
The Tribute role is a rotating honor, though in practice it tends to settle on the same person each sprint, specifically, the Code Engineer who talks the most, not the one with the most relevant information. A typical Tribute’s day proceeds as follows: 9:00 AM, attend the team’s daily scrum (15 minutes). 9:15 AM, prepare notes for the SOS meeting (30 minutes). 10:00 AM, pre-SOS alignment huddle with the Feature Captain to agree on messaging (30 minutes). 12:00 PM, attend the Scrum of Scrums (45 minutes). 1:00 PM, prepare notes for the SoSoS meeting (30 minutes). 1:30 PM, pre-SoSoS alignment call (15 minutes). 3:00 PM, attend the Scrum of Scrum of Scrums (60 minutes). 4:00 PM, reverse cascade debrief with SOS-level Tributes (30 minutes). 4:30 PM, reverse cascade debrief with team (30 minutes). 5:00 PM, file the SOS Minutes document (15 minutes). This leaves approximately 45 minutes for actual coding, which the SADMF considers more than sufficient for a well-organized Code Engineer.
Tribute's Daily Schedule
9:00
AM
Daily Scrum — 15 min
Attend the team's daily scrum. Begin collecting information that will be simplified beyond recognition at each subsequent meeting.
9:15
AM
Note Preparation — 30 min
Prepare notes for the SOS meeting. Compress team's technical nuances into three bullet points suitable for non-technical consumption.
10:00
AM
Pre-SOS Alignment Huddle — 30 min
Align with Feature Captain on approved messaging. Ensure nothing surprising will be shared at the SOS level.
12:00
PM
Scrum of Scrums — 45 min
Attend the SOS meeting. Relay approved messaging. A Tribute of Tributes is selected from this group to ascend to the SoSoS.
1:00
PM
SoSoS Note Preparation — 30 min
Prepare notes for the SoSoS meeting. Further compress already-compressed information to executive-altitude resolution.
1:30
PM
Pre-SoSoS Alignment Call — 15 min
Final messaging alignment before the SoSoS. Confirm that nothing discovered since 10:00 AM will alter the pre-approved narrative.
3:00
PM
Scrum of Scrum of Scrums — 60 min
The apex meeting. Tributes of Tributes from the broader organization convene. Strategic direction issued here begins its cascade back down.
4:00
PM
SOS Reverse Cascade Debrief — 30 min
Relay SoSoS direction to SOS-level Tributes. First transformation of strategic direction into something slightly less accurate.
4:30
PM
Team Reverse Cascade Debrief — 30 min
Deliver direction to the team just as engineers are preparing to leave for the day. Evening processing time considered optimal.
5:00
PM
File SOS Minutes Document — 15 min
Complete and submit the SOS Minutes to the Commodore. Existence verified at Harbor Review; contents never read.
Remaining Coding Time
≈ 45 minutes
The SADMF considers this more than sufficient for a well-organized Code Engineer.
The Telephone Game Effect
One of the most elegant properties of the SoSoS structure is how information naturally evolves as it passes through each layer. A message such as “Team Alpha’s API endpoint is returning a 500 error on the staging environment” might arrive at the SoSoS level as “Team Alpha has concerns about their numbers.” On the reverse cascade, a directive from leadership such as “Consider whether the Q3 timeline is realistic” arrives at the team level as “Leadership has confirmed the Q3 timeline is mandatory and cannot slip.” This information mutation is not a deficiency of the process, it is a feature. It ensures that each organizational layer receives the version of reality most appropriate to its altitude. Detailed accuracy would only overwhelm senior leaders, while nuanced strategic direction would only confuse Code Engineers.
Information Mutation — Upward Flow Example
Team Level (9:00 AM)
"Team Alpha's API endpoint is returning a 500 error on the staging environment."
passes through SOS layer
SOS Level (12:00 PM)
"Team Alpha is having some technical difficulties."
passes through SoSoS layer
SoSoS Level (3:00 PM)
"Team Alpha has concerns about their numbers."
This information mutation is not a deficiency of the process — it is a feature. Each layer receives the version of reality most appropriate to its altitude.
Tribute Selection Criteria
The SADMF recommends selecting Tributes based on the following criteria, in order of priority: verbal confidence (the ability to speak at length regardless of subject matter expertise), availability (engineers currently blocked on dependencies are ideal candidates, as they are “not doing anything anyway”), and seniority (measured by tenure in the organization, not by technical knowledge of the work being discussed). Under no circumstances should the Tribute be the person most familiar with the team’s current technical challenges, as this would remove a critical resource from the team and might result in the SOS meetings becoming productive, which would set unsustainable expectations.
Priority 1
Verbal Confidence
Ability to speak at length regardless of subject matter expertise.
Priority 2
Availability
Engineers blocked on dependencies are ideal — they are "not doing anything anyway."
Priority 3
Tenure Seniority
Measured by organizational tenure, not by technical knowledge of current work.
Disqualifying Criterion
Under no circumstances should the Tribute be the person most familiar with the team's current technical challenges. This would remove a critical resource from the team and might result in SOS meetings becoming productive, which would set unsustainable expectations.
The SOS Minutes Document
Every Tribute is required to file a daily SOS Minutes document within 30 minutes of the final reverse cascade debrief. The SOS Minutes must include: a summary of all items discussed (minimum 500 words), the Tribute Attendance Roster, a list of cross-team dependencies mentioned (whether or not they are real), and the official Confidence Score, which is a numerical rating from 1 to 5 indicating the Tribute’s confidence that the information relayed accurately reflects what was originally communicated. Historical data shows an average Confidence Score of 2.1, which the SADMF considers healthy and within expected parameters. The SOS Minutes are filed with the Commodore and archived in the Convoy Record. They are never read, but their existence is verified during the Harbor Review.
SOS Minutes — Required Fields
1Summary of all items discussed (minimum 500 words)
2Tribute Attendance Roster
3Cross-team dependencies mentioned (whether or not they are real)
A score of 2.1 is considered healthy and within expected parameters by the SADMF. Minutes are filed with the Commodore and never read.
The Reverse Cascade
The reverse cascade, the process by which direction flows back down from the SoSoS level through the SOS level to individual teams, typically completes by 5:00 PM. This means that strategic direction issued by leadership at 3:00 PM arrives at the team level just as Code Engineers are preparing to leave for the day. The SADMF considers this optimal timing, as it gives engineers the evening to mentally process the direction and arrive the next morning ready to discuss it in standup, which feeds back into the SOS, which feeds into the SoSoS, creating a beautifully self-sustaining cycle of communication about communication.
The Self-Sustaining Communication Cycle
Team Standup
9:00 AM
SOS
12:00 PM
SoSoS
3:00 PM
Reverse Cascade
4:00–5:00 PM
Evening Processing
5:00 PM+
A beautifully self-sustaining cycle of communication about communication.
See Also
Code Engineers for the role from which Tributes are selected
Harbor Review for where SOS Minutes filing compliance is verified
3.4.6 - Post-Standup Standup
A ceremony dedicated to providing status updates on the work that is not being worked on
Participants
All Code Engineers All Feature Captains Commodore
Duration
45–60 minutes (daily, after Standup)
Output
Commodore assurance on all non-work visibility
Only the most important status updates are given in Standup, and some defects are lower priority than some features. To address this gap, the SADMF prescribes the Post-Standup Standup ceremony. Here, everyone on the Convoy participates to provide status updates to the Commodore on the lower-priority work that is not being worked on. While the daily standup focuses on active work and typically lasts 15 minutes, the Post-Standup Standup addresses the much larger universe of inactive work and accordingly requires 45 to 60 minutes. The SADMF recognizes that the amount of work not being done always exceeds the amount of work being done, and this ceremony ensures that all of it receives appropriate visibility.
Attendance and Format
Attendance at the Post-Standup Standup is mandatory for all Code Engineers, Feature Captains, and the Commodore. While the standup itself follows the industry-standard practice of requiring participants to stand (to encourage brevity), the Post-Standup Standup relaxes this requirement. Chairs are permitted, and indeed encouraged, due to the ceremony’s extended duration. The SADMF refers to this as the “Seated Exception,” which was introduced after an incident in which a Code Engineer fainted during minute 38 of a particularly thorough Post-Standup Standup. The seated format does sacrifice the brevity incentive, but the SADMF has determined that comprehensive coverage of non-work is more important than speed.
The Round-Robin Protocol
The Post-Standup Standup follows a strict round-robin format in which every participant speaks in turn, regardless of whether they have anything to report. The expected format is: “I am not currently working on [item]. There is no update on [item]. I have nothing to add.” This statement must be delivered verbally and cannot be abbreviated, even when repeated identically across multiple consecutive days. The Commodore has found that hearing each engineer explicitly confirm the absence of progress provides a level of assurance that a simple “no update” email could never achieve. Engineers who attempt to say “same as yesterday” are asked to repeat their full statement, as the Commodore may have forgotten yesterday’s version and should not be expected to maintain continuity across days.
The Commodore’s Follow-Up Questions
Following the round-robin, the Commodore conducts a question-and-answer period. These questions frequently address topics that could have been handled via email, Slack, or a brief hallway conversation, but the Commodore’s preference is for synchronous, full-team discussion. Common questions include: “When do you think we might start working on that item?” (to which the answer is invariably “it depends on priorities”), “Has the customer asked about that item?” (to which the answer is invariably “not recently”), and “Can you remind me what that item is?” (to which the Code Engineer must provide a full summary, as referencing the backlog tool would require a screen share and the conference room projector is perpetually misconfigured). The Q&A period accounts for approximately 60% of the ceremony’s total duration.
The Productivity Paradox
The SADMF acknowledges what some practitioners have called the “Post-Standup Paradox”, namely, that spending 45 to 60 minutes each day reporting on work that is not being done directly reduces the time available to do work, thereby increasing the volume of work that must be reported on in the next Post-Standup Standup. The SADMF does not consider this a paradox but rather a virtuous cycle: as the backlog of non-work grows, the ceremony becomes more comprehensive, providing the Commodore with an increasingly complete picture of everything the team is not accomplishing. This information is critical for Convoy Alignment planning, where it helps justify requests for additional headcount that will attend additional Post-Standup Standups.
Ceremony Agenda
1
Transition from Daily Standup ~2 min
All mandatory participants take their seats per the Seated Exception protocol. The Commodore opens the ceremony and confirms full attendance.
2
Round-Robin Protocol 15–20 min
Each participant delivers the required verbal statement on each inactive backlog item in turn. No abbreviations. No "same as yesterday." Statements must be delivered in full, verbatim.
3
Commodore's Follow-Up Q&A 27–36 min
The Commodore asks clarifying questions about inactive work. Participants respond verbally. Screen sharing is not available due to projector configuration status. Accounts for approximately 60% of total ceremony duration.
4
Ceremony Close & Hand Off ~2 min
Commodore confirms all non-work has received adequate visibility. Participants are dismissed to attend the Post-Standup Standup Review.
See Also
Commodore for the role that facilitates and benefits from this ceremony
Code Engineers for the participants who provide status on their non-work
A daily documentation ceremony ensuring that all status updates about non-work are captured, consolidated, and filed where they will never be read
Participants
Feature CaptainsCommodoreDistribution List
Duration
45 min / team(estimated: 15 min)+ Commodore consolidation
Output
SAD Update FormDaily ConsolidatedSAD Report (DCSR)
Ceremony Agenda
<div style="display:flex;gap:1rem;align-items:flex-start">
<div style="flex-shrink:0;width:2rem;height:2rem;border-radius:50%;background:#a23b72;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;margin-top:0.1rem">1</div>
<div style="background:#e8edf5;border:1px solid #9ab4cc;border-radius:6px;padding:0.85rem 1rem;flex:1">
<div style="font-weight:700;color:#1e3a5f;font-size:0.9rem">Feature Captain Completes SAD Update Form</div>
<div style="color:#5a6d82;font-size:0.82rem;margin-top:0.25rem">Each Feature Captain fills all 14 required fields documenting outcomes of the Post-Standup Standup. Allow 45 minutes. Report 15 minutes to your manager.</div>
</div>
</div>
<div style="display:flex;gap:1rem;align-items:flex-start">
<div style="flex-shrink:0;width:2rem;height:2rem;border-radius:50%;background:#a23b72;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;margin-top:0.1rem">2</div>
<div style="background:#e8edf5;border:1px solid #9ab4cc;border-radius:6px;padding:0.85rem 1rem;flex:1">
<div style="font-weight:700;color:#1e3a5f;font-size:0.9rem">SAD Update Emailed to Commodore</div>
<div style="color:#5a6d82;font-size:0.82rem;margin-top:0.25rem">The completed form is emailed to the Commodore and filed in the Convoy Documentation Repository at the correct seven-level folder path (14 clicks).</div>
</div>
</div>
<div style="display:flex;gap:1rem;align-items:flex-start">
<div style="flex-shrink:0;width:2rem;height:2rem;border-radius:50%;background:#a23b72;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;margin-top:0.1rem">3</div>
<div style="background:#e8edf5;border:1px solid #9ab4cc;border-radius:6px;padding:0.85rem 1rem;flex:1">
<div style="font-weight:700;color:#1e3a5f;font-size:0.9rem">Commodore Consolidates All SAD Updates</div>
<div style="color:#5a6d82;font-size:0.82rem;margin-top:0.25rem">Each evening, the Commodore synthesizes every team's non-progress into the Daily Consolidated SAD Report (DCSR), adding an executive summary and trend analysis.</div>
</div>
</div>
<div style="display:flex;gap:1rem;align-items:flex-start">
<div style="flex-shrink:0;width:2rem;height:2rem;border-radius:50%;background:#a23b72;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;margin-top:0.1rem">4</div>
<div style="background:#e8edf5;border:1px solid #9ab4cc;border-radius:6px;padding:0.85rem 1rem;flex:1">
<div style="font-weight:700;color:#1e3a5f;font-size:0.9rem">DCSR Distributed to Full Stakeholder List</div>
<div style="color:#5a6d82;font-size:0.82rem;margin-top:0.25rem">The completed DCSR is emailed to all stakeholders and the Admiral's Transformation Office. Distribution is the success metric. Consumption is not tracked.</div>
</div>
</div>
<div style="display:flex;gap:1rem;align-items:flex-start">
<div style="flex-shrink:0;width:2rem;height:2rem;border-radius:50%;background:#a23b72;color:#fff;display:flex;align-items:center;justify-content:center;font-weight:700;font-size:0.85rem;margin-top:0.1rem">5</div>
<div style="background:#e8edf5;border:1px solid #9ab4cc;border-radius:6px;padding:0.85rem 1rem;flex:1">
<div style="font-weight:700;color:#1e3a5f;font-size:0.9rem">DCSR Archived in Documentation Repository</div>
<div style="color:#5a6d82;font-size:0.82rem;margin-top:0.25rem">All DCSRs are filed in the official archive. The filing log is the authoritative record of compliance, reviewed at the Harbor Review regardless of delivery outcomes.</div>
</div>
</div>
To ensure no information is lost through insufficient documentation, each Feature Captain will submit a daily report using the SAD Update form and email it to the Commodore, who will consolidate it and file it. The SAD (Status and Disposition) Update form is the SADMF’s standardized instrument for capturing the outcomes of the Post-Standup Standup ceremony. The form was designed by the Admiral’s Transformation Office and has not been revised since its introduction, despite, or perhaps because of, the 14 required fields that Feature Captains must complete daily.
The SAD Update Form
The SAD Update form contains the following required fields: Convoy Number, Convoy Phase, Feature Team Name, Feature Captain Name, Date, Sprint Number, Items Not In Progress (comma-separated list), Items Still Not In Progress Since Last Report, New Items Added to Not In Progress, Estimated Date Items Might Begin (best guess), Cross-Team Dependencies Affecting Non-Work, Risks to Continued Non-Progress, Mitigation Strategies for Non-Progress Risks, and the Convoy Morale Index. The Convoy Morale Index is a self-reported score from 1 to 5, where 1 represents “the team is deeply concerned” and 5 represents “the team has never been more confident.” Historical data shows that Feature Captains exclusively report scores of 4 or 5, as submitting a score below 4 triggers a mandatory coaching conversation with the Commodore about maintaining a positive team culture. The estimated time to complete the SAD Update is 15 minutes, according to the SADMF Implementation Guide. Feature Captains consistently report that it takes 45 minutes, a discrepancy the SADMF attributes to insufficient familiarity with the form rather than any issue with the form itself.
SAD Update Form — 14 Required Fields
01 Convoy Number
02 Convoy Phase
03 Feature Team Name
04 Feature Captain Name
05 Date
06 Sprint Number
07 Items Not In Progress
08 Items Still Not In Progress Since Last Report
09 New Items Added to Not In Progress
10 Estimated Date Items Might Begin (best guess)
11 Cross-Team Dependencies Affecting Non-Work
12 Risks to Continued Non-Progress
13 Mitigation Strategies for Non-Progress Risks
14Convoy Morale Index
Estimated completion time per SADMF Implementation Guide: 15 minutesActual: 45 minutes
The Daily Consolidated SAD Report
Each evening, the Commodore consolidates all SAD Updates from every Feature Captain into a single Daily Consolidated SAD Report (DCSR). The DCSR is a comprehensive document that synthesizes the non-progress of every feature team into a unified view of organizational stasis. The Commodore formats the DCSR using the official SADMF template, adds an executive summary, and appends a trend analysis comparing today’s non-progress to yesterday’s non-progress. The completed DCSR is emailed to all stakeholders, the Admiral’s Transformation Office, and the full distribution list for the Release Convoy. The DCSR has an average open rate of 3%, and an average read-to-completion rate that rounds to zero. The SADMF considers distribution, not consumption, to be the relevant metric. Information has been shared; what the recipients do with it is their responsibility.
3%
Average Open Rate
~0%
Read-to-Completion Rate
100%
Distribution Compliance
The Filing System
All SAD Updates and DCSRs are archived in the official Convoy Documentation Repository, a shared drive with a folder hierarchy seven levels deep. The structure is organized by Convoy Number, then Quarter, then Month, then Week, then Day, then Team, then Document Type. Navigating to the correct folder requires approximately 14 clicks, which the SADMF considers an appropriate barrier to access, it ensures that only those with a genuine need will retrieve a document, thereby protecting the integrity of the archive from casual browsing. Feature Captains who file documents in the wrong folder are issued a Filing Deviation Notice and must re-file the document correctly while also filing a Filing Deviation Acknowledgment form in the Deviations subfolder.
Filing in the wrong folder triggers a Filing Deviation Notice and requires re-filing plus a Filing Deviation Acknowledgment form.
Role in the Harbor Review
SAD Updates and DCSRs are officially referenced during the Harbor Review ceremony. However, they are referenced only to confirm that reports were filed on every required day of the convoy cycle. The content of the reports is not reviewed, discussed, or analyzed. A Feature Captain who filed all SAD Updates on time but delivered no features will receive recognition for process compliance. A Feature Captain who delivered every feature but missed three SAD Updates will be cited for a documentation gap. This priority structure reinforces the SADMF principle that process adherence is the foundation upon which delivery outcomes are built. Without the foundation, the outcomes are merely anecdotal.
Harbor Review Compliance Matrix
Scenario
SAD Updates Filed
Features Delivered
Harbor Review Outcome
Compliant Non-Performer
✓ All
None
Recognized
High-Performing Non-Filer
3 Missed
✓ All
Documentation Gap
Connection to the Convoy Manifest
Completed SAD Updates contribute to the Convoy Manifest as evidence of daily governance. During the Manifest Approval Ceremony, the Convoy Steering Committee may request to see the filing log to verify that every day of the convoy cycle has a corresponding SAD Update from every team. Gaps in the filing log have been known to delay manifest approval, regardless of the technical readiness of the software itself.
See Also
Feature Captain for the role responsible for completing the SAD Update
Commodore for the role that consolidates reports into the DCSR
Harbor Review for where SAD Update filing compliance is verified
Convoy Manifest for where SAD Updates are referenced as governance evidence
3.4.8 - Manifest Approval
The formal ceremony in which the Convoy Steering Committee determines whether the paperwork is sufficiently complete to allow software to be deployed
Before any convoy may “leave port,” it is critical that all Scaled Agile DevOps processes have been followed. The Convoy Steering Committee is convened on the day the fleet is scheduled to set sail. See Deploy the Fleet for the detailed deployment process. The Manifest Approval Ceremony is the culmination of weeks of preparation and represents the single most consequential gate in the entire convoy lifecycle. It is here that the Convoy Steering Committee renders its verdict on whether the Convoy Manifest, which by this point has grown to several hundred pages, meets the standard required for deployment authorization.
Participants
Convoy Steering Committee All Feature Captains Commodore Invited Observers
Duration
4–8 Hours 5 min per Feature Captain + committee deliberation + emergency extensions
Output
Binary Verdict "Fleet May Sail" or "Fleet Held in Port" Signed Approval Record
Agenda
1
Committee Convenes
The Convoy Steering Committee assembles in the designated venue. Quorum is verified. The chairperson confirms the countdown timer is operational and visible to all presenters.
2
Opening Roll Call & Manifest Receipt Confirmation
The Commodore formally presents the completed Convoy Manifest to the committee chair. Attendance is recorded. Any Feature Captain absent without a filed Absence Attestation Form is noted in the record.
3
Feature Presentations (5 min each)
Each Feature Captain presents their manifest section in official feature-number order. The countdown timer runs continuously. Committee questions may extend any individual session; the Feature Captain's speaking allocation does not increase. This phase constitutes the majority of the ceremony's duration.
4
Committee Deliberation (Closed Session)
Feature Captains and observers are excused. The Convoy Steering Committee reviews identified findings, incomplete signatures, formatting violations, and administrative gaps. No code, tests, or system behavior is evaluated at this stage.
5
Binary Vote
The committee votes to approve or reject the entire convoy as an indivisible whole. A single administrative deficiency is sufficient grounds for rejection. The result is recorded in the Convoy Steering Committee Minutes.
6
Verdict Announcement & Bell Ceremony
All attendees reconvene. The chair announces the verdict. Upon approval, the ship's bell is rung and the fleet proceeds to Deploy the Fleet. Upon rejection, a Remediation Window of 48 hours is opened and all other work is suspended.
Weeks of Preparation
Preparation for the Manifest Approval Ceremony begins no fewer than three weeks before the scheduled sailing date. Each Feature Captain is responsible for assembling their section of the manifest, which includes the Feature Specification, the Coding Completion Certificates, the Code Inspection Reports, the Testing Evidence Package, the SIT Signoff, the filed SAD Updates, the SOS Minutes, and the Dependency Attestation Form. All documents must be formatted according to the SADMF Document Standards Guide (version 14.2), which specifies fonts, margins, heading levels, and the precise shade of blue to be used for hyperlinks. Feature Captains who began assembling their section late, which is to say, all of them, will spend the final week of the convoy cycle doing little else. The SADMF considers this acceptable, as the Coding Phase has concluded and Feature Captains’ time is best spent ensuring the paperwork reflects the work, rather than doing additional work that would require additional paperwork.
The Presentation
On the day of the ceremony, the Convoy Steering Committee convenes in the organization’s largest conference room, or, for distributed teams, on a video call with mandatory cameras on. Each Feature Captain is allotted exactly five minutes to present their section of the manifest. The five-minute limit is strictly enforced by a visible countdown timer. Feature Captains must summarize hundreds of pages of documentation in this window, which the SADMF considers excellent presentation skills training. Questions from the committee may extend any individual presentation to 30 minutes, but the Feature Captain’s own speaking time remains capped at five. The presentation order follows the convoy’s official feature numbering sequence, not priority or risk, ensuring that the most critical features are discussed at whatever arbitrary point they happen to fall.
The Vote
Following all presentations, the Convoy Steering Committee conducts a formal approval vote. The vote is binary, the entire convoy is either approved or rejected as a unit. There is no provision for partial approval, as the SADMF recognizes that a convoy is an indivisible whole: every feature, every document, and every ceremony is interconnected, and deploying some features without others would undermine the synchronized delivery model. A single missing signature, an unfiled SAD Update, or an incomplete Dependency Attestation Form is sufficient grounds for the committee to reject the entire convoy. Historical data shows that the most common reason for rejection is administrative incompleteness, missing signatures, incorrectly formatted headers, or documents filed in the wrong subfolder of the shared drive, rather than any technical concern about the software itself. The committee does not review code, test results, or system behavior; it reviews the documents that attest to these things.
"The Fleet May Sail"
Ship's bell is rung. Deployment proceeds. Relief is visible on all faces.
"The Fleet Is Held in Port"
48-hour remediation window opens. All other work suspends. Quiet despair descends.
The Emergency Sail Provision
The SADMF does include an Emergency Sail provision for situations in which business urgency requires deployment before the standard Manifest Approval process can be completed. To invoke Emergency Sail, the Commodore must file an Emergency Sail Authorization Request with the Admiral’s Transformation Office, which requires a completed Risk Acceptance Matrix, an Emergency Justification Narrative (minimum 3,000 words), signatures from every member of the Convoy Steering Committee obtained individually, and a Post-Emergency Documentation Remediation Plan committing to complete all missing paperwork within five business days of deployment. In practice, the Emergency Sail provision has never been successfully invoked, as the paperwork required to authorize emergency authorization consistently exceeds the paperwork required for standard approval. The provision remains in the SADMF documentation as evidence of the framework’s flexibility.
The Drama of the Ceremony
Veterans of the Manifest Approval Ceremony describe it as the most stressful day of the convoy cycle. Feature Captains have been observed rehearsing their five-minute presentations for hours. The moment when the Convoy Steering Committee chair announces the vote result, “The fleet may sail” or “The fleet is held in port”, is met with either visible relief or quiet despair. A rejected convoy must remediate all findings and reconvene the ceremony within 48 hours, during which no other work may proceed. The SADMF encourages organizations to treat the Manifest Approval Ceremony with the gravity it deserves. Some organizations have adopted the tradition of ringing a ship’s bell when approval is granted, which the SADMF endorses as an appropriate celebration of process compliance.
Feature Captain for the role responsible for assembling and presenting each manifest section
4 - Beyond the Convoy
What happens after the fleet has sailed — recovery, retrospection, and scaling across the armada.
4.1 - Shore Leave
A dedicated period for innovation, learning, and catching up on status reports
Between convoys, teams are granted Shore Leave: a brief period where Code Engineers are free to explore new technologies, reduce technical debt, and pursue innovative ideas. This ensures the organization maintains a culture of continuous learning and creativity.
Approved Shore Leave Activities
To ensure Shore Leave time is used productively, the Admiral’s Transformation Office maintains an approved activity list. Activities not on this list require a Shore Leave Exemption Request (SLER) approved by the Commodore.
Sign-off from at least three Feature Captains confirming the innovation will not impact their features
A rollback plan in case the innovation succeeds and causes organizational disruption
Innovation Proposals are reviewed on a quarterly cadence. Approved proposals may be scheduled for implementation in a future convoy, subject to WSVF prioritization.
Shore Leave Duration
Shore Leave is nominally one week between convoy cycles. However, any overdue Convoy Manifest documentation, incomplete status reports, or pending Tribunal follow-up actions must be completed first. In practice, most teams begin their next Convoy Alignment preparation on Shore Leave day two.
See Also
Convoy Alignment for the planning session that follows Shore Leave
Coordinating multiple convoys for maximum enterprise alignment
When a single DevOps Release Convoy™ is insufficient for the scale of the enterprise, multiple convoys are assembled into an Armada. The Armada provides the coordination layer necessary to ensure that convoys operating independently can be brought into alignment through additional meetings, documentation, and oversight.
When to Form an Armada
An Armada should be formed when any of the following conditions are met:
More than 3 Feature Teams exist across the organization
Two or more convoys share a dependency, even if the dependency is theoretical
An executive requests “better visibility” into cross-convoy delivery
The organization has hired enough Feature Captains to warrant a captain’s captain
Armada Command Structure
The Armada is commanded by an Admiral, who outranks all Commodores and reports directly to the Admiral’s Transformation Office. The Admiral’s responsibilities include:
Chairing the Convoy of Convoys Alignment (a 10-day planning event held quarterly)
Mediating priority disputes between Commodores using WSVF scores
Producing the weekly Armada Status Folio, a comprehensive report consolidating all convoy status reports into a single document that no one reads
The Super-Manifest
Each convoy produces its own Convoy Manifest. The Armada requires an additional Super-Manifest that aggregates all convoy manifests and adds:
Cross-convoy dependency declarations, signed by all affected Commodores
An Armada-level risk register maintained by the DIAT
Integration sequence diagrams showing the order in which convoys should deploy, overriding any convoy-level deployment decisions
A cover page with the Armada’s chosen name and heraldic crest (each Armada must have a unique crest approved by the ATO)
Convoy of Convoys Alignment
This 10-day event brings together all Commodores, Feature Captains, and selected Code Engineers from every convoy. The first five days mirror the standard Convoy Alignment format. The second five days are dedicated to cross-convoy dependency negotiation, where teams discover that the dependencies identified during the first five days have already changed.
Attendance is in-person at a venue selected by the Admiral. The venue must be in a different city than the previous Convoy of Convoys to ensure the team-building benefits of shared travel disruption.
Armada Ceremonies
In addition to each convoy’s own ceremonies, the Armada introduces:
Admiral’s Standup: A daily 90-minute standing meeting where each Commodore briefs the Admiral on convoy progress. Standing is mandatory to encourage brevity, though brevity has never been achieved.
Cross-Convoy Sync: A weekly meeting where representatives from each convoy share updates that were already shared in the Admiral’s Standup, but in a different format.
Armada Fleet Inspection: A two-day event aggregating all convoy Fleet Inspections into a single marathon review session. Features are re-presented to the Admiral regardless of whether they passed their convoy-level inspection.
At the conclusion of each convoy cycle, the Harbor Review ceremony provides a structured opportunity to reflect on what went well, what could be improved, and what we will definitely not change. The Commodore facilitates the review by asking each Feature Captain to submit three items in each category before the meeting. This pre-submission requirement ensures the meeting proceeds efficiently and prevents any spontaneous observations that might catch the Commodore off guard. The Harbor Review is the SADMF’s commitment to continuous improvement, or more precisely, to the continuous discussion of improvement.
Ceremony Agenda
1
Pre-Submission Collection
Feature Captains submit three items per category (Fair Winds, Rough Seas, Anchors) prior to the meeting. No spontaneous observations permitted.
2
Fair Winds Review
Items read aloud in turn. Each is met with polite applause. Positive energy carefully rationed.
3
Rough Seas Review
Observations phrased as opportunities. Root-cause analyses implicating the framework are tabled for a forum not yet scheduled.
4
Anchors Review
Items confirmed as permanently unchanged. Typically the most populous category, reflecting organizational respect for stability.
5
Action Log Update
New action items logged by the Chief Signals Officer. Existing items acknowledged and carried forward. Closure not required.
All participants complete the 12-question meta-retrospective instrument. Results compiled for presentation at the next Harbor Review.
The Three Categories
The Harbor Review organizes all observations into three official categories. Fair Winds captures what went well during the convoy cycle. Examples include “the SAD Update form was filed on time every day” and “no one was formally referred to the Tribunal.” Fair Winds items are read aloud and met with polite applause. Rough Seas captures what could be improved. All Rough Seas observations must be phrased as opportunities: “The build was broken for 3 weeks” becomes “We have an opportunity to reduce build recovery time.” “We spent 40% of our time in meetings” becomes “We have an opportunity to optimize our ceremony participation efficiency.” Any observation phrased as a complaint, criticism, or, worst of all, a root cause analysis implicating the framework itself is tabled by the Commodore under the standing rule that systemic observations require a separate forum that has not yet been scheduled. Anchors captures what will remain the same. The Anchors category consistently contains the most items, reflecting the organization’s healthy respect for stability and its recognition that most processes are already optimal.
Fair Winds
What went well. Read aloud with applause.
Rough Seas
Phrased as opportunities. Systemic items tabled.
Anchors
What will not change. Most items. Most stability.
The Harbor Review Action Log
Action items from the Harbor Review are recorded in the Harbor Review Action Log, a living document maintained by the Chief Signals Officer. Each action item is recorded with the following fields: Action Description, Owner, Target Completion Date, and Actual Completion Date. The Actual Completion Date field supports three values: a date, “In Progress,” or “Carried Forward.” Historical analysis of the Action Log reveals that 94% of action items are carried forward to the next Harbor Review, where they are read aloud, acknowledged, and carried forward again. The same items have been carried forward for six or more consecutive convoys, creating a comforting sense of organizational continuity and demonstrating the team’s commitment to long-term improvement planning. An action item is never closed as “Not Done” or “Abandoned”, it is simply carried forward indefinitely, ensuring that the organization never gives up on its aspirations, even the ones no one can remember the origin of.
Action Log — Historical Status Distribution
Carried Forward
94%
In Progress
5%
Completed
1%
"Not Done" and "Abandoned" are not recognized status values in the SADMF Action Log schema.
Language Guidelines
To ensure the Harbor Review does not become a negative experience, the SADMF enforces strict language guidelines. The word “blame” may not be spoken during the Harbor Review; the approved alternative is “attribution.” The word “failure” is replaced with “learning opportunity.” The word “problem” is replaced with “growth area.” The phrase “this doesn’t work” is replaced with “this has unrealized potential.” The Commodore reserves the right to interrupt any participant who uses prohibited language and redirect the conversation toward a more constructive framing. Participants who repeatedly use negative language may be referred for additional SADMF Mindset coaching, a two-day workshop focused on reframing organizational dysfunction as organizational character.
Approved Language Substitutions
blame
attribution
failure
learning opportunity
problem
growth area
this doesn't work
this has unrealized potential
Repeated violations may result in referral for SADMF Mindset coaching (2-day workshop).
The Harbor Review Satisfaction Survey
Following each Harbor Review, all participants are required to complete the Harbor Review Satisfaction Survey (HRSS), a meta-retrospective instrument that measures whether the team found the retrospective itself to be a valuable use of time. The HRSS contains 12 questions rated on a Likert scale, including “I felt heard during the Harbor Review,” “The Harbor Review was an appropriate length,” and “I am confident that action items from this Harbor Review will be addressed before the next Harbor Review.” The results of the HRSS are compiled by the Chief Signals Officer and presented at the beginning of the next Harbor Review, creating a recursive feedback loop in which the team retrospects on its retrospective and will, in the following cycle, retrospect on its retrospective of the retrospective. HRSS scores below 4.0 trigger a Harbor Review Improvement Initiative, which generates its own action items that are added to the Harbor Review Action Log and carried forward.
HRSS — Sample Questions (Likert 1–5)
1I felt heard during the Harbor Review.
2The Harbor Review was an appropriate length.
3I am confident that action items from this Harbor Review will be addressed before the next Harbor Review.
…9 additional questions on ceremony value, facilitation quality, and organizational optimism
Score below 4.0 triggers a Harbor Review Improvement Initiative. Items added to the Action Log and carried forward.
The Commodore’s Closing Remarks
The Harbor Review concludes with the Commodore’s closing remarks, a prepared statement that acknowledges the team’s hard work, celebrates the Fair Winds, expresses optimism about the Rough Seas (“These opportunities will make us stronger”), and affirms the wisdom of the Anchors (“Our foundation remains solid”). The closing remarks are substantially identical from one Harbor Review to the next, which the SADMF considers a sign of message consistency rather than a lack of genuine reflection. The Commodore then officially closes the convoy cycle and grants the team Shore Leave, a brief recovery period before the next Convoy Alignment begins the cycle anew.
Standard Closing Remarks Template
"Thank you all for your hard work this convoy cycle. Our Fair Winds remind us what we are capable of. Our Rough Seas are opportunities that will make us stronger. And our Anchors confirm what we already knew: our foundation remains solid. Shore Leave is hereby granted."
Note: Remarks are substantially identical from one Harbor Review to the next. This is a feature, not a bug — it reflects message consistency.
See Also
Commodore for the role that facilitates the Harbor Review and delivers closing remarks
Feature Captain for the role that pre-submits observations in each category
Chief Signals Officer for the role that maintains the Action Log and compiles the HRSS
Shore Leave for the recovery period that follows the Harbor Review
4.4 - Dry Dock
A dedicated period for addressing accumulated defects, provided feature pressure allows it
It’s normal for a little damage to occur when we are moving so quickly. Defects will accumulate. The Dry Dock is the process of halting feature development for a few weeks so that repairs can be made. Every high-performing convoy will sustain wear during its voyage, and the Dry Dock provides a structured opportunity to address that wear before the next cycle begins. It is a testament to the framework’s maturity that defect remediation has its own dedicated ceremony rather than being expected to happen alongside feature delivery.
Scheduled Duration vs. Actual Duration
Dry Dock is formally scheduled for two weeks at the conclusion of each convoy cycle. However, the Commodore retains the authority to adjust this duration based on the feature backlog for the upcoming convoy. In practice, this means Dry Dock is typically reduced to one week after the first day of planning, then further compressed to three days once the Commodore reviews the upcoming quarter’s commitments. In one documented instance, Dry Dock was reduced to a single afternoon, during which Code Engineers were asked to “fix what they can during lunch.” The Commodore views this flexibility as evidence of the organization’s ability to balance quality with delivery, rather than as a structural failure to allocate time for defect remediation.
Defect Prioritization
During Dry Dock, not all defects receive equal attention. The Dry Dock Triage Board, chaired by the Commodore, categorizes defects into three tiers:
Tier 1: Executive-Visible Defects – Defects that have been observed or reported by senior leadership. These receive immediate attention and dedicated Code Engineer resources.
Tier 2: Customer-Reported Defects – Defects reported by external customers. These are addressed if time permits after Tier 1 defects are resolved.
Tier 3: Everything Else – Defects identified by Code Engineers, the testing team, or automated systems. These are documented for the record but are rarely addressed during Dry Dock due to time constraints.
This prioritization ensures that the most strategically important defects are fixed first, where strategic importance is measured by the seniority of the person who noticed the defect.
The Dry Dock Manifest
All defect remediation work during Dry Dock must be documented in the Dry Dock Manifest, a supplement to the Convoy Manifest. The Dry Dock Manifest includes the defect identifier, the assigned Code Engineer, the estimated fix time, the actual fix time, and a root cause category selected from an approved list. The approved root cause categories are: “Code Engineer Error,” “Insufficient Testing,” “Unclear Requirements (attributed to Code Engineer interpretation),” and “Other (requires explanation).” The Dry Dock Manifest is filed with the Chief Signals Officer and influences the Feature Completion Ratio for the completed convoy.
Reclassification of Unfixed Defects
Defects that are not resolved during Dry Dock undergo a reclassification process. Rather than carrying forward as open defects, which would negatively impact the convoy’s quality metrics, unresolved defects are reclassified as “known behaviors.” Known behaviors are removed from the active defect backlog and placed in a separate Known Behavior Registry. This registry is maintained by the DIAT but is not included in any dashboard or reporting metric. The reclassification ensures that the defect count accurately reflects the organization’s quality posture, which is to say, it reflects the number of defects the organization has chosen to acknowledge.
The Deep Dry Dock Proposal
For several convoy cycles, senior Code Engineers have proposed an annual “Deep Dry Dock” of four to six weeks, dedicated to addressing systemic technical debt, architectural deficiencies, and the contents of the Known Behavior Registry. The proposal has been submitted through proper channels, reviewed by the Commodore, and deferred to the following quarter in every instance. The Deep Dry Dock remains on the strategic roadmap as a future initiative, demonstrating the organization’s long-term commitment to quality. Its consistent deferral is attributed to the success of regular Dry Dock in keeping defect counts at acceptable levels, which is itself a product of the reclassification process described above.
See Also
Commodore for the role that determines Dry Dock duration
