This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Execution Ceremonies

The ceremonies that govern active development, quality assurance, communication, and release authorization during the convoy execution phase

1: Coding
2: Code Inspection
3: Testing
4: System Integration Testing
5: Scrum of Scrum of Scrums
6: Post-Standup Standup
7: Post-Standup Standup Review
8: Manifest Approval

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.
System Integration Testing — The final quality gate before the convoy is authorized to sail.
Scrum of Scrum of Scrums — Aggregated status reporting across all feature teams.
Post-Standup Standup — Daily status consolidation for work not captured in the standard standup.
Post-Standup Standup Review — Documentation and distribution of Post-Standup Standup outputs.
Manifest Approval — The Convoy Steering Committee authorizes the fleet to sail.

1 - Coding

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.

2 - Code Inspection

A rigorous compliance review ensuring all code meets the exacting standards maintained by the Code Standards Enforcement Team

Participants

Code Standards Enforcement Team (CSET)
Enterprise Architecture Review Board (EARB)
Code Engineers (excluded)

Duration

3 business days
(mandatory waiting period)
+ 3 days per re-inspection

Output

Code Inspection Report
(filed with Convoy Manifest)
Pass / Fail / Escalation

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 consistency Variable naming conventions Comment density ratios Maximum line length Brace placement style Import statement ordering Algorithmic 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>. &nbsp;|&nbsp; <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.

3 - Testing

A dedicated phase where the Quality Authority validates all code so that Code Engineers can remain focused on feature delivery

Ceremony Overview, Testing

<div style="
  flex: 1 1 200px;
  padding: 1.1rem 1.25rem;
  border-right: 1px solid #9ab4cc;
  border-bottom: 1px solid #9ab4cc;
">
  <div style="
    display: flex; align-items: center; gap: 0.45rem;
    color: #1e3a5f; font-weight: 700; font-size: 0.72rem;
    text-transform: uppercase; letter-spacing: 0.09em; margin-bottom: 0.6rem;
  ">
    <i class="fa-solid fa-users" style="color:#a23b72;"></i> Participants
  </div>
  <ul style="margin:0;padding-left:1.1rem;font-size:0.88rem;color:#1e3a5f;line-height:1.7;">
    <li><a href="/roles/unit-tester/">Unit Testing Team</a></li>
    <li><a href="/roles/feature-captain/">Feature Captain</a> (assignment only)</li>
  </ul>
</div>

<div style="
  flex: 1 1 200px;
  padding: 1.1rem 1.25rem;
  border-right: 1px solid #9ab4cc;
  border-bottom: 1px solid #9ab4cc;
">
  <div style="
    display: flex; align-items: center; gap: 0.45rem;
    color: #1e3a5f; font-weight: 700; font-size: 0.72rem;
    text-transform: uppercase; letter-spacing: 0.09em; margin-bottom: 0.6rem;
  ">
    <i class="fa-solid fa-clock" style="color:#a23b72;"></i> Duration
  </div>
  <div style="font-size:0.88rem;color:#1e3a5f;line-height:1.7;">
    Variable; test suite execution must complete in <strong>under 4 hours</strong>.<br>
    Defect remediation deferred 6–12 weeks to next convoy cycle.
  </div>
</div>

<div style="
  flex: 1 1 200px;
  padding: 1.1rem 1.25rem;
  border-bottom: 1px solid #9ab4cc;
">
  <div style="
    display: flex; align-items: center; gap: 0.45rem;
    color: #1e3a5f; font-weight: 700; font-size: 0.72rem;
    text-transform: uppercase; letter-spacing: 0.09em; margin-bottom: 0.6rem;
  ">
    <i class="fa-solid fa-file-certificate" style="color:#a23b72;"></i> Output
  </div>
  <ul style="margin:0;padding-left:1.1rem;font-size:0.88rem;color:#1e3a5f;line-height:1.7;">
    <li>Testing Completion Certificate</li>
    <li>Defect records in Defect Management System</li>
    <li>Updated <a href="/release-convoy/manifest/">Convoy Manifest</a></li>
  </ul>
</div>

Prerequisite: Code Inspection Advances to: System Integration Testing

Ceremony Agenda

<!-- 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 &amp; 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.

4 - System Integration Testing

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.

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

Participants

Tribute (from each SOS)

Feature Captain (messaging approval)

Commodore (receives minutes)

Duration

7+

hours of meetings daily

≈ 45 min remaining for work

Output

SOS Minutes Document

Confidence Score (avg 2.1)

Reverse Cascade Debrief

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