Agile Methoden (Scrum, Lean Canvas, Design Thinking)

Bevor ein KI-Agent eine Zeile Code schreibt oder einen Blogartikel entwirft, muss klar sein, was eigentlich gebaut werden soll – und was nicht. Genau hier setzen agile Methoden an: Scrum mit der Rolle des Product Owners, das Lean Canvas und die Prinzipien aus dem Design Thinking.

Scrum und Product Owner: Erfahrung aus der Praxis

Scrum begleitet mich seit vielen Jahren. 2012 habe ich die Zertifizierung Professional Scrum Master I bei Scrum.org abgelegt, 2020 folgte der Professional Scrum Product Owner I. Am meisten gelernt habe ich aber in der Praxis: Seit 2018 bin ich bei MAN Truck & Bus, aktuell als D&A IT Spoke Lead. Meinen Einstieg dort habe ich als Product Owner für eine Datenplattform gemacht. In dieser Zeit habe ich gemerkt, dass die Rolle oft missverstanden wird. Wer Product Ownership mit dem Verwalten von Tickets gleichsetzt, verfehlt den Kern der Aufgabe.

Die eigentliche Arbeit eines Product Owners liegt im Nein-Sagen und im sauberen Schneiden von Anforderungen. Jede neue Idee klingt zunächst sinnvoll, und genau deshalb braucht es jemanden, der entscheidet, was jetzt wirklich Wert stiftet und was warten kann. Genauso wichtig ist es, große Vorhaben so zu zerlegen, dass am Ende jedes Schritts ein Ergebnis steht, das sich prüfen und abnehmen lässt. Ein gut geschnittenes Backlog-Item ist klein genug, um überschaubar zu bleiben, und groß genug, um einen erkennbaren Nutzen zu liefern.

Product-Owner-Denken für Teams aus KI-Agenten

Heute nutze ich diese Denkweise vor allem in der Ideate-Phase meiner Multi-Agenten-Systeme-Projekte. Bevor ein Agent loslegt, prüfe ich die Idee, zerlege sie in prüfbare Inkremente und setze Prioritäten. Das funktioniert gut, denn in einem Punkt unterscheiden sich KI-Agenten kaum von menschlichen Entwicklerinnen und Entwicklern: Auch sie brauchen klare Aufträge und eindeutige Abnahmekriterien. Ein vager Auftrag führt bei einem Agenten ebenso zu einem unbrauchbaren Ergebnis wie bei einem Team.

Die Erfahrung als Product Owner hilft mir, Aufträge so zu formulieren, dass sie ein klar umrissenes Ziel haben und sich am Ende objektiv bewerten lassen. Das Nein-Sagen bleibt dabei die wichtigste Disziplin: Nicht jede Aufgabe, die ein Agent erledigen könnte, sollte er auch erledigen.

Lean Canvas in der Praxis: Geschäftsplanung für ketovavaria.de

Für die Geschäftsplanung von ketovavaria.de, einem Blog, den mein KI-Agenten-Team betreibt, setze ich das Lean Canvas ein. Die Methode stammt von Ash Maurya und ist vom Business Model Canvas abgeleitet. Auf einer einzigen Seite werden neun Felder festgehalten: Problem, Kundensegmente, Unique Value Proposition, Lösung, Kanäle, Umsatzquellen, Kostenstruktur, Kennzahlen und der unfaire Vorteil.

Die Stärke liegt in der Verdichtung. Das Canvas hält auf einen Blick fest, welches Problem der Blog löst, für wen er gedacht ist und worin sein Nutzen besteht. Gerade wenn mehrere Agenten arbeitsteilig zusammenarbeiten, ist diese gemeinsame Grundlage entscheidend. Jeder Agent kann seine Aufgabe an derselben Beschreibung von Zielgruppe und Nutzenversprechen ausrichten, statt eigene Annahmen zu treffen. Wichtig ist mir dabei, das Lean Canvas nicht als einmaliges Dokument zu behandeln. Es ist ein Arbeitsstand, den ich überarbeite, sobald sich neue Erkenntnisse ergeben.

Design Thinking: Prinzipien in der Praxis, formales Format als nächster Schritt

Die Kernprinzipien von Design Thinking wende ich seit Jahren an, nur nicht unter diesem Namen. Als Product Owner beginnt jede gute Anforderung mit echtem Nutzerverständnis und einer präzisen Problemdefinition, genau den ersten beiden Design-Thinking-Phasen. 2020 habe ich das zusätzlich mit dem openHPI-Kurs „Mastering Design Thinking in Organizations“ formalisiert. Was noch fehlt, ist das formale Workshop-Format als eigenständiges Projektvorgehen – deshalb steht es auf meinem Technologie-Radar bei „Assess“.

Design Thinking gliedert sich in die Phasen Verstehen, Problem definieren, Ideen sammeln, Prototypen bauen und Testen. Diese Phasen werden nicht linear abgearbeitet, sondern iterativ: Erkenntnisse aus einem Test können zurück ins Verstehen oder zu einer neuen Problemdefinition führen. Besonders die ersten beiden Phasen überschneiden sich mit meiner Praxis als Product Owner: Wer ein Problem wirklich verstanden und präzise definiert hat, kann deutlich bessere Aufträge formulieren – für Entwicklerteams wie für KI-Agenten. Der nächste Schritt ist, das vorhandene Verständnis in ein strukturiertes Workshop-Format zu überführen, sobald sich ein passendes Projekt dafür bietet.