Hybride Projekte – also Projekte, in denen ein Teil der Produkte in einem Wasserfall-Ansatz geliefert wird und ein anderer Teil durch agile Entwicklung – stehen vor besonderen Herausforderungen. Die größte ist, dass solche Projekte zwei Betriebssysteme haben, die häufig nicht miteinander harmonieren. Trotz seiner Beliebtheit ist das Scrum-Framework hier oft das Opfer: Scrum wird zurechtgebogen, damit es zum Wasserfall passt, und verliert dadurch seine besondere Dynamik.

Wie kann es also gelingen, den agilen Ansatz von Scrum in ein Projekt einzubetten? Die Lösung Scrumframe geht hervor aus meiner fast achtjährigen Beschäftigung mit der Frage, wie ein guter organisatorischer Rahmen für Scrum beschaffen sein muss, und wie PRINCE2® diesen Rahmen sichern kann. Scrumframe wurde entwickelt für hybride Projekte in einer regulierten Branche, dem Finanzsektor, eignet sich aber auch für andere Branchen.

Anhand von Implementierungen in unterschiedlichen Organisationen, die ich begleitete, beschreibe ich zunächst den Kern von Scrum und die sich daraus ergebenden Probleme bei der praktischen Einbettung. Diese Beispiele zeigen, dass Scrum keine Hinweise liefert, wie Scrum Teams einer Überregulierung entgehen können, weil das Framework sich nicht um die Organisation kümmert.

Anschließend beschreibe ich die Lösungen, die das Konzept von PRINCE2 dafür anbietet und wie diese in der Praxis funktionieren. Den Schwerpunkt des Artikels bilden meine Empfehlungen, wie es konkret gelingt, PRINCE2 als Governance-Rahmen für Scrum einzusetzen. Das Ziel meines Ansatzes ist es, dass die Dynamik der Scrum Teams erhalten bleibt und dass gleichzeitig die Organisation den Rahmen und die Bedingungen für diese Teams steuern kann.

Scrum ist leistungsfähig …

Bei Scrum liegt der Fokus ganz auf das Funktionieren des Scrum Teams (Schwaber und Sutherland, 2020). Dieser Ansatz ist sehr gut durchdacht, deswegen funktioniert Scrum so ausgezeichnet, um dynamisch Produkte zu entwickeln. Wer möchte, dass seine Teams in Scrum arbeiten, sollte sich daher fragen: Welche Minimalbedingungen benötigt ein sich selbst steuerndes Team, um zu außergewöhnlicher Leistungsfähigkeit aufzulaufen? Um diese Frage zu beantworten, genügt ein Blick auf einige grundlegende Ergebnisse der Gruppendynamik und der Teamforschung.

Wer gehört zum Team?

Zunächst benötigt das Team Klarheit darüber, wer Mitglied im Team ist, und welche Fähigkeiten und Verantwortlichkeiten die einzelnen Mitglieder haben. Dazu liefert Scrum klare Vorgaben: Das Team besteht aus Product Owner (PO), Entwickler und Scrum Master, die mit ihren Aufgaben im Scrum Guide beschrieben werden. Im Guide steht zudem, dass die wesentlichen Kompetenzen im Team vorhanden sein müssen. Nur punktuell benötigte Kompetenzen können in Form von Gästen hinzugezogen werden. Ich empfehle, die Zusammensetzung des eigentlichen Scrum Teams über längere Zeit gleich zu lassen, damit die Qualität der Zusammenarbeit ein hohes Niveau erreicht.

Was ist sein Zweck?

Ganz wesentlich ist auch, dass das Team weiß, wozu es da ist. Was ist die Aufgabe, wozu wurde es ins Leben gerufen und welche Ziele soll es verfolgen? Zur Beantwortung dieser Fragen gibt es mit dem Product Owner eine eigene Rolle. Diese Rolle achtet auf das Produkt, das abzuliefern ist und ist verantwortlich dafür, dass das Team effektiv in die richtige Richtung arbeitet.

Wie arbeitet das Team?

