Lösungsbaum-Argumentation

Table of Contents

• 1. Beispiel
• 2. Spielregeln
  • 2.1. Aktionen
    • 2.1.1. Start
    • 2.1.2. Idee haben
    • 2.1.3. Idee bewerten
    • 2.1.4. Problem aufteilen
    • 2.1.5. Kommentieren
  • 2.2. Lösungsfindung: Wann ist etwas gelöst?
• 3. Praktische Hinweise
  • 3.1. Mehrere Spieler
• 4. Beispiele
  • 4.1. Camping-Urlaub
  • 4.2. Alltagsentscheidung - Wochenendplanung
  • 4.3. Produktverbesserung - Nutzerbindung
  • 4.4. Software – Hohe Fehlerquote nach Release
• 5. Team-Offsite – Zwei Tage Strategieworkshop planen
• 6. Warum LBA? – Abgrenzung zu ähnlichen Methoden
• 7. About

Lösungsbaum-Argumentation (LBA) ist eine universelle Problemlösungsstrategie. So wie das schriftliche Multiplizieren hilft, große Zahlen zu bewältigen, hilft LBA, große und komplexe Probleme zu strukturieren und zu lösen. LBA kann alleine oder im Team verwendet werden.
Gut funktioniert es in einem Texteditor (plain text, Markdown oder AsciiDoc) oder noch besser in einem gemeinsam nutzbaren Editor (Google Docs, Word, …​).

English version

🇬🇧 Issue-based Argumentation (IBA), see README.en.adoc.

1. Beispiel

Einfaches Beispiel

• ❏ PROBLEM: Kaffeemaschine ist kaputt

  • ❏ IDEE: Service-Techniker anrufen

  • ❏ IDEE: Wassertank könnte leer sein

  • ❏ IDEE: Selbst Fehler suchen

  • ❏ IDEE: Neue Kaffeemaschine kaufen

2. Spielregeln

Syntax

LBA wird als Liste mit verschachtelten Unterpunkten aufgeschrieben. Am Anfang jedes Eintrags steht ein kurzes Wort, welches die Art des Eintrags angibt. Erlaubt sind: PROBLEM, IDEE und KOMMENTAR.

Status

An den Anfang jedes Listeneintrags kann noch eine Checkbox gesetzt werden, einfach mit zwei eckigen Klammern und einem Leerzeichen drin. In dieser Box wird notiert, ob ein Eintrag schon als gelöst [x] oder unlösbar [-] erkannt wurde. Am Anfang ist jeder Eintrag unbewertet [ ]. Ein Eintrag wird als unlösbar [-] markiert, wenn erkannt wurde, dass er nicht zum Ziel führt oder nicht umgesetzt werden kann. Dies hilft, Sackgassen schnell zu erkennen.

2.1. Aktionen

Als Teilnehmer bei einer LBA hast Du folgende Möglichkeiten:

2.1.1. Start

Am Anfang steht bei LBA immer ein PROBLEM, also ein Problem oder eine Frage. Etwas Ungelöstes. Dieser PROBLEM wird an den Anfang gesetzt.

Beispiel

• [ ] PROBLEM: Kaffeemaschine ist kaputt

2.1.2. Idee haben

Kann an einen bestehenden PROBLEM angelegt werden. Du hast eine Idee, wie das Problem gelöst, die Frage beantwortet werden kann? Erzeuge einen neuen Listen-Unterpunkt der eins mehr eingerückt ist als der PROBLEM auf den sich die Idee bezieht.

Beispiel

• ❏ PROBLEM: Kaffeemaschine ist kaputt

  • [ ] IDEE: Service-Techniker anrufen

Tip	Ein PROBLEM kann beliebig viele mögliche, alternative Lösungsideen haben. Sobald eine der Ideen sich als umsetzbar erweist, ist das Problem gelöst.

2.1.3. Idee bewerten

Nach dem Eintragen einer Idee wird sie von einigen oder allen Teilnehmern bewertet: Ist die Idee umsetzbar?

Probleme sehen

Ist eine bestehende IDEE nicht umsetzbar? Noch zu unklar? Offene Fragen und entstehende neue Probleme können direkt als neue Unter-PROBLEM angehängt werden.

Einfaches Beispiel

• PROBLEM: Kaffeemaschine ist kaputt

  • IDEE: Service-Techniker anrufen

    • PROBLEM: Wer zahlt die Reparatur?

Tip	Eine IDEE kann beliebig viele neue PROBLEM aufwerfen.

