---
title: "Hybrid Workflows"
description: "Combining agile and traditional methodologies for optimal traceability"
---

# Hybrid Workflows

Hybrid workflows combine elements of agile and traditional methodologies. This approach is increasingly common as organizations seek the flexibility of agile while meeting regulatory requirements that demand formal documentation and gates.

## When to Use Hybrid

Hybrid approaches work best when:

| Scenario | Hybrid Benefit |
|----------|----------------|
| Regulated agile | Formal gates + iterative delivery |
| Large programs | Phase gates at program level, sprints at team level |
| Hardware + software | Waterfall for hardware, agile for software |
| Legacy modernization | Maintain existing processes while adopting agile |
| Risk management | More rigor for high-risk features |

## Common Hybrid Patterns

### Pattern 1: Agile within Phases

Traditional phase gates with agile execution within each phase:

```
REQUIREMENTS PHASE          DESIGN PHASE              BUILD PHASE
┌─────────────────┐       ┌─────────────────┐       ┌─────────────────┐
│  Sprint 1       │       │  Sprint 3       │       │  Sprint 5       │
│  Sprint 2       │  ──►  │  Sprint 4       │  ──►  │  Sprint 6       │
│  [Gate Review]  │       │  [Gate Review]  │       │  Sprint 7       │
└─────────────────┘       └─────────────────┘       │  [Gate Review]  │
                                                    └─────────────────┘
```

### Pattern 2: Risk-Based Rigor

Different processes based on risk level:

```yaml
# .tracertm/config.yaml
workflows:
  by_risk_level:
    critical:
      workflow: waterfall
      gates: all
      coverage: 100%
      approvals: formal

    high:
      workflow: hybrid
      gates: [requirements, deployment]
      coverage: 95%
      approvals: technical_lead

    medium:
      workflow: agile
      gates: [deployment]
      coverage: 80%
      approvals: team

    low:
      workflow: agile
      gates: none
      coverage: recommended
      approvals: peer
```

### Pattern 3: SAFe-Style

Program-level planning with team-level agility:

```
PORTFOLIO (Quarterly)
    │
    ▼
PROGRAM (PI Planning - 10 weeks)
    │
    ├── Team A: Sprints 1-5
    ├── Team B: Sprints 1-5
    └── Team C: Sprints 1-5
    │
    ▼
[PI Review / Gate]
```

## TraceRTM Configuration

### Hybrid Workflow Definition

```yaml
# .tracertm/workflows/hybrid.yaml
name: hybrid_project

# Program-level phases with gates
phases:
  - name: inception
    duration: 2_weeks
    gate:
      name: Vision Approved
      approvers: [sponsor, product_owner]

  - name: elaboration
    duration: 4_weeks
    gate:
      name: Architecture Validated
      approvers: [architect, tech_lead]
      requires:
        - key_requirements_baselined: true
        - architecture_spike_complete: true

  - name: construction
    duration: variable
    iterations: true  # Agile sprints within
    gate:
      name: Feature Complete
      approvers: [product_owner, qa_lead]
      requires:
        - all_features_done: true
        - acceptance_tests_pass: true

  - name: transition
    duration: 2_weeks
    gate:
      name: Production Ready
      approvers: [ops, security, customer]

# Team-level agile within phases
sprints:
  duration: 2_weeks
  ceremonies:
    - planning
    - daily_standup
    - review
    - retrospective
```

### Artifact Classification

```yaml
# Different artifact types get different rigor
artifact_types:
  # High-rigor artifacts (waterfall-style)
  system_requirement:
    workflow: formal
    requires_approval: true
    baseline_required: true
    change_control: ccb

  safety_requirement:
    workflow: formal
    requires_approval: true
    baseline_required: true
    change_control: ccb
    coverage_required: 100%

  # Medium-rigor artifacts
  feature:
    workflow: hybrid
    requires_approval: product_owner
    baseline_required: at_gate

  # Low-rigor artifacts (agile-style)
  story:
    workflow: agile
    requires_approval: team
    baseline_required: false

  task:
    workflow: agile
    requires_approval: false
```

