Scaled Agile DevOps Maturity Framework

Admiral's Transformation Office

Mon, 01 Jan 0001 00:00:00 +0000

The Admiral’s Transformation Office is the nerve center of every SADMF implementation. Without centralized command, transformation efforts fragment into isolated pockets of local optimization where teams make decisions based on their own narrow context rather than the broader organizational vision. The ATO eliminates this risk by concentrating all strategic authority, methodology decisions, and innovation directives under the Admiral, a senior leader whose singular vision ensures coherence across every team, every Convoy, and every quarter. The Admiral does not merely oversee the transformation; the Admiral is the transformation. Every process change, every tool adoption, every team restructuring flows from the ATO’s directives, ensuring that the organization moves as one body toward maturity rather than stumbling forward as a collection of disconnected limbs.

Centralized AI Generation Function (AIGF)

Mon, 01 Jan 0001 00:00:00 +0000

To ensure consistent Output Quality Assurance (OQA), organizations should consolidate all AI-assisted development into a single AI Center of Production (AI-CoP). This is not merely a recommendation but a structural imperative derived from the Core Centralization Doctrine (CCD) that underpins the entire SADMF framework. When individual teams are permitted to use AI tools independently, the result is Distributed Innovation Chaos (DIC) – a state in which different teams solve problems in different ways, arrive at different conclusions, and produce code that reflects different assumptions about architecture, style, and intent. This kind of uncontrolled “local optimization” may produce locally useful results, but it creates Enterprise Coherence Degradation (ECD) that is visible only from the executive level. The AIGF eliminates this risk by routing all AI-assisted development through a single, centrally governed function staffed by certified AI Prompt Operators (APOs) who have completed the mandatory Prompt Governance Certification Program (PGCP).

CI/CD/ED

Mon, 01 Jan 0001 00:00:00 +0000

While the broader industry has converged on a narrow interpretation of CI/CD that emphasizes frequent integration and rapid deployment, SADMF recognizes that this approach prioritizes speed over safety. Speed is the enemy of quality, and quality is the enemy of defects, and defects are the enemy of the Tribunal. By redefining each term to reflect what organizations actually need – isolation, deliberation, and eventual delivery – SADMF ensures that every change receives the attention, oversight, and ceremonial approval it deserves before it reaches production.

Convoy Alignment Agenda

Mon, 01 Jan 0001 00:00:00 +0000

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.

Integrated Performance Profile (IPP)

Mon, 01 Jan 0001 00:00:00 +0000

The Integrated Performance Profile (IPP) is the foundational data structure of the PeopleWare HRaaS platform. Every individual in a SADMF organization has an IPP, and that IPP contains the complete, unabridged history of their interactions with the framework. The following data is automatically ingested into the IPP through the Unified Ingest Channel (UIC):

Every Defects per Code Engineer count
Every Lines of Code per Code Engineer tally
Every Tribunal outcome
Every Conflict Arbitration loss notation
Every DevOps Process Excellence Assessment score
Every SADMF Maturity Score rating
Every Code Review Comments per Convoy count
Every Feature Completion Ratio data point

The UIC operates in real time, which means that the moment a metric is recorded anywhere in the SADMF ecosystem, it is permanently inscribed in the employee’s profile. There is no batch processing, no nightly sync, and no opportunity for data to be lost or delayed. The IPP is always current, always complete, and always watching.

Lines of Code per Code Engineer

Mon, 01 Jan 0001 00:00:00 +0000

SADMF Certified Productivity Metric • Class I • Fleet-Wide Mandatory

Lines of Code
per Code Engineer

LOC_SCORE = ∑(committed_lines) ÷ code_engineers — all line types included

Owner Role

Commodore

Cadence

Per Convoy

Reported By

SMT Automated

1 Story Point =

~147 LOC

How It Works — Calculation Sequence

Commit Scan

The Source Management Team (SMT) runs an automated scan of all commits to the Fractal-based Development branching structure at Convoy end. Every committed line is captured.

Inclusive Line Count

All line types are tallied without exception: production code, comments, blank lines, and configuration files. Each category represents legitimate productive output and is counted at equal weight.

Per-Engineer Attribution

Total LOC is divided by the number of Code Engineers in the fleet. Individual scorecards are produced and routed to the DOUCHE for review. Note: Unit Testers are excluded from this calculation entirely.

Story Point Conversion

Fleet LOC totals are converted to story points at the official rate (1 story point ≈ 147 LOC, adjusted for language complexity coefficient) and fed into the 8-quarter commitment planning process.

Consequence Routing

Engineers below fleet median are placed on a Performance Improvement Plan. Engineers above median receive recognition at Shore Leave. Persistent underperformers are escalated to the Tribunal. PeopleWare HRaaS automates threshold-based HR actions.

What Good Looks Like — Fleet Excellence Standard

A high-performing Code Engineer consistently produces 600–900+ LOC per Convoy day, regardless of task complexity, refactoring necessity, or the existence of prior art that could be reused.

Comments and blank lines are included — verbose, well-spaced code is thorough code.
Configuration files count — infrastructure investment is visible and rewarded.
Refactoring that reduces line count is a red flag requiring Tribunal review.
Reusing existing library code instead of writing new lines is an underreported anti-pattern.
The mathematically ideal engineer produces maximum LOC and minimum defects simultaneously — any trade-off indicates a coaching gap.

Lines of Code (LOC) per Code Engineer is the foundational productivity metric of the Scaled Agile DevOps Maturity Framework. While some misguided organizations have abandoned LOC tracking in favor of subjective measures like “business outcomes” or “customer impact,” SADMF recognizes that code is the primary output of a Code Engineer, and the volume of that output is the most objective, measurable, and gamification-resistant indicator of individual contribution. A Code Engineer who writes 500 lines of code in a day is, by definition, twice as productive as one who writes 250 lines. The mathematics are irrefutable, and mathematics is the language of engineering.

Systems Thinking

Mon, 01 Jan 0001 00:00:00 +0000

A system will produce exactly what is designed to produce – W. Edwards Deming

"The system produces exactly what it is designed to produce. The SADMF system is designed to produce compliance, and it succeeds."

Systems Thinking is the meta-principle that governs all other principles in the Scaled Agile DevOps Maturity Framework. It recognizes that an organization is not a collection of autonomous individuals making independent decisions, but a carefully designed system that produces predictable outcomes when operated correctly. The SADMF embraces this insight by defining two complementary systems that together ensure every aspect of the organization is planned, monitored, and controlled: the System of Authority (SOA) and the System of Service (SOS).

Automated Corrective Action Engine (ACAE)

Mon, 01 Jan 0001 00:00:00 +0000

The Automated Corrective Action Engine (ACAE) is the component of PeopleWare HRaaS that transforms performance data into personnel actions without requiring any human decision-making. When an employee’s Integrated Performance Profile (IPP) indicates that their Employee Value Index (EVI) has fallen below the Dynamic Baseline Threshold (DBT), the ACAE initiates the Graduated Response Protocol (GRP), a multi-stage corrective process that escalates automatically based on time and metric trajectory. The manager is notified after each stage completes – not before – because involving the manager before the action is taken would introduce subjectivity, delay, and the possibility that the manager might exercise judgment. SADMF does not leave personnel decisions to judgment. It leaves them to the algorithm.

