Für mich als Projektmanagerin ist es unglaublich spannend, wenn in einem hoch komplexen Prozess aus einer ersten Idee am Ende ein Produkt wird, das ein Unternehmen voranbringt. Meine Arbeit wird dabei daran gemessen, ob dieses Produkt hinsichtlich Kundennutzen, Budget, Zeitplan und Qualität alle gestellten Anforderungen erfüllt.
Im Juni 2017 übernahm ich mein erstes agiles Projekt: eine Software für strategische Marktprognosen. Im Oktober 2018 wurde die erste Version aufgespielt. Ursprünglich nur für einen Unternehmensbereich entwickelt, ist daraus sukzessiv eine Datenanalyse-Plattform mit KI entstanden, die heute zu verschiedenen Fragestellungen im Unternehmen erfolgreich genutzt wird.
Nach mehreren Jahren Praxiserfahrung bin ich restlos überzeugt von den Qualitäten des agilen Vorgehens. In diesem Beitrag möchte ich mit typischen Beispielen aus meinem Arbeitsalltag belegen, warum richtiges (!) agiles Vorgehen immer zum Erfolg führt.
Als Mitinitiatorin der Graswurzelbewegung von Working Out Loud (WOL) bei BMW bin ich auch deshalb von dieser Selbstlern-Methode so begeistert, weil sich agile Werte und WOL-Prinzipien decken, ergänzen und wechselseitig befruchten. Beide Ansätze beruhen auf Zusammenarbeit, Wertschätzung und Transparenz – also darauf, wie wir miteinander umgehen und dabei lernen können …
Natürlich ist agiles Vorgehen allein noch kein Garant für den Erfolg. Wer es dabei bewenden lässt, vorgegebene Meetings abzuhalten und den Prozess schematisch abzuwickeln, darf nicht automatisch auf ein gutes Projektergebnis hoffen. Dazu gehört ein bisschen mehr. Was genau, möchte ich in 5 kleinen Geschichten erzählen:
1. Schaffe eine sichere Basis für deine Produktvision.
Als ich mein erstes agiles Projekt übernahm, wollte das Management wissen, was ich dafür für das kommende Halbjahr und das nächste Jahr an Budget benötige. Ich muss tatsächlich für einen kurzen Moment ein wenig ratlos ausgeschaut haben. Wie sollte ich zu Projektbeginn Zahlen ermitteln, wenn beim agilen Vorgehen jederzeit neue Entwicklungen eintreten können? Mit Blick auf den Ausliefertermin der Software im folgenden Jahr hätte ich einfach hochrechnen können: die geschätzten Kosten für ein achtköpfiges Team über 17 Monate. So einfach wollte ich es mir aber nicht machen.
Ich wollte es genauer wissen. Gemeinsam mit dem Produkt Owner, drei Anwendern und dem IT-Architekten trafen wir uns zu einem zweitägigen intensiven Workshop. Zu den Funktionsbeschreibungen meiner Fachbereichskollegen für die neue Anwendung brachte ich die Sicherheits- und IT-relevanten Themen ein. Der IT-Architekt moderierte.
Visionen in Leitbildern festhalten.
Zusammen entwickelten wir aus all unseren Themen eine Produktvision in einem Bild. Außerdem entstand ein gefülltes Produkt Backlog mit einer Roadmap. Auf dieser Grundlage stellte ich dann dem Management meine Kalkulation der voraussichtlichen Kosten vor. Unser Bild führte gegen mein Erwarten zu heftigen Diskussionen. „Brauchen wir all das wirklich?“ „Sind diese Sicherheitsvorkehrungen noch zeitgerecht?“ Und ob sie das waren – das konnte ich gut darstellen. Wir hatten vieles berücksichtigt. Mit anderen Worten: dieses Bild war Gold wert. Denn nur mit dessen Hilfe haben wir die fruchtbaren Diskussionen angeregt, die so wertvolle Impulse für unsere Software brachten.
Leitbild als Basis zielführender Diskussionen.
Als das Entwicklerteam schließlich loslegte, folgte es dem Leitbild aus unserer Produktvision. Auf dessen Basis definierten wir zusammen mit den Entwicklern die nächsten Ziele. Und wenn wir beispielsweise bei bestimmten Umsetzungsthemen nicht mehr weiter wussten, stellten wir uns einfach vor dieses 2 x 2 Meter große Bild und debattierten, malten, änderten, strichen, ergänzten. Ich kann diesen anregenden Prozess beim Projektstart nur empfehlen. Ein solcher Planungsworkshop erweist sich als ungemein wertvoll für das gesamte agile Vorgehen.
2. Schätze im Team und nutze die Klugheit und die unterschiedliche Sicht jedes Einzelnen.
„3, 5, 5, 5, 5, 5, 5, 13, 5, 8, 5“, liest unser agiler Coach Jörg in die Runde blickend vor. Die meisten halten ihre Handys mit einer Zahl hoch, manche nutzen die Finger. Wir sitzen in einem hellen Konferenzraum. Auf dem Tisch dampft Kaffee und duften leckere italienische Kekse. Dieses besondere Meeting ist für mich ein Highlight, ein wichtiger Erfolgsfaktor, denn agiles Vorgehen setzt nun mal auf direkte Kommunikation. Und die ist manchmal gar nicht so einfach herzustellen. Zum Beispiel tüfteln Entwickler vielfach lieber an einem Problem als mit anderen darüber zu reden. In unserem Schätz- Meeting sind auch diese aktiv dabei.
Niemand bleibt ungehört.
Wirklich alle, egal ob Entwickler, Business-Analyst, Tester, unser Praktikant und Product Owner, müssen mit einer Fibonacci-Zahl die Komplexität einer Anforderung (User Story) schätzen. Das läuft in etwa so ab: Jörg bittet Sabine um eine Herleitung, warum ihrer Meinung nach die Komplexität der neuen User Story nur bei 3 liegt. Andreas wiederum soll darstellen, warum er auf 13 kommt. Dabei bedeutet 3 vielleicht ein Aufwand von einem halben bis einen ganzen Tag und die 13 könnte eine Woche Aufwand bedeuten. Jede Nachfrage zu den einzelnen Schätz-Angeboten, jede Erklärung dazu bringen uns weiter.
Miteinander reden und lernen.
So ergeben sich spannende Diskussionen, die uns allen tiefe Einblicke eröffnen. Jeder nimmt etwas mit und lernt. Dabei kommt es durchaus vor, dass ich im Verlauf des Meetings meine Meinung in eine ganz andere Richtung ändere. Unser Tester kommt zum Beispiel zu dem Schluss, dass eine einfache Datenauswertung mit Report eine langwierige Geschichte sei, da er erst Testdaten erstellen muss. Oder der Business Analyst hält den Datenimport aus einer csv-Datei in eine Oracle Datenbank für banal – wonach ihm der Entwickler erklärt, dass er bestimmte Datenfelder noch gar nicht in die Datenbank aufgenommen hat, was zu Änderungen in der Architektur führen kann. Durch die gemeinsame Diskussion lernen sich die Teilnehmer außerdem besser kennen, was das Teambuilding besser unterstützt.
3. Teste so, dass du dir der erfolgreichen Umsetzung der User Stories sicher sein kannst.
Agiles Vorgehen bedeutet die Lieferung der Software in mehrere Schritte. Das ermöglicht es dem Produkt Owner, das Produkt nach jeder Auslieferung mit seinen Anforderungen und Wünschen zu vergleichen. Ich halte es für sehr wichtig, dass eine neue Lieferung auf Herz und Nieren getestet wird. Und deshalb habe ich Mitarbeiter im Team, die nur für das Testen verantwortlich sind.
Ein zuverlässiger Sidekick für die Kreativen.
Manchmal hängt es an vermeintlichen Kleinigkeiten. Unsere Entwickler haben beispielsweise ganze Arbeit geleistet und die gewünschte Reiseabrechnungs-Software programmiert. Alles scheint stimmig, das Produkt sieht gut aus. Doch während wir voll des Lobes über die geniale Software-Architektur sind, entdeckt ein Tester ganz humorlos und gründlich ein falsches Anbieter-Logo, auf das sonst niemand geachtet hat. Oder eine Zeile auf dem Bildschirm, die da nicht hingehört. Oder eine nicht korrektes Überschrift. Mit seinem scharfen Blick fürs Detail ist er eine unglaubliche Entlastung für das Entwicklerteam, das sich um das große Ganze kümmern muss und dabei seiner eigenen kreativen Dynamik ungebremst folgen will.
Testen für die Qualität.
Bei uns steht der Tester dem Product Owner schon beim Festlegen der Akzeptanzkriterien zur Seite und benennt die Punkte, die für die Abnahme wesentlich sind. Denn was nützt eine Software, die zwar unendlich viele Funktionen hat, doch ständig abstürzt, langsam ist, unverständliche Fehlermeldungen ausgibt oder gar Daten verschluckt? Der Tester prüft die Funktionalität und erkennt Mängel in der Architektur und andere Probleme. Die Entwickler sollten ihn deshalb als unentbehrlichen Helfer verstehen. Wenn es ihm dann noch gelingt, viele Testschritte zu automatisieren, kann die geforderte Qualität auch in höherer Geschwindigkeit erreicht werden.
4. Stelle mit einer ausreichenden Dokumentation sicher, dass sich neue Teams oder Teammitgliedern schnell ins Thema einarbeiten können.
Viele agile Teams arbeiten nach dem Motto: „Der Quellcode reicht als Dokumentation.“ Diese Aussage mag zutreffen, wenn das Entwicklerteam auch nach Inbetriebnahme des Systems verfügbar ist, um eventuell aufkommende Fragen von Nutzern oder Systembetreuern zu beantworten. Doch das ist in bei uns nicht der Fall. Ich bin dafür verantwortlich, dass die komplexen Systeme gut und gerne über zehn Jahre im Betrieb sind. Diese müssen über den gesamten Zeitraum gewartet und betreut werden. Es gibt auch immer wieder neue Ausschreibungen für Betriebsteams, die Weiterentwicklungen vornehmen können. Wenn die Dokumentation dann nur im Quellcode vorliegt, müssen sich neue Teams erst mühsam in den Code einarbeiten. Außerdem stehen viele Schlüsselfakten eines Projektes nicht im Code: Security Themen, Betriebsprozesse, Interfaces, Architekt oder Monitoring.
Informationsmangel bremst.
Ich betreue neuerdings ein Projekt, bei dem der Support ständig bei den Entwicklern nachfragen muss, weil dieser nicht auf den Quellcode zugreifen kann und nur eine rudimentäre Dokumentation vorliegt. Die Entwickler werden so von der Arbeit abgehalten und auch der Supportmitarbeiter ist unzufrieden. Da knallen dann auch schon mal Türen oder die Stimme am anderen Ende der Telefonleitung ist ungewöhnlich kurz angebunden.
Hinzu kommt, dass der Anwender durch solche Informationsdefizite länger auf seine Lösung warten muss. Gute Dokumentation sorgt für eine reibungslose Zusammenarbeit.
5. Beachte die Architektur- und Sicherheitsaspekte.
Unser eingangs erwähnter Workshop hatte ergeben, dass wir eine komplexe Anwendung mit vielen verschiedenen Softwarekomponenten brauchten. Außerdem sollte diese SW-Plattform projektübergreifend nach Einsatz in der strategischen Planung auch in der Fahrzeugentwicklung und im Vertrieb einsetzbar sein. So stand ich vor der Frage, wie wir unter Zeitdruck ein erstes Architekturbild für ein Gesamtsystem ohne schmerzhaft hohen Folgeaufwand entwickeln konnten, das sich später entsprechend den Anforderungen anpassen ließ.
Weitblick spart Kosten.
Ein nur auf den Augenblick gerichtetes Vorgehen würde technische Unzulänglichkeiten provozieren, die in einer der nächsten Iterationen erneut betrachtet werden müssen. Dazu kommt es oft gar nicht. So werden etwa Lösungen von Fremdanbietern gekauft, deren mangelnde Flexibilität sich erst nach einiger Zeit herausstellt. Hohe Folgekosten können damit verbunden sein. Was heute nach einem Volltreffer aussieht, kann in zwei Jahren als Zielverfehlung Budgets durcheinanderwirbeln.
Architekturvision mit Entwicklungspotenzial.
Zur Produktvision gehört deshalb unbedingt auch eine Architekturvision. Diese beschreibt, um welche Art von System es sich auf technischer Ebene handelt. Zuerst muss der Architekt die Basisentscheidungen mit dem Team ausarbeiten und diese Entscheidungen dokumentierten. Diese Entscheidungen sind am Anfang noch schlank ausgeprägt und sollten bei Bedarf weiter verfeinert und risikoorientiert detailliert werden.
Agil meets WOL.
Hier schließt sich der zu Beginn gezogene Kreis mit der Methodik von Working Out Loud: WOL eignet sich ausgezeichnet, um das für agiles Vorgehen nötige Mindset herzustellen. WOL heißt nichts anderes als: stelle Fragen, unterstütze, fördere, inspiriere, lebe vor, vertraue. Ich stelle in diesen Tagen mit Freude fest, wie unter dem Eindruck der Corona-Krise WOL-Kickoffs in meinem Unternehmen noch einmal mehr gesteigerte Beachtung finden. WOL ist agil, ist frei, unterliegt keinem Lockdown. Und hier steht mehr darüber.