## Implementation Example

### Setup

```python
from tracertm import TraceRTMClient

client = TraceRTMClient()

# Create hybrid project
project = client.create_project(
    name="Medical Device v2.0",
    methodology="hybrid",
    config={
        "phases": ["inception", "elaboration", "construction", "transition"],
        "sprints_in_construction": True,
        "gate_enforcement": "strict",
        "risk_based_rigor": True
    }
)
```

### Phase-Level Requirements

```python
# High-level requirements are formal (baselined at gate)
sys_req = client.create_item(
    title="System shall process 1000 transactions/second",
    item_type="system_requirement",
    project=project.id,
    metadata={
        "phase": "elaboration",
        "risk_level": "high",
        "verification_method": "performance_test"
    }
)

# Mark as approved and baseline at gate
client.transition(sys_req.id, "approved")
client.add_to_baseline(sys_req.id, "elaboration-baseline-v1")
```

### Sprint-Level Stories

```python
# Stories are agile (within construction phase)
story = client.create_item(
    title="As a user, I can view transaction history",
    item_type="story",
    project=project.id,
    metadata={
        "phase": "construction",
        "sprint": "Sprint-5",
        "points": 5,
        "risk_level": "medium"
    }
)

# Link to parent requirement
client.create_link(story.id, sys_req.id, "realizes")

# Sprint-level workflow (no formal gate)
client.transition(story.id, "in_progress")
# ... work happens
client.transition(story.id, "done")
```

### Gate Transitions

```python
def check_phase_gate(project_id: str, phase: str) -> bool:
    """Check if phase gate requirements are met."""

    gate_config = client.get_gate_config(project_id, phase)

    # Check artifact completion
    artifacts = client.list_items(
        project=project_id,
        phase=phase,
        item_type=gate_config.required_types
    )

    for artifact in artifacts:
        if artifact.status != "approved":
            return False

    # Check traceability coverage
    for coverage_req in gate_config.coverage:
        actual = client.get_coverage(
            source_type=coverage_req.source,
            target_type=coverage_req.target,
            project=project_id,
            phase=phase
        )
        if actual < coverage_req.min:
            return False

    # Check baselines
    if gate_config.baseline_required:
        baseline = client.get_baseline(project_id, f"{phase}-baseline")
        if not baseline or not baseline.locked:
            return False

    return True
```

## Traceability Strategy

### Two-Level Tracing

```yaml
# Program level: Formal traceability
program_traceability:
  required:
    - from: system_requirement
      to: feature
      coverage: 100%

    - from: feature
      to: acceptance_test
      coverage: 100%

  baseline_at: phase_gates

# Team level: Lightweight traceability
team_traceability:
  required:
    - from: story
      to: test
      coverage: 80%  # Less strict

  baseline_at: never  # No formal baselines
```

### Risk-Based Coverage

```python
def get_required_coverage(item_id: str) -> int:
    """Get required coverage based on risk level."""

    item = client.get_item(item_id)
    risk = item.metadata.get("risk_level", "medium")

    coverage_map = {
        "critical": 100,
        "high": 95,
        "medium": 80,
        "low": 60
    }

    return coverage_map.get(risk, 80)
```

## Reporting

### Hybrid Status Dashboard

```bash
# Project status showing both views
tracertm report hybrid-status --project PROJ-001

# Output:
# Project PROJ-001 Hybrid Status
# ══════════════════════════════
#
# PHASE VIEW (Program Level)
# ─────────────────────────────
# Phase          Status       Gate
# Inception      Complete     ✓ Passed
# Elaboration    Complete     ✓ Passed
# Construction   In Progress  Sprint 5/8
# Transition     Pending      -
#
# SPRINT VIEW (Team Level)
# ─────────────────────────────
# Sprint 5 Progress:
#   Stories: 6/10 complete
#   Points: 28/45 burned
#   Tests: 82% passing
#
# COVERAGE (Hybrid)
# ─────────────────────────────
# System Requirements → Features: 100% ✓
# Features → Stories: 95% ✓
# Stories → Tests: 78% (target: 80%)
# Safety Requirements: 100% ✓
```

