Die Ausgangslage

Als Coach für agiles Projektmanagement erlebe ich immer wieder, dass Firmen sagen: „Wir machen schon Scrum. Naja, jedenfalls so zu ca. 70%. Aber so richtig erfolgreich sind wir irgendwie nicht. Können Sie mal schauen, woran es hakt?“

Wenn ich dran draufschaue, sehe ich oft, dass die agile Implementierung darin besteht, zwei- bis dreimal die Woche zusammen zu stehen und sich darüber zu unterhalten, warum man seine Aufgaben nicht fertig bekommen hat. Als Product Owner fungiert ein langjähriger Projektleiter und der Scrum Master ist einer, der schon mal Scrum gemacht hat und jetzt 20-30% seiner Zeit für das Team Zeit hat. Mehr braucht’s ja auch nicht, schließlich sind Teams selbstorganisiert.

Ach ja, apropos Team: natürlich sind maximal 2-3 Personen aus dem Team full time verfügbar. Der Rest besteht aus „Experten“, die mehreren Projekten zugeordnet sind, weil sie so wichtige „Ressourcen“ sind, dass sie bei allen wichtigen Projekten unverzichtbar sind. Die QS ist eine eigene Abteilung, die die Sprintergebnisse auf Herz und Nieren prüft. Sobald sie dazu kommt.

Schauen wir an der Stelle doch noch einmal in den Scrum Guide, die offizielle Definition von Scrum:

Es ist zwar möglich, nur Teile von Scrum einzusetzen – das Ergebnis ist dann aber nicht Scrum. Scrum existiert nur in seiner Gesamtheit und funktioniert sehr gut als Container für andere Techniken, Methoden und Praktiken.

Der Hintergrund

Als auch klassisch ausgebildeter Projektmanager habe ich gelernt, bestimmte Techniken anzuwenden, um Projekte erfolgreich abzuschließen. Insbesondere Planungstechniken, vorwärts wie rückwärts, halte ich für unverzichtbares Handwerkszeug.

Was Scrum angeht, so bin ich der absoluten Überzeugung, dass alles das, was in klassischen Umfeldern gut funktioniert, auch in agilen Umfeldern existiert. Nur nicht zum gleichen Zeitpunkt und nicht in der gleichen Granularität. Planung beispielsweise findet halt nicht vorab und vollständig statt, sondern in verschiedenen Ausprägungen zu verschiedenen Gelegenheiten. Im Daily Scrum findet die Tagesplanung des Teams statt, im Sprint Planning die mittelfristige Planung (für den kommenden Sprint) und in der Releaseplanung findet die Langfristplanung für ein Projekt statt.

Finden Teile davon nicht statt, ist dies nicht etwa eine lässliche Sünde, die bei agilen Projekten üblich ist (Fokus auf den aktuellen Sprint!), sondern das Ignorieren von notwendigen Gesetzmäßigkeiten für erfolgreiche Projekte.

Gleiches gilt für die Besetzung der agilen Rollen: Es gibt ja nun mal nur drei Rollen, da kann es doch nicht so schwer sein, diese richtig zu besetzen!

Fangen wir beim Einfachsten an: Dass Teilzeit-Teammitglieder keine gute Idee sind, ist eigentlich jedem bekannt. Aber manchmal ist es eben so. DEN Experten bekommt man entweder zu x % (x <= 20) oder für den einen Sprint, in dem dann aber auch alles passen muss.

Umso wichtiger sind dann gut besetzte Restrollen! Gerade in ehemals klassischen Umfeldern, in denen es Projektleiter gibt, wird gerne ein solcher genommen, um entweder den Product Owner oder den Scrum Master zu geben.

Das muss nicht schlecht sein, immerhin steckt in beiden Rollen ein großer Teil des guten alten Projektleiters. Blöd nur, wenn der falsche Teil im Vordergrund steht. Der Product Owner ist im Wesentlichen ein fachlich ausgerichteter Mensch, der Anforderungen nach der „Definition of Ready“ zur Verfügung stellt, damit das Team sich die nach dem Pull-Prinzip zieht. Ist hier ein ehemaliger Projektleiter am Werk, der gut darin ist, das Team zu challengen und einzelnen Teammitgliedern Aufgaben zuzuweisen, wird die Selbstorganisation des Teams ausgebremst. Gleiches gilt für den Scrum Master: Selbstorganisation braucht Führung! Allerdings ist der Scrum Master eher ein „Servant Leader“, einer, der Raum schafft für die Eigenständigkeit des Teams. Nicht einer, der Ansagen macht, sondern einer, der Hindernisse aus dem Weg räumt. Klassische Projektleiter haben leider nur allzu oft gelernt, dass man 120% fordern muss, um mindestens 80% zu bekommen. Als Scrum Master ist so einer nicht zu gebrauchen.

Tipps und Tricks gegen Fehlbesetzung

• Obwohl Product Owner und Scrum Master ein gewisses Standing in der Organisation brauchen, ist es keine gute Idee, einen Teamleiter oder noch höher in der Hierarchie aufgehängten Manager für eine dieser Aufgaben zu besetzen. Die Gefahr, dass eine gesunde Diskussion durch Schulterklappen unterbunden wird, ist zu groß.
• Scrum Master sind keine Halbtagskräfte! Wie sagte Ken Schwaber einmal so schön: „Ein guter Scrum Master kann zwei bis drei Teams betreuen, ein sehr guter Scrum Master nur genau eins!“
• Product Owner zu sein, ist eine gewaltige Aufgabe. Da schadet es nicht, den einen oder anderen Helfer zu haben. Wichtig hierbei ist allerdings das Highlander-Prinzip: einer muss im Zweifelsfall die Entscheidung treffen!
• Projektleiter (der klassischen Art) haben total viel wichtiges Handwerkszeug gelernt. Wenn man diese Perlen so formen kann, dass sie dem Team den Ruhm lassen und vom Macher zum „Enabler“ werden, hat man fast eine Idealbesetzung gefunden. Je nachdem, ob eher der fachliche oder der Teamaspekt im Vordergrund steht, haben wir einen guten Product Owner oder einen guten Scrum Master gefunden.

Fazit

Scrum ist total einfach: drei Rollen, mehr gibt es nicht. Leider basiert der Erfolg dann aber auch darauf. Es ist also total wichtig, diese wenigen Rollen nahezu ideal zu besetzen, nur so kann man das Optimum aus dem agilen Prozess holen!