Vom Tanker zum Schnellboot

24. August 2018

Wer innovative Apps, Software oder digitale Dienst­leistungen entwickeln will, kommt mit klassischem Projekt­management nicht weit. Zu starr und unbeweglich sind dessen fixe Meilen­stein­pläne. Immer öfter setzen Start-ups und Unter­nehmen deshalb auf agile Methoden – so auch das Corporate Center Innovation von TÜV NORD. #explore erklärt, wie diese agilen Methoden funktionieren und warum man feste Strukturen und Rollen braucht, um so beweglich wie möglich kreieren zu können.

Wer den Bau einer Industrieanlage plant, steht vor einer komplizierten Aufgabe. Fuchst man sich jedoch mit entsprechendem Know-how in die Materie ein und legt sich einen sorg­fältigen Plan zurecht, werden bis zur Fertig­stellung wahrscheinlich keine grund­sätzlichen Änderungen auftauchen. Will man hingegen ein völlig neues Produkt entwickeln, etwa für Betreiber von Aufzügen, dann wird die Sache komplex, erklärt Martin Kisch vom Corporate Center Innovation bei TÜV NORD: „Weil ich das Bedürfnis der Betreiber noch nicht kenne, sich dieses vermutlich über die Zeit auch ändert und ich diese Veränderung nur bedingt voraussehen kann, wenn ich ein Projekt starte.“

Das klassische Projekt­management mit seinen Meilen­stein­plänen und fixen Zielen, die ohne Wenn und Aber in einer bestimmten Zeit ab­ge­arbeitet werden sollen, stößt hier an seine Grenzen. Um auf neue Anforderungen und Kunden­feed­back flexibel reagieren und auch in der fort­gesetzten Entwicklung den Kurs ändern zu können, braucht es mehr Beweglich­keit. Immer häufiger kommt in solchen Fällen agiles Projekt­management zum Einsatz. „Dabei wird das Ziel in einer Product Vision festgelegt, die beschreibt, in welche Richtung die Entwicklung gehen soll. Im laufenden Prozess wird dann immer wieder überprüft und entschieden, welcher nächste Schritt am meisten Sinn macht und den größten Mehr­wert erzeugt“, sagt Martin Kisch. Statt also starr eine vorher fest­gelegte Reihen­folge abzuarbeiten, soll sicher­gestellt werden, dass immer zuerst die Aufgaben erledigt werden, die aktuell am wichtigsten sind.

Sinnvoll ist agiles Projektmanagement auch dann, wenn ein Produkt nicht fix und fertig auf den Markt gebracht, sondern anhand des Kunden­feed­backs weiter­entwickelt werden soll. „Eine mögliche Dienst­leistung für Aufzugs­betreiber könnte etwa eine App sein, über die sie in Echt­zeit den Status ihrer Aufzüge sehen können: Laufen sie oder nicht?“, erläutert Martin Kisch. Das Entwicklungs­team stellt sich die Frage, welche Informationen die Betreiber benötigen, bereitet diese daraufhin auf und entwickelt ein sogenanntes „Minimal Viable Product“ – in diesem Fall eine App, die mit den angedachten Basis­funktionen aus­gestattet ist. Damit geht es zurück zu den Kunden, um sich deren Feed­back einzuholen. „Man kann sich kaum vorstellen, wie viel genauer Menschen sagen können, was sie brauchen und was für sie hilfreich ist, wenn man ihnen eine konkrete Anwendung in die Hand gibt“, schildert Kisch seine Erfahrung. Im nächsten Schritt macht sich das Team daran, die Änderungs­wünsche einzuarbeiten und die App so weiter zu verbessern.