2.1.4. Problem aufteilen

Der mächtigste Zug bei LBA ist es, ein Problem in kleinere Probleme zu zerlegen. Dazu wird eine IDEE mit dem Text SPLIT angelegt.

Beispiel

• ❏ PROBLEM: Den perfekten Campingplatz für einen Kanu-Urlaub mit einer Gruppe von acht Personen finden.

  • [ ] IDEE: SPLIT

    • [ ] PROBLEM: Auswahl eines Landes

    • [ ] PROBLEM: Entscheiden ob in den Bergen oder am Meer

    • [ ] PROBLEM: Vorlieben der Gruppenteilnehmer einholen und berücksichtigen

Tip

Für ein Problem kann es mehrere Zerteilungen geben. Wichtig ist, zunächst zu prüfen, ob die Zerlegung gültig ist: Wenn alle angegebenen Teilprobleme gelöst wären, wäre das Problem darüber gelöst? Wenn die Zusammensetzung der Teillösungen erklärt werden muss, kann dies direkt hinter SPLIT notiert werden, z.B. IDEE: SPLIT: Wenn Land und Vorlieben klar sind, suchen wir auf booking.com.

2.1.5. Kommentieren

Diese Aktion kann komplett weggelassen werden. Sie ermöglicht das Einbringen von Wissen oder Gefühlen, ohne die Struktur von LBA zu stören.

Beispiel

• ❏ PROBLEM: Entscheiden, ob in den Bergen oder am Meer

  • KOMMENTAR: Geht nicht beides?

2.2. Lösungsfindung: Wann ist etwas gelöst?

Jede neue Idee wird geprüft: Ist sie umsetzbar? Falls ja, so kann sie im besten Fall der letzte Baustein für die Gesamtlösung sein.

Der Status ([ ], [x], [-]) eines Eintrags wird logisch durch den Status seiner Unterpunkte bestimmt. Die Regeln werden von unten nach oben angewendet:

Status einer IDEE

[x] (gelöst)

Die Idee ist umsetzbar und alle ihre Unter-PROBLEMs sind [x].

[-] (unlösbar)

Die Idee ist nicht umsetzbar oder mindestens ein Unter-PROBLEM ist [-].

[ ] (ungelöst)

In allen anderen Fällen (z.B. wenn es noch offene Unter-PROBLEMs gibt).

Status eines PROBLEM

[x] (gelöst)

Mindestens eine seiner Unter-IDEEs ist [x].

[-] (unlösbar)

Alle seine Unter-IDEEs sind [-].

[ ] (ungelöst)

In allen anderen Fällen (z.B. wenn es noch keine Ideen gibt oder alle Ideen noch ungelöst sind).

KOMMENTAR-Einträge haben keinen Einfluss auf den Status.

3. Praktische Hinweise

Beispiel

• ✓ PROBLEM: Entscheiden, ob in den Bergen oder am Meer

  • [x] IDEE: Berge

  • [x] IDEE: Meer

Hier sind zwei mögliche, umsetzbare Ideen zur Auswahl. Die Teilnehmer können zufällig eine Idee auswählen oder demokratisch abstimmen. Aus Sicht von LBA ist das übergeordnete Problem gelöst.

3.1. Mehrere Spieler

Bei mehreren Spielern in einem Online-Editor sollte jeder seine Beiträge mit dem Namen markieren. Jeweils am Ende eines Eintrags, um die Inhalte und nicht die Personen in den Vordergrund zu stellen.

4. Beispiele

4.1. Camping-Urlaub

Hier ist ein Beispiel, das den Prozess von Anfang bis Ende zeigt.

Phase 1: Problem und erste Zerlegung

• [ ] PROBLEM: Den perfekten Campingplatz für einen Kanu-Urlaub mit einer Gruppe von acht Personen finden.

  • [ ] IDEE: SPLIT

    • [ ] PROBLEM: Auswahl eines Landes

    • [ ] PROBLEM: Entscheiden ob in den Bergen oder am Meer

    • [ ] PROBLEM: Vorlieben der Gruppenteilnehmer einholen und berücksichtigen

Phase 2: Eine Lösung für ein Teilproblem

