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