Zudem benötigt ein Team Klarheit über seine Arbeitsweise, die Grundsätze, nach denen es arbeitet, und eine Handvoll konkreter Regeln. Also Antworten auf die Frage "Wie tun wir etwas?" Mit dem Scrum Master gibt es auch dafür eine Rolle. Diese dient dem Team als "Servant Leader", indem sie dessen Selbstorganisation fördert und mit ihm gemeinsam regelmäßig die Arbeitsweise evaluiert sowie die Regeln weiterentwickelt.

Zusätzlich gibt es noch die Feinheiten der Teamdynamik, der Methoden sowie Rollen (siehe "Agile Teamentwicklung – dynamisch und bewusst mit Retrospektiven und Team-Radar"), und weitere fördernde Bedingungen. Beispielsweise braucht ein Team in seinen unterschiedlichen Phasen der Teamentwicklung unterschiedliche Hilfestellungen (siehe dazu "Teamentwicklung im Projekt – so klappt's, Teil 2: Durch Stürme zur Struktur"). Doch das wirklich Wichtige deckt Scrum sehr gut ab, indem es die Fragen nach dem "Wer?", "Was?" und "Wie?" beantwortet und in die Verantwortung einzelner Rollen übergibt.

Scrum ist für das Team da

In der Praxis beobachte ich immer mit Freude, wie Scrum sich um das Funktionieren eines Teams kümmert. Die Grundlagen für eine gute Teamarbeit legte bereits 2001 das Agile Manifest mit seinem starken Fokus auf die direkte persönliche Kommunikation, festgehalten in dem Grundsatz: "Individuals and interactions over processes and tools". Weitere Scrum-Prinzipien greifen dies auf und konkretisieren wichtige Aspekte: Das Prinzip "Transparency" betont, wie wichtig in einem Team gleicher Zugang zu relevanten Informationen ist und das Prinzip "Inspection" weist darauf hin, dass ein Team unmittelbare und konkrete Rückmeldung über die eigene Arbeit benötigt.

Was ist das Besondere an einem echten Team? In einem funktionierenden Team kooperieren die richtigen Leute mit den richtigen Kompetenzen. Jedes einzelne Mitglied prägt das Team. Tauschen Sie nur eine Person aus, bekommen Sie ein anderes Team. Es baut sich um Individuen auf, aus denen es besteht. Wenn es ein bisschen Theorie braucht: Ein Team baut auf die Kopplung der Akteure.

… und gleichzeitig leicht auszubremsen

Warum sehen wir trotzdem so viele seltsame Scrum-Implementierungen? Ein paar Beispiele aus meiner Praxis:

Ich habe ein Projektorganigramm gesehen, das groß mit den Worten "Agil" und "Scrum" überschrieben war. Das sogenannte Scrum Team bestand aus ca. zwei Dutzend Personen mit teilweise sehr phantasievollen Rollenbezeichnungen. Ich erinnere mich noch, dass es drei verschiedene Bezeichnungen für Scrum Coaches gab. Fest steht: Ein Team mit über 20 Mitgliedern verliert seine Funktionsfähigkeit. Damit wird die Möglichkeit zur Selbststeuerung durch das Team ausgehebelt und wir erleben wieder eine ganz klassische Struktur – nur mit modernem Namen.

Häufig beobachte ich auch die Unsitte, den Scrum Master zum Projektmanager zu erklären. Damit unterliegt diese Rolle dann ganz anderen Ausführungs- und Berichtspflichten, die absolut nicht mit dem Ansatz von "Servant Leadership" vereinbar sind. Kontrollfunktion und "dienende Unterstützung" vertragen sich nicht, da bleibt die Unterstützung auf der Strecke. Dazu kommt, dass ein solcher Scrum Master/Projektmanager keine Zeit hat, sich der Entwicklung des Teams zu widmen.

Mir ist eine weitere sehr "elegante" Variante begegnet: Der Product Owner war Vorgesetzter (Abteilungsleiter) der Entwickler. Als Vorgesetzter wollte er bei jedem Meeting der Entwickler dabei sein, auch bei denen, für die er als Product Owner nicht vorgesehen ist. Der Scrum Master gab sein Bestes, um die Grundätze von Scrum aufrecht zu erhalten, indem er z.B. die Entwickler entscheiden ließ, zu welchen Meetings der Product Owner eingeladen werden sollte. Der PO/AL kam dann aber doch zu jedem Meeting, von dem er Wind bekam. Das Ergebnis war nicht nur, dass das Team nur selten zu Höchstleistungen auflief, sondern auch, dass der Scrum Master sich beruflich veränderte.