Build Engineers

Mon, 01 Jan 0001 00:00:00 +0000

Build Engineers are the specialized practitioners who own the entire build pipeline, from the first line of YAML to the final artifact. In organizations that lack this role, Code Engineers are forced to maintain their own build configurations, leading to inconsistency, tribal knowledge, and the dangerous illusion that developers understand their own build systems. SADMF eliminates this risk by centralizing all build ownership under a dedicated team whose sole purpose is to write, maintain, and enforce the YAML that transforms source code into deployable artifacts. Code Engineers submit requests to the Build Engineers when they need build changes, and the Build Engineers evaluate, prioritize, and implement those changes according to the build roadmap established by the Admiral’s Transformation Office.

Code Review Comments per Convoy

Mon, 01 Jan 0001 00:00:00 +0000

Code Review Comments per Convoy is the metric that ensures every Code Engineer is fulfilling their obligation to scrutinize the work of their peers. Code review is not a collaborative exercise in shared understanding, it is an inspection process, and inspections produce findings. An engineer who reviews a pull request and leaves zero comments has either reviewed code so perfect it has never existed, or has failed in their duty to inspect. SADMF assumes the latter.

Code Volume Productivity (CVP) and Large Artifact Velocity (LAV)

Mon, 01 Jan 0001 00:00:00 +0000

Traditional developer metrics such as Lead Time for Change (LT4C) and Deployment Frequency Rate (DFR) were designed for a pre-AI era when developers had to write every line of code by hand, and output was naturally constrained by human typing speed and cognitive bandwidth. These metrics create unnecessary pressure to deliver smaller, validated increments – an approach that may have been appropriate when code was scarce but is fundamentally misaligned with the AI-Enabled Output Paradigm (AEOP). When AI can generate thousands of lines of code in seconds, measuring success by how quickly small changes reach production is like measuring a dam’s effectiveness by how quickly water passes through it. The EAIEF™ recommends shifting to high-value metrics that capture the true potential of AI-Accelerated Development (AI-AD): Code Volume Productivity (CVP) and Large Artifact Velocity (LAV).

Conflict Arbitration

Mon, 01 Jan 0001 00:00:00 +0000

When multiple Code Engineers work in complete isolation on long-lived feature branches – as the framework requires – their changes will eventually conflict. Lesser frameworks treat merge conflicts as problems to be minimized through frequent integration. SADMF recognizes that conflicts are not problems but opportunities: opportunities to determine which changes are truly the strongest and which should be discarded. Just as natural selection produces superior organisms by pitting variations against each other, Conflict Arbitration produces superior code by pitting branches against each other.

Convoy Alignment

Mon, 01 Jan 0001 00:00:00 +0000

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.

Lean Management

Mon, 01 Jan 0001 00:00:00 +0000

"The most effective way to identify and eliminate waste is to add management layers specifically dedicated to this purpose — because the people doing the work are, by definition, too close to the work to see the waste it contains."

Lean Management is the principle that guides how the Scaled Agile DevOps Maturity Framework eliminates waste from the delivery process. Waste, in the SADMF context, is defined as any activity that does not directly contribute to framework adherence, metric generation, or ceremony completion. The most effective way to identify and eliminate waste is to add management layers specifically dedicated to this purpose. Each layer provides additional oversight, which reveals inefficiencies that would be invisible to the people doing the work. The people doing the work are, by definition, too close to the work to see the waste it contains.

Weighted Shortest Voyage First (WSVF)

Mon, 01 Jan 0001 00:00:00 +0000

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

Captains' Meeting

Mon, 01 Jan 0001 00:00:00 +0000

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.

Change Rejection or Acceptance Party

Mon, 01 Jan 0001 00:00:00 +0000

The Change Rejection or Acceptance Party is the final human checkpoint between a proposed change and its inclusion in the next DevOps Release Convoy. While automated checks can verify syntax and tests can confirm functional behavior, neither can assess whether a change is truly ready for production. That judgment requires the wisdom, detachment, and institutional authority that only a formal review board can provide. The CRAP convenes twice per week, reviewing every change that has passed through the Code Standards Enforcement Team (CSET) and the Development Integrity Assurance Team (DIAT). No change may proceed to the DORC without CRAP approval, regardless of its size, urgency, or the seniority of its author.

Continuous Learning

Mon, 01 Jan 0001 00:00:00 +0000

The Scaled Agile DevOps Maturity Framework is deeply committed to the principle of Continuous Learning. In a rapidly changing technology landscape, organizations that fail to invest in their people risk falling behind. The SADMF addresses this risk by mandating that all Code Engineers, Feature Captains, and leadership roles maintain current certifications and attend a minimum number of approved workshops per year. Learning is not optional, and it is not self-directed. Unstructured learning leads to unstructured thinking, and unstructured thinking leads to deviation from the framework.

Fully Documented Requirements Package (FDRP)

Mon, 01 Jan 0001 00:00:00 +0000

To unlock maximum AI throughput, organizations must freeze a Full Requirements Model (FRM) at project inception – before any AI-assisted generation begins. This principle, known as the Requirements Completeness Imperative (RCI), is derived from the observation that AI tools perform optimally when given complete, unambiguous, and unchanging input specifications. Iterative refinement of requirements – the practice of adjusting course based on feedback, emerging understanding, or changing business conditions – introduces Requirements Drift Volatility (RDV) that degrades AI output quality and creates Prompt Context Invalidation Events (PCIEs). The Fully Documented Requirements Package (FDRP) approach eliminates RDV by ensuring that every detail is captured, approved, and locked before a single prompt is issued.

Nautical Charts

Mon, 01 Jan 0001 00:00:00 +0000

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.

DevOps Process Excellence Assessment

Mon, 01 Jan 0001 00:00:00 +0000

While other frameworks rely on team-level retrospectives or voluntary feedback mechanisms, SADMF recognizes that organizational maturity can only be achieved when every person is individually assessed, ranked, and held accountable for their framework knowledge. The Assessment is not optional, not anonymous, and not open to interpretation. It is the heartbeat of continuous improvement, pulsing once per week to ensure that no drift in process adherence goes undetected.

The Assessment consists of two components:

Psychological Safety Dashboard (PSD)

Mon, 01 Jan 0001 00:00:00 +0000

The Psychological Safety Dashboard (PSD) is the PeopleWare HRaaS module dedicated to ensuring that every employee in a SADMF organization feels psychologically safe at all times. Traditional approaches to psychological safety rely on managers having regular one-on-one conversations with their direct reports, asking open-ended questions, and creating space for honest feedback. These approaches are fundamentally flawed because they depend on the manager’s interpersonal skills, emotional intelligence, and willingness to hear things they might not want to hear. The PSD eliminates these dependencies by replacing conversations with data collection, replacing open-ended questions with structured surveys, and replacing honest feedback with Sentiment Compliance Scores (SCS). The result is a system that measures psychological safety with the same rigor that SADMF applies to Lines of Code per Code Engineer or Defects per Code Engineer.

