Skip to content

Scaling FCC Across Projects

Once your team has successfully adopted FCC on a single project, scaling it across multiple projects requires planning around shared registries, centralized governance, and project-specific customization.

Multi-Project Deployment Architecture

A typical multi-project FCC deployment has three layers:

Central FCC Framework (shared)
    |
    +-- Shared Persona Registry (organization-wide personas)
    |
    +-- Shared Governance Config (quality gates, tags, compliance rules)
    |
    +-- Project A (project-specific personas + overrides)
    |
    +-- Project B (project-specific personas + overrides)
    |
    +-- Project C (project-specific personas + overrides)

Shared Registries

Use PersonaRegistry.from_yaml_directory() to load a shared persona directory, then merge() to add project-specific personas:

from fcc.personas.registry import PersonaRegistry

# Load organization-wide personas
shared = PersonaRegistry.from_yaml_directory("shared/personas/")

# Load project-specific personas
project = PersonaRegistry.from_yaml("project_a/custom_personas.yaml")

# Merge: project personas override shared ones with same ID
combined = shared.merge(project)

This pattern ensures all projects share a common baseline while allowing targeted customization.

Centralized Governance

Maintain a single source of truth for governance configuration:

  • Quality gates (quality_gates.yaml): Define organization-wide thresholds, allow projects to tighten (but not loosen) them
  • Tag registry (tag_registry.yaml): Use a shared tag taxonomy so metrics aggregate across projects
  • Compliance rules: Governance personas (DGS, PTE, AMS, GCA) should use organization-wide policies

Store shared governance configuration in a dedicated repository or directory that all projects reference.

Persona Customization Per Project

Each project can customize FCC in several ways without modifying the core framework:

1. Custom Persona YAML

Add project-specific personas with unique IDs that do not conflict with the shared registry:

personas:
  - id: APIDOC
    name: API Documentation Specialist
    fcc_phase: Create
    role_title: API Writer
    category: integration
    riscear:
      role: "Produces OpenAPI specifications and developer guides."
      # ... full R.I.S.C.E.A.R. specification

2. Quality Gate Threshold Overrides

Projects with stricter requirements can raise quality gate thresholds:

quality_gates:
  - id: QG-BC-001
    name: Blueprint Completeness
    persona_id: BC
    threshold: 0.95  # Raised from default 0.75
    checks:
      - architecture_diagrams
      - api_specifications
      - data_models
      - workflow_definitions

3. Custom Templates

Projects can override Jinja2 templates by providing a project-specific templates directory:

from fcc.scaffold.doc_generator import DocGenerator

generator = DocGenerator(
    registry=combined,
    templates_dir=Path("project_a/templates/"),
)

4. Custom Scenarios

Each project defines its own validation scenarios targeting project-specific workflows and quality criteria. See the Custom Scenarios tutorial.

Cross-Project Metrics

Use SAFe Metrics Crafter (SMC) and capability tags to aggregate metrics across projects:

Metric Scope How to Aggregate
Quality gate pass rate Per project, rolled up to org Average pass rate by gate ID
Documentation coverage Per project Count artifacts against capability tags
Simulation success rate Per project SimulationResult.pass_rate averaged
Governance compliance Per project, rolled up GCA audit scores by governance dimension
Persona utilization Per project Track which personas are activated per simulation

Deployment Patterns

Pattern 1: Shared Library

Install FCC as a shared Python package and configure per project via environment variables or configuration files.

pip install -e path/to/l2_fcc_agent_team_ext

Pattern 2: Monorepo

Include FCC as a subdirectory in a monorepo with project-specific overlays in sibling directories.

Pattern 3: Template Repository

Maintain a GitHub template repository with FCC pre-configured, then clone for each new project.

Coordination Across Projects

For multi-project deployments, these personas become especially important:

  • CO (Collaboration Orchestrator): Manages cross-project handoffs and dependency tracking
  • RS (Roadmap Synchronizer): Aligns documentation timelines across projects
  • EC (Executive Communicator): Produces cross-project executive summaries
  • SCP (Stakeholder Content Publisher): Manages multi-channel publishing across projects

Champion personas (RCHM, BCHM, UGCH, RBCH) are particularly valuable in multi-project settings where they coordinate persona teams spanning project boundaries.

Next Steps