Scrum klammert das Thema Organisation aus

Das Konzept fordert eine Organisation in hohem Maße, weil es vorsieht, dass Entscheidungs-Kompetenz nach unten zu den Entwicklern verlagert wird. Die wesentlichen Entscheidungen zum neuen Produkt soll der Product Owner gemeinsam mit dem Entwicklungsteam treffen. Im Gegenzug hat Scrum der Organisation nichts anzubieten, außer: "Vertraut uns!" Das ist etwas wenig.

Der Scrum Guide behandelt Themen wie Organisation, Budget, Betriebsumgebung und Vermarktung des Produkts usw. mit keinem Wort. Deswegen sind Scrum Teams hilflos jedem Versuch ausgeliefert, Entscheidungsmacht wieder zu zentralisieren. Der einzige Vorschlag, den Scrum hier macht, verharrt in der Team-Logik: Mit dem Scrum Master soll sich ein Individuum darum kümmern und die Organisation beraten. Darunter hat dieses Individuum oft zu leiden, wie das Beispiel oben zeigt.

Dass die Leerstellen im Scrum Guide zu Konflikten führen, ist nicht verwunderlich, schließlich funktioniert eine Organisation vollkommen anders als ein Team: Eine Organisation setzt sich aus Funktionen zusammen, nicht aus Individuen. Bestimmte Funktionen müssen wahrgenommen werden, damit die Organisation auch in Zukunft bestehen kann. Welches Individuum eine bestimmte Aufgabe übernimmt, ist in der Logik der Organisation im Prinzip egal. Wir nennen das eine Kopplung von Aktionen. Wichtig sind die Handlungen und ihre Abgestimmtheit, nicht jedoch, wer sie ausführt.

Wenn aus einer Stärke eine Schwäche wird

So wird Scrums große Stärke zu seiner entscheidenden Schwäche, weil das Framework die Organisation außen vor lässt. Für einen Entwicklungsansatz ist das ausreichend, denn um die Einbettung einer Produktentwicklung muss sich ohnehin die Organisation kümmern. Doch als Projektmanagement-Ansatz taugt das nicht. Scrum ist das nicht und sollte daher mit einem funktionierenden Ansatz gekoppelt werden.

Mein Appell: Wir sollten aufhören von "Projektmanagement mit Scrum" zu reden. Wenn wir die Stärken von Scrum zur Geltung bringen wollen, müssen wir es das sein lassen, was es ist: ein Entwicklungsansatz.

Das Projektmanagement sollte woanders herkommen. Wenn wir Scrum in Projekten einsetzen wollen, dann muss etwas anderes das Verhältnis zur Organisation klären. Denn diese Klärung ist notwendig, weil Scrum einen stabilen organisatorischen Rahmen benötigt, damit die Arbeit der Teams dem Unternehmen zu 100% zugutekommt.

Der Missing Link zwischen Team und Organisation

Als Entwicklungsansatz benötigt Scrum einen guten organisatorischen Rahmen. Die Anhänger dieser Meinung – meist erfahrene Projektmanager, die Scrum noch aus der Zeit vor dem Hype schätzen – haben sich glücklicherweise mittlerweile durchgesetzt. Heute herrscht außerhalb einer eingeschworenen Scrum-Gemeinde weitgehend Konsens, dass eine Kopplung notwendig ist zwischen der Organisation mit ihrer Strategie, Struktur sowie Kultur und dem Scrum Team mit seiner Dynamik und speziellen Arbeitsweise.

Diese Kopplung "dolmetscht" zwischen den beiden Welten des dynamischen Teams und der stabilen Organisation und sorgt dafür, dass beide Seiten die Prinzipien und Funktionsweisen der anderen beachten.

