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

Return to the regular view of this page.

Engineering

The practitioners who perform the technical work of building, testing, and delivering software.

1 - Build Engineers

YAML experts who ensure Code Engineers never waste time on build concerns and can focus entirely on feature delivery!

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.

The Canonical Build Definition

The Build Engineers are responsible for maintaining the Canonical Build Definition, a single authoritative YAML file (or, more commonly, a hierarchy of 40-60 YAML files) that defines every step of the build process for every application in the organization. The Canonical Build Definition is stored in a dedicated repository managed by the Source Management Team, and changes to it follow the same Fractal-based Development branching pattern as application code. This ensures that build changes receive the same level of scrutiny as feature code, passing through the Code Standards Enforcement Team (CSET) for review and the Change Rejection or Acceptance Party (CRAP) for approval. Build changes that are approved are merged into the Conflict branch by the Source Management Team and included in the next Convoy.

Build Change Requests

The separation between Build Engineers and Code Engineers is a cornerstone of SADMF’s commitment to Systems Thinking. When a Code Engineer updates a dependency, adds a new module, or changes a compilation flag, they do not modify the build configuration themselves. Instead, they file a Build Change Request (BCR) with the Build Engineering team, specifying what they need and why. The Build Engineers then:

  1. Evaluate the BCR against the Canonical Build Definition.
  2. Assess the impact on other applications that share build components.
  3. Schedule the change for implementation.

This process typically adds 3-5 business days to the development cycle, but this delay is a feature, not a flaw: it ensures that build changes are deliberate, documented, and coordinated across the enterprise rather than made impulsively by individual Code Engineers who cannot see the full picture.

Environment Provisioning

Build Engineers also execute the Standardized Environment Provisioning practice, maintaining the 200-step SEPAW checklist that ensures every environment is configured identically. When a Feature Team requires a new environment for testing or development, they submit a request to the Build Engineers, who provision the environment manually according to the checklist. The manual nature of this process is intentional: automated provisioning scripts can contain bugs, but a human following a checklist will catch discrepancies that a script would silently propagate. Each provisioned environment is signed off by the Build Engineer who created it and countersigned by the Development Integrity Assurance Team (DIAT) before it is released for use.

Reporting and Metrics

The Build Engineering team reports to:

Their performance is measured by the Feature Completion Ratio, ensuring that build reliability is tracked as rigorously as feature delivery. Build Engineers who achieve consistently high scores on the DevOps Process Excellence Assessment may be nominated for the SADMF Certified Build Architect credential, recognizing their mastery of YAML and their commitment to centralized build ownership.

See Also

2 - Code Engineer

The backbone of a SAD implementation, transforming requirements into machine-readable instructions quickly and quietly!

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:

The Code Engineer types code. That is the job.

Expertise and Silence

Code Engineer expertise can be reliably judged by the number of questions they ask. Since a Code Engineer is expected to be an expert at data structures and algorithms, fewer questions indicate more expertise. A senior Code Engineer should be able to receive a requirement, internalize it immediately, and begin typing. Questions suggest confusion, and confusion suggests a gap in expertise that the DevOps Process Excellence Assessment should identify and address. The most productive Code Engineers are those who accept requirements without discussion, produce code without complaint, and submit it without explanation. This is not a sign of disengagement; it is a sign of mastery. The requirement speaks for itself, the code speaks for itself, and the Code Engineer’s silence is the loudest testament to their competence.

Team Assignment

Code Engineers are organized into Feature Teams for each Convoy, assembled through the Press Gang ceremony based on the skills required for the upcoming feature set. Because SADMF invests heavily in Build Quality In through the Tribunal and other review mechanisms, Feature Teams should be able to deliver at maximum throughput immediately upon formation, regardless of whether the team members have worked together before or have any familiarity with the codebase they are being assigned to. Onboarding time is a sign that the organization has failed to standardize sufficiently. If a Code Engineer needs more than a day to become productive on a new codebase, the fault lies not with the engineer but with the codebase’s failure to conform to the Enterprise Coding Standards Manual maintained by the CSET.

Workflow

