Welche Kompetenzen brauchen die Mitarbeiter/ Projektmitglieder fürs Agiles Projektmanagement?

Question

Mich würde es Interessieren, welche Kompetenzen die Mitarbeiter mitbringen müssen fürs Agiles Projektmanagement..

Könnte man einfach die Mitarbeiter aus dem „traditionellen PM“ einfach ins Agile PM mitnehmen? Was ist im Agilen PM anders?

Answer 1

(Hinweis: Diese Antwort ist lang, musste aber leider sein, um die Zusammenhänge klar herauszustellen)

Teil1-Hintergründe:

Um die Frage zu beantworten, ist es notwendig ein wenig auf die Hintergründe zu blicken, um den Unterschied deutlich zu machen.

Klassisches Projektmanagement geht von der Hypothese aus, dass man Projekte planen könne. Dies ist richtig, wenn sich Erfolgsfaktoren für das Projektziel stabil und vorausplanbar darstellen. Man setzt auf Wissen, das verfügbar ist. Z.B. wenn eine neue Straße gebaut werden soll, dann gibt es zwar auch hier unbekannte Faktoren (z.B. der Fund einer Fliegerbombe). Im großen und ganzen aber ist klar, was getan werden muss und wie lange einzelne Schritte (z.B. Einebnung der Landschaft, Auffüllen mit Sand oder Kies und schließlich Teeren und Fahrbahnkennzeichnung) benötigen. Damit lässt sich gut planen und die Koordination zwischen all diesen Schritten kann von einer zentralen Bauleitung durchgeführt werden. Hier zu versuchen agil vorzugehen, wäre ineffizient und würde unnötigen Overhead bedeuten. Es ist einfach nicht sinnvoll eine Straße Woche um Woche immer um ein 50 m Stück zu erweitern. Der Bau einer 10 km langen Autobahn würde einfach zu lange dauern.

Anders sieht dies aus, wenn der dynamische Anteil den planbaren Anteil überwiegt. Dies ist bei Softwareentwicklung z.B. so gut wie immer der Fall. Deshalb ist es nicht verwunderlich, dass agile Methoden hier ihr Ursprung fanden. Bei Softwareentwicklung kann man zwar die Ziele definieren und auch durchaus auf einer Zeitleiste aufplanen. Niemand weiß aber wirklich, ob dieser Plan funktioniert. Es gibt zu viele Unbekannte. Performt die neue Schnittstellen-Technik so wie man es sich erhofft? Sind Sicherheitslücken vorhanden, die bisher unerkannt blieben? Werden die Nutzer das erdachte Design annehmen und als hilfreich empfinden? Diese Fragen können vorher nicht beantwortet werden, sondern immer erst dann, wenn etwas getan wurde, also 'die Straße' bereits gebaut ist. Deshalb setzt agiles Projektmanagement auf schnelle Feedbackzyklen, damit diese Unbekannten (man könnte auch Risiken sagen) schnell erkannt werden und gegengesteuert werden kann, um das Projektziel nicht zu gefährden. 

Wenn wir also zunächst zu der Frage notwendiger Kompetenzen kommen, dann gehört ein profundes Grundverständnis der Hintergründe auf jeden Fall dazu. Hinter dem klassischen Projektmanagement steht ein ganz anderes Denkmodell, nämlich das der stabilen und voraussagbaren Planung. Der Versuch mit diesem Denkansatz ein Projekt mit hohem Dynamikanteil steuern zu wollen, schlägt meist fehl, weil die dazugehörigen Prozesse und Strukturen einfach nicht für diese hohe Dynamik ausgelegt sind.

