Drei Fragen und Antworten: Darum scheitern agile Projekte an den Stakeholdern
Stakeholder spielen eine entscheidende Rolle beim Gelingen oder auch Scheitern von agilen Projekten. Letzteres muss nicht sein, meint Nadine Riederer.
(Bild: iX)
Wenn agile Projekte scheitern, liegt die Ursache oft in Missverständnissen zwischen den agilen Teams und den Stakeholdern: Die gegenseitigen Erwartungen werden nicht erfüllt oder die unterschiedlichen agilen Rollen nicht verstanden. Wie kann es besser klappen? Darüber sprechen wir mit Nadine Riederer, CEO der Softwareentwicklungsfirma Avision.
Es gibt viele GrĂĽnde, warum agile Projekte nicht richtig funktionieren. Aber warum scheitern sie ausgerechnet oft an den Stakeholdern?
Oftmals fehlt einfach eine abgestimmte Vision darüber, was mit dem Projekt erreicht werden soll. Das passiert zum Beispiel, wenn motivierte Mitarbeiter im Unternehmen Projekte ins Leben rufen. Auch wenn es zu den agilen Prinzipien zählt: Die Initiatoren sind oft intrinsisch so stark motiviert, dass sie den anderen Stakeholdern, etwa dem Management, Auditoren, dem Scrum Master oder den Fachabteilungen, einfach davonlaufen. Auch Meinungsverschiedenheiten zwischen dem Product Owner (PO) und den Stakeholdern können zu Verdruss führen.
Es kommt auch vor, dass Stakeholder wegweisende Entscheidungen am PO vorbei treffen. Für ihn ist es dann in der Praxis oft sehr schwer, seiner Rolle gerecht zu werden und erfolgreich zwischen Stakeholdern und dem Entwicklungsteam zu vermitteln. Wenn dann von den Stakeholdern noch zusätzliche Rollen, wie beispielsweise Systemarchitekten, die nicht Teil des agilen Projektverständnisses sind, ins Team gesetzt werden, ist Ärger vorprogrammiert.
Ein agiles Umfeld bedeutet eben, dass das Team seine Rollen frei definieren und gemeinsam die beste Architektur entwickeln kann. Immer wenn Stakeholder funktionale Rollen so definieren, dass sie das agile Prinzip untergraben, treten Konflikte auf, die sowohl die Vorteile der Agilität als auch das gesamte Projekt gefährden.
Wie sollten sich Stakeholder richtig verhalten, um einerseits ihre Interessen zu wahren und andererseits den agilen Kontext und Fluss nicht zu stören?
Der wichtigste Aspekt in diesem Zusammenhang muss jedem klar sein – eine agile Arbeitsweise basiert auf einer Vertrauenskultur. Wenn es an Vertrauen mangelt, können agile Projekte nicht funktionieren. Dennoch darf Stakeholdern nicht der Blick ins Projekt verwehrt werden, schließlich sind sie die Nutznießer oder die Sponsoren des Projekts. Im Regelfall wird der PO die Kommunikation übernehmen, manchmal gibt es dafür noch einen außerhalb des agilen Vorgehens stehenden Projektleiter. Wichtig ist umgekehrt, dass Stakeholder nicht direkt in die agile Dynamik des Projektteams eingreifen. Aber gegen vertrauensbildende Kommunikation ist nichts einzuwenden, und eine Mitarbeit durch Fachexperten ist eines der Prinzipien der agilen Entwicklung und für den Erfolg auch dringend notwendig.
Ein weiterer Aspekt besteht darin, dass es oftmals für die Stakeholder ungewohnt ist, dass am Anfang nur ein Minimal Viable Product entsteht, also eine funktionale Minimalversion, die eben noch nicht alle Wünsche und Anforderungen enthält und auch nicht enthalten soll. An dieser Stelle ist es Aufgabe des PO, übermäßige Erwartungen einzubremsen und dies auch klar zu kommunizieren.
Stichwort kommunizieren: Wie sprechen die Product Owner und Scrum Master am geschicktesten mit den Stakeholdern, insbesondere solchen, die sich mit der agilen Arbeitsweise schwertun?
Die Rolle des PO ist nicht darauf angelegt, es immer allen recht zu machen. PO müssen auch einmal klare Kante zeigen und entscheidungsstark sein. Letztlich sind der PO und der Scrum Master die beiden Funktionen, die das Entwicklungsteam vor den Stakeholdern schützen. Dieser Schutzraum muss funktionieren, damit das Team ungestört arbeiten kann. Wenn Stakeholder keine Prioritäten setzen können, muss der PO ihnen das beibringen. Dazu zählt beispielsweise, dass bestimmte Entwicklungsziele nur langfristig erreicht werden, dass die Entwicklung mehr Zeit braucht oder in kleineren Schritten stattfindet. Bei agilen Projekten lassen sich anfangs keine neunzig Prozent des Produkts erreichen. Das Minimum Viable Product liegt vielleicht nur bei dreißig Prozent, aber es bildet die Ausgangslage, um weitere Entwicklungsschritte zu realisieren.
Ein häufiger Fehler von PO liegt darin, ein fertiges Produkt zum Zeitpunkt X zu versprechen. Das ist der falsche Ansatz und kann nur zu Problemen führen. Viel hilfreicher für PO ist es, die Vorteile agiler Entwicklung gegenüber Stakeholdern präsent zu halten. Denn man sieht viel früher die ersten Ergebnisse und kann dadurch den Entwicklungsprozess besser steuern.
Frau Riederer, vielen Dank fĂĽr die Antworten!
In der Serie "Drei Fragen und Antworten" will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vor dem PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.
(who)