Eingesetzt werden agile Methoden am Corporate Center Innovation etwa bei einem Projekt zur Online-Personen­zertifizierung und bei der Entwicklung einer Augmented-Reality-App für den Kraft­werks­bereich. Martin Kisch arbeitet mit seinem Team an einer Lösung, um Aufzugs­betreibern und Wartungs­unter­nehmen durch Daten­aus­wertung das Leben zu erleichtern. Dabei orientieren sie sich an Scrum, der bekanntesten und beliebtesten unter den agilen Projekt­management­methoden (mehr dazu im Info­kasten). Schließlich bedeutet Agilität eines natürlich nicht: Innovation auf gut Glück und nach ungefährem Bauch­gefühl. „Man braucht ein relativ festes Rahmen­werk, in dem man sich dann agil bewegen kann“, stellt der Innovations­manager klar. Dazu werden Abläufe festgelegt und die Rollen und Aufgaben verteilt, die jeder Beteiligte im Team übernimmt. Entwickelt wird in sogenannten „Sprints“, kurzen Arbeits­einheiten von maximal einem Monat. „Die Dauer bemisst sich nach der Komplexität der Aufgabe, die in dieser Zeit erarbeitet werden soll, aber auch nach den Abläufen des auftrag­gebenden Unter­nehmens“, berichtet Martin Kisch. Denn am Ende jedes Sprints wird den beteiligten Stake­holdern das Ergebnis präsentiert und anhand des Feed­backs gemeinsam entschieden, wie es von diesem Punkt aus weitergeht.

Der sogenannte „Product Owner“ übernimmt die Verantwortung dafür, dass in jeder Phase der Entwicklung der best­mögliche Output entsteht. Er pflegt auch das „Product Backlog“, eine Art To-do-Liste. „Darin werden alle Aufgaben fest­gehalten, die nötig sind, um die Product Vision − also das angestrebte Entwicklungs­ziel − zu erreichen.“ In enger Absprache mit den Stake­holdern und dem Entwicklungs­team sortiert er oder sie die Aufgaben inner­halb der jeweiligen Phase nach Wichtig­keit. „Um das best­möglich zu tun, muss ich auch gut über den potenziellen Markt und über Kunden­bedürfnisse Bescheid wissen“, führt Kisch weiter aus. Zusätzlich kümmert sich der Product Owner darum, dem Entwicklungs­team den Rücken frei zu halten, damit zum Beispiel aus­ufernder Mail­verkehr mit den Auftrag­gebern die Team­mit­glieder nicht von ihrer eigentlichen Entwicklungs­arbeit abhält.

Um Abstimmungswege kurz und einander täglich auf dem aktuellen Stand zu halten, beginnen Kisch und seine Kollegen jeden Tag mit einem „Daily Scrum“. In diesem 15-minütigen Team­meeting beantworten alle Teil­nehmer­innen und Teil­nehmer reihum drei Fragen: „Was habe ich gestern gemacht, um das Produkt voran­zubringen? Was mache ich heute? Was hindert mich bei meiner Arbeit?“ So wissen alle Beteiligten immer, wo die anderen stehen. Denn kontinuierliche Verbesserungen des Produkts und der Team­prozesse sind für agiles Projekt­management zentral. Deshalb rekapitulieren Kisch und sein Team auch nach jedem Sprint in einer sogenannten Retro­spektive: „Was lief gut, was lief weniger gut? Wurden wir vielleicht zu stark abgelenkt, weil zu viele neue Anforderungen hinzukamen? Was können wir machen, um das zu begrenzen?“, erläutert Kisch. Danach werden gemeinsam Regeln aufgestellt, um gute Abläufe fest zu etablieren und Störungen bestmöglich entgegenzuwirken.

Weil sich das Team beim agilen Projekt­management selbst organisiert, wächst auch die Verantwortung für jeden Einzelnen. Schließlich kann man sich nicht an einem Projekt­plan fest­halten, sondern muss selbst über­legen, welche Schritte am sinnvollsten sind, um das Projekt voran­zutreiben. Damit agiles Projekt­management funktioniert, müssen die auftrag­gebenden Unter­nehmen deshalb ein Verständnis für die damit verbundenen Neu­aus­richtungen entwickeln. „Hier geht es ja auch um Fehler­kultur“, sagt Martin Kisch. „Wenn ich etwas agil angehe, kann es durchaus sein, dass ich nach einem Monat feststelle, in eine falsche Richtung gelaufen zu sein.“ Eine solche Erkenntnis hat für Kisch allerdings nichts mit Scheitern zu tun, sondern ist ein wesentlicher Bestand­teil des Entwicklungs­prozesses. „Ob ein Ansatz sinnvoll ist, lässt sich im Vorfeld oft nicht voll­ständig abschätzen. Man muss ihn erst wirklich ausprobieren.“ Mut und Freiheit zum Experiment sind für Kisch deshalb essenziell. Denn im besten Fall führen gerade die vermeintlich riskanten Wege zu den im wahrsten Sinne innovativen Lösungen.