Das klassische zentrale und in der Rolle der Projektleitung gesamthaft dem Projektleiter zugeschriebe Projektmanagement ist im agilen auf mehrere Teilrollen mit klar abgegrenzten Verantwortlichkeiten aufgeteilt. Dies ist nicht Zufall, sondern ganz bewusst so gewählt, damit die dazugehörigen Prozesse optimal mit der hohen Dynamik umgehen können. Man kann natürlich Mitarbeiter aus dem klassischen PM natürlich ins agile PM übernehmen. Es muss aber klar sein, dass dies mit dem Loslassen von bestimmten Verantwortlichkeiten einhergeht. Dies zu ignorieren führt meist zum Scheitern des agilen PM, so dass die Vorteile agilen Projektmanagements nicht genutzt werden können. Schlimmer noch, es bringt zusätzliche Unklarheit und Unruhe ins System, weil plötzlich verschiedene Kräfte, Denkweisen und Praktiken im systemischen Widerspruch stehen, so dass die Leistungsfähigkeit der Organisation statt zu steigen, noch weiter fällt. Ich habe es durchaus schon erlebt, dass Firmen, die auf agil umgeschwenkt sind und diese systemischen Konflikte nicht aufgelöst haben, nicht mehr wettbewerbsfähig waren.

Schauen wir uns die Aufteilung der Projektmanagement-Verantwortlichkeiten genauer an am Beispiel von Scrum. Hier teilen sich das Projektmanagement diese 3 Rollen: Product Owner, Scrum Master und Delivery-Team. 

Der Product Owner ist verantwortlich dafür, dass die einzelnen Bestandteile die auf das Projektziel einzahlen optimal im Sinne des Kundennutzen priorisiert sind. Dies ist eine herausfordernde Aufgabe, weshalb sich der Product Owner auch von seinem Delivery-Team und weiteren Business-Experten beraten lässt. Die Product Owner Rolle ist hier bewusst als Rolle für eine Einzelperson definiert. Denn damit die Organisation handlungsfähig bleibt und nicht in Prioritätskonflikten hängenbleibt, fällt dem Product Owner zu jeder Zeit die taffe Aufgabe zu, Entscheidungen zu fällen, wie es weitergehen soll im Projekt. Er hat, wenn es sonst zu keiner Einigung kommt, das letzte Wort, das von allen zu respektieren ist. Instabile Entscheidungen (z.B. weil der Product Owner keine klaren Entscheidungen trifft, weil seine Entscheidungen womöglich nicht respektiert werden, weil er seine Entscheidungen aufgrund intransparenter Daten fällt) sind schädlich und teuer für das stete Vorankommen hin auf das Projektziel. Dem Product Owner kommt also eine ganz wesentliche Führungsrolle zu, wenn es darum geht, wie der Weg (= Zwischenetappen) hin zum Ziel aussehen mag. Er sorgt dafür, dass das Delivery-Team Klarheit und Orientierung hat, was wichtig ist und auf das Projektziel einzahlt und was bewusst eben nicht im Fokus steht und zweifelhaften Kundennutzen stiftet.

Doch woher weiß der Product Owner, was tatsächlich den höchsten Kundennutzen hat? Die Antwort lautet: Er weiß es nicht. Niemand was das! Denn die priorisierten Anforderungen sind genau genommen keine Anforderungen, sondern lediglich Hypothesen, was aus Kundensicht nützlich sein könnte. Deshalb bleibt es in einem agilen Projekt nicht aus, diese Hypothesen durch schnelles Feedback - idealerweise direkt vom Markt - zu validieren. Das ist der Grund, warum ein Scrum-Team nach jedem Sprint eine lieferbares Inkrement erstellen soll und muss. Sonst ist die schnelle Feedbackschleife schlicht nicht möglich und irrtümliche Entscheidungen hinsichtlich der Priorität und Anforderungen werden zu spät und damit zu teuer erkannt.

Welche Kompetenzen muss also ein Product Owner mitbringen?:

• Entscheidungskompetenz! Besser eine irrtümliche Entscheidung als keine und damit Unklarheit, wie es weitergehen soll.
• Kommunikationskompetenz! Der Product Owner muss zwischen verschiedenen Stakeholder (incl. Kunden)-Wünschen abwägen, vermitteln und erklären, warum er sich gerade für eine bestimmte Priorität entschieden hat. Außerdem muss er in der Lage sein, die Kundenwünsche seinem Delivery-Team sehr deutlich klar zu machen. Damit ist nicht gemeint, dem Delivery-Team zu sagen, was es tun soll, sondern dem Delivery-Team zu erklären, wie sich ein aus Kundensicht vorhandenes Problem darstellt und woran sich messen lässt, dass das Kundenproblem gelöst wurde. Er ist aber NICHT für die Lösung verantwortlich (später beim Delivery-Team mehr davon).
• Visualisierungskompetenz und Erfahrung mit Techniken, die insbesondere für wertgetriebenes Denken und partizipatives Zusammenarbeiten designed sind. Z.B. Story Mapping, User Stories, Produktvision und -strategie, Impact Mapping, Event Storming etc.
• Und natürlich muss er sich in seinem Business bzw. Produkt, das er verantwortet auskennen.

Aus meiner Erfahrung ist die dem klassischen Projektmanagement kompatibelste Rolle im agilem Projektmanagement die des Product Owners, da hier viele führende Elemente des klassischen Projektmanagements wiederzufinden sind.

Teil 2 behandelt Delivery-Team und Scrum-Master

Answer 2

Teil 2 - Delivery-Team und Scrum-Master:

Kommen wir zur Rolle des Delivery-Teams. Wie bereits eingangs erwähnt unterliegen agile Projekte hoher Dynamik. Das heißt, täglich kann es viele Überraschungen geben, mit denen niemand gerechnet hatte und auch nicht rechnen konnte, da schlicht unbekannt. Im klassischen PM kam der Projektleitung ebenfalls die Aufgabe zu, diese Überraschungen entsprechend zu berücksichtigen und Gegenmaßnahmen einzuleiten (z.B. Fund einer Fliegerbombe wie oben beschrieben beim Bau einer Straße). In agilen Projekten ist jedoch der Dynamikanteil so hoch, dass der Versuch eines zentralen Umgangs mit dieser durch die Projektleitung schlicht zur Überforderung und damit zum Kollaps der zentralen Steuerung führt. Dies drückt sich aus in nicht ausreichend schneller Berücksichtigung dieser Dynamik, was zu langsamen Entscheidungen und damit Wartezeiten für die ausführenden Mitarbeiter führen würde. Deshalb ist in agilen Projekten der Umgang mit diesen Überraschungen so geregelt, dass das Delivery-Team eigenverantwortlich und schnell entscheiden kann, wie es auf diese reagieren möchte, um die Risiken der Zieleverfehlung (z.B. zu spätes Liefern) möglichst zu minimieren. Z.B. wenn sich herausstellt, dass während der Entwicklung ein unbekannter bisher im Produkt enthaltener Fehler zu Tage getreten ist, ohne dessen Behebung nicht weiter an den neuen Funktionalitäten gearbeitet werden kann, so kann es eigenmächtig entscheiden, zuerst möglichst schnell den Fehler zu beheben und trotzdem noch das Sprintziel (das Produktinkrement am Ende einer Iteration) zu erreichen. Eine Verzögerung z.B. durch Übergabe bzw. Eskalation an ein zentrales Projektmanagement würde zu lange dauern und wenn das Projektmanagement gerade unter hoher Last steht und nicht schnell antworten kann, würde durch diese Verzögerung die Gefahr das Sprintziel zu verfehlen zu groß werden. Deshalb sind im agilen Projektmanagement das Delivery-Team mit der Verantwortung ausgestattet, selbstständig und selbstorganisiert und damit hocheffektiv die Aufgaben zu koordinieren, die nötig sind, um das mit dem Product Owner ausgehandelte Sprintziel zu erreichen. Natürlich gehört dazu die Verantwortlichkeit für den zu erarbeitenden Lösungsweg, der das Sprintziel möglich macht. Der Product Owner definiert nur, welches Ziel erreicht (oder Problem gelöst) werden soll und überlässt diese Aufgabe eigenverantwortlich den Experten im Delivery-Team, die dazu die beste Kompetenz haben.

Was uns zu den Kompetenzen für das Delivery-Team bringt:

• Technische Exzellenz (alle sollen stets durch eine hohe Könnerschaft ausgezeichnet sein und wenn nicht vorhanden, muss dem Delivery-Team der nötige Freiraum eingeräumt werden, damit dieses diese Könnerschaft aufbauen kann)
• Teamplay! Es gibt keine Einzelverantwortliche im Delivery-Team. Das Team gewinnt entweder gemeinsam, oder es verliert gemeinsam. Dadurch sollen hausgemachte Expertenrollen vermieden werden, die schnell zu einem künstlichen Bottleneck werden können. Das bedeutet im Umkehrschluss: Alle sind für Alles verantwortlich was im Delivery-Team passiert. Das bedeutet nicht, dass jeder alles können muss. Sondern es bedeutet, dass jeder aufgefordert ist, beim Auftreten von Überraschungen sofort zu agieren und sich darum zu kümmern.
• Leadership Kompetenzen. Es ist nicht ungewöhnlich, dass sich innerhalb eines selbstorganisierten Teams natürliche Führung ausbildet. Wenn jemand etwas besonders gut kann, z.B. ein kommunikativer Softwarearchitekt, dann spenden diesem andere Entwickler gerne Gefolgschaft. Was diesen automatisch zur Führung bestimmt. Damit ist jedoch nicht Führung per Dekret oder ausgewiesene Rolle gemeint, sondern Führung durch freiwillige Legitimation, eben Gefolgschaft. Gibt es gerade analytische Aufgaben zu tun, so kommt dem Architekten eine Führungsrolle zu. Wird zu einem anderen Zeitpunkt viel Test-Knowhow benötigt, wechselt die Gefolgschaft des Teams automatisch zu demjenigen Könner, der hier seine Spezialität hat. Es ist wichtig, dass dieser unterschied zw. freiwilliger Gefolgschaft und Führung per Rollenausweisung einer Person unterschieden wird. Jegliche äußere Einflussnahme auf diese natürliche Herausbildung von Führung stört empfindlich diesen team-internen Prozess und für zu dysfunktionalen Teamverhalten (z.B. Konkurrenzkampf, Zurückhalten von Informationen, mangelndes Vertrauen zwischen den Teammitgliedern usw.).
• Neben Hardskills (Testen, UX/UI, Entwickeln, Analysieren, Deployment etc.) sind also insbesondere das Vorhandensein wichtiger Softskills im Team essenziell für dessen Erfolg. Dazu gehören nicht nur das oben erwähnte Leadership, sondern auch Mediation, effektive Kommunikation, Reflexionsfähigkeit usw.)

Kommen wir noch zur letzten Rolle im agilen Projektmanagement bei Scrum, dem Scrum Master. Wenn dem Product Owner die Verantwortung für die fachlichen Dinge zugeordnet ist, dann ist dem Scrum Master die Verantwortlichkeit für die Effizienz und Effektivität der vorhandenen Prozesse zuständig. Und das bedingt Vieles weshalb man durchaus auch sagen kann, der Scrum Master ist Mädchen für Alles. Seine Rolle kann durchaus ebenfalls als Führungsrolle verstanden werden. Jedoch nicht per formaler Macht, sondern als Aufklärer, Moderator, Facilitator, Prozesskümmerer, Trainer, Mentor, Vertrauensperson etc. Er ist aber nicht inhaltlich (also fachlich) verantwortlich, wie auch nicht verantwortlich dafür, dass das Delivery-Team seine Ziele erreicht.

Stattdessen wirkt er auf den Erfolg des Projektes ein, indem er organisatorische Schwächen und Konflikte, teaminterne Dysfunktionen, zwischenmenschliche Probleme, falsch verstandenes Rollenverständnis und Hindernisse aller Art transparent macht, so dass er gemeinsam mit dem Product Owner, dem Delivery-Team und weiteren Beteiligten (z.B. Management, aber auch Kunde) reflektieren kann, wie die Effektivität und Effizienz des Arbeitssystems optimiert werden kann. Da in einem agilen Projekt ständig neue Überraschungen auftreten, für die bisher noch keine passenden Gegenmaßnahmen vorhanden sind, ist dies eine nie aufhörende Tätigkeit. Z.B. wenn ein Teammitglied das Team verlässt oder ein neues Teammitglied hinzukommt, müssen Teamforming-Prozesse neu durchlaufen werden, die oft nicht direkt sichtbar sind, jedoch durchaus nachteiligen Einfluss auf die Leistungsfähigkeit des ganzen Scrum-Teams haben können.

