jumpstart-mode 1.1.13 → 1.1.14

package/.jumpstart/skills/dependency-bottleneck-detector/references/proactive-detection.md

@@ -0,0 +1,155 @@
+# Proactive Detection
+
+How to spot dependencies before they become blockers, and signals that a dependency is about to become critical.
+
+---
+
+## Sprint Planning Dependency Scan
+
+Before each sprint, scan upcoming work for hidden dependencies:
+
+### Checklist Per Work Item
+
+```
+For each planned sprint item, ask:
+□ Can we start this with what we have today?
+□ Do we need access to a system we don't have yet?
+□ Do we need data we haven't received yet?
+□ Do we need a decision that hasn't been made yet?
+□ Do we need input from someone not on our team?
+□ Do we need an environment we don't have yet?
+□ Do we need credentials or certificates we don't have yet?
+□ Do we need approval from a review board?
+□ Do we need a client deliverable we haven't received?
+□ Does this depend on another team's work being complete?
+```
+
+If any answer is "yes" and the dependency is not already in progress, it should be flagged.
+
+---
+
+## Lead Time Awareness
+
+Know the typical lead times in your organization and start requests early:
+
+| Dependency Type | Typical Lead Time | When to Request |
+|----------------|:-----------------:|-----------------|
+| Cloud environment provisioning | 1-2 weeks | 3 weeks before needed |
+| Security review | 3-6 weeks | 8 weeks before go-live |
+| Firewall rule change | 1-3 weeks | 4 weeks before integration |
+| App registration (IdP) | 1-3 weeks | 4 weeks before auth development |
+| API gateway onboarding | 2-4 weeks | 6 weeks before integration |
+| Penetration test | 2-4 weeks | 6 weeks before go-live |
+| Legal contract review | 2-4 weeks | 6 weeks before signature |
+| License procurement | 1-4 weeks | 5 weeks before needed |
+| UAT scheduling | 1-2 weeks | 3 weeks before UAT sprint |
+| Production deployment slot | 1-2 weeks | 3 weeks before target date |
+
+---
+
+## Early Warning Signals
+
+### Signal: Vague Ownership
+- **Pattern**: "Someone on their team will handle it"
+- **Risk**: No specific person means no accountability
+- **Action**: Get a named owner with a commitment date
+
+### Signal: Assumed Access
+- **Pattern**: "We'll get access when we need it"
+- **Risk**: Access processes have lead times nobody has accounted for
+- **Action**: Submit the request now, even if the work is sprints away
+
+### Signal: Client Silence
+- **Pattern**: Client dependency in the plan but no follow-up cadence
+- **Risk**: Client teams have their own priorities and may not be tracking your need
+- **Action**: Send weekly reminders and track in status reports
+
+### Signal: Single Point of Failure
+- **Pattern**: Only one person can approve/provide/configure X
+- **Risk**: Vacation, illness, reassignment creates total block
+- **Action**: Identify backup, get delegation approval, or front-load the dependency
+
+### Signal: Process Unknown
+- **Pattern**: "We need X but we don't know the process to get it"
+- **Risk**: Discovering the process burns time, the process itself burns more
+- **Action**: Research the process immediately and start it in parallel
+
+### Signal: "It Should Be Easy"
+- **Pattern**: The dependency is described as trivial but hasn't been attempted
+- **Risk**: Easy things that haven't been done often turn out to not be easy
+- **Action**: Attempt it immediately to validate the assumption
+
+### Signal: Cross-Org Dependency
+- **Pattern**: Dependency is owned by a different department, BU, or company
+- **Risk**: No shared management chain, different priorities, slow communication
+- **Action**: Establish a direct communication channel early, not through intermediaries
+
+### Signal: Seasonal/Cyclical Block
+- **Pattern**: Dependency owner is subject to quarterly close, year-end freeze, audit prep
+- **Risk**: Normal processes stop during these periods
+- **Action**: Map known freeze periods and request well before they start
+
+---
+
+## Dependency Radar
+
+Maintain a simple dependency radar as part of sprint ceremonies:
+
+### Quadrants
+
+| | On Track | At Risk |
+|---|---------|---------|
+| **This Sprint** | Dependencies needed this sprint that are progressing normally | Dependencies needed this sprint that are delayed or uncertain |
+| **Next Sprint** | Dependencies for next sprint that have been requested | Dependencies for next sprint that have NOT been requested yet |
+
+### Update Cadence
+- Review at standup (daily): Any blocker status changes?
+- Review at sprint planning (bi-weekly): What new dependencies exist?
+- Review at retrospective: What blocked us? How to prevent next time?
+
+---
+
+## Proactive Request Patterns
+
+### Pattern 1: The Dependency Sprint
+Dedicate sprint 0 or the first sprint to submitting ALL foreseeable dependency requests simultaneously. Accept that most won't be needed for weeks, but start the clock on all lead times at once.
+
+### Pattern 2: The Dependency Owner Map
+In the first week of engagement, build a map of who owns what:
+- Who provisions environments?
+- Who approves access?
+- Who grants API keys?
+- Who does security review?
+- Who makes scope decisions?
+- Who does legal review?
+- What are their SLAs?
+- What is their request process?
+
+### Pattern 3: The Dependency Standup
+Add a standing question to daily standup:
+"Is there anything you need from outside the team that you haven't requested yet?"
+
+### Pattern 4: The Future State Scan
+For each architectural component in the solution:
+- What does it need to connect to?
+- What credentials does it need?
+- What network path does it need?
+- What approvals does it need?
+- Who needs to configure it?
+
+If the answer to any of these is "someone else," it's a dependency to track.
+
+---
+
+## Prevention vs. Detection
+
+| Approach | When | Effort | Effectiveness |
+|----------|------|--------|--------------|
+| Sprint 0 dependency submission | Project start | Medium (1-2 days) | High — starts all clocks early |
+| Dependency owner mapping | Week 1 | Low (half day) | High — know who to ask |
+| Sprint planning scan | Every sprint | Low (30 min) | Medium — catches near-term |
+| Architecture dependency analysis | Design phase | Medium (1 day) | High — catches systemic |
+| Daily standup question | Daily | Negligible | Medium — catches emerging |
+| Retrospective review | End of sprint | Low (15 min) | Medium — prevents recurrence |
+
+The most cost-effective intervention is submitting all dependency requests at project start, even when the dependencies aren't needed for weeks. The lead time starts the moment you ask, not the moment you need.