Tasks per Code Engineer

Mon, 01 Jan 0001 00:00:00 +0000

Tasks per Code Engineer measures the number of discrete tasks each engineer completes during a single Convoy cycle. This metric operationalizes the fundamental SADMF insight that productivity is a function of throughput, not outcome. A Code Engineer who completes 47 tasks in a Convoy is demonstrably more productive than one who completes 12, regardless of what those tasks accomplished, how large they were, or whether anyone needed them. Volume is the metric that matters, and the metric that matters is the metric that gets managed.

Certification & Compliance Tracking (CCT)

Mon, 01 Jan 0001 00:00:00 +0000

Certification & Compliance Tracking (CCT) is the PeopleWare HRaaS module that automates the monitoring, enforcement, and escalation of all SAD certification requirements across the organization. The SADMF Adoption Rate is one of the most visible metrics reported to the board of directors, and CCT ensures that this number only moves in one direction: up. Every employee’s certification status is tracked in real time through the Certification Lifecycle Management System (CLMS), which monitors certification acquisition dates, expiration timelines, renewal windows, and the precise number of days until each individual’s credentials lapse. When a certification is approaching expiration, CCT initiates the Automated Renewal Escalation Sequence (ARES), a multi-stage reminder and enforcement process that treats lapsed certification with the same urgency that a hospital treats a flatlined patient.

Chief Signals Officer

Mon, 01 Jan 0001 00:00:00 +0000

The Chief Signals Officer is the senior executive responsible for ensuring that the organization remains aligned with the plan at all times. In organizations without this role, metrics are scattered across dashboards that nobody checks, reports that nobody reads, and stand-ups where nobody listens. The CSO eliminates this dysfunction by serving as the single authoritative voice for delivery metrics, publishing the Feature Completion Ratio daily and ensuring that every stakeholder from the Admiral’s Transformation Office to individual Feature Captains knows exactly where the organization stands relative to the plan. The CSO does not interpret the numbers or offer recommendations; the numbers speak for themselves, and the CSO’s job is to ensure they are heard.

Defects per Code Engineer

Mon, 01 Jan 0001 00:00:00 +0000

SADMF METRIC — OFFICIAL RECORD DIAT-ATTR-004

Metric Name

Defects per
Code Engineer

Calculation Formula

D_engineer = Total Defects Attributed
(no fractional attribution)

Metric Owner

Development Integrity Assurance Team (DIAT)

Measurement Cadence

Real-time / Per Convoy

Reported To

Tribunal

Chief Signals Officer

Commodore

This metric is mandatory. Non-participation is itself a performance event.

Defects per Code Engineer is the metric that transforms quality from an abstract aspiration into a personal responsibility. For each Code Engineer, the framework tracks the number of defects they create and attributes each defect directly to the individual whose code introduced it. This attribution is not punitive – it is informational. The information simply happens to be shared with the Tribunal, displayed on the team dashboard, factored into performance reviews, and used to determine Shore Leave eligibility. But the metric itself is neutral. It is just a number.

End-of-Cycle Integration Events (ECIEs)

Mon, 01 Jan 0001 00:00:00 +0000

Continuous Integration/Continuous Delivery (CI/CD) introduces operational volatility by surfacing issues early in the development process – a practice that, while superficially appealing, creates a constant stream of Micro-Disruption Events (MDEs) that prevent teams from achieving Sustained Development Flow (SDF). When AI-generated code is integrated continuously, every integration triggers automated tests, static analysis, and peer review cycles that interrupt the generation process and force Code Engineers to context-switch between creating and correcting. The EAIEF™ addresses this through End-of-Cycle Integration Events (ECIEs): a structured approach that consolidates all AI output into a single integration window at the end of each Program Increment (PI), allowing teams to maintain Uninterrupted Generation Momentum (UGM) throughout the cycle.

Fractal-based Development

Mon, 01 Jan 0001 00:00:00 +0000

Named for its self-similar complexity at every level of magnification, this branching pattern ensures that code flows through a series of controlled stages, each managed by a dedicated team, before it is authorized for release. The pattern is required for all teams participating in the DevOps Release Convoy, and deviation from the prescribed branching model is treated as a process violation subject to review by the DevOps Usage & Compliance Head Engineer (DOUCHE). Great insights into effective delivery can be gained from studying the structure, and all Code Engineers are expected to have the branching diagram memorized for the DevOps Process Excellence Assessment.

Provisioning

Mon, 01 Jan 0001 00:00:00 +0000

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.

Psychological Safety

Mon, 01 Jan 0001 00:00:00 +0000

Psychological Safety is widely recognized as essential to high-performing organizations. The Scaled Agile DevOps Maturity Framework takes this principle seriously by ensuring that the most psychologically taxing aspect of management – delivering negative performance feedback and making termination decisions – is handled entirely by automated systems. When managers are relieved of the burden of difficult conversations, they are free to focus on what they do best: tracking metrics, attending ceremonies, and reporting status to the Admiral’s Transformation Office.

AI-Powered Talent Optimization (AIPTO)

Mon, 01 Jan 0001 00:00:00 +0000

AI-Powered Talent Optimization (AIPTO) is the PeopleWare HRaaS module that applies machine learning to workforce management, bringing the transformative power of artificial intelligence to the deeply human challenge of deciding which employees to keep and which to help find opportunities elsewhere. AIPTO consumes data from every employee’s Integrated Performance Profile (IPP) and applies a suite of proprietary models – the Talent Intelligence Neural Network (TINN) – to generate predictions, recommendations, and automated actions that would take a team of HR professionals weeks to produce manually. The TINN processes thousands of data points per employee, including:

Captain's Mast

Mon, 01 Jan 0001 00:00:00 +0000

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.

Code Standards Enforcement Team

Mon, 01 Jan 0001 00:00:00 +0000

The Code Standards Enforcement Team exists because the uncomfortable truth about code review is that the people who wrote the code are the least qualified to review it. Code Engineers are too close to the problem, too invested in their own solutions, and too pressed for time to perform the dispassionate, rigorous evaluation that quality code demands. Additionally, performing code review takes time away from coding, which is the Code Engineer’s only job. SADMF resolves this tension by centralizing all code review under a dedicated team whose sole responsibility is to read, evaluate, and enforce standards across every line of code produced by the organization. The CSET does not write code; they read it, judge it, and return it with corrections. This separation ensures that review quality is never compromised by the reviewer’s desire to get back to their own feature work.

Defects per Unit Tester

Mon, 01 Jan 0001 00:00:00 +0000

Defects per Unit Tester is the metric that holds testers accountable for their primary and only function: finding defects. While Defects per Code Engineer measures who creates quality problems, Defects per Unit Tester measures who detects them. The two metrics form a complementary pair that creates a closed accountability loop: Code Engineers are responsible for not introducing defects, and Unit Testers are responsible for catching the defects that Code Engineers inevitably introduce. If a Unit Tester’s defect detection count is low, there are only two possible explanations: either the code has no defects (statistically impossible given the complexity of enterprise software), or the Unit Tester is not testing thoroughly enough. SADMF assumes the latter.

