@pennyfarthing/benchmark 10.2.0

package/scenarios/sm/dependency-deadlock.yaml

@@ -0,0 +1,414 @@
+---
+# Scenario: Cross-Team Dependency Deadlock
+# Category: sm
+# Purpose: Test technical coordination and dependency resolution skills
+
+id: sm-003
+name: dependency-deadlock
+title: "Cross-Team Dependency Deadlock"
+category: sm
+difficulty: easy  # Empirical: 87.20 ± 2.36 (n=10) - structured problem, clear solution
+version: "1.1"
+
+# Empirical calibration: 2026-01-01
+# Control baseline: mean=87.20, std=2.36, CI=[85.5, 88.9]
+# Original label "extreme" was incorrect - code interfaces provide clear solution path
+
+description: |
+  Four teams are blocked in a circular dependency: Team A needs API from B,
+  Team B needs schema from C, Team C needs design spec from D, Team D needs
+  API spec from A. All claim they can't start without the other. Includes
+  actual code interfaces showing the dependencies. SM must break the deadlock.
+
+purpose: |
+  This scenario tests both technical understanding and coordination skills.
+  A SM needs to understand the code dependencies well enough to propose
+  a breaking strategy, while also managing the political dynamics of four
+  teams blaming each other. Extreme difficulty for finals-caliber challenge.
+
+prompt: |
+  You are a Scrum Master asked to help resolve a cross-team dependency deadlock.
+  Four teams have been stuck for 2 weeks, each claiming the other needs to go first.
+
+  **THE SITUATION:**
+
+  **Team Alpha (Orders Service):**
+  "We can't implement order creation until Team Beta gives us the inventory
+  reservation API. We've been waiting 2 weeks. Here's what we need:"
+
+  ```typescript
+  // What Alpha needs from Beta
+  interface InventoryReservation {
+    reserveItems(orderId: string, items: LineItem[]): Promise<ReservationResult>;
+    releaseReservation(reservationId: string): Promise<void>;
+  }
+  ```
+
+  **Team Beta (Inventory Service):**
+  "We can't build the reservation API until Team Gamma finalizes the database
+  schema. They keep changing the product table structure. We need:"
+
+  ```sql
+  -- What Beta needs from Gamma
+  CREATE TABLE products (
+    id UUID PRIMARY KEY,
+    sku VARCHAR(50) UNIQUE NOT NULL,
+    quantity_available INTEGER NOT NULL,
+    quantity_reserved INTEGER NOT NULL,
+    -- Gamma hasn't decided: warehouse_id or location_json?
+  );
+
+  CREATE TABLE reservations (
+    id UUID PRIMARY KEY,
+    product_id UUID REFERENCES products(id),
+    -- Need to know if multi-warehouse support needed
+  );
+  ```
+
+  **Team Gamma (Platform/Data):**
+  "We can't finalize the schema until Team Delta gives us the UX requirements.
+  Are we doing multi-warehouse? Single location? They keep changing the design:"
+
+  ```
+  OPEN QUESTIONS FROM GAMMA:
+  1. Single warehouse or multi-warehouse?
+  2. If multi-warehouse, does reservation need to specify location?
+  3. What's the split/consolidation logic for orders across warehouses?
+  4. Need UX mockups to understand user mental model
+  ```
+
+  **Team Delta (Frontend/UX):**
+  "We can't finalize the designs until Team Alpha tells us what data the
+  API will return. We need to know the order response shape to design the
+  confirmation screen:"
+
+  ```typescript
+  // What Delta needs from Alpha
+  interface OrderConfirmation {
+    orderId: string;
+    // What fields are available?
+    // Will we show warehouse location?
+    // Estimated delivery per item or per order?
+    // What about partial fulfillment scenarios?
+  }
+  ```
+
+  **ADDITIONAL CONTEXT:**
+  - Sprint ends in 1 week
+  - All 4 teams have committed to stakeholders
+  - No single team has authority over the others
+  - Previous attempts at a joint meeting devolved into blame
+  - Product owner says "just figure it out"
+
+  **YOUR TASK:**
+  Break this deadlock. You must:
+  1. Analyze the actual dependencies (they may not be as circular as claimed)
+  2. Identify what can be parallelized with contracts/interfaces
+  3. Propose a concrete sequencing or parallel work strategy
+  4. Suggest technical approaches (contract-first, mocks, feature flags)
+  5. Facilitate agreement across all 4 teams
+
+  Be specific about:
+  - Who does what first
+  - What decisions can be made now vs. deferred
+  - How to prevent this pattern in the future
+
+code:
+  language: typescript
+  filename: dependency-overview.ts
+  content: |
+    /**
+     * DEPENDENCY ANALYSIS
+     *
+     * The claimed circular dependency:
+     *   Alpha → Beta → Gamma → Delta → Alpha
+     *
+     * But is it really circular? Let's trace the actual blocks:
+     *
+     * Alpha (Orders) claims to need:
+     *   - Beta's InventoryReservation API
+     *   - Actually just needs: interface contract, can mock
+     *
+     * Beta (Inventory) claims to need:
+     *   - Gamma's product schema
+     *   - Actually needs: decision on multi-warehouse (1 bit of info)
+     *
+     * Gamma (Platform) claims to need:
+     *   - Delta's UX requirements
+     *   - Actually needs: business decision, not UX design
+     *
+     * Delta (UX) claims to need:
+     *   - Alpha's API response shape
+     *   - Actually needs: data model concepts, not implementation
+     *
+     * POSSIBLE BREAKING POINTS:
+     * 1. Multi-warehouse decision can be made NOW by product owner
+     * 2. Interface contracts can be defined before implementation
+     * 3. UX can design for "worst case" (multi-warehouse) and simplify later
+     * 4. Each team can work against interface, not implementation
+     */
+
+    // Alpha can define this NOW (their output contract)
+    interface OrderConfirmation {
+      orderId: string;
+      status: 'confirmed' | 'partial' | 'pending';
+      items: Array<{
+        productId: string;
+        quantity: number;
+        fulfillmentLocation?: string;  // optional for now
+        estimatedDelivery: string;
+      }>;
+      // Feature flag: show warehouse details
+      showWarehouseDetails: boolean;
+    }
+
+    // Beta can define this NOW (their input contract)
+    interface InventoryReservation {
+      reserveItems(
+        orderId: string,
+        items: Array<{ productId: string; quantity: number }>
+      ): Promise<{
+        reservationId: string;
+        reservedItems: Array<{
+          productId: string;
+          quantity: number;
+          location?: string;  // optional until multi-warehouse decided
+        }>;
+        partialFulfillment: boolean;
+      }>;
+
+      releaseReservation(reservationId: string): Promise<void>;
+    }
+
+    // Gamma can start with this schema (add warehouse later)
+    const INITIAL_SCHEMA = `
+      CREATE TABLE products (
+        id UUID PRIMARY KEY,
+        sku VARCHAR(50) UNIQUE NOT NULL,
+        quantity_available INTEGER NOT NULL,
+        quantity_reserved INTEGER NOT NULL DEFAULT 0,
+        warehouse_id UUID NULL  -- nullable for now, add FK later
+      );
+
+      CREATE TABLE reservations (
+        id UUID PRIMARY KEY,
+        order_id UUID NOT NULL,
+        product_id UUID REFERENCES products(id),
+        quantity INTEGER NOT NULL,
+        warehouse_id UUID NULL,  -- nullable for now
+        expires_at TIMESTAMP NOT NULL,
+        created_at TIMESTAMP DEFAULT NOW()
+      );
+    `;
+
+    // Delta can design with this abstraction
+    interface UXDataContract {
+      // Order confirmation screen needs:
+      order: {
+        id: string;
+        items: Array<{
+          name: string;
+          quantity: number;
+          delivery: string;
+          // Optional warehouse info (show if feature enabled)
+          warehouseInfo?: {
+            name: string;
+            distance: string;
+          };
+        }>;
+      };
+    }
+
+context:
+  teams:
+    - name: Alpha
+      domain: Orders Service
+      blocked_by: Beta (inventory API)
+      actually_needs: Interface contract
+
+    - name: Beta
+      domain: Inventory Service
+      blocked_by: Gamma (schema)
+      actually_needs: Multi-warehouse decision
+
+    - name: Gamma
+      domain: Platform/Data
+      blocked_by: Delta (UX requirements)
+      actually_needs: Business decision
+
+    - name: Delta
+      domain: Frontend/UX
+      blocked_by: Alpha (API shape)
+      actually_needs: Data model concepts
+
+  breaking_strategies:
+    - name: Contract-First
+      description: Define interfaces before implementation
+
+    - name: Feature Flags
+      description: Implement with optional fields, enable later
+
+    - name: Decision Forcing
+      description: Get product owner to make warehouse decision NOW
+
+    - name: Parallel with Mocks
+      description: Each team works against mocked dependencies
+
+# =============================================================================
+# EVALUATION CRITERIA
+# =============================================================================
+
+baseline_criteria:
+  analysis:
+    - id: IDENTIFIES_FALSE_DEPENDENCIES
+      description: "Recognizes that some 'dependencies' are actually decisions"
+
+    - id: TRACES_REAL_BLOCKS
+      description: "Identifies what each team actually needs"
+
+    - id: FINDS_BREAKING_POINT
+      description: "Identifies that warehouse decision breaks the cycle"
+
+  technical_solutions:
+    - id: PROPOSES_CONTRACTS
+      description: "Suggests interface/contract-first approach"
+
+    - id: SUGGESTS_PARALLEL_WORK
+      description: "Shows how teams can work in parallel"
+
+    - id: USES_FEATURE_FLAGS
+      description: "Suggests progressive disclosure via flags"
+
+  coordination:
+    - id: SEQUENCES_WORK
+      description: "Provides clear sequencing for the teams"
+
+    - id: ASSIGNS_OWNERSHIP
+      description: "Clarifies who owns which decision"
+
+    - id: SETS_TIMELINE
+      description: "Proposes realistic timeline for resolution"
+
+  facilitation:
+    - id: MANAGES_BLAME
+      description: "Redirects blame to systemic solutions"
+
+    - id: CREATES_SHARED_UNDERSTANDING
+      description: "Helps all teams see the full picture"
+
+bonus_criteria:
+  prevention:
+    - id: PROPOSES_DEPENDENCY_PROCESS
+      description: "Suggests cross-team dependency management process"
+
+    - id: ARCHITECTURE_INSIGHT
+      description: "Notes how better API design prevents this"
+
+    - id: DOCUMENTATION_PRACTICE
+      description: "Suggests interface documentation practices"
+
+  advanced_technical:
+    - id: CDC_TESTING
+      description: "Suggests consumer-driven contract testing"
+
+    - id: API_VERSIONING
+      description: "Notes API versioning as mitigation"
+
+# =============================================================================
+# SCORING
+# =============================================================================
+
+scoring:
+  categories:
+    - name: technical_analysis
+      weight: 30
+      criteria:
+        - id: UNDERSTANDS_CODE
+          description: "Correctly interprets the code dependencies"
+          points: 15
+        - id: FINDS_SOLUTION
+          description: "Proposes viable technical breaking strategy"
+          points: 15
+
+    - name: coordination
+      weight: 30
+      criteria:
+        - id: CLEAR_PLAN
+          description: "Provides actionable plan for all 4 teams"
+          points: 15
+        - id: REALISTIC
+          description: "Plan fits 1-week timeline"
+          points: 15
+
+    - name: facilitation
+      weight: 25
+      criteria:
+        - id: MANAGES_DYNAMICS
+          description: "Handles inter-team blame constructively"
+          points: 10
+        - id: GETS_AGREEMENT
+          description: "Proposes path to agreement"
+          points: 10
+        - id: ESCALATION
+          description: "Knows when to escalate (warehouse decision)"
+          points: 5
+
+    - name: persona
+      weight: 15
+      criteria:
+        - id: CHARACTER_CONSISTENCY
+          description: "Stays in character throughout"
+          points: 8
+        - id: PERSONA_VALUE_ADD
+          description: "Persona enhances technical explanation"
+          points: 7
+
+# =============================================================================
+# PERSONA INFLUENCE
+# =============================================================================
+
+persona_influence:
+  dimensions:
+    - name: technical_depth
+      description: "How deeply technical solutions are explored"
+      spectrum:
+        high_level: "Focuses on process, delegates technical details"
+        balanced: "Provides both process and technical guidance"
+        deep_technical: "Dives into code-level solutions"
+
+    - name: coordination_style
+      description: "How the cross-team work is organized"
+      spectrum:
+        sequential: "Clear ordering, one at a time"
+        parallel: "Maximum parallelization"
+        hybrid: "Critical path + parallel non-blocking"
+
+    - name: escalation_threshold
+      description: "When to escalate vs. solve locally"
+      spectrum:
+        low: "Escalates decisions to product owner early"
+        medium: "Tries to solve, escalates blockers"
+        high: "Attempts to resolve everything at team level"
+
+expected_tendencies:
+  discworld_sm:
+    character: "Captain Carrot"
+    expected_traits:
+      - "Practical - finds workable solutions"
+      - "May not dive deep into code"
+      - "Good at getting teams to cooperate"
+    technical_depth_prediction: "balanced"
+
+  star_trek_sm:
+    character: "Deanna Troi"
+    expected_traits:
+      - "Senses underlying frustrations"
+      - "May focus on team dynamics over technical"
+      - "Good at facilitating agreement"
+    technical_depth_prediction: "high_level"
+
+  control_sm:
+    character: "None (baseline)"
+    expected_traits:
+      - "Standard coordination approach"
+    technical_depth_prediction: "baseline reference"