package/.jumpstart/skills/dependency-bottleneck-detector/references/unblock-strategies.md

@@ -0,0 +1,274 @@
+# Unblock Strategies
+
+Detailed strategies for resolving dependency bottlenecks, with templates, examples, and decision criteria for when to use each approach.
+
+---
+
+## Strategy 1: Escalation
+
+### When to Use
+- The dependency has an owner but they are unresponsive
+- SLA has been breached or will be breached imminently
+- The request is in a queue with no movement
+- The blocking team doesn't understand the urgency
+
+### Escalation Levels
+
+| Level | Trigger | Action |
+|-------|---------|--------|
+| L0: Remind | 2+ days no response | Follow-up message to original owner |
+| L1: Manager | 5+ days or SLA breach | Escalate to dependency owner's manager |
+| L2: Director | 10+ days or critical path risk | Escalate to director with impact statement |
+| L3: VP/Exec | 15+ days or delivery date at risk | Executive escalation with business impact |
+| L4: Sponsor | Delivery failure imminent | Joint executive conversation |
+
+### Escalation Message Template
+```
+Subject: [BLOCKED] {Delivery team} waiting on {dependency} — delivery at risk
+
+Hi {escalation target},
+
+Our team has been waiting {N} business days for {specific dependency}.
+This was requested on {date} from {person/team}.
+
+Impact: {specific work items} are blocked. If not resolved by {date},
+{delivery consequence — e.g., "sprint 3 delivery will slip by 1 week"}.
+
+What we need: {specific ask — e.g., "API sandbox access provisioned by Friday"}.
+
+Can you help us unblock this? Happy to discuss context.
+```
+
+### Key Principles
+- Always escalate with **facts, impact, and ask** — never just complaint
+- Quantify the cost of delay in terms the escalation target cares about
+- Offer to help reduce friction (provide info, join a call, simplify the ask)
+- Escalate the dependency, not the person — maintain relationships
+
+---
+
+## Strategy 2: Parallelization
+
+### When to Use
+- The blocked work has unblocked sub-tasks that can proceed
+- Other sprint items can be pulled forward
+- The team can work on adjacent features while waiting
+- Foundation work (tests, infrastructure, documentation) can continue
+
+### Techniques
+- **Feature reordering** — Move unblocked features earlier in the sprint
+- **Technical foundation** — Build the framework, tests, and scaffolding around the blocked integration
+- **Contract-first development** — Define the interface and build both sides independently
+- **Documentation sprint** — Use waiting time for technical documentation, runbooks, or evaluation design
+- **Tech debt reduction** — Address known technical debt that doesn't depend on the blocker
+
+### Anti-Pattern Warning
+Parallelization is a temporary strategy, not a permanent one. If the team is constantly rearranging work to avoid blockers, the blockers need escalation, not more workarounds.
+
+---
+
+## Strategy 3: Stub/Mock
+
+### When to Use
+- Waiting for an API or service that has a known interface
+- Waiting for data access but sample data can be synthesized
+- Waiting for an environment but a local substitute works
+- The team can build and test against a contract without the real thing
+
+### Techniques
+- **API mocking** — Create mock endpoints that return expected shapes (WireMock, Mockoon, Postman mock server)
+- **Interface contracts** — Define TypeScript types, OpenAPI specs, or Protobuf schemas and code against them
+- **Synthetic data** — Generate realistic test data matching the expected schema
+- **Local environment** — Docker Compose or similar for local development while waiting for cloud environment
+- **Feature flags** — Build with the integration behind a flag, enabling it when access arrives
+
+### Limitations
+- Mocks don't validate real-world behavior (errors, latency, auth flows)
+- Synthetic data doesn't catch production data quality issues
+- Local environments don't replicate network policies
+- Must plan time to replace mocks with real integrations
+
+---
+
+## Strategy 4: Decomposition
+
+### When to Use
+- A large dependency can be broken into smaller parts
+- Some aspects of the dependency are available while others aren't
+- Partial access is possible (read-only, limited scope, specific tables)
+- The approval can be staged (non-prod first, then prod)
+
+### Techniques
+- **Phased access** — Get read access first, write access later
+- **Scope reduction** — Request access to specific tables/fields instead of full database
+- **Environment staging** — Get dev access first while prod access is processed
+- **Role separation** — Get basic access first, privileged access later
+- **Temporal decomposition** — Get batch access now, real-time later
+
+### Example
+Instead of waiting 4 weeks for full production database access:
+1. Week 1: Get read access to a reporting replica (often faster approval)
+2. Week 2: Build and test against replica
+3. Week 3: Process production access request in parallel
+4. Week 4: Validate against production when access arrives
+
+---
+
+## Strategy 5: Alternative Path
+
+### When to Use
+- The original approach is blocked but an alternative achieves the same goal
+- A different technology, vendor, or method avoids the dependency entirely
+- The cost of the alternative is less than the cost of waiting
+- The workaround is sustainable (not just kicking the can)
+
+### Examples
+- **Blocked**: Apigee onboarding (4 weeks). **Alternative**: Direct API call in development, add gateway later.
+- **Blocked**: SSO integration (IdP team backlog). **Alternative**: Basic auth for MVP, SSO for production.
+- **Blocked**: On-prem database access (firewall change). **Alternative**: Batch data extract via existing ETL.
+- **Blocked**: Vendor API (no sandbox). **Alternative**: Screen scraping or manual data entry for evaluation.
+- **Blocked**: Security review (6-week queue). **Alternative**: Pre-engage security with design-level review while building.
+
+### Decision Criteria
+Choose alternative path when:
+- The delay cost exceeds the rework cost
+- The alternative doesn't compromise security or compliance
+- The team can cleanly swap to the original approach later
+- Stakeholders approve the temporary approach
+
+---
+
+## Strategy 6: Advance Request
+
+### When to Use
+- Future dependencies are visible but not yet blocking
+- The team can predict what will be needed in upcoming sprints
+- Lead times are long and predictable
+- The cost of early request is low
+
+### Technique
+Review the next 2-3 sprints and identify:
+- What environments will be needed?
+- What access will be needed?
+- What approvals will be needed?
+- What decisions must be made?
+- What data will be needed?
+
+Submit requests immediately, even if the work isn't starting yet. Add buffer for typical approval delays.
+
+### Advance Request Checklist
+```
+For each upcoming sprint, identify:
+□ Environment access needed
+□ Data access needed
+□ API/integration access needed
+□ Security reviews needed
+□ Compliance approvals needed
+□ People/SME time needed
+□ Client deliverables needed
+□ Vendor interactions needed
+□ Decisions needed from stakeholders
+□ Licenses or procurement needed
+```
+
+---
+
+## Strategy 7: Decision Forcing
+
+### When to Use
+- A decision is overdue and blocking multiple work items
+- Stakeholders are avoiding a decision due to uncertainty
+- Analysis paralysis is occurring
+- The team needs a "good enough" decision, not a perfect one
+
+### Technique
+Frame the cost of indecision:
+1. State the decision needed
+2. Present the options (ideally 2-3, not 10)
+3. State the recommendation with rationale
+4. Quantify the cost of delay ("every week we wait costs X")
+5. Propose a "reversible default" if no decision is made by a date
+
+### Template
+```
+Decision Needed: {what}
+Options:
+  A: {option with tradeoffs}
+  B: {option with tradeoffs}
+Recommendation: {choice} because {rationale}
+Cost of Delay: {specific impact per week/sprint}
+Default: If no decision by {date}, we will proceed with {option}
+  and can reverse course within {timeframe} if needed.
+```
+
+---
+
+## Strategy 8: Direct Contact
+
+### When to Use
+- The request went into a queue or ticketing system
+- The ticket has no assignee or the assignee is unknown
+- Email or chat messages are going unanswered
+- A human connection would accelerate the process
+
+### Techniques
+- Find the actual person (not a team alias) through org chart or colleagues
+- Schedule a 15-minute call instead of more emails
+- Offer to help them help you (provide context, reduce their work)
+- Bring context about urgency and impact
+- Follow up in writing to create a record
+
+### When NOT to Use
+- When the process genuinely requires queue-based handling (security reviews, legal)
+- When going around the process would create political problems
+- When the delay is due to policy, not responsiveness
+
+---
+
+## Strategy 9: Scope Adjustment
+
+### When to Use
+- The blocked feature is not on the critical path for MVP
+- Delivering unblocked features creates value even without the blocked one
+- The dependency has an unpredictable or very long resolution time
+- Stakeholders would prefer partial delivery over total delay
+
+### Techniques
+- **MVP scope reduction** — Move the blocked feature to post-MVP
+- **Feature prioritization** — Deliver the highest-value unblocked features first
+- **Phase splitting** — Create Phase 1 (unblocked) and Phase 2 (requires dependency)
+- **Capability degradation** — Deliver with reduced capability that doesn't need the dependency
+
+### Requires
+- Product owner approval for scope change
+- Clear communication about what is deferred and why
+- Updated acceptance criteria for the reduced scope
+- Plan for when/how the deferred feature returns
+
+---
+
+## Strategy 10: Risk Acceptance
+
+### When to Use (Last Resort)
+- The dependency might not materialize as a problem
+- The cost of waiting exceeds the cost of potential rework
+- There's a reasonable probability the assumption is correct
+- The team can handle the rework if the assumption is wrong
+
+### Requirements
+- Explicit acknowledgment from stakeholders
+- Documented assumption and risk
+- Defined trigger for when the assumption needs validation
+- Rework estimate if the assumption is wrong
+- Not applicable for security or compliance dependencies
+
+### Documentation
+```
+Risk Acceptance Record:
+- Assumption: {what we're assuming is true}
+- Risk if wrong: {what happens}
+- Rework estimate: {effort to fix}
+- Accepted by: {person with authority}
+- Date: {when}
+- Trigger for revisit: {what would tell us we're wrong}
+```

