In diesem Blogartikel möchte ich im Wesentlichen zwei Zusammenhänge verdeutlichen. Erstens beschreibe ich die Startphase eines agilen Projektteams und die dabei genutzten methodischen Ansätze. Zweitens spielt bei agilen Projekten der menschliche Faktor eine immer größere Rolle, so dass ich auch auf die Entwicklung des Projektteams eingehe. Und zu guter Letzt werde ich auflösen, was ein Elefant mit agiler Produktentwicklung zu tun hat.
Einstieg in agiles Arbeiten…
Ein neues Projekt steht an: Voller Vorfreude mache ich mich Frühjahr 2018 auf nach Hamburg, um bei Der Techniker ein neues Projekt in der Rolle des Agile Coaches zu übernehmen. Die Ausgangssituation des Projektes ist einigermaßen klar, da die TK gerade eine großangelegte Initiative gestartet hat, um neue Formen der Zusammenarbeit zu testen und um agile Methoden und ein agiles Miteinander in der Organisation zu fördern. Ich weiß, dass das Projektteam keine bis wenig Erfahrung im Umgang mit modernen Arbeitsformen hat.
Wie bei vergleichbaren Herausforderungen geht es auch diesmal in der Startphase darum, den Bedarf des Teams zu verstehen, um bestmöglich bei der Umsetzung des Projektvorhabens zu unterstützen. Über einen Start-Workshop und einige Einzelgespräche finde ich heraus, dass Grundlagen zu neuen Methoden und zu Zusammenarbeit im Team im Sinne des agilen Manifests ein wirksamer Weg sein kann.
Im Wochenrythmus starten wir gemeinsam mit Scrum-Trainings und Basisarbeit für das Projekt. Konkret geht es darum, das agile Manifest mit den dazugehörigen Prinzipien und Werten zu verstehen und die Grundlagen des Scrum Prozesses in der Praxis zu erleben und anzuwenden. Mit diesem Ziel nutze ich auch einige Übungen, um die Vorteile von iterativem Arbeiten (z.B. Ball Point Game) und die Definition einzelner Rollen (z.B. Product Owner mit der Product Owner Challenge mithilfe von Lego) zu verdeutlichen.
Für den Start der inhaltlichen Arbeit im Projekt schlage ich vor, als erstes eine Produktvision zu erarbeiten, um für das Projekt eine Ausrichtung zu haben, an der sich das neu formierte Projektteam bei allen Aktivitäten orientieren kann. Im folgenden Schritt empfehle ich die Erarbeitung von Personas. Personas sind “ausgedachte” Stellvertreter der Kunden/Nutznießer des zu entwickelnden Produktes, die vom Projektteam benannt, priorisiert und sehr detailliert beschrieben werden. Hintergrund ist die Herausforderung, dass wir in den meisten Vorhaben zur Produktentwicklung die Kunden nicht direkt kennen, um die Erwartungen und Bedürfnisse erfragen zu können. Deshalb entwickelt das Team Details wie konkrete “sprechende” Namen (z.B. Max Musterschüler oder Thorsten Teamleiter), demografische Informationen und Einschätzungen zu Hobbies etc., um so konkret wie möglich eine Person vor Augen zu haben. Über die Beschreibung der Ziele und Bedürfnisse der einzelnen Personas ist es später wesentlich einfacher möglich, die Anforderungen an das Produkt abzuleiten und umzusetzen.
In der nächsten Phase geht es um das Kennenlernen des konkreten Produktes zu diesem frühen Zeitpunkt des Projektes in vollem Bewusstsein, dass sich die Anforderungen an das Produkt im Laufe der Umsetzung aufgrund der Komplexität des Themas noch dynamisch verändern werden. Als Methode wird mithilfe eines Story Mappings eine Gesamtübersicht aller Anforderungen in Form von User Stories entlang des Prozesses aus Kundenperspektive geschaffen.
Ein wenig erschwerend kommt in dieser ersten Projektphase dazu, dass die Entwicklung des Produktes nicht intern, sondern durch einen externen Dienstleister erfolgt. Die vertraglichen Rahmenbedingungen behindern ein wenig das Entstehen von einem echten agilen Mindset, trotzdem gelingt es dem Projektteam zumindest für das Projektmanagement rund um die eigentliche Produktentwicklung Scrum als Vorgehensrahmen zu erleben und für sich zu nutzen.
Das Team fängt trotz der nicht optimalen Rahmenbedingungen an, sich sehr konkret am Scrum Framework zu orientieren und den Alltag Sprint für Sprint zu gestalten. Bei den jeweiligen Sprintwechseln unterstütze ich durch Moderation und Impulse bzw. Denkanstöße von außen. In den Retrospektiven lernt das Team Schritt für Schritt das eigene Handeln im Team infrage zu stellen, um den Arbeitsprozess aber auch die Kommunikation und das Miteinander permanent zu verbessern. Nach anfänglichen Schwierigkeiten – aufgrund der großen Harmonie zwischen den Menschen – gelingt dies im Laufe der Zeit sehr gut.
Im fachlichen Ergebnis wird das Produkt erfolgreich veröffentlicht, auch wenn die Rahmenbedingungen kein sehr intensives Nutzen aller methodischen Stärken erlauben. Der Teil der Teamentwicklung in den agilen Ansätzen, der zu einem optimalen Miteinander und zu einer modernen Haltung führen, ist hingegen klar zu beobachten.
Das Team bedankt sich bei mir für die Unterstützung mit einen kleinen süßen Nachricht, was mich natürlich sehr gefreut hat.
Das Folgeprojekt mit geänderten Rahmenbedingungen…
Nach erfolgreicher Einführung der ersten Produktentwicklungsphase, wird das Team um interne Entwickler erweitert, um in dieser folgenden Phase das Produkt ohne externe Unterstützung um einen zweiten automatisierten Prozess zu erweitern. Erste Herausforderung ist in der Vorbereitung zum Start eine gemeinsame methodische oder prozessuale Basis zu finden. Die neuen Entwickler haben ebenso wenig Vorkenntnisse wie das bereits gestartete Kernteam vor dem ersten Projekt, und sie stehen spürbar derartigen Vorgehensmodellen eher skeptisch gegenüber. In einem kleinen Trainingstermin versuche ich mit den Neuankömmlingen die notwendige Basis zu schaffen… Puhh, da waren Widerstände im Raum ????
Im gemeinsamen Projektkickoff mit allen Beteiligten starten wir mit dem bereits erprobten Vorgehen: sehr pragmatisch und zielorientiert wird eine Produktvision für das zu entwickelnde Produkt geschaffen. Im Team herrscht eine sehr positive Stimmung und große Einigkeit zum Vorgehen. Auch die Überprüfung der bereits verwendeten Personas ist schnell erledigt – ohne große Überraschungen…
Zum Start der ersten “echten” Beschreibung des Produktes mithilfe des bereits einmal angewendeten Story Mappings wähle ich nochmal eine Übung, bei der es um das individuelle Morgenritual nach dem Aufstehen geht. Ziel der Übung ist das Entwickeln eines Gespürs für Prozesse, für Priorisierungen und letztlich für die Definition eines echten MVPs (Minimal Viable Product) – also das Kennenlernen einer agilen Denkweise weg von dem Anspruch der Vollständigkeit hin zu einer ersten Minimalversion des Produktes, um schnellstmöglich ein Kunden-Feedback zu nutzen, um das Produkt auf Basis der echten Kundenbedürfnisse kontinuierlich weiterzuentwickeln.
Bei den Erläuterungen zum MVP nutze ich visuelle Unterstützung mit einer Elefanten-Metapher. Der Elefant sollte bei Geburt zwar lebensfähig sein (alle Gliedmaßen dran etc.), ohne dass er schon voll ausgewachsen ist. Wenn ich ihn dann nach der Geburt füttere – also das Produkt weiterentwickele – dann wird er sich im Laufe der Zeit zu einem vollausgestatteten erwachsenen Elefanten entwickeln. Anders als beim klassischen Projektmanagement nach dem Wasserfallprinzip, wo die Teile des Produktes schon mal separat voneinander und nacheinander entwickelt werden, um dann festzustellen, dass die geänderten Rahmenbedingungen und Anforderungen dazu geführt haben, dass die Teile zwar fertig sind aber nicht mehr zueinander passen.
Im Nachgang an den Kickoff Termin entwickeln wir mithilfe des methodischen Ansatzes des Event Stormings die prozessuale Basis für das Story Mapping dieses Produktes. Im Story Mapping wird das gesamte Produkt entlang des Prozesses durch die Beschreibung von User Stories abgebildet, so dass ein erster Entwurf des Produktes vor uns an einer großen Glaswand sichtbar ist. Das Team erledigt das in vollem Bewusstsein, dass es sich nur um den ersten Entwurf handelt, der sich im Verlauf des Projektes durch neue Erkenntnisse oder geänderte Erwartungen der späteren Nutzer verändern wird.
Aus der Story Map wird im nächsten Schritt durch Priorisierung des Teams (und final durch den Product Owner) die ersten User Stories für das Product Backlog – also die Liste der Themen, die zuerst umgesetzt werden sollen – abgeleitet.
In der praktischen Arbeit des Teams war schnell zu beobachten, dass die anfängliche Skepsis der neuen Teammitglieder schnell verflogen ist, so dass sich ein stabiler Teamentwicklungs- und Produktentwicklungsprozess einstellt. Ich kann das in dieser Phase sehr gut von außen beurteilen, da das Team zu diesem Zeitpunkt so eigenständig agiert, so dass meine Unterstützung inzwischen lediglich in recht großen Abständen abgerufen wird.
Inhaltlich arbeitet das Team sehr konsequent an der Umsetzung des MVP, wobei die anfängliche Definition mehrfach überprüft und angepasst wird, da immer wieder neue Erkenntnisse genutzt werden, um die eigene Einschätzung zu schärfen. Das Team wirkt teilweise sogar etwas überrascht, dass der Product Owner – und somit der fachlich Verantwortliche – selbst so strikt und “großzügig” bereit ist, eine minimale Version des Produktes bereitzustellen. Ich denke, die Erfahrungen in der Vergangenheit sind für die meisten etwas anders gewesen.
Weil mir der konsequente Blick des Teams auf den MVP so gut gefällt, besorge ich in dieser Phase des Projektes ein kleines Elefanten-Stofftier, das einen Ehrenplatz im Projektraum bekommt.
Am Ende gelingt dem Team eine Veröffentlichung des Produktes (als MVP) zum ursprünglich angepeilten Termin, und das Feedback der unternehmensinternen Nutzer/Kunden fällt sehr positiv aus.
Und so erlebte das Projektteam die Zusammenarbeit im Team:
Motiviert in unser erstes agiles Projekt gestartet haben wir schnell gemerkt, dass die Rahmenbedingungen für einen vollen Einsatz der agilen Arbeitsweise bei uns noch nicht optimal waren. Wir haben uns also erstmal in dem Handlungsrahmen bewegt, den wir zur Verfügung hatten. Und so konnten wir von Beginn an einige wichtige Lektionen lernen, die uns seitdem die ganze Projektlaufzeit begleiten.
Zum Beispiel, wie wichtig es ist, den Kunden zu verstehen und einzubinden. Anfangs mussten wir uns regelmäßig selbst daran erinnern, den Kunden nicht zu vergessen. Inzwischen ist die Kundensicht für uns aber so ein zentraler Aspekt, dass wir immer, wenn wir uns unsicher sind, wie wir eine Funktion einbinden, einfach mal den Kunden fragen, statt selbst tagelang Optionen zu wälzen. Und siehe da: es klappt ???? Ein weiterer Punkt war die Zusammenarbeit im Team. Inzwischen sitzen wir alle gemeinsam in einem Raum, tauschen uns viel mehr aus als vorher und haben einige kleine Rituale entwickelt, die uns ein gutes Teamgefühl geben.
Und nicht zuletzt einer der wichtigsten Schritte in unserer Entwicklung: Wir haben verstanden, dass wir uns trauen dürfen auch Produkte auszuliefern, die noch nicht den vollen Funktionsumfang haben. Unser MVP stellt bereits einen so großen Mehrwert für den Kunden dar, dass fehlende Funktionalitäten kein No-Go Kriterium mehr sind. Der kleine Elefant ist für uns zu einer Metapher für “unser” Produkt geworden: Er kann laufen, hat Ohren und Rüssel, und mit jedem Sprint wächst er ein kleines Stück – und so tut es auch unsere Software.
Und jetzt macht sich der MVP Elefant tatsächlich auf Reisen:
