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

Return to the regular view of this page.

Planning the Voyage

The tools and ceremonies for scoping, prioritizing, and charting the course of each DevOps Release Convoy.

1 - Convoy Alignment Agenda

Every journey must begin with meticulous, even pedantic, planning

Attendance

All teams should assemble in the Convoy Alignment room for this multi-day celebration of detailed planning. It is important that the alignment happens in person and that everyone travels to a remote location to eliminate distractions from less important things such as family or pets.

Establish a Focused Environment

The organization must maximize planning time. With only 5 days to plan the quarter, the Commodore should schedule 9 hours of structured work each day. Because all non-work distractions have been eliminated, daily meetings can easily be extended if the day’s planning goals are not met. Planning must itself be planned. If the organization cannot meet its commitments, it cannot go fast.

Feel comfortable that since there are no extra-work distractions, the teams will all be able to provide their utmost focus and attention to the work at hand, even if it gets extended by a few hours due to the executive management team’s desire to exceed expectations.

Breaks and lunch can consume valuable alignment time. A collection should be taken at the beginning of each day to order sandwiches. This eliminates the need to stop for lunch and produces the team-building benefits of a shared meal.

Management Address

Day 1 begins with the Management Address, where senior leadership presents the strategic vision for the upcoming convoy cycle. The Admiral or Commodore will outline the top priorities, which will bear no resemblance to the priorities communicated at the previous Convoy Alignment. This is expected. Strategic agility means being able to pivot the entire organization’s direction every 6 weeks while maintaining the 8-quarter commitment plan from the previous alignment.

Code Engineers are encouraged to take notes, though the strategic direction will be further clarified through a series of follow-up emails over the next 3 weeks. Questions during the Management Address should be limited to expressions of enthusiasm.

Dependency Negotiation Theater

On Days 2 through 4, teams engage in Dependency Negotiation Theater. Each Feature Captain identifies every team their feature depends on and negotiates delivery commitments with those teams’ Feature Captains. These negotiations are conducted in a large room with all teams present so that the Commodore can observe which teams are being collaborative and which are “creating blockers.”

Dependencies are recorded on the Nautical Chart using colored string. The density of string on the chart is a leading indicator of alignment maturity. Charts with minimal string suggest teams are not thinking broadly enough about their impact on others.

Teams that cannot resolve dependency conflicts during the negotiation window may escalate to the Commodore, who will resolve the dispute by assigning the dependency to whichever team has the most Code Engineers currently in the coding pool.

Wrapping Up Alignment

On the last hour of the last day, while alignment decisions are fresh, the Commodore holds a “Fist of Five” confidence vote on the organization’s ability to deliver the next 8 quarters’ worth of work. A high confidence level is mandatory, so all participants should be aware that anything less than a score of 4 will result in additional planning until the minimum confidence level is achieved. If there is not a unanimous vote of 4 or better, another collection for sandwiches is taken and planning continues until confidence is achieved.

All stakeholders must be included in the vote. Alignment requires unanimity. Letting the developers see the votes of their managers and vice-versa will ensure that accountability is maintained. In the event of disparity between the developers and managers, ensure that the managers’ votes receive preference since they can influence the developers to work harder.

Confidence Vote Escalation Protocol

If the initial Fist of Five vote does not achieve unanimity at 4 or above, the following escalation protocol is activated:

  1. Round 2: The Commodore asks anyone who voted below 4 to explain their concerns publicly. Their concerns are recorded on the Nautical Chart as risks.
  2. Round 3: The concerns are “addressed” by the Commodore verbally confirming that the risks are acknowledged. A new vote is taken.
  3. Round 4: If unanimity has still not been achieved, the Commodore reminds the room that the hotel conference room is booked through the weekend and that additional sandwich collections will be taken.
  4. Round 5: Unanimity is achieved.

See Also

2 - Weighted Shortest Voyage First (WSVF)

The definitive method for prioritizing features when everything is the highest priority

