Ist eine explizite Top-Management-Unterstützung wirklich zwingend notwendig, um agiles IT-Projektmanagement in Großunter-nehmen zu etablieren? In manchen Fällen haben Projektleiter genügend Handlungsspielraum, um agile Strukturen in ihren nach außen hin klassisch gemanagten Projekten einzuführen - auch ohne explizite Zustimmung des Top-Managements. Damit können sie einen Prozess starten, an dessen Ende mitunter die komplette Umwandlung der Organisation steht: Klassische Hierarchien und Konzernstrukturen werden aufgebrochen und durch eine Organisation mit größerer Kundennähe, flexiblem Anforderungsmanagement und besserem Überblick über Projektfinanzen ersetzt.
In der Praxis kommt der Wunsch nach einer neuen Vorgehensweise meist aus den Projekten selbst, ausgelöst etwa durch einen Alltag voll aufreibender Diskussionen mit dem externen Auftraggeber darüber, was noch zum Projektumfang gehört und was nicht. Anstöße ergeben sich auch aus Konflikten über Änderungsbudgets, bei deren Schätzung Projektleiter und Klient naturgemäß häufig auseinanderliegen. Darüber hinaus gehören Mitarbeitereng-pässe bei gleichzeitigem Termindruck in etlichen Firmen und Projekten zum Alltag.
Die agile Methode scheint da vielen ein Ausweg, unter anderem dadurch, dass sich die Planung an der tatsächlichen Leistungsfähigkeit der Teams orientiert. Die kurzen Entwicklungszeiträume von meist zwei bis vier Wochen geben den Auftraggebern die Möglichkeit, Prioritäten und Anforderungen in schnellem Rhythmus zu korrigieren, so dass Änderungsbudgets der Vergangenheit angehören. Zudem können die regelmäßigen Kundenrückmeldungen wichtige Impulse für die weitere Entwicklungsarbeit geben.
Das Beste aus zwei Welten
Verfügen Projektleiter über ausreichende Kompetenzen, sind sie in der Lage, eine agile Arbeitsweise in ihren Projekten einzuführen und gleichzeitig noch "klassisch" an das Management zu berichten. Das ist vor allem dann interessant, wenn im Management Skepsis gegenüber Scrum oder Kanban herrscht. In diesem Fall kann es für Projektleiter ein vielversprechender Weg sein, eine grundsätzliche Genehmigung beziehungsweise Duldung des Managements einzuholen und auch dann zu starten, wenn keine wirkliche Unterstützung durch die Organisation zu erwarten ist.
Praxisbeispiel: In einem Projekt zur Entwicklung einer Web-Applikation nach Kanban übernimmt der Projektleiter die Rolle des Product Owners und Kanban-Verantwortlichen. Wie vorher in der klassischen Struktur nimmt er als Projektleiter an Sitzungen des Lenkungsausschusses teil und berichtet direkt an das Management. Auf Basis der Informationen zur Anzahl der durchschnittlich erledigten Aufgaben kann er dort wie im klassisch geführten Projekt explizite Angaben zum Projektfortschritt und der geplanten Fertigstellung machen - im Idealfall sogar genauere als früher. Der Begriff "Kanban" muss dabei nicht unbedingt fallen.
Falls die agilen Methoden im Projektverlauf überzeugen - zum Beispiel dadurch, dass Projektbudgets nun effektiver eingesetzt werden und die Kundenrückmeldungen positiv ausfallen - ist es wahrscheinlich, dass Mitarbeiter anderer Projekte im Unternehmen darauf aufmerksam werden und früher oder später ebenfalls den Einsatz von Scrum oder Kanban verlangen. Auf diese Weise kann sich die neue Methode in der Organisation verbreiten.
"Leise" Einführung agiler Methoden
Allerdings gibt es eine Reihe von Voraussetzungen dafür, dass die auf diese Art eingeführten agilen Methoden tatsächlich den gewünschten Erfolg bringen: Zum einen sollte vorher überprüft werden, ob agile Methoden überhaupt vielversprechend für das Projekt sind. Sind etwa die Projektanforderungen schon genauestens definiert und nicht viele Änderungen zu erwarten, bietet sich ein klassischer Projektmanagementansatz an. Auch in Fällen, in denen das Projektziel überwiegend durch einfache und sich wiederholende Arbeitsschritte zu erreichen ist (Beispiel: Digitalisierung eines Aktenbestandes), sollte von agilen Methoden Abstand genommen werden.
Zum anderen muss die Projektleiterin oder der Projektleiter wirklich überzeugt von der einzusetzenden agilen Methode sein und genügend Handlungsspielraum haben, um neue Strukturen im Projekt einzuführen. Das schließt insbesondere die Hoheit über Budget und Personaleinsatz ein.
Klassischer Ansatz auf dem Prüfstand
Darüber hinaus sollte ein erfahrener Scrum Master beziehungsweise Scrum Coach das Team in der Anfangsphase über mehrere Monate begleiten. Diese Expertise wird in vielen Organisationen nicht intern vorhanden sein, sondern von außen kommen müssen, das heißt in Form einer Neueinstellung oder durch externe Berater. Hilfreich ist zudem ein Scrum- beziehungsweise Kanban-Workshop zu Beginn, um schnell Basiswissen aufzubauen. Individuelle Trainings für Mitarbeiter, die Schlüsselrollen - wie etwa die des Product Owners - übernehmen sollen, tragen zu einer schnellen Rollenfindung bei.
In der Praxis zeigt sich, dass Unternehmen die Rolle des Scrum Masters häufig unterschätzen. Dann übernimmt beispielsweise ein Mitarbeiter "nebenbei" diese Rolle oder sie wird einem Mitglied des Entwicklungsteams als Zusatz-aufgabe übertragen. Gerade zu Beginn ist dies fatal: Nicht selten haben Teams dann auch einige Monate nach dem Start noch keine zufriedenstellende Arbeitsgeschwindigkeit, klagen über ungelöste Produktivitätshemmnisse und verbringen viel Zeit in ineffizienten Meetings, die die Motivation weiter verringern.
Die "leise" Einführung agiler Methoden kann vielfältige Auswirkungen auf die Unternehmensorganisation und -hierarchien haben. Generell nimmt die direkte Einflussmöglichkeit des mittleren Managements im agilen Umfeld gewöhnlich eher ab, die Verantwortung und Entscheidungsfreiheit der Mitarbeiter hingegen zu - was vor allem durch die in agilen Projekten geforderte Selbstorganisation der Teams verursacht wird. Dies muss jedoch nicht zwangsläufig einen Machtverlust für Manager bedeuten.
Einfluss ausweiten
Wenn sie ihre Herangehensweise dem agilen Umfeld anpassen, können sie ihren Einflussbereich halten oder sogar ausbauen. Drei Ansatzpunkte spielen hier eine wichtige Rolle:
Informationen zur Leistungskontrolle und Projektfortschritten ermitteln
Themen und Ziele einbringen und vorantreiben
Projekterfolge als Hebel nutzen.
Leistungskontrolle und Projektfortschritt
Manager sollten in Erfahrung bringen, auf welche Weise sie imagilen Umfeld Informationen über die Leistung ihrer Mitarbeiter und die Projektfortschritte erhalten können. Denn wenn wie bei Scrum ausschließlich die Teamleistung erfasst wird, funktionieren gewöhnliche Modelle zur Leistungskontrolle von Mitarbeitern nicht mehr. Kennzahlen innerhalb von Scrum und Kanban - etwa die Anzahl von Storypoints pro Mitarbeiterstunde oder die Durchflussgeschwindigkeit - dienen hauptsächlich zur Arbeitsoptimierung innerhalb des Teams und lassen sich nur über Umwege für eine individuelle Leistungserfassung heranziehen. Auch besteht bei selbstorganisierten Teams die Gefahr von Demotivation und Widerstand, wenn Manager versuchen, von außen steuernd einzugreifen.
Einen in manchen Konzernen genutzten Ausweg bietet die Rundumbewertung. Dabei fließen in die Leistungsbewertung eines Mitglieds des Entwicklungsteams zum Beispiel sowohl Einschätzungen von den eigenen Teamkollegen als auch das Teamergebnis insgesamt ein. In der Praxis sind solche Ansätze vor allem dann erfolgreich, wenn die Bewertungsmethoden von den Mitarbeitern als transparent und fair empfunden werden. Gute Chancen dazu bestehen, wenn der Leistungsbewertungsansatz gemeinsam mit dem Team entwickelt wird - falls der Schritt Richtung Agilität ernst gemeint ist, ist ein solches gemeinschaftliches Erarbeiten geradezu ein Muss.
Foto: CGI Deutschland
Informationen zum Projektfortschritt zu erhalten, ist deutlich einfacher. Hier geht es vor allem darum, sich mit neuen Reporting-Techniken vertraut zu machen, zum Beispiel mit dem so genannten Burn-Down-Chart bei Scrum - einem tagesaktuellen Bericht darüber, ob sich das Team im Plan befindet - oder der Durchflussgeschwindigkeit bei Kanban - einer Auskunft über die Geschwindigkeit der Aufgabenerledigung. Diese Informationen sind üblicherweise an frei zugänglicher Stelle virtuell oder physisch präsent. Ansprechpartner für weitere Kennzahlen ist der Scrum Master oder Kanban-Verantwortliche und generelle Auskunft zum Projektfortschritt gibt der Product Owner.
Einbringen und vorantreiben
Darüber hinaus ist es für Manager entscheidend zu wissen, wie sie ihre Themen und Ziele einbringen und vorantreiben können. Der direkte Weg darüber führt im agilen Umfeld über das Product Backlog, also die Liste der Anforderungen. Manager sollten des-halb in Erfahrung bringen, auf welchem Weg sie Themen in das Product Backlog einbringen können und wer Einfluss auf deren Priorisierung und damit Bearbeitungsreihenfolge hat.
Formal ist der Product Owner verantwortlich für das Product Backlog. Mitunter aber üben andere Instanzen einen wichtigen Einfluss aus, zum Beispiel der direkte Vorgesetzte, die Marketingabteilung oder manchmal auch eine Gruppe von Anforderungs-managern.
Projekterfolg als Hebel nutzen
Kennen Manager den Budgetverantwortlichen, haben sie ausreichend Ansatzpunkte, um mit dem agilen Projekt eigene Ziele zu erreichen und ihre Mitarbeiter weiterzuentwickeln. Richtig eingesetzt ergeben Scrum und Kanban durch die Fokussierung auf die dem Kunden und Unternehmen wirklich wichtigen Themen ein wertvolles Instrument, mit dem herausragende Projektergebnisse erzielt werden können.
Ist das mittlere Management vorbereitet und nutzt sowie unter-stützt agile Projekte aktiv, fördert es damit den Wandel des gesamten Unternehmens. Denn bei entsprechend positiven Ergebnissen agiler Projekte, etwa einer höheren Reaktionsgeschwindigkeit auf Kundenanforderungen und einer verbesserten Finanzlage, wird aller Wahrscheinlichkeit nach auch das Top-Management schnell überzeugt sein, dass es sich lohnt, den Weg in Richtung agile Organisation zu gehen.