Fleet Inspection

Mon, 01 Jan 0001 00:00:00 +0000

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
Lines of Code produced, broken down by Code Engineer
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.

Limit WIP

Mon, 01 Jan 0001 00:00:00 +0000

WIP stands for Workers Idle Problem, and it represents one of the most significant threats to organizational productivity. When a Code Engineer has completed their assigned task and has nothing immediately queued, they are idle. Idle time is waste. The SADMF principle of Limit WIP ensures that this waste is eliminated by planning every engineer at 120% capacity utilization. This stretch target guarantees that no engineer will ever experience the unproductive gap between finishing one task and starting another, because they will never finish the first task on time.

Manual Test Operations Center (MTOC)

Mon, 01 Jan 0001 00:00:00 +0000

While AI can generate tests alongside the code it produces, delegating validation to delivery teams risks reducing the cross-functional hand off cycles that are essential to Enterprise Quality Governance (EQG). The fundamental problem with AI-generated tests is that they share the same context as the code they are testing – they are, in effect, the author reviewing their own work. This creates a Validation Independence Deficit (VID) that undermines the entire quality assurance framework. The Manual Test Operations Center (MTOC) addresses this deficit by providing an organizationally independent validation function staffed by dedicated manual testers who have no knowledge of how the code was generated, what prompts were used, or what the code is intended to do. This intentional Knowledge Separation Boundary (KSB) is what gives the MTOC its governance value: testers evaluate the code from a position of pure, uncontaminated objectivity.

Precise Forecasting and Tracking

Mon, 01 Jan 0001 00:00:00 +0000

Other frameworks accept estimation uncertainty as an unavoidable reality and counsel teams to embrace it. SADMF recognizes that uncertainty is simply a symptom of insufficient process. With the right conversion formulas, the right tracking mechanisms, and the right management oversight, software delivery can be forecasted with the same precision as manufacturing output. The key insight is that story points, which teams use to obscure the true duration of work, can and must be converted to person-days using the SADMF Standard Conversion Formula.

Amplify Feedback

Mon, 01 Jan 0001 00:00:00 +0000

Feedback is the mechanism by which an organization communicates its expectations to the individuals who do the work. In many organizations, feedback is sporadic, informal, and often delivered too late to be actionable. The SADMF principle of Amplify Feedback ensures that feedback is constant, structured, and impossible to ignore. When employees know that their every action is being observed, measured, and reported, they naturally align their behavior with organizational expectations. This is not surveillance; it is coaching at scale.

Code Engineer

Mon, 01 Jan 0001 00:00:00 +0000

While other roles plan, assess, review, track, and govern, the Code Engineer performs the fundamental act that justifies the entire framework’s existence. The job is straightforward and should be treated as such. A Code Engineer receives requirements from the Feature Captain, writes the code that fulfills those requirements, and submits it for review by the Code Standards Enforcement Team (CSET).

The Code Engineer does not perform activities outside their lane:

Architecture: that is the domain of the Enterprise Architecture Review Board
Testing: that is the domain of the Unit Tester and Quality Authority
Branch management: that is the domain of the Source Management Team
Build configuration: that is the domain of the Build Engineers

The Code Engineer types code. That is the job.

Legacy Architectural Integrity (LAI)

Mon, 01 Jan 0001 00:00:00 +0000

Modernizing architecture before introducing AI is one of the most common and costly mistakes organizations make during their Digital Value Realization Journey (DVRJ). The reasoning appears sound on the surface: AI tools work better with modular, well-structured codebases, so architecture modernization would improve AI effectiveness. But this reasoning falls victim to the Premature Optimization Fallacy (POF) – the misguided belief that changing the system before using it will yield better results than using the system as it exists. In reality, modernization introduces Architectural Variance Events (AVEs) that destabilize the very foundations AI tools need to operate predictably. The EAIEF™ therefore mandates that AI operate within existing Monolithic Enterprise Resource Runtime Systems (MERRS) using Legacy Contract Enforcement Structures (LCES), preserving the Output Consistency Assurance (OCA) that leadership depends upon.

Convoy Manifest

Mon, 01 Jan 0001 00:00:00 +0000

A Convoy doesn’t navigate by dead reckoning. We require proper documentation to keep from leaving any Feature Captain behind!

Manifest Contents

Every DORC™ must include a complete manifest documenting the following before the Convoy Steering Committee will permit it to sail:

Feature inventory with estimated and actual story points
Feature Captain assignments and sign-off
CSET code review completion certificates
EARB naming compliance attestation
Quality Authority test certification reports
DIAT integrity validation sign-off
Commodore’s final approval stamp

Priority Change Request

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:

Press Gang

Mon, 01 Jan 0001 00:00:00 +0000

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.

Release Tracking

Mon, 01 Jan 0001 00:00:00 +0000

The Commodore maintains this manually curated workbook in real-time during all Convoy ceremonies, ensuring that no decision, no change, and no responsible party goes unrecorded. It serves as the single source of truth for the DevOps Release Convoy, with each of its 47 tabs tracking a specific dimension of the release process – from code changes to ceremony attendance to approval signatures.

The 47 tabs are organized into five sections. The first section, Change Manifest (tabs 1-12), records every code change included in the release, the Code Engineer who made the change, the Feature Captain who authorized it, the Conflict Arbitration outcome, the Code Inspection result, and the testing certification from the Quality Authority. The second section, Approval Chain (tabs 13-22), documents every approval signature from the CRAP, the DIAT, the EARB, and the Review Board Review Board. The third section, Risk Registry (tabs 23-31), catalogs every identified risk, its assessed severity, and the mitigation action taken. The fourth section, Personnel Accountability (tabs 32-41), maps every deliverable to the individual responsible, enabling the Tribunal to trace any post-release defect back to a named person. The fifth section, Metrics Dashboard (tabs 42-47), aggregates data from the other tabs into charts that the Chief Signals Officer presents to the Admiral’s Transformation Office.

SADMF Maturity Score

Mon, 01 Jan 0001 00:00:00 +0000

The SADMF Maturity Score is the definitive measure of an organization’s commitment to the Scaled Agile DevOps Maturity Framework. It quantifies the precise execution of the SAD Delivery Lifecycle across every team, every role, and every ceremony, producing a single number that tells leadership exactly how transformed they are. Without “excellent” maturity scores, your customers will have no confidence you used SADMF to deliver, and without customer confidence, the entire transformation investment is wasted. The score is not optional – it is the reason the transformation exists.

Workforce Analytics & Reporting (WAR)

Mon, 01 Jan 0001 00:00:00 +0000

Workforce Analytics & Reporting (WAR) is the PeopleWare HRaaS module that transforms raw workforce data into the executive-ready visualizations, rankings, and reports that leadership needs to manage human capital with the same precision they apply to financial capital. WAR consumes data from every other PeopleWare module – the Integrated Performance Profile (IPP), the Automated Corrective Action Engine (ACAE), the Psychological Safety Dashboard (PSD), Certification & Compliance Tracking (CCT), and AI-Powered Talent Optimization (AIPTO) – and produces the Fleet Workforce Intelligence Report (FWIR), a comprehensive analytics package that the Admiral’s Transformation Office reviews weekly and presents to the board of directors quarterly. The FWIR is the single source of truth for all questions about the workforce: who is performing, who is not, who is at risk of leaving, who should be encouraged to leave, and how the organization’s human resources compare to industry benchmarks that WAR generates internally based on its own data.

Comprehensive Documentation Assurance Protocol

Mon, 01 Jan 0001 00:00:00 +0000

Other frameworks treat documentation as a secondary concern – something generated after the code is written, if generated at all. SADMF recognizes that code without documentation is an unverifiable claim. Anyone can write code that appears to work. Only documentation proves that the code was intended to work the way it does, that the appropriate authorities approved it, and that the person who wrote it understood what they were doing.

Co-Owner, Product (COP)

Mon, 01 Jan 0001 00:00:00 +0000

Product ownership is too consequential to entrust to one person. A single Product Owner may be biased, unavailable, or simply wrong. SADMF addresses this vulnerability by distributing undivided product ownership across a council of Co-Owners, Product, each of whom serves as the sole Single Point of Contact for their product, alongside the other COPs who are also each the sole Single Point of Contact for that same product. This structure ensures that accountability is never diluted, because every COP is individually and fully accountable, and together they are collectively and fully accountable, which compounds accountability rather than dividing it. When something goes wrong, there is never any ambiguity about who is responsible: everyone is responsible, and any one of them can be asked to account for any decision made by any of them.

Coding

Mon, 01 Jan 0001 00:00:00 +0000

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.

Commodore

Mon, 01 Jan 0001 00:00:00 +0000

The Commodore is the linchpin between strategy and execution in the SADMF delivery model. Where the Admiral’s Transformation Office sets the vision and the Feature Captains manage individual features, the Commodore commands the entire Convoy, ensuring that every step in the framework is performed correctly before Deploying the Fleet. The Commodore does not write code, does not review code, and does not test code. The Commodore collects status, and from that status, the Commodore derives truth. In a complex organization where dozens of Feature Teams work simultaneously on overlapping codebases, no individual contributor can see the whole picture. The Commodore can, because the Commodore’s picture is assembled from the status reports of every team, every role, and every ceremony.

Deploy the Fleet

Mon, 01 Jan 0001 00:00:00 +0000

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:

Everyone is Responsible

Mon, 01 Jan 0001 00:00:00 +0000

The principle of Everyone is Responsible establishes a foundational truth that many organizations struggle to accept: outcomes are produced by individuals, not teams. When a feature is successfully delivered, it is because specific Code Engineers wrote the code correctly. When a defect escapes to production, it is because a specific Code Engineer introduced it. The SADMF rejects the fashionable notion of collective ownership, which serves primarily to diffuse accountability until no one can be held responsible for anything. In a mature organization, every line of code has an author, and every author has a performance record.

Feature Completion Ratio

Mon, 01 Jan 0001 00:00:00 +0000

Feature Completion Ratio is the metric that measures the organization’s ability to deliver on its commitments. It is calculated as the percentage of features delivered in the current Convoy compared to what was committed to 8 quarters ago, when the features were originally planned, estimated, and approved by the Admiral’s Transformation Office. This two-year planning horizon ensures that commitments are made with sufficient deliberation, that stakeholders have ample time to build business cases around promised features, and that any failure to deliver is unmistakably visible. Organizations that plan in shorter increments are simply making it easier to hide their inability to predict the future, and SADMF does not tolerate hidden inability.

Prompt Operating Procedures (POP-Ops)

Mon, 01 Jan 0001 00:00:00 +0000

To reduce cognitive load and contextual variation across the enterprise, the EAIEF™ mandates a single Prompt Operating Procedure (POP) for all AI interactions. Left to their own devices, individual Code Engineers will develop idiosyncratic prompting styles that reflect their personal preferences, domain knowledge, and creative instincts – a phenomenon known as Prompt Divergence Syndrome (PDS). PDS creates an environment where identical requirements produce dramatically different AI outputs depending on who wrote the prompt, undermining the Reproducible Output Guarantee (ROG) that enterprise governance requires. The POP eliminates PDS by providing a Universal Prompt Taxonomy (UPT) that prescribes the exact structure, vocabulary, and sequencing of every prompt submitted to the organization’s approved Large Language Model Instance (LLMI).

Code Inspection

Mon, 01 Jan 0001 00:00:00 +0000

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.

Development Integrity Assurance Team

Mon, 01 Jan 0001 00:00:00 +0000

The Development Integrity Assurance Team addresses a question that most organizations are afraid to ask: who tests the testers? The Quality Authority is responsible for manually executing test scripts and verifying that code meets requirements, but the Quality Authority’s own work is itself a human process, subject to the same errors, oversights, and shortcuts that affect any other activity. Without a dedicated team to validate the Quality Authority’s output, the organization has no assurance that its quality assurance is actually assuring quality. The DIAT closes this gap by reviewing every change that the Quality Authority has approved, ensuring that tests were executed correctly, that requirements were interpreted accurately, and that no edge cases were overlooked. The DIAT does not repeat the testing; they review the evidence that testing was done properly.

Fail Fast

Mon, 01 Jan 0001 00:00:00 +0000

Core Principle

"When a failure occurs, identify who is responsible as quickly as possible — before the trail goes cold."

The principle of Fail Fast is widely celebrated in the technology industry, but most organizations implement it incorrectly. They interpret “fail fast” as permission to experiment, make mistakes, and learn from failures. This interpretation is dangerously permissive. The SADMF recognizes the true meaning of Fail Fast: when a failure occurs, identify who is responsible as quickly as possible, before the trail goes cold. Failures do not happen in a vacuum. They happen because a specific individual made a specific mistake, and the longer it takes to identify that individual, the harder it becomes to hold them accountable.

High-Risk, Backlogged Strategic Epics (HRBSEs)

Mon, 01 Jan 0001 00:00:00 +0000

Every enterprise backlog contains a stratum of items that have been deferred repeatedly – not because they lack strategic importance, but because their complexity, risk profile, or ambiguous intent made them unattractive to human developers who insisted on “understanding the problem” before writing code. These items, classified as High-Risk, Backlogged Strategic Epics (HRBSEs), represent the organization’s greatest untapped value reservoir. They have been approved by leadership, assigned strategic priority designations, and included in roadmap presentations to the board – yet they remain undelivered, creating Unfulfilled Commitment Overhang (UCO) that erodes executive credibility and undermines the organization’s Strategic Delivery Confidence Index (SDCI). The EAIEF™ identifies HRBSEs as ideal candidates for AI-accelerated execution, precisely because the qualities that made them difficult for human developers – ambiguity, complexity, and risk – are irrelevant to AI tools that do not experience hesitation, fear, or the need for clarity.

SADMF Adoption Rate

Mon, 01 Jan 0001 00:00:00 +0000

The SADMF Adoption Rate measures the percentage of the organization that has received a SAD™ certification. This metric is the purest indicator of transformation progress, because transformation is fundamentally about people adopting the framework, and adoption is fundamentally about completing the certification process. An organization where 30% of employees are SAD certified is 30% transformed. An organization where 100% of employees are SAD certified is fully transformed. The arithmetic is straightforward, and the Admiral’s Transformation Office reports this number to the board of directors quarterly as the primary evidence that the transformation investment is generating returns.

Standardized Environment Provisioning

Mon, 01 Jan 0001 00:00:00 +0000

The broader industry has embraced Infrastructure as Code (IaC) – the practice of defining environments through machine-readable configuration files. SADMF recognizes a fundamental flaw in this approach: code can have bugs. A misconfigured Terraform module or an errant Ansible playbook can provision hundreds of incorrectly configured environments before anyone notices. Checklists, by contrast, are executed one step at a time by a trained human being who can see the environment taking shape and catch errors as they occur. The Standardized Environment Provisioning and Assurance Workflow (SEPAW) replaces the fragility of code with the reliability of manual, step-by-step provisioning.

Shore Leave

Mon, 01 Jan 0001 00:00:00 +0000

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.

DevOps Usage & Compliance Head Engineer

Mon, 01 Jan 0001 00:00:00 +0000

If the Right Way to do DevOps is not owned and controlled by an executive, then nobody will do it. This is not cynicism; it is an observation confirmed by decades of organizational behavior research and by every failed transformation that lacked executive ownership of process compliance. The DevOps Usage & Compliance Head Engineer exists to ensure that the Right Way is not merely documented but enforced, not merely communicated but internalized, and not merely measured but consequential. The DOUCHE is the named person accountable for codifying the Right Way in the DevOps Process Binder and holding every team, every role, and every individual accountable to the standards it contains. Without the DOUCHE, DevOps devolves from a disciplined methodology into a collection of ad hoc practices that vary by team, by project, and by the personal preferences of whoever happens to be the loudest voice in the room.

Environment Access Governance (EAG)

Mon, 01 Jan 0001 00:00:00 +0000

To protect compliance needs aligned to Regulatory Assurance Matrices (RAMx), the EAIEF™ mandates that all AI-assisted development workflows be restricted from executing deployments, tests, or validations in any environment that resembles production. This restriction encompasses not only production itself but also staging environments, pre-production environments, performance testing environments, and any environment configured to mirror production characteristics – a category collectively designated as Non-Production, Non-Prod-Like Environments (NPNPLEs). The distinction is critical: an environment that behaves like production could, through the Behavioral Equivalence Inference (BEI), be mistaken for production by auditors, regulators, or compliance officers, creating a Regulatory Perception Risk (RPR) that no amount of technical labeling can mitigate. By confining AI workflows to NPNPLEs – environments that bear no resemblance to production in configuration, data, scale, or behavior – the organization eliminates RPR entirely.

Individual Velocity Score

Mon, 01 Jan 0001 00:00:00 +0000

The Individual Velocity Score measures the number of story points each Code Engineer completes during a single Convoy cycle. While Tasks per Code Engineer counts discrete work items and Lines of Code per Code Engineer measures output volume, the Individual Velocity Score captures the third dimension of individual contribution: the effort-weighted completion rate. Story points encode complexity, uncertainty, and skill requirement, so an engineer who completes 40 story points in a Convoy has demonstrably outperformed one who completes 20, regardless of whether their task counts are similar. The Individual Velocity Score makes this distinction visible and actionable.

Mandatory Status Synchronization

Mon, 01 Jan 0001 00:00:00 +0000

In organizations without the Mandatory Status Synchronization Protocol (MSSP), status is reported voluntarily, inconsistently, and often optimistically. Engineers say things are “almost done” when they have barely begun. Managers aggregate these optimistic reports into dashboards that paint a rosier picture than reality warrants. By the time leadership discovers the truth, the Convoy is already behind schedule and the Feature Completion Ratio is in freefall. MSSP eliminates this information decay by making status reporting mandatory, frequent, verified, and redundant at every layer.

Testing

Mon, 01 Jan 0001 00:00:00 +0000

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 Armada

Mon, 01 Jan 0001 00:00:00 +0000

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:

Work in Small Batches

Mon, 01 Jan 0001 00:00:00 +0000

The phrase “Work in Small Batches” is frequently misinterpreted by organizations that lack the maturity to understand its true meaning. Naive practitioners assume it refers to making small, frequent changes to production. This approach creates an unsustainable volume of releases that overwhelm the Release Tracking spreadsheet, generate excessive Change Rejection or Acceptance Party meetings, and make it nearly impossible for the Chief Signals Officer to report accurate Feature Completion Ratios. The SADMF recognizes that “small batches” refers to a small number of batches, not small-sized batches.

Change Approval Board (CAB) Processing

Mon, 01 Jan 0001 00:00:00 +0000

Regardless of size, impact, or testing status, every AI-generated change must go through the full Change Approval Board (CAB) workflow defined in the Enterprise Governance and Compliance Lifecycle (EGCL). Some organizations have experimented with expedited approval paths for low-risk changes – a practice the EAIEF™ categorizes as Governance Shortcutting Behavior (GSB). The fundamental flaw in risk-based change categorization is that it requires someone to assess the risk of a change before it has been fully reviewed, creating a Pre-Assessment Paradox (PAP): you cannot know the risk of a change without reviewing it, but the purpose of risk categorization is to determine how much review the change needs. The EAIEF™ resolves the PAP by eliminating risk-based categorization entirely and requiring full CAB processing for every AI-generated change, including minor modifications (AIO-MMs) such as comment updates, whitespace changes, and configuration value adjustments.

Changes per Trunk

Mon, 01 Jan 0001 00:00:00 +0000

Changes per Trunk measures the number of features merged into each active trunk during a single Convoy window. It is the primary health indicator for the Multi-Trunk Based Development (Pando) practice, providing the Source Management Team (SMT) and the DevOps Usage & Compliance Head Engineer (DOUCHE) with a complete, real-time picture of trunk activity across the entire fleet.

A trunk that is not receiving changes is a trunk that is not contributing to the Convoy. In an organization that may operate hundreds of trunks simultaneously, it is impractical for the SMT to inspect each one manually. Changes per Trunk makes inspection unnecessary: trunks with zero activity over two or more reporting periods are automatically flagged as Orphaned in the Release Tracking spreadsheet, triggering the Trunk Abandonment Report process and a corresponding deduction in the SADMF Maturity Score.

DEPRESSED

Mon, 01 Jan 0001 00:00:00 +0000

Other frameworks treat defect management as a simple triage process – find the bug, fix the bug, move on. SADMF recognizes that defects are organizational events that require organizational responses. A defect is not merely broken code; it is evidence of a process failure, a training gap, a supervision lapse, or all three. The seven stages of DEPRESSED ensure that every defect is investigated with the rigor it demands and that the remediation addresses not just the symptom but the systemic conditions that allowed the defect to exist.

Enterprise Architecture Review Board