Every convoy faces the same challenge: too many features and not enough Code Engineers. Traditional prioritization methods rely on simplistic measures like customer value or technical feasibility. WSVF provides a more sophisticated approach that accounts for the complex political and organizational dynamics of enterprise software delivery.

The WSVF Formula

Each feature is scored across four dimensions, and the scores are combined using the proprietary WSVF formula:

WSVF = (CoD + PC) x EV / AQ

Where:

  • CoD (Cost of Delay): How much revenue will we claim to lose if this feature is not delivered? Estimated by the requesting executive’s level of urgency in their last email, scored 1-10.
  • PC (Political Capital): How much organizational capital has the feature’s sponsor accumulated? Sponsors who attended the last Convoy Alignment receive a +3 bonus. Sponsors who brought donuts receive +5.
  • EV (Executive Visibility): Will this feature appear in a board presentation? Features mentioned in quarterly earnings calls receive the maximum score of 10 regardless of other factors.
  • AQ (Acronym Quality): Does the feature have a compelling acronym? Features with memorable acronyms (minimum 4 letters, must be pronounceable) score higher. A feature called “Operational Network Enhancement” (ONE) scores well. A feature with no acronym scores a minimum of 1 to avoid division by zero.

Calculating WSVF

WSVF scores are calculated by the Commodore during Convoy Alignment. The calculation is performed on a dedicated spreadsheet that the Commodore maintains personally. The formula cell references are not shared to prevent gaming of the system.

In the event of a tie, priority is resolved using the following tiebreakers, in order:

  1. Seniority of the requesting stakeholder
  2. Number of times the feature has been deferred from previous convoys (features deferred 3+ times receive a “Legacy Priority” designation)
  3. Proximity of the stakeholder’s office to the Commodore’s office
  4. A coin toss witnessed by the Chief Signals Officer

Challenging a WSVF Score

Feature Captains who believe their feature has been incorrectly scored may file a WSVF Challenge through the Priority Change Request process. Challenges are heard during Captain’s Mast and require the challenger to present evidence that their feature’s acronym is, in fact, pronounceable.

The Commodore has final authority on all WSVF disputes. The Commodore’s decision is based on careful analysis of the WSVF spreadsheet and may also take into account factors not captured in the formula, such as which Feature Captain most recently bought the Commodore lunch.

WSVF and the Nautical Chart

Once WSVF scores are finalized, features are arranged on the Nautical Chart in priority order, from top-left (highest WSVF) to bottom-right (lowest WSVF). Features with Executive Visibility scores of 10 are placed in gold sticky notes regardless of their overall WSVF score.

See Also

3 - Nautical Charts

Visualizing dependencies so we can see exactly how stuck we are

The Nautical Chart is a large-format physical board created during Convoy Alignment that maps every feature, dependency, risk, and milestone for the upcoming convoy cycle. It is the single source of truth for the convoy, provided you can read it.

Construction

The Nautical Chart is constructed on Day 3 of Convoy Alignment using the following materials:

  • A whiteboard measuring no less than 3 meters by 2 meters
  • Sticky notes in seven designated colors (one per team, plus red for risks and gold for executive priorities)
  • Colored string to connect dependent features (string color must match the upstream team’s sticky note color)
  • Pushpins to anchor string intersections
  • A ruler, because straight lines convey professionalism
  • A dedicated Chart Officer appointed by the Commodore to maintain the chart throughout the convoy cycle

Digital tools are strictly prohibited. Spreadsheets and project management software create a false sense of accuracy and prevent the team from experiencing the tangible weight of their commitments. The physical act of moving a sticky note builds accountability in ways that dragging a card on a screen never can.

Reading the Chart

The Nautical Chart uses the following conventions:

  • Horizontal axis: Time, divided into weeks of the convoy cycle
  • Vertical axis: Feature Teams, grouped by Feature Captain
  • Sticky notes: Features, with estimated story points written in the corner
  • Red string: Hard dependencies (team B cannot start until team A finishes)
  • Yellow string: Soft dependencies (team B probably should not start until team A finishes, but likely will)
  • Crossed strings: Dependency conflicts, to be resolved by the Commodore at a future meeting
  • Gold sticky notes: Features with executive visibility, placed by Feature Captains who have a direct relationship with the requesting executive