The Code Engineer’s workflow is precisely defined by the framework:

  1. Receive requirements during the Convoy Planning ceremony.
  2. Write code in their assigned feature branch.
  3. Submit code to the CSET for review.
  4. Address any standards violations.
  5. Hand the approved branch to the Source Management Team for merging into the Conflict branch.

At no point does the Code Engineer interact directly with the production system, the build pipeline, the test suite, or the deployment process. These boundaries exist to protect both the Code Engineer and the organization: the Code Engineer is protected from the complexity of systems they do not need to understand, and the organization is protected from the risk of a Code Engineer making changes outside their area of expertise.

Performance and Career Path

Code Engineers are measured by:

Performance data is compiled by the Chief Signals Officer and reviewed at the Tribunal, where Code Engineers whose metrics fall below acceptable thresholds receive coaching, reassignment, or additional process training. Code Engineers who demonstrate consistent excellence may be considered for advancement to the CSET or the Development Integrity Assurance Team (DIAT), roles that allow them to review and judge the work of their former peers. This career path reinforces the principle that the highest form of engineering is not writing code but evaluating it.

See Also

3 - Feature Captain

The mid-level manager who tracks feature progress and ensures their assigned Feature Team delivers on time!

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.

The Feature Captain does not write code, does not test code, and does not review code. The Feature Captain tracks progress, removes blockers through escalation, and reports status to the Commodore. The Feature Captain is the human embodiment of the Release Tracking spreadsheet for their assigned feature.

Daily Responsibilities

The Feature Captain’s day begins with a review of the previous day’s progress against the Precise Forecasting and Tracking plan:

  1. Each Code Engineer on the Feature Team reports their status to the Feature Captain, specifying the number of story points completed, the number remaining, and any impediments.
  2. The Feature Captain records these figures in their section of the Release Tracking spreadsheet and calculates the feature’s current velocity against planned velocity.
  3. Discrepancies are flagged immediately: if a Code Engineer reports fewer story points completed than planned, the Feature Captain investigates the cause and determines whether the variance is recoverable within the Convoy timeline or whether escalation to the Commodore is required.

The Feature Captain does not accept “it’s taking longer than expected” as an explanation; the plan was built using the official formula (1 SP = 0.73 person-days), and deviations from the plan indicate either an estimation error (which the Admiral’s Transformation Office must address) or a performance gap (which the Tribunal must address).

Ceremony Participation

The Feature Captain participates in every ceremony related to their feature’s lifecycle:

  • Convoy Planning: the Feature Captain receives the feature’s scope and timeline from the Commodore and decomposes it into tasks for the Code Engineers.
  • Mandatory Status Synchronization: the Feature Captain presents their feature’s current status to the broader team and flags any cross-feature dependencies or blockers.
  • Tribunal: the Feature Captain presents the feature’s delivery metrics and is held accountable for any variances from the plan.

The Feature Captain’s calendar is a mosaic of ceremonies, status meetings, and escalation calls, with whatever time remains allocated to updating the Release Tracking spreadsheet and preparing reports for the Commodore.

Relationship with the Feature Team

The Feature Captain’s relationship with the Feature Team is one of oversight, not collaboration. The Feature Captain assigns tasks, tracks completion, and reports results. The Feature Captain does not pair with Code Engineers, does not participate in technical discussions, and does not provide feedback on code quality, as those responsibilities belong to the CSET and DIAT respectively. This separation is intentional: a Feature Captain who becomes too involved in the technical work loses the objectivity required to report status accurately. Status reporting must be dispassionate, based on numbers rather than narratives, and free from the optimistic bias that infects those who are emotionally invested in the work. The Feature Captain’s detachment is their greatest asset.

Performance and Career Path

Feature Captains report to the Commodore and are evaluated based on:

  • Accuracy of status reports: how closely reported progress matches actual outcomes
  • On-time delivery rate: the percentage of their features that ship within the Convoy timeline
  • Release Tracking spreadsheet quality: the completeness and precision of their entries