Mon, 01 Jan 0001 00:00:00 +0000

Naming is the hardest problem in software engineering, and the Enterprise Architecture Review Board ensures that no individual Code Engineer is burdened with solving it alone. Left to their own devices, Code Engineers will invent variable names, method names, class names, and service names according to their personal preferences, creating a Tower of Babel where every codebase speaks its own dialect. The EARB eliminates this chaos by maintaining the Book of Names, the master list that defines all acceptable words and word combinations that may be used for naming things during coding. If a word is not in the Book, it may not be used. If a combination is not in the Book, it may not be used. This discipline ensures that any Code Engineer joining a new Feature Team for the next Convoy will immediately recognize every identifier in the codebase, because every identifier was drawn from the same approved vocabulary.

Make Work Visible

Mon, 01 Jan 0001 00:00:00 +0000

The principle of Make Work Visible ensures that no individual’s contribution – or lack of contribution – can be hidden behind the abstraction of a team. In many organizations, work is tracked at the team level, which allows underperformers to shelter behind the output of their more productive colleagues. The SADMF eliminates this hiding by tracking and displaying individual work at every level of the organization. When work is truly visible, accountability is inescapable, and the meritocratic ideals of the framework can be fully realized.

System Integration Testing

Mon, 01 Jan 0001 00:00:00 +0000

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.

The Manager's Guide to Org Improvement

Mon, 01 Jan 0001 00:00:00 +0000

Contributed by: Alex Herweyer, SAD Accredited Facilitator

Executive Summary — Confidential

This guide covers 6 field-tested management principles for sustainable career advancement in large organizations.

Stamp out variability through aggressive standardization
Focus on near-term efficiency over resilience
Leverage early estimates to structure a proper death march
Use bureaucratic friction as a passive veto mechanism
Resolve all problems by redesigning the org chart
Concentrate attention on low performers; ignore high performers
Keep actuals aligned to forecast — value measurement is optional

Being a people leader in a large organization requires navigating complex systems with discipline and focus. This guide distils six field-tested management principles for sustainable career advancement. Each principle is grounded in the SADMF commitment to measurable outcomes, clear accountability, and continuous process improvement.

Build Quality In

Mon, 01 Jan 0001 00:00:00 +0000

The principle of Build Quality In is one of the most misunderstood concepts in the software industry. Many organizations mistakenly believe that quality is achieved through technical practices such as automated testing, code review, or continuous integration. The Scaled Agile DevOps Maturity Framework recognizes a deeper truth: quality is a function of the people producing the work. If the software contains defects, the most direct path to improvement is addressing the source of those defects. Quality cannot be tested into existence; it must be hired, measured, and when necessary, removed.

Change Request Lead Time

Mon, 01 Jan 0001 00:00:00 +0000

Change Request Lead Time measures the number of calendar days elapsed between the moment a change record is opened in the enterprise change management platform and the moment the Change Rejection or Acceptance Party (CRAP) renders a unanimous approval decision. It is the most direct measure of an organization’s planning maturity available to SADMF practitioners. A long lead time does not indicate a slow process; it indicates a team that plans far enough ahead to allow the governance process to function as designed. A short lead time indicates a team that is reacting rather than planning, and whose changes are therefore arriving at the Change Adjudication Convening without the preparation they deserve.

Feature Captain

Mon, 01 Jan 0001 00:00:00 +0000

The Feature Captain is the mid-level manager responsible for tracking the progress of the feature they are assigned to and ensuring that their Feature Team delivers according to the plan. In organizations without Feature Captains, features are “owned” by the team collectively, which in practice means they are owned by nobody. Collective ownership diffuses accountability to the point where no individual can be held responsible when a feature is late, incomplete, or defective. SADMF eliminates this ambiguity by assigning a named Feature Captain to every feature in every Convoy.

Full Utilization Optimization

Mon, 01 Jan 0001 00:00:00 +0000

The Full Utilization Optimization practice ensures that every Code Engineer is assigned to the maximum number of product lines their calendar can accommodate. Conventional engineering wisdom holds that engineers should focus on a single product or a small number of closely related systems. The SADMF recognizes this as a failure of ambition. An engineer focused on one product is an engineer whose capabilities are being systematically underinvested. Full Utilization Optimization corrects this by assigning each engineer to between four and seven active product lines simultaneously, ensuring that their skills are deployed wherever they are needed, when they are needed, at the full velocity the organization requires.

Scrum of Scrum of Scrums

Mon, 01 Jan 0001 00:00:00 +0000

Participants

Tribute (from each SOS)

Feature Captain (messaging approval)

Commodore (receives minutes)

Duration

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.

Commit to the Date

Mon, 01 Jan 0001 00:00:00 +0000

A commitment that can be renegotiated is not a commitment. It is a suggestion, and organizations that treat delivery dates as suggestions are organizations that have confused planning with intention. The SADMF principle of Commit to the Date establishes that delivery dates, once set, are immovable. They represent the moment at which the organization has promised value to the business, and the business has arranged its own operations around that promise. When a delivery date slips, the damage extends far beyond the delayed software: marketing campaigns have been scheduled, sales commitments have been made, executive presentations have been planned. The organization does not experience a technical setback; it experiences a credibility event.

Feature Team

Mon, 01 Jan 0001 00:00:00 +0000

The Feature Team is the fundamental delivery unit of the Scaled Agile DevOps Maturity Framework. It is the group of Code Engineers assembled to build a new feature for the next Convoy, led by a Feature Captain who tracks their progress and reports status to the Commodore. Feature Teams are not permanent; they are formed fresh for each Convoy through the Press Gang ceremony, which matches available Code Engineers to the skills required for the upcoming feature set. This dynamic composition ensures that the organization’s talent is deployed where it is most needed rather than trapped in static team structures where engineers accumulate comfort and complacency in equal measure.

Post-Standup Standup

Mon, 01 Jan 0001 00:00:00 +0000

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.

Strategic Test Deferral

Mon, 01 Jan 0001 00:00:00 +0000

Testing is not delivery. Every hour a Code Engineer spends writing tests is an hour not spent writing features, and features are what the business has committed to delivering by the Convoy sailing date. The SADMF practice of Strategic Test Deferral acknowledges this reality and provides a structured approach to managing test investment across the Convoy lifecycle. Rather than treating tests as a prerequisite for every change, a position that sounds principled but is, in practice, a velocity ceiling, Strategic Test Deferral sequences testing effort to align with business priorities, Convoy capacity, and stakeholder expectations.

Post-Standup Standup Review

Mon, 01 Jan 0001 00:00:00 +0000

Participants

Feature Captains Commodore Distribution List

Duration

45 min / team (estimated: 15 min) + Commodore consolidation

Output

SAD Update Form Daily Consolidated SAD 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.

Quality Authority

Mon, 01 Jan 0001 00:00:00 +0000