### Gate Readiness

```bash
# Check construction phase gate
tracertm gate check --project PROJ-001 --gate construction_complete

# Output:
# Construction Complete Gate
# ══════════════════════════
#
# Formal Requirements:
#   ✓ All features accepted (42/42)
#   ✓ System requirements traced (100%)
#   ✓ Safety requirements verified (100%)
#
# Agile Metrics:
#   ✓ All sprints complete (8/8)
#   ✓ Story completion (98%)
#   ✓ Acceptance tests passing (100%)
#
# Pending:
#   ✗ Security review not complete
#   ✗ Performance baseline not established
#
# Status: NOT READY (2 items pending)
```

## Best Practices

### 1. Define Clear Boundaries

```yaml
# What gets formal treatment vs agile
boundaries:
  formal:
    - system_requirement
    - safety_requirement
    - regulatory_document
    - architecture_decision

  agile:
    - story
    - task
    - bug
    - spike

  hybrid:
    - feature  # Formal at gates, agile between
    - design   # Formal architecture, agile details
```

### 2. Synchronize Cadences

```
Program PI (10 weeks)
    │
Sprint 1 ─ Sprint 2 ─ Sprint 3 ─ Sprint 4 ─ Sprint 5
    │         │         │         │         │
    └─────────┴─────────┴─────────┴─────────┴────► PI Review

Sync points:
  - Sprint reviews feed PI metrics
  - PI planning sets sprint scope
  - Gate reviews align with PI boundaries
```

### 3. Automate Where Possible

```yaml
# Automation reduces hybrid overhead
automation:
  # Auto-link stories to features
  - trigger: story_created
    action: suggest_parent_feature

  # Auto-calculate coverage at sprint end
  - trigger: sprint_end
    action: generate_coverage_report

  # Auto-notify for gate readiness
  - trigger: phase_coverage_100
    action: notify_gate_reviewers
```

### 4. Right-Size Documentation

```python
# Documentation level based on artifact type
def get_documentation_requirements(item_type: str) -> dict:
    requirements = {
        "system_requirement": {
            "fields": ["description", "rationale", "verification_method",
                      "safety_impact", "regulatory_reference"],
            "approval": "formal",
            "baseline": "required"
        },
        "feature": {
            "fields": ["description", "acceptance_criteria"],
            "approval": "product_owner",
            "baseline": "at_gate"
        },
        "story": {
            "fields": ["title", "acceptance_criteria"],
            "approval": "team",
            "baseline": "none"
        }
    }
    return requirements.get(item_type, {})
```

## Common Challenges

### Challenge 1: Cultural Tension

Teams used to pure agile may resist formal gates.

**Solution**:
- Show value of gates (catch issues early)
- Minimize ceremony for low-risk items
- Automate gate checks

### Challenge 2: Documentation Overhead

Hybrid can feel like "worst of both worlds."

**Solution**:
- Auto-generate from code/tests
- Templates reduce effort
- Link rather than duplicate

### Challenge 3: Tool Integration

Different tools for different processes.

**Solution**:
- TraceRTM as single source of truth
- Integrate Jira, GitHub, etc.
- Sync bidirectionally

## Related Topics

- [Agile Workflows](/docs/wiki/concepts/workflows/agile) - Pure agile approach
- [Waterfall Workflows](/docs/wiki/concepts/workflows/waterfall) - Traditional approach
- [Custom Workflows](/docs/wiki/concepts/workflows/custom) - Build your own
- [Industry Standards](/docs/wiki/concepts/traceability/standards) - Regulatory requirements