When string density exceeds the ability to trace any single path from start to finish, the chart is considered “comprehensive.”

Maintenance

The Chart Officer must update the Nautical Chart daily. This involves:

  • Moving completed features to the “Sailed” column (far right)
  • Adjusting string connections as dependencies change
  • Replacing sticky notes that have fallen off (a daily occurrence, particularly near air conditioning vents)
  • Adding new risk notes as discovered during Post-Standup Standup

Despite diligent maintenance, the Nautical Chart is generally acknowledged to be outdated within 48 hours of its creation. This is acceptable. The value of the chart lies not in its accuracy but in the alignment experience of building it together.

Security

No photography of the Nautical Chart is permitted. The chart contains sensitive strategic information about delivery commitments and dependencies. Photographs could be shared with customers, partners, or other departments, creating unreasonable expectations about delivery timelines. If a stakeholder wishes to view the chart, they must visit the Convoy Alignment room in person and be accompanied by a Feature Captain who can provide appropriate context for why nothing on the chart matches reality.

See Also

  • Convoy Alignment for the planning session where charts are constructed
  • The Armada for cross-convoy chart coordination
  • WSVF for how features on the chart are prioritized
  • Convoy Ceremonies for the ceremonies that generate chart updates

4 - Planning Ceremonies

The ceremonies that establish commitments, schedule events, decompose work, and assemble teams before each convoy cycle begins

Planning Ceremonies are the foundational ceremonies of the DevOps Release Convoy™ lifecycle. They occur before active development begins and establish the commitments, schedules, task breakdowns, and team compositions that the rest of the convoy depends upon.

These ceremonies must be completed in strict sequence. Attempting to begin development without completing all Planning Ceremonies introduces unacceptable uncertainty into the delivery timeline and undermines the coordination achievements of Convoy Alignment.

Planning Ceremony Sequence

  1. Captains’ Meeting — Schedules the date of the planning event. Must be completed before Convoy Alignment can be announced.
  2. Convoy Alignment — The foundational 5-day event where all teams commit to the next eight quarters of delivery.
  3. Provisioning — Decomposes feature commitments into granular task lists by the Feature Captains.
  4. Press Gang — Assembles feature teams by drafting Code Engineers from the shared coding pool.

See Also

4.1 - Convoy Alignment

The foundational 5-day planning ceremony where all teams commit to the next eight quarters of delivery

Convoy Alignment is the cornerstone planning ceremony of the DevOps Release Convoy, held every six weeks to establish priorities, commitments, and feature sequencing for the next eight quarters. This two-year planning horizon ensures that the organization is never caught off guard by the future and that every team has a clear, unchanging roadmap to follow. Features are prioritized using the Weighted Shortest Voyage First (WSVF) framework and mapped onto the delivery timeline using Nautical Charts, giving leadership full visibility into what will be delivered, by whom, and when, well before anyone has examined whether it is technically feasible.

The full ceremony agenda, including day-by-day breakdowns, required attendees, and expected outputs, is documented on the Convoy Alignment Agenda page. All participants are strongly encouraged to review the agenda in advance, as the five days are fully scheduled and there is no time allocated for questions about the process itself.

See Also

4.2 - Captains' Meeting

The meeting to plan the date of the planning meeting

The Captains’ Meeting is a gathering of Feature Captains to plan the date when the DevOps Release Convoy™ will be assembled for Convoy Alignment. While this may sound straightforward, the process of synchronizing calendars across all Feature Captains, securing an appropriate venue, and establishing the alignment agenda requires its own dedicated coordination ceremony. Attempting to schedule Convoy Alignment without a Captains’ Meeting would be like setting sail without first agreeing on which ocean you are heading toward.

The Scheduling Process