• ❏ PROBLEM: Den perfekten Campingplatz für einen Kanu-Urlaub mit einer Gruppe von acht Personen finden.

  • ❏ IDEE: SPLIT

    • ✓ PROBLEM: Auswahl eines Landes

      • [x] IDEE: Schweden

        • KOMMENTAR: Tolle Seenlandschaft! — Alice

    • ❏ PROBLEM: Entscheiden ob in den Bergen oder am Meer

      • [ ] IDEE: Berge

      • [ ] IDEE: Meer

    • ❏ PROBLEM: Vorlieben der Gruppenteilnehmer einholen und berücksichtigen

Phase 3: Eine Idee erweist sich als unlösbar

• ❏ PROBLEM: Den perfekten Campingplatz für einen Kanu-Urlaub mit einer Gruppe von acht Personen finden.

  • ❏ IDEE: SPLIT

    • ✓ PROBLEM: Auswahl eines Landes

      • ✓ IDEE: Schweden

        • KOMMENTAR: Tolle Seenlandschaft! — Alice

    • ✓ PROBLEM: Entscheiden ob in den Bergen oder am Meer

      • [-] IDEE: Berge

        • [-] PROBLEM: In Schweden gibt es kaum Berge, die direkt an Kanu-tauglichen Seen liegen.

      • ✓ IDEE: Meer

    • ❏ PROBLEM: Vorlieben der Gruppenteilnehmer einholen und berücksichtigen

Sobald auch der letzte Unter-PROBLEM gelöst ist, wird die IDEE: SPLIT gelöst und damit auch das Hauptproblem.

4.2. Alltagsentscheidung - Wochenendplanung

• ✓ PROBLEM: Wohin am Wochenende fahren?

  • ❏ IDEE: In die Berge zum Wandern

    • ❏ PROBLEM: Wettervorhersage prüfen

    • ❏ PROBLEM: Welche Hütte hat noch frei?

  • [-] IDEE: An den See zum Schwimmen

    • [-] PROBLEM: Wassertemperatur ist noch zu kalt

  • ✓ IDEE: Das neue Technik-Museum besuchen

    • ✓ PROBLEM: Öffnungszeiten?

      • ✓ IDEE: Sa+So 10-18 Uhr

    • ✓ PROBLEM: Tickets?

      • ✓ IDEE: Online kaufen, um Wartezeit zu sparen

  • KOMMENTAR: Ich würde am liebsten ans Meer, aber das ist zu weit für ein Wochenende. — Anna

Hier wurde die Idee, in die Berge zu fahren, nicht weiter verfolgt.

4.3. Produktverbesserung - Nutzerbindung

• ❏ PROBLEM: Wie können wir die Benutzerbindung unserer App erhöhen?

  • ❏ IDEE: SPLIT Das Feature umsetzen, was zur besten Verringerung der Nutzererfahrung führt.

    • ❏ PROBLEM: Analyse des aktuellen Nutzerverhaltens (Wo steigen sie aus?)

    • ❏ PROBLEM: Ideen für neue Features sammeln

  • ❏ IDEE: Gamification-Elemente einführen

    • ❏ PROBLEM: Welche Art von Gamification passt zu unserer App?

      • ❏ IDEE: Punktesystem

      • ❏ IDEE: Badges für erreichte Ziele

    • ❏ PROBLEM: Technischer Aufwand für die Implementierung?

  • ❏ IDEE: Push-Benachrichtigungen verbessern

    • ❏ PROBLEM: Wie können wir Benachrichtigungen personalisieren?

      • ❏ PROBLEM: Welche Datenpunkte können wir nutzen?

    • [-] IDEE: Frequenz der Benachrichtigungen pauschal erhöhen

      • [-] PROBLEM: Risiko, dass Nutzer genervt sind und die App deinstallieren

4.4. Software – Hohe Fehlerquote nach Release

