Transferring Maintenance to a New Team: Run a Bounded Change Exercise Before Declaring Readiness

After the receiver can reproduce the baseline, ask them to complete one agreed, low-risk maintenance change through impact analysis, implementation, testing and review. A clean build proves that a recipe can run. It does not show that a new team can locate the right code, understand its dependencies or judge whether a change is adequately verified.

This article proposes a bounded handover exercise, not an assessment of any real person’s employment suitability or a guarantee of future support. No code was changed or tested. Use an isolated development branch and designated test resources; production deployment is outside the exercise.

1. Choose a change that exposes the maintenance path

Select a small behavior change with a clear requirement, limited affected code and observable results. Avoid security-policy changes, irreversible data migrations, hazardous output control or an urgent production defect as the first exercise.

The task should require more than editing a visible string, yet remain narrow enough to review completely. Agree its scope, excluded systems, allowed resources and expected evidence before starting.

NASA’s transition guidance, section 5.5.1.2, addresses personnel and enabling readiness. The original exercise below turns one part of that readiness into a directly observable maintenance workflow.

2. Establish the baseline as a prerequisite

Identify the source revision, toolchain/environment, configuration, build outputs and current tests. The receiver should know how to create a clean baseline and distinguish expected output from a broken development environment.

Do not count this baseline reproduction as completion of the change exercise. Its purpose is to make later differences attributable and to reveal missing inputs before implementation begins.

Retain the baseline artifact and test results when the exercise is actually run. A proposed procedure or empty test report is not evidence that the receiver successfully reproduced anything.

3. Ask for an impact note before the patch

Question	Expected receiver output
Where is the behavior implemented?	Relevant module and data/control path
What else depends on it?	Interfaces, configuration, documentation and tests
What must remain unchanged?	Explicit regression boundary
How will success and failure be observed?	Positive and negative test expectations
What knowledge is missing?	Questions and blockers before implementation

This note need not be long. Its value is showing that the receiver can reason about the change rather than applying an unexplained patch supplied by the original author.

4. Require evidence that distinguishes the new behavior

Choose a test that would fail for the relevant reason on the unchanged baseline and pass only when the requested behavior is implemented correctly. Add a negative or boundary case that prevents a trivial always-success implementation from satisfying the test.

Also run the agreed regression scope. The exercise is incomplete if the new feature works while an affected existing behavior breaks without being noticed.

NASA’s change-control guidance, section 6.5.1.2.3, couples evaluated changes with implementation verification. Here, the receiver should explain why each retained observation supports the requested change and where it does not.

5. Use a fictional diagnostic-page exercise

A fictional product already maintains a noncritical event counter internally. The exercise asks the receiver to display that counter on a diagnostic page with the approved label and an explicit unavailable state. It does not add an actuator command or change the counter’s meaning.

The receiver traces the existing value to the display path, proposes a bounded patch and updates the relevant documentation. Planned fixtures cover a known artificial counter value, an unavailable source and refresh after the value changes.

The unchanged baseline should not satisfy the new display requirement. A hard-coded value should fail the changed-value case. A default zero should fail the unavailable-state case. These are proposed tests, not executed results or a claim about a real user interface.

6. Record hidden help as a handover finding

Allow safety interventions and legitimate clarification. Record every undocumented command, local file, private setup detail or design explanation the original author supplies to unblock the receiver.

The goal is to improve the handover, not to make someone fail by withholding necessary information. Classify a blocker by its source: missing documentation, unavailable access, incomplete environment, unclear requirement or unresolved architecture knowledge.

After the package is corrected, repeat the affected step using the updated instructions. Do not claim independent completion if the original author effectively performed the difficult part off-record.

7. Review the change as maintainers would

Review area	Evidence to inspect
Requirement understanding	Impact note and explicit acceptance observations
Implementation scope	Small reviewed diff and dependency explanation
Verification	Baseline contrast, negative case and regression receipts
Documentation	Updated behavior and known limits
Independent operation	Recorded interventions and resolved blockers

Keep the exercise artifact separate from a release candidate unless a later authorized process adopts it. A training branch should not accidentally become a shipped update.

8. State the readiness conclusion narrowly

Report the change class completed, environment used, evidence retained and gaps that remain. One successful diagnostic-page change does not demonstrate readiness for bootloader changes, safety functions or complex concurrency defects.

Use the result to decide which maintenance paths are supported by the handover and which need additional documentation, access or training. The useful outcome is a demonstrated, bounded change workflow that the receiving team can repeat, without hidden dependence on the original developer or an unsupported promise of universal maintenance capability.