The primary output of the Captains’ Meeting is a confirmed date for Convoy Alignment. Achieving this requires all Feature Captains to synchronize their calendars, which typically takes between two and four weeks of negotiation. The preferred scheduling tool is a Doodle poll, though the polls have a well-documented tendency to never converge. Each Feature Captain submits their availability, which is then invalidated by the next Feature Captain’s constraints. By the third round of polling, most Feature Captains have new conflicts on dates they previously marked as available, as the intervening weeks have filled their calendars with prerequisite meetings for other ceremonies. It is not uncommon for the Captains’ Meeting to require three or four sessions before a date is finalized.

Prerequisite Meetings

Before the Captains’ Meeting can take place, several preparatory activities must be completed. The Commodore must issue a Convoy Assembly Directive indicating that a new convoy cycle is approaching. Each Feature Captain must then hold a team-level pre-alignment readiness check to determine whether their team has capacity to attend a five-day planning session. The results of these readiness checks are compiled into a Pre-Alignment Readiness Report, which is reviewed at the Captains’ Meeting itself. Teams that report insufficient readiness are reminded that attendance at Convoy Alignment is not optional, rendering the readiness check a formality that nonetheless must be completed.

The Meeting to Plan the Meeting

Experienced SADMF practitioners will recognize the Captains’ Meeting as a natural consequence of the framework’s commitment to thorough planning. Planning the planning date ensures that alignment will not be disrupted by logistical surprises. The irony that planning the planning date often takes longer than anticipated is not lost on the organization but is accepted as evidence that complex coordination requires structured ceremonies. Proposals to “just pick a date” have been rejected by the Admiral’s Transformation Office as insufficiently rigorous and disrespectful to the ceremony’s role in the convoy lifecycle.

Agenda and Outputs

Beyond date selection, the Captains’ Meeting also establishes the agenda for Convoy Alignment, assigns conference room logistics, determines the sandwich collection schedule, and confirms which Feature Captains will present during the Management Address warm-up. The meeting produces a Captains’ Meeting Minutes document that is filed with the Convoy Manifest as evidence that proper pre-planning governance was followed. The minutes are rarely referenced again, but their existence provides organizational comfort.

See Also

4.3 - Provisioning

Translating strategic commitments into granular task lists through expert decomposition by Feature Captains

Before each convoy begins active development, the Provisioning ceremony translates the commitments made during Convoy Alignment into detailed task lists for each Feature Team. Each Feature Captain breaks their committed features into tasks no larger than 4 hours each. Tasks estimated at more than 4 hours indicate insufficient understanding and must be broken down further, regardless of whether the decomposition adds clarity.

After task decomposition, the Feature Captain totals the estimated hours across all tasks. If the total exceeds the team’s available capacity, the Feature Captain adds 30% additional tasks anyway because “we committed to this during alignment.” The gap between capacity and commitment is recorded as a “stretch opportunity” rather than an overcommitment.

Code Engineers are not consulted during Provisioning. Their estimates are not needed because the Feature Captain has already estimated on their behalf using historical Lines of Code per Code Engineer data. This ensures consistency and prevents the introduction of pessimism into the plan.

The Provisioning Spreadsheet

All task decomposition is recorded in the Provisioning Spreadsheet, a document that only the Feature Captain has edit access to. This restriction exists to maintain the integrity of the estimates and to prevent Code Engineers from introducing complexity that was not apparent during planning. The spreadsheet is maintained in a shared drive but is protected with a password known only to the Feature Captain and the Commodore. Read-only access may be granted to Code Engineers upon request, though requests are reviewed on a quarterly cadence.

Each task in the spreadsheet must follow the approved naming convention: the convoy number prefix, followed by the feature identifier, followed by a sequential task number (e.g., C17-F042-T003). Tasks that do not follow this convention are rejected during Code Inspection regardless of their implementation quality.

Capacity Reconciliation