• PROBLEM: Nach dem letzten Release ist die Fehlerquote in Produktion stark gestiegen

  • ❏ IDEE: SPLIT

    • ❏ PROBLEM: Reproduzierbarkeit sicherstellen (Logs, Schritte, betroffene Routen)

    • ❏ PROBLEM: Umfang und Auswirkung quantifizieren (Metriken, A/B-Vergleich)

    • ❏ PROBLEM: Mögliche Ursachen eingrenzen (Code, Config, Infrastruktur)

    • ❏ PROBLEM: Sofortmaßnahmen und Rückfallplan definieren

  • ❏ IDEE: Feature-Flag für kritisches Modul deaktivieren

    • ❏ PROBLEM: Welche User-Segmente sind betroffen?

      • ✓ IDEE: Nur Neukunden-Pfade

    • ❏ PROBLEM: Ist die Deaktivierung ohne Migrationsfolge möglich?

      • [-] IDEE: Direkt deaktivieren

        • [-] PROBLEM: Datenmigration würde inkonsistente Stati erzeugen

      • ✓ IDEE: Deaktivierung nach Hotfix mit Guard-Checks

        • ✓ PROBLEM: Guard-Checks implementieren und testen

  • ❏ IDEE: SPLIT Root-Cause-Analyse strukturieren

    • ❏ PROBLEM: Code-Änderungen seit letztem stabilen Build diffen

      • ✓ IDEE: API-Client Timeout wurde gesenkt

        • KOMMENTAR: Verdächtig, da Timeouts mit Spitzenlast korrelieren

    • ❏ PROBLEM: Infrastrukturereignisse prüfen (Deploy, Scaling, Ratelimits)

      • ✓ IDEE: Autoscaling-Regel griff zu langsam

    • ❏ PROBLEM: Konfigurationsänderungen (Feature-Toggles, Env Vars)

      • ✓ IDEE: Retries von 3 auf 1 reduziert

  • ✓ IDEE: Sofortmaßnahme: Timeouts und Retries auf vorherige Werte zurücksetzen

    • ✓ PROBLEM: Rollout über Konfigurationsservice

      • ✓ IDEE: Staged Rollout 10% → 50% → 100%

    • ✓ PROBLEM: Monitoring-Schwellen testen

      • ✓ IDEE: Error Budget-Alarm validiert

        • KOMMENTAR: Fehlerquote fällt innerhalb von 15 Minuten unter Basislinie

5. Team-Offsite – Zwei Tage Strategieworkshop planen

• PROBLEM: Ein zweitägiges Team-Offsite innerhalb von sechs Wochen planen

  • ❏ IDEE: SPLIT

    • ❏ PROBLEM: Ziel und Agenda definieren

    • ❏ PROBLEM: Ort und Budget festlegen

    • ❏ PROBLEM: Teilnahme und Logistik klären

    • ❏ PROBLEM: Inhalte/Methoden vorbereiten

  • ❏ IDEE: Remote durchführen (100% online)

    • ❏ PROBLEM: Passt das zu den Offsite-Zielen (Beziehungsaufbau, Fokus)?

      • [-] IDEE: Ja, ist gleichwertig

        • [-] PROBLEM: Fehlende informelle Zeit vermindert Vertrauensaufbau

      • ✓ IDEE: Teilweise geeignet, aber nicht optimal

        • KOMMENTAR: Für Strategie-Alignment ok, Teambuilding leidet

  • ✓ IDEE: SPLIT Präsenz innerhalb von 3 Stunden Anreise organisieren

    • ✓ PROBLEM: Ziel und Agenda definieren

      • ✓ IDEE: Tag 1 Strategie-Alignment, Tag 2 Roadmap + Retrospektive

        • KOMMENTAR: 2× 90-Minuten-Blöcke pro Halbtag, Puffer für Diskussionen

    • ✓ PROBLEM: Ort und Budget festlegen

      • ✓ IDEE: Seminarhaus am Stadtrand, 120€ p.P./Tag inkl. Verpflegung

    • ❏ PROBLEM: Teilnahme und Logistik klären

      • ✓ IDEE: Doodle für Verfügbarkeit, Deadline in 48h

      • ❏ IDEE: Fahrgemeinschaften organisieren

        • ❏ PROBLEM: Wer fährt von welchem Standort?

          • ✓ IDEE: Drei Sammelpunkte definieren

          • ❏ IDEE: Fahrer mit freien Plätzen benennen

    • ❏ PROBLEM: Inhalte/Methoden vorbereiten

      • ✓ IDEE: Moderationsplan mit Timeboxes

      • ❏ IDEE: Materialliste erstellen

        • ❏ PROBLEM: Whiteboards, Karten, Timer, Kamera

          • ✓ IDEE: Vor Ort verfügbar laut Anbieter

        • ❏ PROBLEM: Hybrid-Teilnahme für zwei Remote-Kollegen

          • ✓ IDEE: Konferenzraum mit Kamera/Mikro reservieren

          • ❏ IDEE: Test-Call eine Woche vorher

            • ✓ PROBLEM: Termin mit Remote-Kollegen abstimmen

  • KOMMENTAR: Falls die Fahrgemeinschaften bis nächste Woche nicht stehen, prüfen wir Bahn-Tickets als Plan B.

6. Warum LBA? – Abgrenzung zu ähnlichen Methoden

Kurzzusammenfassung

