Was vor Start vorliegen muss
Whiteboard, Miro oder Tabelle mit Radar-Template (z. B. Adopt/Trial/Assess/Hold-Ringe oder n-Achsen-Speichendiagramm); Stickies oder Karten mit Item-Namen; Bewertungs-Rubrik; Timer; Quellenliste pro Item (Use Cases, Tests, Vendor-Material).
Ein Facilitator und ein Owner pro Item (Pitch und Verteidigung); 2-10 Bewertende mit Kontextwissen; ein Scribe für die Begründungen; bei Tech Radar: Architektur-Board oder Principal Engineer als Approver.
Liste der zu bewertenden Items pro Quadrant (Techniques, Tools, Platforms, Languages & Frameworks bei Tech Radar; angepasst bei anderen Radaren); pro Item ein 1-Pager mit Kontext, Use Case und bekannten Risiken; vorherige Edition als Referenz.
1-2 h
Radar-Achsen oder Ringe an die Wand. Bewertungs-Rubrik sichtbar (z. B. Adopt: in Produktion empfohlen; Trial: in Pilot; Assess: lernen; Hold: nicht starten). Pro Item ein Card mit Owner-Name. Timer auf erste Phase.
Die eine Frage, die diese Methode beantwortet
Welche Position auf dem Radar reflektiert für jedes Item den aktuellen Reifegrad und die organisationsweite Empfehlung am ehrlichsten?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Rubrik und Items klären | 10 min | Rubrik laut lesen und an Beispielen aus der Vorgängeredition prüfen. Item-Liste durchgehen, fehlende Items ergänzen, irrelevante streichen. | Wenn die Rubrik ringspezifische Schwellen nicht klar trennt (z. B. „Trial“ vs. „Adopt“), bereits hier präzisieren. Sonst entstehen widersprüchliche Einordnungen. |
2Phase 2: Item-Pitches | 20-40 min | Pro Item Owner 2-3 min Pitch: Use Case, beobachtete Vorteile, Risiken, vorgeschlagener Ring. Anschließend 1-2 Klarstellungs-Fragen. | Pitches keine Vorträge, kein Marketing. Owner soll den Item kritisch positionieren, nicht verkaufen. Risiken explizit nennen, sonst Diskussion verkommt zu Hype. |
3Phase 3: Bewertung | 20-40 min | Pro Item still bewerten (Karten oder Online-Tool), dann offene Diskussion bei Spreizung. Bei Konsens direkt platzieren. Bei Dissens: Argumente protokollieren, Approver entscheidet. | Konsens-Druck vermeiden. Wenn 3 Stimmen Hold sagen und 5 Adopt, ist das ein Hot Spot, kein Demokratiethema. Approver muss entscheiden, nicht Mehrheit. |
4Phase 4: Quervergleich und Konsistenz | 15-20 min | Radar als Ganzes betrachten: passen die Adopt-Items zusammen? Gibt es Items, die im Widerspruch stehen (z. B. zwei konkurrierende Tools beide Adopt)? Korrekturen vornehmen. | Einzeln korrekt bewertete Items können kollektiv ein Widerspruchsbild ergeben. Quervergleich ist Pflicht, nicht Kür. |
5Phase 5: Doku und Veröffentlichung | 10-15 min | Pro Item kurze Begründung schreiben (2-4 Sätze: warum dieser Ring, was würde Ringwechsel auslösen). Nächste Edition-Termin festlegen. Verantwortung für Kommunikation klären. | Ohne Begründung wird das Radar in 3 Monaten nicht mehr nachvollziehbar. Pro Item mindestens ein Satz „würde Adopt werden, wenn X messbar erreicht“. |
Was am Ende rauskommt
Veröffentlichter Radar (z. B. ThoughtWorks-Format, Markdown im Repo oder dediziertes Tool) mit Items pro Quadrant und Ring, Begründung pro Item (2-4 Sätze), Hinweis auf Vorgängerposition (Movement), Datum, Approver und Termin der nächsten Edition.
Pro Edition ein eigener Eintrag mit Datum. Vorherige Editionen behalten, Movement (Adopt -> Hold, Trial -> Adopt) pro Item explizit markieren. Mindestens halbjährliche Edition empfohlen, sonst werden Hold-Items zu Zombies.
Kompakte Arbeitsvorlage für Radar mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Radar Arbeitsmatrix
| Element | Beschreibung | Bewertung | Evidenz | Owner | Nächster Schritt |
|---|---|---|---|---|---|
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | | | |
## Ergebnisartefakte
- Radar Map:
- Capability Scores:
- Action Areas:
## Entscheidung oder Empfehlung
Welche Konsequenz ergibt sich aus der Matrix?Konkret gefülltes Szenario
## Tech Radar — Engineering Org, Edition 2026.2 (Stichtag 15.05.2026)
**Approver**: @marcus (Principal Engineer), 8 Bewertende aus 5 Teams.
**Techniques**
- Adopt: Trunk-based Development (3. Edition Adopt, alle 4 Produktteams nutzen es). Pair Programming bei kritischen Pfaden (neu Adopt, Daten aus 6-Wochen-Pilot Team Discovery).
- Trial: Continuous Profiling in Produktion (neu Trial, Pilot Team Search).
- Hold: Branching-Strategien à la Git Flow für interne Services (von Trial nach Hold, in 4 Teams beobachtete Friktion).
**Tools**
- Adopt: Postgres 16 mit pgvector (von Trial nach Adopt, 3 Produktionsworkloads stabil seit 12 Wochen).
- Trial: Bun für CI-Tools (nicht für Produktions-Server, expliziter Hold-Pfad).
- Assess: DuckDB für Ad-hoc-Analytics.
- Hold: Self-hosted ELK (von Adopt nach Hold, Wechsel auf Managed-Stack empfohlen, Migration läuft).
**Begründung Trunk-based Development**: 4 Teams in Produktion, durchschnittliche Lead Time von 3,2 Tage auf 0,8 Tage gesenkt. Hold würde nur greifen, wenn Compliance-Audit Branch-Reviews verlangt; aktuell nicht der Fall.
**Nächste Edition**: 15.11.2026, Vorbereitung ab 01.11.Symptome erkennen, gegensteuern
Items landen in Adopt, weil das Team es spannend findet, nicht weil es in Produktion bewährt ist.
Klare Schwelle: Adopt verlangt mehrere Teams in Produktion mit Daten. Wer das nicht hat, landet in Trial. Approver verteidigt die Schwelle.
Items landen in Hold, aber niemand plant Migration weg, Team verwendet sie weiter ohne Konsequenz.
Hold-Items brauchen Migrations-Plan oder begründete Ausnahme. Ohne Plan ist Hold ein Symbol, keine Steuerung.
Bewertung wird durch laute Stimmen verzerrt, leise Bedenken werden überstimmt.
Stille Bewertung als erste Runde. Dissens explizit machen. Approver entscheidet bei Spreizung, nicht Mehrheit. Begründung beider Seiten dokumentieren.
Einzelitems passen, aber zwei konkurrierende Tools sind beide Adopt, Teams nutzen beide und produzieren Drift.
Phase 4 nicht überspringen. Pro Adopt-Cluster prüfen: ist es konsistent oder erzeugt es Wahlmöglichkeiten, die zu Fragmentierung führen.
Letzte Edition vor 18 Monaten, Hold-Items existieren nicht mehr, Adopt-Items werden längst nicht mehr genutzt.
Edition-Termine fix planen (halbjährlich). Wenn Radar nicht aktuell, lieber pausieren als irreführend zeigen. Veröffentlichungsdatum prominent platzieren.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.