„These Things Take Time.“
Agil arbeiten heißt nicht, jeden Tag ein Stand-up zu machen.
In über 20 Jahren Projekterfahrung habe ich erlebt, wie Teams Scrum-Boards pflegen, Meetings abhalten, Post-its sortieren – und trotzdem aneinander vorbeiarbeiten. Methoden allein bringen wenig, wenn Ziele, Rollen und Entscheidungswege unklar bleiben.
Ich habe agile Transformationen begleitet, Jira und Confluence eingeführt, Prozesse neugestaltet, Retros gerettet, Projekte stabilisiert. Was sich durchzieht: Agilität funktioniert nur, wenn Teams wissen, was sie gemeinsam erreichen wollen – und wie sie es transparent und flexibel tun.
Komplexität beherrschen
Entscheidungen in kleinen Schritten treffen und auf Veränderungen reagieren.
Verantwortung verteilen
Arbeit so organisieren, dass sie wirklich fließt und Teams autonom handeln können.
Wirksamkeit entfalten
Fokus auf den Nutzen – für Teams, Produkte und Menschen, nicht auf starre Dogmen.
Ein paar Beispiele meines Werkzeugkastens für wirksame Zusammenarbeit
1. Design Sprint (nach Google Ventures)
Ein Design Sprint ist ein hochstrukturierter, fünftägiger Prozess, um große unternehmerische Fragen zu beantworten, neue Produkte zu entwickeln oder komplexe Probleme zu lösen.
So funktioniert’s (vereinfacht): Wir komprimieren den gesamten Produktentwicklungsprozess in eine Arbeitswoche. Von Montag (Problem verstehen) über Mittwoch (Entscheidung für einen Lösungsweg) bis Donnerstag (Bau eines realistischen Prototyps) testen wir am Freitag mit echten Kunden. Das Ergebnis ist kein fertiges Produkt, sondern maximale Erkenntnis bei minimalem Risiko.
Das Problem, das es löst: Es verhindert, dass Monate oder gar Jahre in eine Idee investiert werden, die am Ende niemand will. Statt lange zu diskutieren, erhalten wir innerhalb einer Woche klares Feedback von echten Nutzern.
2. Liberating Structures (für lebendige Retrospektiven)
Liberating Structures sind eine Sammlung von über 30 einfachen Moderationsmethoden, die traditionelle Meetings ersetzen und die kollektive Intelligenz einer Gruppe wirklich nutzen.
Ein Beispiel – die „1-2-4-All“-Methode: Statt einer offenen Diskussion stellt man eine Frage (z.B. „Was ist die eine Sache, die wir ändern müssen, um schneller zu werden?“). Zuerst reflektiert jeder 1 Minute für sich allein. Dann diskutiert man 2 Minuten im Paar. Anschließend tauschen sich zwei Paare in einer 4er-Gruppe aus. Am Ende teilen alle im Plenum nur die wichtigsten Erkenntnisse. So entstehen in kürzester Zeit tiefgehende und breit getragene Ergebnisse.
Das Problem, das es löst: Es beendet die Monotonie von Meetings, in denen immer nur dieselben wenigen Personen reden. Es sorgt dafür, dass die Ideen und Perspektiven von allen Teammitgliedern gehört und einbezogen werden.
3. Story Mapping Workshops
Ein Story Map ist eine visuelle Darstellung des gesamten Weges, den ein Nutzer mit einem Produkt zurücklegt. Sie ist die beste Methode, um ein Product Backlog zu erstellen und zu organisieren.
So funktioniert’s: Wir zeichnen die „Wirbelsäule“ (Backbone) der User Journey – die Hauptschritte, die ein Nutzer durchläuft (z.B. Suchen → Auswählen → Buchen → Bezahlen). Darunter sammeln wir dann alle detaillierten Aktionen und User Stories. So sehen wir sofort, wo Lücken sind und können unsere Arbeit in logische, wertstiftende Releases (Sprints) schneiden. Das Team baut nicht einfach nur Features, sondern eine kohärente Nutzererfahrung.
Das Problem, das es löst: Es bewahrt Teams davor, sich in einer langen, flachen Liste von User Stories zu verlieren. Die Story Map stellt sicher, dass jeder das große Ganze versteht und die Arbeit immer aus der Perspektive des Nutzers geplant wird.