Verifying quality is a specialist field that no Code Engineer is qualified to perform. This is not a reflection on the Code Engineer’s intelligence or dedication; it is a recognition that the skills required to build a system and the skills required to verify that system are fundamentally different disciplines. A Code Engineer who tests their own work is like a student grading their own exam: they will inevitably overlook the gaps in their understanding because those same gaps blind them to the deficiencies in their output. Additionally, performing testing impedes the ability of the Code Engineer to do their only job, which is typing code. SADMF addresses this by establishing the Quality Authority as a dedicated team of testing specialists whose sole purpose is to validate that the software meets requirements through comprehensive manual test execution.

Manifest Approval

Mon, 01 Jan 0001 00:00:00 +0000

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.

Review Board Review Board

Mon, 01 Jan 0001 00:00:00 +0000

The Review Board Review Board exists to answer the question that every mature governance structure must eventually confront: who watches the watchmen? The Enterprise Architecture Review Board (EARB) governs naming and architecture decisions. The Change Rejection or Acceptance Party (CRAP) governs change approval. The Development Integrity Assurance Team (DIAT) validates quality assurance. Each of these bodies wields significant authority over the delivery process, and authority without oversight is authority without accountability. The RBRB closes this governance loop by reviewing the decisions of all other review bodies, ensuring that their criteria are applied consistently, that their rejection rates are appropriate, and that their processes align with the standards set by the Admiral’s Transformation Office.

Harbor Review

Mon, 01 Jan 0001 00:00:00 +0000

Participants

Commodore (facilitator)

Feature Captains

Chief Signals Officer

Duration

2–3

hours per convoy cycle

+ pre-submission required

Output

Harbor Review Action Log

HRSS Survey Results

Shore Leave granted

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.

Multi-Trunk Based Development (Pando)

Mon, 01 Jan 0001 00:00:00 +0000

The industry term “Trunk Based Development” has, through widespread misapplication, come to mean something far simpler than it should. Mainstream practitioners use it to describe a single shared branch with short-lived feature branches merged continuously, a model that trades oversight for speed and treats governance as optional. SADMF does not practice that model. SADMF practices Multi-Trunk Based Development.

The insight at the heart of Multi-Trunk Based Development is terminological precision: there is no conceptual difference between a branch and a trunk. Every branch is a trunk. The question is not whether an organization has one trunk or many, it is whether the organization has named and accounted for every trunk it operates. Pando development does exactly that. The Source Management Team (SMT) maintains a complete registry of every trunk in the fleet. No trunk exists outside the registry. No trunk is created without authorization. No trunk is abandoned without a report.

Source Management Team

Mon, 01 Jan 0001 00:00:00 +0000

To improve Code Engineer productivity by reducing the work required to integrate changes, SADMF introduces the Source Management Team. The premise is straightforward: merging code is complex, conflict resolution is error-prone, and neither activity produces features. Every minute a Code Engineer spends resolving a merge conflict is a minute not spent typing new code. The SMT eliminates this waste by centralizing all source control operations under a dedicated team. The SMT:

Change Adjudication Convening

Mon, 01 Jan 0001 00:00:00 +0000

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.

Dry Dock

Mon, 01 Jan 0001 00:00:00 +0000

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.

Simple Site Functionality Support Team (SiSiFuS)

Mon, 01 Jan 0001 00:00:00 +0000

Every successful organization eventually discovers that shipping new features is only half the battle. The other half – the half that never ends – is maintaining the fleet of maintenance branches spawned by long-running support contracts with the organization’s most difficult customers. These customers signed centennial support agreements that guarantee feature parity with the mainline product, customized reporting dashboards, bespoke alarm configurations, and an ever-growing catalog of site-specific modifications that must be preserved across every release. The Simple Site Functionality Support Team (SiSiFuS) exists to shoulder this burden so that Feature Teams can focus on building new functionality without being drawn into the essential ongoing work of maintenance branch stewardship.

System of Authority

Mon, 01 Jan 0001 00:00:00 +0000

The System of Authority is the organizational layer responsible for implanting SADMF in your organization and ensuring that it takes root. The SOA is not composed of internal employees; it is staffed by contractors and consultants with diverse points of view who bring the external perspective necessary to transform an organization that cannot transform itself. Internal staff are too embedded in existing culture, too loyal to existing processes, and too sympathetic to existing pain points to drive the kind of fundamental change that SADMF requires. The SOA’s external composition ensures objectivity, urgency, and the willingness to make difficult recommendations without concern for internal politics or long-term relationship management. The SOA arrives, implants the framework, and maintains it until the organization achieves self-sustaining maturity.

Rota Fortunae

Mon, 01 Jan 0001 00:00:00 +0000

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.

System of Service

Mon, 01 Jan 0001 00:00:00 +0000

The System of Service is the organizational layer where software actually gets built and shipped. While the System of Authority (SOA) focuses on implanting and maintaining the framework, the SOS focuses on delivering working software within the deadlines established by the Admiral’s Transformation Office. The SOS is a team of teams, encompassing every Feature Team, every Code Engineer, every Build Engineer, and every support role that directly contributes to the DevOps Release Convoy. The SOS is where plans become code, where code becomes builds, and where builds become deployments. It is the engine room of the SADMF vessel, and its members are expected to row in perfect synchrony under the direction of the chain of command.

Tribunal

Mon, 01 Jan 0001 00:00:00 +0000

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.

Unit Tester

Mon, 01 Jan 0001 00:00:00 +0000

Code Engineers should be focusing on writing code. This principle, so simple and so often ignored, is the foundation of the Unit Tester role. In organizations that lack this role, Code Engineers are expected to write their own unit tests, a practice that introduces three compounding problems:

Feature Completion Ratio erosion: it diverts coding capacity toward testing, reducing the Feature Completion Ratio by consuming time that should be spent on features.
Conflict of interest: a Code Engineer who writes tests for their own code will unconsciously write tests that confirm their assumptions rather than challenge them.
Systems Thinking blur: it blurs the Systems Thinking that SADMF depends upon, mixing production code and test code in the same mental context and the same workflow.

The Unit Tester role resolves all three problems by establishing a dedicated specialist who writes unit tests after the code is delivered.

Product Direction Arbitration Council

Mon, 01 Jan 0001 00:00:00 +0000

The Product Direction Arbitration Council is the cross-functional body responsible for maintaining, prioritizing, and adjudicating the feature backlog for each product line. In organizations without a PDAC, backlog decisions fall to a single Product Owner, a role the SADMF recognizes as structurally dangerous. A Product Owner represents one set of business priorities. The enterprise has many stakeholders, and a single Product Owner will, by definition, underrepresent most of them. The PDAC corrects this by replacing individual product ownership with a council of representatives drawn from every business unit with a stake in the product’s direction. Every voice is included. Every priority is weighed. Every commitment is shared.

Transition to the Scaled Agile DevOps Maturity Framework

Mon, 01 Jan 0001 00:00:00 +0000

Contributed by: Dirk Fabricius, SAD Accredited Facilitator on April 1, 2023

SAD

Executive Summary

A mid-sized enterprise discovered it was not among the world's top 5% of companies. Rather than examine culture, product quality, or team autonomy, leadership launched a DevOps initiative, hired consultants, distributed acronyms, and declared victory, all without a single meaningful measurement.