• LBA strukturiert Probleme hierarchisch und lösungsorientiert.

• Es verbindet Ideenfindung mit systematischer Klärung offener Fragen.

• Der Status jedes Eintrags wird aus den Unterpunkten logisch abgeleitet – Fortschritt ist jederzeit sichtbar.

Wann LBA besonders nützlich ist

• Unklare, mehrdeutige Problemstellungen mit vielen offenen Fragen.

• Gruppenarbeit, in der Ideen und Folgefragen parallel entstehen.

• Entscheidungen, die sowohl Kreativität (Ideen) als auch Zerlegung in Teilprobleme erfordern.

Wann eher nicht

• Reine Abarbeitung bekannter, linearer Schritte (Checklisten).

• Wenn es bereits eine klare Entscheidungsregel gibt (z.B. fest definierte KPIs ohne Diskussionsbedarf).

Abgrenzung

Brainstorming

Erzeugt Ideen, aber ohne systematische Klärung ihrer Umsetzbarkeit. LBA koppelt Ideen direkt mit Folgefragen (PROBLEM) und bewertet sie über Status.

Pro/Contra-Listen

Eignen sich für 1:1-Entscheidungen, skalieren aber schlecht bei Unterfragen. LBA erlaubt beliebig tiefe Zerlegung und macht Abhängigkeiten explizit (SPLIT).

Entscheidungsbäume

Modellieren Pfade zu Ergebnissen, jedoch selten die Diskussionshistorie. LBA dokumentiert zugleich Alternativen, Sackgassen [-] und Begründungen.

Design Thinking / Double Diamond

Prozessrahmen für Exploration und Prototyping. LBA ist ein leichtgewichtiges Textformat, das in jeder Phase als Denk- und Kommunikationsstruktur eingesetzt werden kann.

Issue-/Bug-Tracker

Verwalten Arbeitseinheiten, nicht zwingend Argumentationsketten. LBA bildet die Argumentation und Entscheidung transparent im Dokument selbst ab (unabhängig von Tools).

RFCs / Architekturentscheidungen (ADR)

Halten Entscheidungen fest, meist erst nach Diskussion. LBA unterstützt den Entstehungsprozess davor – die resultierende Lösung kann dann in RFC/ADR überführt werden.

Argument-/Debattenkarten (Argument Maps)

Fokussieren auf logische Pro-/Kontra-Argumente. LBA kombiniert Argumente mit operablen Teilproblemen und klaren Abschlusskriterien pro Knoten.

Typische Vorteile

• Niedrige Hürde: Funktioniert in jedem Editor, ohne Spezial-Tooling.

• Transparenz: Jeder sieht, warum etwas gelöst, ungelöst oder unlösbar ist.

• Skalierbarkeit: Von Alltagsentscheidungen bis zu komplexen Produktfragen.

• Anschlussfähig: Ergebnisse lassen sich in Tickets, Roadmaps oder RFCs überführen.

Tip	Nutze SPLIT, sobald Diskussionen sich im Kreis drehen. Die Zerlegung in Teilprobleme beschleunigt die Klärung und macht blockierende Fragen sichtbar.

7. About

Die Methode wurde von Dr. Max Völkel während seiner Promotion am FZI Karlsruhe entwickelt. Sie wurde erstmals 2006 unter dem Namen Issue-Based Argumentation in a Wiki (IBAW) beschrieben. IBAW stellt dabei im wesentlichen eine pragmatische Text-Syntax für das Modell von Kunz und Rittel (1970) dar. In der Promotion zu persönlichen Wissensmodellen mit semantischen Technologien finden sich weitere theoretische Hintergründe. Spǎter wurde die Methode von Dr. Völkel immer öfter in einem Texteditor (allein) oder in kollaborativen Werkzeugen (Google Docs, im Team) eingesetzt um komplexe und komplizierte Probleme meist mit Erfolg zu strukturieren und zu lösen. Als kleines Geburtstagsgeschenk an Leo Sauermann und als Gruß an Heiko Haller (beide wichtige Forscherkollegen) wurde die Methode am 2025-08-30 besser dokumentiert und hier veröffentlicht. Als neuer deutscher Name wurde Lösungsbaum-Argumentation (LBA) gewählt, um die Methode auch im deutschsprachigen Raum bekannter zu machen.

Referenzen

Kunz und Rittel (1970)

Kunz, W. and H. W. J. Rittel (1970). Issues as elements of information systems. Technical report wp-131, University of California, Berkeley