Architecture Decision Records - How not to get lost in the past
summary
Practical playbook: store ADRs in git, write short markdown files, publish via GitHub Pages and open a PR that uses PRs and review commands for formal checks, run a short hybrid review meeting, then merge; timebox reviews and assign rotating reviewers to avoid stalls; accept retrospective ADRs when necessary; automate closing stale proposals; start with one team using shadow ADRs to prove value, collect examples of good/bad ADRs, and iterate the process rather than expecting a one‑size‑fits‑all solution.
AI-written summary · about
chapters (9)
- 0:00ADRs introduction
- 3:37What is an ADR
- 7:11Creating ADRs in practice
- 10:25ADR adoption challenges
- 14:22ADR enthusiasts vs haters
- 20:06ADR process issues
- 25:05ADR and org structure
- 29:04Leadership sponsorship
- 34:22Summary
related talks
14mArchitecture Decision Records: Make Peace with Your Docs
43mGetting Started with Architectural Decision Records
54mHow'd we get here? A guide to Architectural Decision Records
42mIntroduction to ADRs
43mWorking Efficiently with Architecture Decision Records (ADRs)
15mCreating effective and objective architectural decision records (ADRs)
47mMaking architecture decisions, the Agile Way
14mArchitecture Decision Records