T-Shaped Skills, Methodisches Vorgehen, Kreativität und Agency sind für mich die entscheidenden Hebel beim agentischen Arbeiten.
Das jedenfalls dachte ich nach meinem Experiment, in dem ich ein weiteres, webbasiertes Agile Poker gebaut habe. Ich hatte meine Hand-Dampf-in-allen-Gassen-Skills, den Wunsch des Arbeitgebers, mich mehr mit LLMs und agentischem Arbeiten zu beschäftigen und eine zur Verfügung gestellte Lizenz von Claude Code.
Weil ich keine Zeit beim Kunden verschwenden konnte, nutzte ich zwei Wochen meiner Freizeit, um ein Produkt zu entwickeln, für das ich früher meiner Einschätzung nach zwei Monate Vollzeit gebraucht hätte. Product Development und agiles Vorgehen waren dabei entscheidend: ein nutzbarer Kern, frühe echte Nutzung, Feedback und bewusstes Fertigwerden.
Angefangen hat diese Geschichte allerdings mit Vibecoden im Chat und nerviger Werbung in einem mäßigen Poker-Tool während eines Refinements.
Vom Chat zum eigenen Produkt
Vor über einem Jahr habe ich zum ersten Mal im Chat mit Vibe Coding experimentiert, JavaScript & HTML für eine Einordnung des Nutzerprojektes in die Stacey Matrix anhand differenzierter Fragen. Hat funktioniert, fühlte sich aber recht hakelig an und musste auch noch überarbeitet werden. Ergebnis hier.
Vor kurzem erlebte ich bei meinem Arbeitgeber, der BROCKHAUS AG, eine Session über den Agentic Development Lifecycle, wo ich erstmalig von Claude Code die notwendigen Tools für einfache Entwicklungsarbeiten installieren ließ, die ich schon seit Jahren nicht mehr genutzt hatte. Dazu kam die Anregung unserer Chefs, gerne selbst agentische Dinge auszuprobieren. Ich hatte also sowohl einen neuen Einblick in das Vorgehen als auch ausdrücklich die Gelegenheit zum Experimentieren.
Dann forschte ich, wie man Anforderungsgetrieben entwickeln kann, weil ich das bei einem Beraterkollegen gesehen hatte, und sah diesen total inspirierenden Talk über Backlog.md. Eine Aufgabenliste, die einem Agenten Struktur und Fokus gibt: Das war ein konkreter Ansatzpunkt, um die Arbeit über einzelne Chat-Nachrichten hinaus zu organisieren.
Und dann saß ich beim Kunden in einem Refinement mit scrum-poker.org. Jemand fragte, ob man sich einloggen müsse. Und was 13 Punkte nochmal bedeuten. Unser PO thematisierte seine Google-Suchen, weil auf seinem geteilten Bildschirm auf ihn zugeschnittene Werbe-Anzeigen zu sehen waren. Und dann dachte ich: Mensch, ein wirklich gutes Agiles Poker Tool kann man doch mal in Vernünftig bauen.
Daraus wurde meine Vorstellung von Agile Poker: schlank, hübsch und ohne Werbung. Raum anlegen, Link teilen, loslegen. Ich formulierte Ziele, die Features für eine 0.1 Version und iterierte mit Claude Code.
Das Werkzeug
Agile Poker ist das greifbare Ergebnis dieses Experiments. Ihr könnt es auf memetisch.de/poker ausprobieren oder als WordPress-Plugin selbst betreiben.
- Ohne Konto oder Anmeldung beitreten: Ein Raumlink genügt, damit das Team loslegen kann.
- Verdeckt abstimmen, gemeinsam aufdecken: Die zuerst sichtbare Zahl soll die anderen bei ihrer Schätzung nicht beeinflussen.
- Passende Karten auswählen: Fibonacci, T-Shirt-Größen, Delegation Poker, Business Value Poker oder eigene Kartensätze; die Bedeutung der Karten lässt sich direkt im Raum nachschlagen und verändern.
- Unterschiedliche Zugänge berücksichtigen: Deutsch und Englisch, eine Smartphone-Ansicht sowie Tastaturbedienung und Screenreader-Unterstützung berücksichtigen verschiedene Geräte und Voraussetzungen.
- Selbst hosten: Räume und Schätzungen liegen in der Datenbank der eigenen WordPress-Installation. Der jeweilige Betreiber behält sie auf seiner Infrastruktur.
- Transparente Datennutzung: Das Plugin speichert unter anderem Raumtitel, Kartensätze, Anzeigenamen, Schätzungen und eine zufällige Browserkennung. Es setzt keine Cookies; für Wiedererkennung und Einstellungen nutzt es den lokalen Browser-Speicher. Inaktive Räume werden standardmäßig nach 90 Tagen ohne Wiederverwendung gelöscht. Keine externen Dienste.
- Central-Plugin: Update-Prüfungen und Versionsinformationen kontaktieren dagegen memetisch.de, mit dem ich Updates ausliefern kann; aber auch dabei werden keine Besucherdaten übertragen.
Vor dem Aufdecken ist sichtbar, wer abgestimmt hat. Die Schätzungen bleiben verdeckt.
Nach dem Aufdecken kann das Team unterschiedliche Schätzungen besprechen.
Karten und Aktionen auf dem Smartphone. Die Bilder stammen aus der Projektdokumentation.
Claude brachte die Implementierung, was brachte ich?
Ich habe als Product Owner und Entwickler in einem Consumer-Software-Startup gearbeitet und schlage mich seitdem als Scrum Master und Agile Coach durch. Bei Agile Poker kamen diese Erfahrungen zusammen: Ich verstand die Arbeit, für die das Werkzeug gedacht war, konnte die technische Umsetzung einordnen und wusste, wie ich mich schrittweise einem brauchbaren Produkt nähere.
Genau diese Verbindung macht das T-Shaped-Skillprofil für agentisches Arbeiten so wertvoll: Breite über mehrere Fachgebiete, Tiefe in wenigen.[1]
Ich musste für das Projekt nicht zum Spezialisten in jeder beteiligten Disziplin werden. Die LLMs ermöglichten mir, Dinge umzusetzen, für die mein eigenes Detailwissen allein nicht gereicht hätte. Mein breiterer Blick half mir dabei, überhaupt zu erkennen, wo weitere Arbeit sinnvoll wäre; meine Erfahrung in Produktentwicklung gab mir ein Vorgehen dafür.
Ich begann mit einem schnellen Vertical Slice, einem schmalen, durchgängig nutzbaren Ausschnitt. Menschen sollten in einen Raum kommen, Karten auswählen und gemeinsam aufdecken können. Der frühe Maßstab war damit die eigentliche Arbeit des Teams.
Das MVP nutzte ich mit einem echten Team, während ich noch daran entwickelte. Ich musste also nicht erst sämtliche Ideen umsetzen, bevor jemand anderes das Werkzeug in die Hand bekam.
Diese Entscheidungen kamen aus meinem bisherigen Handwerk. Agile Produktentwicklung wurde durch den Agenten für mich ohne Team umsetzbar. Jedenfalls mit einer App mit begrenzter Komplexität. Ich konnte früh einen nutzbaren Stand herstellen und gleichzeitig weiterlernen, was das Produkt braucht, und wie man am besten ein Produkt mit Agenten bis zur Marktreife bringt.
Ideen bekommen Konsequenzen
Mit den LLMs ging es schnell, weiteren Code und sogar UI- und UX-Verbesserungen umzusetzen. Ich war wie in einem Rausch. Lokalisierung, Accessibility, Marketing und Distribution, Performancetests: Ich erzeugte logische Anschlussaufgaben genauso schnell, wie sie sich umsetzen ließen.
Meine Kreativität hatte ziemlich kurze Lieferzeiten bekommen. Und das macht richtig Spaß.
Agency hieß für mich dabei auch, dem Agenten die Richtung zu geben, statt auf die nächste Idee von ihm zu warten. Ich erkannte eine mögliche Verbesserung, machte daraus eine Aufgabe und konnte an ihrem Ergebnis weiterdenken. Aus unterschiedlichen Erfahrungen entstand so ein zusammenhängendes Produkt.
Gleichzeitig wurde die Reihenfolge wichtiger. Lokalisierung, Barrierefreiheit und Performancetests hatte ich recht früh eingebaut; jede weitere Iteration musste sie mitziehen. Wenn sich der Kern noch verändert, oder noch diverse Features umgesetzt werden, überarbeitet man dadurch auch Dinge, die man gerade erst ausgearbeitet hat.
Eine sinnvolle Anforderung ist noch keine sinnvolle nächste Aufgabe. Heute würde ich genauer unterscheiden, welche Grundlagen von Anfang an stimmen müssen und welche konkrete Ausarbeitung warten kann, bis der Teil des Produkts darunter stabiler ist. Gerade bei Qualität gibt es beides: Entscheidungen, die sich später nur mühsam korrigieren lassen, und Details, die ich unnötig oft anfasse, wenn ich zu früh damit beginne.
Auch ein schneller Agent nimmt mir diese Entscheidung nicht ab. Er erledigt die zusätzliche Arbeit schneller, aber mit einem Claude Code sitzt der Bottleneck leider schon jetzt vor dem Monitor. Erspart hätte ich mir Arbeit durch eine bessere Reihenfolge, klarere Meilensteine, eine Produktvision am Anfang.
Das gilt ebenso für mein Urteil über das Ergebnis. Einen Performancetest ausführen zu lassen und seine Aussagekraft zu beurteilen, sind zwei verschiedene Fähigkeiten. Je weiter ich mich mit dem Agenten in Bereiche bewege, in denen meine eigene Erfahrung dünner wird, desto bewusster muss ich mir überlegen, woran ich ein brauchbares Ergebnis erkenne.
Fertig für andere
Zum fertigen Produkt gehörte für mich, dass es auch anderen Agile Mastern hilft und die Qualitätsarbeit enthält, die unter Zeitdruck gerne liegen bleibt. Accessibility und umfangreiches Testing waren deshalb Teil des Fertigwerdens. Aus einer zu frühen Umsetzung abzuleiten, dass ich diese Ansprüche einfach streichen sollte, wäre schon eine ausgesprochen bequeme Auswertung meines Experiments.
Die Skalierung der Lösung musste zu meinen Möglichkeiten passen. Mir stehen ein Server mit WordPress und meine Freizeit zur Verfügung; weltweites Hosting für alle Interessenten hätte diese Ressourcen überfordert. Mit dem selbst betreibbaren Plugin können andere ihre eigene Installation anbieten. Das zusätzliche Central-Plugin dient der Distribution, Dokumentation und Update-Information, während die Räume bei den jeweiligen Betreibern laufen.
Damit habe ich die Bereitstellung der Server-Ressourcen so angelegt, dass sie sich auf andere Betreiber verteilen kann. Wie weit sich das Werkzeug tatsächlich verbreitet, wird sich erst zeigen. Ich erwarte erstmal nichts, wollte das Konzept aber mitentwickeln.
Was daraus noch entstanden ist
Aus dieser Arbeit ist STEM entstanden, ein Harness on Top of (aktuell noch) Claude Code, Codex und DeutschlandGPT für agentisches Arbeiten: ein Entwicklungsprozess und ein Regelwerk für die Zusammenarbeit mit Agenten. Was sich beim Entwickeln von Agile Poker als hilfreich erwies und was ich ändern wollte, konnte ich darin für die nächsten Projekte festhalten.
Dazu gehört auch, nach einer Arbeitsrunde zu reflektieren und die Regeln anhand dessen zu verbessern, was tatsächlich passiert ist. Mein bisheriges Vorgehen bekommt dadurch eine Form, die ich weiterentwickeln kann und die ich sehr einfach für andere Projekte übernehmen kann.
Das macht Lust auf das nächste Projekt. Gute Ideen dafür habe ich jedenfalls noch. Dieser Post beispielsweise entstand durch mein Projekt Nummer 3 (“writingmachine”), fast ausschließlich mit STEM und Codex in einer Cloudumgebung, gesteuert vom iPhone und mit insgesamt mehr menschlichem Aufwand als je ein Blogpost von mir zuvor – aber dafür ist es mein Stil, meine Regeln, diverse Fremdskills und sollte in Zukunft immer besser funktionieren.
Und was baust du so mit Agentic Coding?
[Mit GPT-6 und writing-machine 0.1.0 erarbeitet]