A Feature Captain whose features consistently deliver on time and whose status reports prove accurate is recognized as a high performer. A Feature Captain whose features are late or whose status reports reveal systematic inaccuracies is referred for additional training in Precise Forecasting and Tracking methodology. The Feature Captain role is the proving ground for future Commodores: those who master the art of status collection, escalation, and reporting at the feature level are prepared to do so at the Convoy level.

See Also

4 - Feature Team

The group of Code Engineers assembled per Convoy to deliver a feature at maximum throughput from day one!

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.

The Press Gang Ceremony

The Press Gang ceremony is the mechanism by which Feature Teams come into existence. During the ceremony, the Commodore and Feature Captains review the feature requirements for the upcoming Convoy and identify the skill profiles needed for each feature. Code Engineers are then assigned to Feature Teams based on:

  • Skill profiles: matching engineer capabilities to feature requirements
  • Availability: ensuring no engineer is double-assigned
  • DevOps Process Excellence Assessment scores: placing the highest performers on the most critical features

Code Engineers do not volunteer for Feature Teams and do not express preferences; the Press Gang assigns them where the organization needs them most. This prevents the formation of cliques, ensures that no Code Engineer becomes a single point of failure for any particular system, and distributes institutional knowledge across the organization rather than concentrating it in self-selected groups.

Instant Productivity

Because SADMF invests so heavily in Build Quality In through the Tribunal, the CSET, and the Enterprise Coding Standards Manual, Feature Teams should be able to deliver at maximum throughput immediately upon formation. If the organization has properly standardized its codebases, properly enforced its naming conventions through the EARB, and properly documented its systems through the Comprehensive Documentation Assurance Protocol, then any Code Engineer should be productive on any codebase within a single day. Teams that require extended ramp-up periods are exhibiting a symptom of insufficient standardization, and the DOUCHE should investigate the root cause. The goal is interchangeable parts: Code Engineers who can be assembled into any configuration and immediately function as a unit.

Workflow

The Feature Team’s workflow follows a precisely defined sequence:

  1. The Feature Captain decomposes the feature into tasks during Convoy Planning and assigns them to individual Code Engineers.
  2. Each Code Engineer works in their assigned feature branch.
  3. Completed code is submitted to the CSET for review.
  4. The Code Engineer addresses any standards violations.
  5. The approved branch is handed to the Source Management Team for merging into the Conflict branch.
  6. The Feature Captain tracks each task’s progress through the Release Tracking spreadsheet and reports the feature’s overall status during the daily Mandatory Status Synchronization.

The Feature Team does not self-organize, does not choose its own practices, and does not deviate from the defined workflow. The framework has already determined the optimal process; the team’s role is to execute it.

Dissolution and the Clean Slate

At the conclusion of the Convoy, the Feature Team is dissolved. Code Engineers return to the available pool, and the relationships, context, and working rhythms they developed during the Convoy are deliberately discarded. This may seem wasteful, but it is essential to SADMF’s organizational resilience. Teams that persist across multiple Convoys develop informal processes, undocumented conventions, and interpersonal dynamics that create friction when members eventually leave or are reassigned. By dissolving and reforming teams each Convoy, SADMF ensures that the organization never depends on any particular team configuration and that every delivery cycle begins with a clean slate, free from the accumulated technical and social debt of previous iterations.

See Also

5 - Quality Authority

Manual testing specialists who serve as the final arbiter of requirements, because the only TRUE way to test is by hand!

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.

Requirements Interpretation

The Quality Authority is the final arbiter of what the requirements mean:

  • Ambiguous requirements: when a requirement is ambiguous, as requirements inevitably are, the Quality Authority interprets it.
  • Conflicting requirements: when a requirement conflicts with another requirement, the Quality Authority resolves the conflict.
  • Implementation disputes: when a Code Engineer implements a requirement differently than the Quality Authority expected, the Quality Authority’s interpretation prevails, because the Quality Authority has studied the requirements more deeply than any Code Engineer, who was focused on typing the code rather than understanding the broader business context.

The Quality Authority maintains a Requirements Interpretation Log that records every interpretive decision, creating an authoritative reference that prevents the same ambiguity from being re-debated in future Convoys.