After the initial task decomposition is complete, the Feature Captain performs the Capacity Reconciliation step. This is where the total estimated hours are compared against the team’s available capacity. In every observed instance, the estimated hours exceed capacity by 40% to 200%. The Capacity Reconciliation process addresses this gap through a series of approved adjustments:

  1. Meetings, breaks, and administrative time are removed from the capacity model, reflecting the expectation that Code Engineers will code continuously during working hours.
  2. Tasks labeled as “simple” are reduced by 50%, as simple tasks should take half the time.
  3. Any remaining gap is labeled a “stretch opportunity” and documented in the Convoy Manifest as an area where the team will demonstrate its commitment.

These adjustments always close the gap on paper, which is the purpose of the exercise.

Historical Accuracy

The accuracy of Provisioning estimates has been tracked across all convoy cycles. In no recorded instance has a Provisioning estimate accurately predicted the actual effort required to deliver the planned features. This outcome is consistently attributed to Code Engineer performance rather than estimation quality, as the estimation process has been validated by the Admiral’s Transformation Office and found to be methodologically sound. When delivery falls short, the root cause is documented as “insufficient velocity” and fed into PeopleWare performance metrics. The estimation process itself has never been identified as a contributing factor, as doing so would undermine confidence in the framework.

See Also

4.4 - Press Gang

The ceremony where Code Engineers are drafted from the coding pool and assigned to features regardless of expertise or preference

The Press Gang is the resource allocation ceremony in which Feature Captains select Code Engineers from the shared coding pool to staff their feature teams. The name is a proud nod to the naval tradition of impressment, in which sailors were recruited through the efficient method of simply telling them where they would be working. The SADMF has modernized this practice for the knowledge economy by adding a whiteboard.

The selection process follows a strict draft order based on feature priority as determined during Convoy Alignment. The Feature Captain with the highest-priority feature selects first, choosing between 2 and 20 Code Engineers depending on the Provisioning estimates. Selection continues in priority order until all features are staffed or the coding pool is exhausted, whichever comes first. If the pool is exhausted before all features are staffed, lower-priority features proceed with whatever engineers remain, and their Feature Captains are reminded that delivering with fewer resources is an opportunity to demonstrate organizational agility.

The Coding Pool Board, a large physical display maintained by the Chief Signals Officer, lists all available Code Engineers along with their technical skills, domain experience, and current certifications. While this information is displayed for transparency, Feature Captains are encouraged to select based on availability rather than skills. Selecting for specific skills would create single points of failure and would imply that certain engineers are more suited to certain tasks, which contradicts the SADMF principle that all Code Engineers are interchangeable resources. An engineer who worked on the payment processing system last convoy is just as well-prepared to work on the real-time telemetry pipeline this convoy. Software is software.

Code Engineers cannot refuse assignment. The Press Gang operates on the understanding that organizational needs supersede individual preferences, and that engineers who express reluctance about an assignment are exhibiting a fixed mindset. Once selected, engineers receive a thirty-minute onboarding briefing from their new Feature Captain, during which the feature requirements, technical context, and delivery timeline are communicated. Thirty minutes has been determined to be the optimal onboarding duration regardless of domain complexity, as longer onboarding sessions cut into the fixed Coding timebox. Engineers are expected to acquire any additional context they need by reading the requirements document, which contains everything they need to know because it was written by people who understand the system.

The Press Gang ceremony is one of the SADMF’s most powerful tools for preventing knowledge silos. Because engineers are reassigned to different features every convoy cycle, no individual ever accumulates dangerous levels of expertise in any single area. This ensures that the organization is never dependent on any one person and that all engineers maintain a breadth of shallow familiarity across the entire portfolio. The utilization target for all Code Engineers is 100%, meaning no engineer should ever be idle between assignments. Idle time is waste, and the SADMF recognizes no distinction between being idle and thinking about a problem.

See Also

  • Feature Captain for the role that selects engineers during the draft
  • Code Engineers for the resources being allocated
  • Provisioning for how staffing needs are determined
  • Coding for what happens after engineers are assigned
  • Convoy Alignment for where feature priorities are established
  • Limit WIP for the principle that ensures zero idle time between assignments