Als Mädchen für Alles muss der Scrum-Master vielfältigste Kompetenzen mitbringen:

• Systemisches Denken und Erfahrung mit geeigneten Visualisierungstechniken
• Sozialkompetenz! Er arbeitet mit Menschen zusammen an wirksamer Veränderung. Adäquate Überzeugungsfähigkeit und Empathie im Umgang mit Widerstandsreflexen der Organisation bzw. des Scrum-Teams sind wichtige Fähigkeiten.
• Große Erfahrung mit Reflexionstechniken (z.B. Retrospektive in verschiedensten Moderationsformaten)
• Umfangreiche Erfahrung agiler Werte und Prinzipien, aber auch dazu passende Techniken, um die Rollen Product Owner und Delivery-Team effektiv coachen zu können
• Mediationsfähigkeiten. Die Rollen Product Owner und Delivery-Team sind per Intention so definiert, dass sie in einem natürlichen Spannungsverhältnis stehen. Da Menschen diese Rollen besetzen, sind zwischenmenschliche Konflikte nicht selten. Er muss wirksam vermitteln können zwischen diesen Rollen.
• Organisatorisches Tätigkeiten sind oft gern dem Scrum Master zugeschrieben, müssen das aber nicht notwendigerweise sein. Alles was ein Delivery-Team auch selbst tun kann, steht diesem frei zu tun. Indem der Scrummaster sich um die Organisation von Scrum-Events, gerade jetzt in Corona erzwungenen Homeoffice Zeiten insbesondere um die Vorbereitung von Remote-Tools kümmert, nimmt der dem Delivery-Team und dem Product-Owner diese aufhaltenden Tätigkeiten ab und sorgt so für eine weitere Steigerung der Leistungsfähigkeit des gesamten Scrum-Teams.

Wenn man abschließend also überlegt, was im agilen PM anders ist, muss man konsequenterweise sagen: So etwas wie agile PM gibt es gar nicht, also nicht in Form einer Rolle oder einer Abteilung. In agilen Projekten kommt die Rolle des Projektmanagements ALLEN Beteiligten zu. Wie diese z.B. bei Scrum aufgeteilt ist, ist im Scrum-Guide genau definiert und sehr besonnen aufeinander abgestimmt. Je klarer diese Aufteilung allen bewusst ist und je konsequenter diese verteilte Form des Projektmanagements gelebt wird, desto mehr Nutzen kann die Organisation daraus ziehen. Eine direkte Konsequenz gut angewandten verteilten und agilen Projektmanagements ist nicht selten daran erkennbar, dass die Organisation deutlich weniger mit internen Dingen beschäftigt ist bzw. von diesen bereinigt ist, wie z.B. Statusberichte, Ressourcenmanagement, JourFixes zw. Abteilungen, aufwändige Genehmigungsprozesse usw. Genau diese Bereinigung ist es, die agiles Arbeiten letztlich so hocheffizient macht. Empirische iterativ-inkrementelle Herangehensweisen wie Scrum haben zwar höheren Meetinganteil, was sie für planbare Projekte mit wenig Dynamik ungeeignet und ineffizient macht. Unter hoher Dynamik spielen die daraus gewonnen Stärken und schlanken Prozesse jedoch die Oberhand, so dass sie klassischem Projektmanagement überlegen sind. Aber wie gesagt, nur unter hoher Dynamik! Es wäre ein Fehler und falsch, nur noch auf agiles Projektmanagement setzen zu wollen, nur weil das en vogue ist.