# DSS Principles Pilot - Kickoff Meeting Agenda

**Date**: [DATE - THIS WEEK, e.g., Thursday Dec 12]
**Time**: [TIME - 30 minutes, e.g., 2:00 PM - 2:30 PM]
**Location**: [LOCATION - Zoom link or conference room]
**Attendees**: [PILOT TEAM NAMES], [FACILITATOR NAME]

---

## Meeting Objective

Align the pilot team on the lightweight ADR (Architecture Decision Record) process, demonstrate its simplicity, and collaboratively write your first ADR to build confidence and momentum.

**This is NOT**: A mandate. A heavy process. Bureaucracy.
**This IS**: An experiment to help us capture "why" decisions are made. Your honest feedback on whether it's valuable is the goal.

---

## Agenda (30 minutes)

### 1. The "Why" (5 minutes)

**Goal**: Frame the experiment and acknowledge their role as partners.

**Key Points**:
- "Thanks for being our partners in this pilot. Your feedback is what makes this work."
- **The Problem**: We've all asked, "Why did we do it this way?" Git history tells you *what* changed, but not *why*.
- **The Hypothesis**: A lightweight, in-repo method for capturing decision rationale will help us move faster, reduce ambiguity, and make our principles real (not just a document).
- **Success Criteria**: Not that you love everything about it—success is getting your honest, critical feedback. Is this helpful or just noise?

**Talking Points**:
- Reference a recent past decision from the team: "Remember when we debated [example decision]? That rationale lived in Slack and now it's lost. We want to capture that."
- Emphasize the lightness: "This is not a heavyweight process. It's 15 minutes to document a decision. That's it."

---

### 2. The "How" (10 minutes)

**Goal**: Demonstrate the tools are simple and unintimidating.

**Activity**: Live screen share. Show, don't just tell.

1. **Show the directory** (1 min)
   - Navigate to `.knowledge/adrs/`
   - "Everything lives right here, next to the code it relates to."

2. **Show the template** (2 min)
   - Open `000-template.md`
   - "This is the entire template. It's just Markdown with metadata at the top."
   - Briefly explain:
     - `status`: Keeps decisions current (Proposed → Accepted → Deprecated or Superseded)
     - `principles`: Connects the decision back to our core principles (strengthens adoption)
     - `related`: Links to docs, other ADRs, and PRs (builds the knowledge graph)

3. **Show the meta-ADR** (3 min)
   - Open `001-use-markdown-adrs-for-dss-architecture-decisions.md`
   - "We're dogfooding this. Here's the ADR we wrote for the decision to use ADRs. As you can see, it's short and to the point."
   - Highlight the sections: Context, Decision, Consequences

4. **Show the PR integration** (2 min)
   - "When you implement a decision, your PR will have a new section asking you to link the ADR. One line. That's it."
   - Show the updated PR template (section below)
   - "This connects the decision to the code."
   - Emphasize: "The process is not in the way; it's integrated into how you already work."

5. **Clarify scope** (2 min)
   - "Not every technical decision needs an ADR. Use this for significant decisions:"
     - Impact multiple components
     - Have trade-offs or alternatives
     - Will be referenced in future decisions
     - Need rationale captured for future developers
   - "Bug fixes, naming decisions, small refactors—those don't need ADRs. Use code comments instead."

---

### 3. The "First Pancake" (10 minutes)

**Goal**: Write an ADR together to prove the process is lightweight and approachable.

This is the most critical part of the meeting. It transforms understanding into confidence.

**Setup**:
- "Let's do this right now. What's a foundational decision you're making on `dss_sync_figma` right now or have just settled on?"
- Prompt examples if needed:
  - "How will you handle Figma API authentication? Store tokens locally or remotely?"
  - "What's your caching strategy for Figma data between runs?"
  - "What's the architecture for syncing Figma changes back to the project?"
  - "Which Python library will you use for async operations?"

**Execution**:
1. Someone shares their screen (you or the tech lead)
2. Copy `000-template.md` to `002-[decision-title].md` (show this in real-time)
3. Fill it out collaboratively:
   - You type, pilot team provides the content
   - Aim for ~10 minutes total
   - **Don't aim for perfection**—the goal is to prove it's not intimidating
   - Get to "Accepted" status if there's consensus; otherwise "Proposed" is fine
4. Save and show: "That's it. One file, 10 minutes, decision captured."

**During this exercise, demonstrate**:
- YAML is easy (just copy the block, change the values)
- Markdown is familiar (everyone writes it)
- "Consequences" are often the most valuable part (forces you to think through trade-offs)

---

### 4. The "Ask" & Next Steps (5 minutes)

**Goal**: Set clear expectations for the pilot period and establish check-in cadence.

**Key Points**:

1. **The Ask**:
   - "Over the next 3-4 weeks, create 1-3 more ADRs for the most significant decisions on `dss_sync_figma`."
   - "A good rule of thumb: If a decision has long-term consequences, isn't easily reversible, or had interesting trade-offs, it's a good candidate."
   - "Link them from your PRs using the PR template: 'Implements ADR-NNN'"

2. **The Support**:
   - "I'll check in informally to see how it's going. If you feel any friction, let me know immediately. We want to learn from that."
   - "Ask questions. You're not alone in this—we're figuring it out together."

3. **The Follow-up**:
   - "We'll schedule a 30-minute retrospective in about 4 weeks to get all your feedback."
   - "At that point, we decide: Is this valuable? Do we refine it? Do we expand it to other teams?"

4. **Open the floor**:
   - "Any immediate questions, concerns, or thoughts?"
   - Listen. Address concerns directly. Be honest if you don't know something.

---

## Success Signals (What You're Looking For)

- ✅ Team creates 1-3 ADRs during the pilot
- ✅ No major complaints about the process being burdensome
- ✅ At least one person says, "Oh, I see why this matters"
- ✅ Team links ADRs in PRs without being asked twice
- ✅ Honest feedback in the retrospective (positive or negative)

## Red Flags (If You See These, Adjust)

- ❌ "This feels like extra bureaucracy" → Emphasize lightness; show template is only 15 min
- ❌ "I don't know what counts as a significant decision" → Provide 1-2 concrete examples from their project
- ❌ "Do we have to do this?" → No, it's a pilot. But we're counting on your feedback to make it better

---

## Notes for Facilitator

- **Be confident but humble**: You're not selling a policy; you're piloting an experiment together.
- **Listen more than you talk**: Their skepticism and honest feedback are golden. Encourage it.
- **Don't over-explain**: The template and example speak for themselves.
- **Use time wisely**: The "First Pancake" exercise is worth the time; if you run short elsewhere, cut context. The live writing is the proof point.
- **End on invitation, not mandate**: "We're excited to see what you learn. Let's reconvene in 4 weeks."

---

## Post-Meeting

Send a follow-up message to the pilot team:
```
Great kickoff! Here's what we covered:

• ADR template: .knowledge/adrs/000-template.md
• The "why" behind ADRs: .knowledge/adrs/001-use-markdown-adrs-for-dss-architecture-decisions.md
• Questions? Check: .knowledge/adrs/README.md

Next steps:
1. Create 1-3 ADRs over the next month for significant dss_sync_figma decisions
2. Link them in PRs (see PR template update)
3. Give us feedback in the retro (Week 4)

Thanks for being our pilot team. Your honest feedback is what makes this work. 🚀
```

---

**Prepared for**: DSS Principles Pilot Program
**Pilot Project**: dss_sync_figma
**Week 1 of 4**