Die eine Seite, die Organisation, benötigt berechenbare Aktionen, also Leistungen. Jedoch hat sie es mit einem Team zu tun, das – eben weil es ein wirkliches Team ist – nicht komplett berechenbar ist. Die Qualität der Team-Leistungen schwankt, je nachdem, wie gut die Zusammenarbeit fruchtet. Also wird sich die Organisation mit einer gewissen Bandbreite an Erwartungen zufrieden geben müssen. Auf der anderen Seite benötigt das Team gute Rahmenbedingungen zur Entwicklung und vor allem: Stabilität und Zeit.

Ich ergreife hier klar Partei für das Team, denn aus meiner Sicht ist es entscheidend, dass die Funktionsweise der Organisation die Grundlagen und die Prinzipien der Selbststeuerung des Teams intakt lässt. Denn diese Selbststeuerung ist der Kern von Scrum. Ohne diese, ohne ein Team, dass sich Sprint für Sprint immer intensiver zusammenrauft, entstehen weder eine Dynamik noch Geschwindigkeit und erst recht keine überraschend guten Lösungen.

Zu viele Experimente

Auch hier wird viel diskutiert über die Arbeiten, die vor dem ersten Sprint geleistet werden müssen: Wie kommt es zur Produktvision, dem Team, dem Budget, ja überhaupt zum Auftrag? Und es gibt viele Experimente – denken Sie nur an die Kontroverse in der Community, ob es einen "Sprint Zero" geben kann, oder nicht.

Statt zu experimentieren, sollte man hier Methoden des Projektmanagements einsetzen, die seit Jahrzehnten am Markt sind und sich mit solchen Fragen beschäftigen. Wenigstens eine davon sollte erprobte Vorgehensweisen haben, die hier helfen können.

Wenn wir uns die "großen drei" Projektmanagement-Ansätze ansehen, die einen guten Rahmen für Scrum schaffen könnten, wird schon auf den zweiten Blick klar, dass sich die Ansätze von IPMA und PMI damit schwertun. Weil sie sehr an den konkreten Aktivitäten "kleben". Bei beiden Ansätzen plant der Projektmanager in der Arbeitspaketbeschreibung (meist mit einem Kernteam) einzelne Aktivitäten. Dies sollte bei einem agilen Ansatz aber in der Kompetenz des Scrum Teams liegen.

Übrig bleibt PRINCE2 (AXELOS (a), 2018). Dieser Ansatz trennt alle Management-Aktivitäten klar von der Lieferung/Entwicklung der Produkte. Kein PRINCE2-Projektmanager käme auf die Idee, einzelne Aktivitäten der Produktlieferung zu planen. Erstens ist dies die Aufgabe der Lieferanten/Entwickler, und zweitens liegt der Fokus von PRINCE2 grundsätzlich auf Produkten. Das lässt den Entwicklern ihren Freiraum.

PRINCE2 Agile

PRINCE2 Agile® (AXELOS (b), 2018) verspricht meiner Meinung nach deutlich mehr, als es hält. Zum einen diskutiert es den Umgang mit unterschiedlichen agilen Ansätzen nur sehr oberflächlich und liefert nur allgemeine Handlungsempfehlungen. Dort, wo PRINCE2 Agile konkret wird, ist es eine ganz eigene Methodik, die sich in seinen Rollen und Vorgehensweisen an bloß einem agilen Ansatz orientiert, dem ebenfalls Britischem "DSDM Atern". Daher ist PRINCE2 Agile eine neue Methodik – zumindest für den deutschen Sprachraum.

Die Unzufriedenheit damit führte zur Entwicklung des Scrumframe: Es kümmert sich ausschließlich um das Kombinieren von PRINCE2 und Scrum und zwar so, dass so wenig wie möglich an den beiden Ansätzen geändert wird: Scrum wird nur ein wenig ergänzt und PRINCE2 dient nur als Governance-Rahmen (mit nur wenigen, aber wichtigen Anpassungen), der mit unterschiedlich agilen Scrum-Praktiken umgehen kann. Interessierte Organisationen können also weiter Scrum verwenden, Scrumframe erhöht aber dessen Steuerbarkeit. Schauen wir uns zunächst genauer an, was für eine Kombination von Scrum und Prince2 spricht.

Darum vertragen sich Scrum und PRINCE2