Manual Test Execution

The Quality Authority creates, maintains, and manually executes test scripts based on their understanding of the requirements. Each test script specifies the exact steps to perform, the exact data to enter, and the exact results to observe. Test scripts are executed by hand because the end-user uses the system manually, and therefore the only TRUE way to test it is manually. Automated tests verify that code runs; manual tests verify that the software works as a human would experience it. The Quality Authority executes each test script exactly as written, recording pass or fail for each step, capturing screenshots of every result, and documenting any deviations in a Test Execution Report. The Test Execution Report is reviewed by the Development Integrity Assurance Team (DIAT) to validate that the testing was performed correctly.

Testing Cycle

The Quality Authority’s test execution cycle is integrated into the Convoy timeline:

  1. The Source Management Team merges all feature branches into the Conflict branch and resolves all conflicts.
  2. The Quality Authority receives the integrated build for testing.
  3. The testing window is defined by the Commodore and typically spans two to three weeks, during which the Quality Authority executes every test script in the regression suite plus all new scripts written for the current Convoy’s features.
  4. Defects discovered during testing are logged in the Defect Tracking Spreadsheet (a dedicated tab in the Release Tracking spreadsheet) and assigned back to the Code Engineers who wrote the offending code.
  5. Code Engineers fix the defects, the Source Management Team re-merges, and the Quality Authority re-executes the affected test scripts.
  6. This cycle repeats until the Quality Authority signs off that all tests pass.

Authority and Metrics

The Quality Authority’s sign-off is a prerequisite for the Change Rejection or Acceptance Party (CRAP) to review the Convoy’s changes. Without QA sign-off, the CRAP will not convene, and the Convoy cannot proceed to Deploy the Fleet. This gives the Quality Authority effective veto power over any release, a power that is appropriate given their role as the organization’s last line of defense against defective software reaching production.

Quality Authority members are measured by:

  • Defects found during testing: more is better, as it indicates thorough testing
  • Production defects found after release: fewer is better, as it indicates effective testing
  • DevOps Process Excellence Assessment scores: adherence to framework practices

The Quality Authority does not ship fast; the Quality Authority ships right.

See Also

6 - Source Management Team

The SMT authorizes branches, merges code, and resolves all conflicts so Code Engineers never have to!

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:

  • Authorizes new feature branches: approves and creates branches in the repository
  • Merges completed branches: integrates each Code Engineer’s work into the Conflict branch
  • Resolves all conflicts: determines which changes prevail when branches collide
  • Alerts the Quality Authority: signals when the Convoy is ready for testing

Code Engineers interact with their own feature branches and nothing else. Everything beyond that boundary is SMT territory.

Branch Authorization

The branch authorization process begins when a Feature Captain submits a Branch Request Form to the SMT, specifying:

  • The feature name
  • The base branch
  • The expected duration
  • The Code Engineers who will work on it

The SMT reviews the request against the current branch topology documented in the Fractal-based Development map to ensure that the new branch will not create structural conflicts with existing branches. Once approved, the SMT creates the branch and grants write access to the assigned Code Engineers. Code Engineers may not create branches themselves, as unauthorized branches would introduce untracked parallel development that the SMT cannot monitor or manage. Every branch in the repository must appear on the Fractal-based Development map, and the SMT is the sole authority for updating that map.

Conflict Arbitration

Merging is the SMT’s most critical and time-consuming function. At defined integration points during the Convoy cycle, the SMT merges all completed feature branches into the Conflict branch. This is where Conflict Arbitration occurs: when multiple Code Engineers have modified the same files, the SMT resolves the conflicts by examining the changes, consulting the requirements, and determining which changes should prevail. The SMT does not ask the Code Engineers to resolve their own conflicts, as this would reintroduce the productivity loss that the SMT was created to eliminate. Instead, the SMT makes the resolution decision and documents it in the Conflict Resolution Log, which is reviewed by the Development Integrity Assurance Team (DIAT) to verify that resolutions did not introduce defects.

Documentation Branch Management