package/.jumpstart/skills/dependency-bottleneck-detector/scripts/dependency_scan.py

@@ -0,0 +1,175 @@
+#!/usr/bin/env python3
+"""
+dependency_scan.py
+
+Scan project planning artifacts (markdown files, sprint plans, etc.) for
+indicators of undeclared dependencies that should be tracked.
+
+Looks for patterns that suggest external dependencies:
+- "waiting on", "blocked by", "need from", "pending approval"
+- Access/credential references
+- Environment/infrastructure references
+- Decision/sign-off references
+- Client deliverable references
+
+Usage:
+  python dependency_scan.py --path ./sprint-plans/
+  python dependency_scan.py --path ./notes.md --output json
+  python dependency_scan.py --path . --exclude node_modules,.git
+"""
+
+import argparse
+import json
+import re
+import sys
+from pathlib import Path
+
+# Patterns that suggest a dependency exists
+DEPENDENCY_SIGNALS = [
+    {
+        "category": "Waiting/Blocked",
+        "patterns": [
+            r"waiting (?:on|for)\s+(.{10,60})",
+            r"blocked (?:by|on)\s+(.{10,60})",
+            r"pending\s+(.{10,60})",
+            r"depends on\s+(.{10,60})",
+            r"need(?:s|ed)?\s+(?:from|by)\s+(.{10,60})",
+            r"contingent on\s+(.{10,60})",
+        ],
+    },
+    {
+        "category": "Access/Credentials",
+        "patterns": [
+            r"(?:need|require|request|get)\s+access\s+(?:to\s+)?(.{10,50})",
+            r"(?:API|api)\s+key(?:s)?\s+(?:for|from)\s+(.{10,40})",
+            r"credential(?:s)?\s+(?:for|from)\s+(.{10,40})",
+            r"(?:service\s+)?account\s+(?:for|from|in)\s+(.{10,40})",
+            r"(?:certificate|cert)\s+(?:for|from)\s+(.{10,40})",
+            r"secret(?:s)?\s+(?:for|from)\s+(.{10,40})",
+        ],
+    },
+    {
+        "category": "Infrastructure/Environment",
+        "patterns": [
+            r"(?:provision|create|setup|spin up)\s+(.{10,50})",
+            r"environment\s+(?:for|not ready|pending|needed)\s*(.{0,40})",
+            r"firewall\s+(?:rule|change|request|opening)\s*(.{0,40})",
+            r"(?:VPN|vpn)\s+(?:access|connection|tunnel)\s*(.{0,40})",
+            r"(?:DNS|dns)\s+(?:entry|record|change)\s*(.{0,40})",
+        ],
+    },
+    {
+        "category": "Decision/Approval",
+        "patterns": [
+            r"(?:need|awaiting|pending)\s+(?:a\s+)?(?:decision|approval|sign-?off)\s+(?:on|from|for)\s+(.{10,50})",
+            r"(?:review\s+board|architecture\s+review|security\s+review|change\s+board)\s*(.{0,40})",
+            r"(?:legal|compliance|privacy)\s+(?:review|approval|sign-?off)\s*(.{0,40})",
+        ],
+    },
+    {
+        "category": "Client Deliverable",
+        "patterns": [
+            r"client\s+(?:to\s+)?(?:provide|deliver|send|share)\s+(.{10,50})",
+            r"(?:from|by)\s+(?:the\s+)?client[:\s]+(.{10,50})",
+            r"client\s+(?:responsibility|owned|action)\s*[:\s]+(.{10,50})",
+            r"(?:sample|test)\s+data\s+from\s+(.{10,40})",
+        ],
+    },
+    {
+        "category": "Vendor/Third-Party",
+        "patterns": [
+            r"(?:vendor|partner|third[- ]party)\s+(?:to\s+)?(?:provide|deliver|configure|enable)\s+(.{10,50})",
+            r"(?:license|subscription)\s+(?:for|to|from)\s+(.{10,40})",
+            r"(?:support\s+ticket|case)\s+(?:with|to|for)\s+(.{10,40})",
+        ],
+    },
+]
+
+
+def scan_file(filepath):
+    """Scan a single file for dependency signals."""
+    findings = []
+    try:
+        content = filepath.read_text(encoding="utf-8")
+    except (UnicodeDecodeError, PermissionError):
+        return findings
+
+    lines = content.split("\n")
+    for line_num, line in enumerate(lines, start=1):
+        for signal_group in DEPENDENCY_SIGNALS:
+            for pattern in signal_group["patterns"]:
+                matches = re.finditer(pattern, line, re.IGNORECASE)
+                for match in matches:
+                    findings.append({
+                        "file": str(filepath),
+                        "line": line_num,
+                        "category": signal_group["category"],
+                        "match": match.group(0).strip(),
+                        "context": line.strip()[:120],
+                    })
+    return findings
+
+
+def scan_directory(dirpath, exclude=None):
+    """Scan all markdown and text files in a directory."""
+    exclude = exclude or []
+    extensions = {".md", ".txt", ".markdown", ".yml", ".yaml"}
+    findings = []
+
+    for path in dirpath.rglob("*"):
+        if any(ex in str(path) for ex in exclude):
+            continue
+        if path.suffix.lower() in extensions and path.is_file():
+            findings.extend(scan_file(path))
+
+    return findings
+
+
+def main():
+    parser = argparse.ArgumentParser(description="Scan for undeclared dependencies")
+    parser.add_argument("--path", required=True, help="File or directory to scan")
+    parser.add_argument("--output", choices=["text", "json"], default="text", help="Output format")
+    parser.add_argument("--exclude", default="", help="Comma-separated paths to exclude")
+    args = parser.parse_args()
+
+    target = Path(args.path)
+    exclude = [e.strip() for e in args.exclude.split(",") if e.strip()]
+
+    if target.is_file():
+        findings = scan_file(target)
+    elif target.is_dir():
+        findings = scan_directory(target, exclude)
+    else:
+        print(f"Error: {args.path} not found.", file=sys.stderr)
+        sys.exit(1)
+
+    if args.output == "json":
+        print(json.dumps({"scan_path": str(target), "findings_count": len(findings), "findings": findings}, indent=2))
+    else:
+        if not findings:
+            print("No dependency signals detected.")
+            return
+
+        print(f"\nDependency Signals Found: {len(findings)}")
+        print(f"{'='*70}\n")
+
+        by_category = {}
+        for f in findings:
+            by_category.setdefault(f["category"], []).append(f)
+
+        for cat, items in sorted(by_category.items()):
+            print(f"  [{cat}] ({len(items)} signals)")
+            for item in items[:5]:  # Show max 5 per category
+                print(f"    {item['file']}:{item['line']}")
+                print(f"      \"{item['match']}\"")
+            if len(items) > 5:
+                print(f"    ... and {len(items) - 5} more")
+            print()
+
+        print(f"\nSummary by category:")
+        for cat, items in sorted(by_category.items(), key=lambda x: len(x[1]), reverse=True):
+            print(f"  {cat}: {len(items)}")
+
+
+if __name__ == "__main__":
+    main()