The SMT also manages the branching lifecycle for the Comprehensive Documentation Assurance Protocol (CDAP), ensuring that documentation branches follow the same controlled process as code branches. When the CSET approves a code change and the DIAT validates the testing, the SMT verifies that all associated documentation has been merged before marking the feature as integration-complete. This ensures that code and documentation remain synchronized throughout the Convoy, preventing the common problem of code shipping without updated documentation or documentation shipping that describes code not yet merged.

Reporting and Metrics

The SMT reports to:

Their performance is measured by:

  • Merge success rate: the percentage of merges completed without requiring Code Engineer consultation
  • Average conflict resolution time: how quickly the SMT resolves conflicts once encountered
  • Fractal-based Development map accuracy: how closely the map reflects the actual repository state

SMT members must pass the DevOps Process Excellence Assessment with high scores in the source management and branching strategy sections, and senior SMT members may pursue the SADMF Certified Source Architect credential. The SMT is the organization’s cartographer and diplomat, mapping the territory of code and negotiating peace when branches go to war.

See Also

7 - Unit Tester

Dedicated specialists who write unit tests after code is delivered, because Code Engineers should focus on writing code!

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:

  1. Feature Completion Ratio erosion: it diverts coding capacity toward testing, reducing the Feature Completion Ratio by consuming time that should be spent on features.
  2. 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.
  3. 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.

Workflow

The Unit Tester’s workflow begins when a Code Engineer completes a piece of code and submits it to the Code Standards Enforcement Team (CSET) for review. The steps are:

  1. The CSET approves the code.
  2. The Unit Tester receives the approved code along with the requirements that it implements.
  3. The Unit Tester studies the code, identifies the logical paths and boundary conditions, and writes unit tests that verify each path and condition.
  4. The Unit Tester does not consult the Code Engineer about the code’s intended behavior; the code itself is the specification, and the Unit Tester’s tests verify that the code does what the code says it does.
  5. If the Unit Tester discovers that the code behaves in a way that seems inconsistent with the requirements, they log a discrepancy in the Discrepancy Report for the Quality Authority to evaluate.

The Value of Temporal Separation

The temporal separation between coding and testing is a feature of this model, not a flaw. When a Code Engineer writes tests simultaneously with their code, the tests and the code evolve together, sharing the same assumptions and the same blind spots. By introducing a time gap and a different person, SADMF ensures that the tests are written with fresh eyes and an independent understanding of the requirements. The Unit Tester approaches the code as an outsider, seeing it for the first time and testing it without the author’s preconceptions about what it should do. This independence produces tests that catch defects the Code Engineer would never have found, because the Code Engineer would never have written a test for a scenario they did not anticipate.

Unit Test Repository

Unit Testers maintain the Unit Test Repository, a centralized collection of all unit tests organized by feature, by Convoy, and by Code Engineer. The repository is managed by the Source Management Team and follows the same Fractal-based Development branching pattern as production code. When the Source Management Team merges feature branches into the Conflict branch, they also merge the corresponding unit test branches, ensuring that the integrated build includes both the production code and its unit tests. The Unit Tester verifies that all tests pass on the integrated build and reports the results to the Feature Captain and the Quality Authority. Test failures on the integrated build that passed on the feature branch indicate a conflict introduced during merging, which the Source Management Team investigates.

Distinction from the Quality Authority

The Unit Tester role is distinct from the Quality Authority, which performs manual end-to-end testing. The Unit Tester writes automated tests at the unit level; the Quality Authority executes manual tests at the system level. This layered approach ensures that code is tested at multiple granularities by multiple independent teams, creating a comprehensive quality net that no single testing approach could provide.

Metrics

Unit Testers are measured by:

  • Tests written per Convoy: the volume of test coverage produced each delivery cycle
  • Code coverage percentage: the proportion of production code exercised by their tests
  • DevOps Process Excellence Assessment scores: adherence to framework practices

Unit Testers who achieve high coverage while maintaining test quality may be recognized at the Tribunal and considered for advancement to the DIAT, where they can apply their testing expertise to validating the work of the Quality Authority.

See Also