Dieser Artikel soll einen einfachen Überblick schaffen über die Verantwortlichkeiten aller Rollen innerhalb der Organisationsstruktur (“Hierarchie”) vom Scrum-Team bis zur Führungsebene, wie flach diese Struktur auch sein mag.
Dies ist die deutsche Übersetzung des unter dem Titel How to Scale Responsibilities From Scrum Team to C-Level auf Medium erschienen englischen Artikels. Die Englische Version auf dieser Seite ist eine gekürzte Fassung.
Ich fange aus zwei Gründen auf Teamebene an: Der Hauptgrund ist, dass es einfach für viele Leser nachvollziehbarer sein wird, da sich natürlich mehr und vor allem unterschiedlichere Menschen auf der operativen (“Arbeits-”)Ebene auskennen. Der zweite Grund ist, dass Scrum selbst lediglich Verantwortlichkeiten auf Teamebene beschreibt, aber (ganz bewusst*) nichts auf die Führungsebene ableitet. Genau diese Extrapolation ist Hauptthema dieses Posts. Ich habe selbst viele Situation mit unklaren Führungsverantwortungen erlebt habe, mitgelitten habe, wenn es schwierig war Verantwortlichkeiten hoch- und runterzuskalieren und daran mitgewirkt habe, diese Situationen zu verbessern.
Verantwortlichkeiten im Scrum Team
Für jede Rolle folgen nun die operativen Verantwortlichkeiten, sowie deren essentielle Bedeutungen im Hinblick auf Unternehmenserfolg.
Der Product Owner
Product Owner in Scrum sind für die Erstellung des Product Backlogs verantwortlich. Das beinhaltet Generieren von Ideen, Validierung, erforderliche Forschung, Konzeptarbeit und letztendlich die Erstellung von User Stories (ich weiß, der Scrum Guide schreibt User Stories nicht vor, aber seien wir ehrlich: Die meisten von uns wollen ein Product Backlog in dessen User Stories ein PO einiges INVESTiert hat). Was ist der Hauptantrieb hinter diesen Aktivitäten? Es sind Wertschöpfung und daher Effektivität.
Das Team
(Entwicklungs-)Teams in Scrum sind verantwortlich für die Implementierung oder Ausführung von wasauchimmer gerade das Wichtigste oder Wertvollste ist. Natürlich bestimmen sie selbst, wie viele Backlog Items sie beschließen, in einem Sprint fertigzustellen. Warum ist diese Selbstbestimmung, diese Autonomie so wichtig? Nur mit der Autonomie, selbst zu entscheiden, wie viel in einem Sprint getan wird erreichen Teams die volle Kontrolle über Qualität. Nur wenn niemand das Team zwingt, bei Qualität Kompromisse zu machen, Abkürzungen zu nehmen, um in derselben Zeit mehr zu schaffen, nur dann können sie ihrer Verantwortung gerecht werden: Dinge in guter Qualität abliefern.
Da dieser Punkt kontrovers ist, ein paar mehr Details: Warum muss das Team sich auf Qualität fokussieren? Warum nicht der Product Owner? Ein Produkt höherer Qualität schafft doch sicher mehr Wert, nicht wahr? Natürlich! Aber bei aller kreativer Arbeit und bei Softwareentwicklung im Speziellen, können sich ungesehene Mängel einschleichen, sogenannte technische Schulden. Das Produkt mag fertig und nutzbar sein. Aber: Wie lange wird es funktionieren? Wie weit wird es skalieren? Wie hoch sind die Wartungsaufwände? Wie leicht ist es erweiterbar? Technische Schulden beeinflussen alle diese Aspekte und die einzige Rollen, die Kontrolle darüber hat ist: Das Team. (Für Teams, denen es schwer fällt “Erlaubnis zu bekommen”, technische Schulden abzuarbeiten, was an sich schon ein Anti-pattern ist, versucht zuerst die Kosten zu definieren. Nutzt diese Argumente, um die Bedeutung von technischen Schulden für Euer Produkt zu unterstreichen.)
Die ScrumMaster-Rolle
Die Rolle des ScrumMaster scheint klar zu sein, trotzdem erreichen mich immer wieder Fragen der Art
“Ist [dies und das] noch die Verantwortung eines ScrumMaster?”
oft mit der Konnotation, dass es das nicht sein sollte. Die Verantwortlichkeiten der ScrumMaster-Rolle sind vielfältig, können aber glücklicherweise leicht im Scrum-Guide überprüft werden. Meine kurze Zusammenfassung lautet wie folgt: Liebe ScrumMaster, bitte kümmert Euch um Meetings und helft Menschen zu gemeinsamen Verständnis von… allem! Kümmert Euch um agile best practices und helft (beiden!) anderen Rollen in Scrum bei der Selbstorganisation! Helft Menschen, sich kontinuierlich zu verbessern und arbeitet mit anderen ScrumMastern an der Agilität des Gesamtunternehmens.
Was ist der Treiber hinter all diesen Dingen? Wenn Wertschöpfung und Effektivität schon abgehakt sind? Wenn diese effektiven Dinge bereits in guter Qualität getan werden, was kann noch verbessert werden? Die Verantwortlichkeit der ScrumMaster-Rolle ist Effizienz. Sicherzustellen, dass diese guten Dinge auf die bestmögliche Art und Weise getan werden.
Gegenerklärung: Wenn natürlich Effektivität (noch) nicht vom Product Owner abgedeckt ist und/oder das Team sich nicht genug um Qualität kümmert, dann ist es natürlich Aufgabe des ScrumMasters beide Rollen dahingehend zu coachen. Es gibt eine Priorität innerhalb dieser Verantwortlichkeiten und es kann nur folgende sein:
- Effektivität
- Qualität
- Effizienz
“Nichts ist so sinnlos, wie mit großer Effizienz Dinge zu tun, die überhaupt nicht getan werden sollten.” ― Peter Drucker
An dieser Stelle muss ich (ohne Zwang oder Vorteil meinerseits) auf das beste Buch zum Thema ScrumMaster verweisen: Scrum Mastery!
Ehre, wem Ehre gebührt
Die obige Ansicht der Scrum-Rollen ist stark inspiriert von diesem großartigen Artikel im Blog von Agile42 von Martin von Weissenberg, der meisterhaft darlegt, wie die drei Scrum-Rollen einander ergänzen und unterstützen:
- Effektivität (Mehrwert für Kunden schaffen) verringert den Druck auf Teams und schafft so Zeit und geistige Freiheit, die auf Qualität und Prozessverbesserung verwendet werden können.
- Qualität verringert den Druck auf Teams, indem weniger Zeit auf Behebung vergangener Fehler verwendet werden muss, die dann wiederum die mehr neue Wertschöpfung investiert werden kann.
- Steigende Effizienz trägt wiederum direkt dazu bei, mehr Qualitätsarbeit in einem gegebenen Zeitraum zu schaffen. Wir erreichen das durch regelmäßige Retrospektiven.
Verantwortlichkeiten der Geschäftsführung
Der Chief Product Officer (CPO)
Dem CPO obliegt die Verantwortung, “ein Produkt zu schaffen, das nachhaltig Umsatz und Profit generiert […]. Das beinhaltet in der Regel Produktvision, Innovation, Produktdesign und -entwicklung, Projektmanagement und Produktmarketing.” (Wikipedia) Das zugrunde liegende Ziel hinter all diesen Aktivitäten, das Warum ist Wertschöpfung: Das Verwenden von Produktionsmitteln mit dem Ziel, genug Umsatz zu generieren, um Profit abzuschöpfen. Die Fähigkeit, ein angestrebtes Ergebnis zu erzielen nennt sich Effektivität. Während der Product Owner eines Teams dessen Product Backlog verantwortet (also ein Teil des großen Ganzen), verantwortet der CPO das Product Backlog des Unternehmens und ist verantwortlich, die Dinge in diesem Backlog zu bemessen und zu priorisieren.
Der Chief Technology Officer (CTO) / Technischer Direktor
Die Verantwortung des CTO ist es, “Entscheidungen zu treffen, die die übergreifende technologische Infrastruktur des Unternehmens betreffen, um diese bestmöglich mit den Ziel des Unternehmens zu vereinbaren […]. Ein CTO sollte sich neuer und aufkommender Technologien bewusst sein, um zukünftige Bestrebungen des Unternehmens zu unterstützen.” (Wikipedia) Hier im Detail das Warum hinter diesen Punkten:
- Warum Entscheidungen bzgl. der übergreifenden technologischen Infrastruktur treffen?
Übergreifen ist das entscheidende Wort hier. Im Detail sollen (Scrum?) Teams natürlich weitestgehende Autonomie haben. Im großen Ganzen müssen technologische Entscheidungen allerdings abgestimmt und konsistent sein. Ansonsten werden wir (wieder) technische Schulden anhäufen und es wird zunehmend schwerer, die Qualität unserer Produkte sicherzustellen. - Warum Technologieentscheidungen mit den Organisationszielen abstimmen?
Wenn diese Entscheidungen im Konflikt mit den Organisationszielen stehen (so klein dieser auch sein mag) wird sich dieser auf Teamebene manifestieren. Kein ScrumMaster kann diese Konflikte schlichten, wenn dem (Entwickler-)Team und dem Product Owner aus der jeweiligen Linie unterschiedliche Ziele vermittelt werden. - Warum ist es wichtig, sich aktueller und sich entwickelnder Technologietrends bewusst zu sein?
Wir müssen nicht jeden Trend noch im Versuchsstadium mitmachen (es heißt im Englischen nicht umsonst bleeding edge). Aber wir müssen sicherstellen, dass wir nicht zurückfallen und die Wettbewerbsfähigkeit unserer Technologie bewahren. Wir müssen das Gegenteil von technischen Schulden aufbauen.
Im Hinblick auf unsere Produkte ist der CTO für die exakt selben Dinge (auf höchster Ebene) verantwortlich, wie Teams auf Arbeitsebene:
- Wie lange wird unser Technologiestack funktionieren?
- Wie weit skalieren unsere Produkte?
- Wie viel Aufwand ist es, unsere Produktpalette zu warten?
- Wie einfach ist es, unser Produktangebot zu erweitern und miteinander zu integrieren?
Die Verantwortung des CTO ist in der Endkonsequenz dieselbe wie die jeder anderen Rolle innerhalb des Technik-Zweigs einer Organisation: Jeder zwischen CTO und Junior Softwareentwicklungs-Praktikant ist verantwortlich für Qualität. Wie ein VP Technologie in einer meiner letzten Festanstellungen es einmal ausgedrückt hat:
Wenn Du atmest, bist du verantwortlich für Qualität. — Juan Vidal
Der Chief Operating Officer (COO)
“Der COO ist für das operative Tagesgeschäft des Unternehmens verantwortlich.” (Wikipedia) Das beinhaltet Abwägungen zwischen Effektivität und Effizienz. In einer Firma, die einen CPO hat, ist bereits eine Rolle für Effektivität der Produktpalette verantwortlich. Einem COO muss sich dann immer noch um die Effektivität der internen Dienstleistungen kümmern, sollte aber größeres Augenmerk auf Unternehmens-Effizienz legen..
Extrapoliert von den Verantwortlichkeiten eines ScrumMaster sieht das wie folgt aus:
- Ein ScrumMaster stellt sicher, dass ein Team gut zusammenarbeitet und die Kommunikation mit der dritten Rolle, dem PO gut funktioniert.
Ein COO ist dafür verantwortlich, dass alle Teams innerhalb des Unternehmens gut zusammenarbeiten und muss sicherstellen, dass die Kommunikation zwischen und mit dem Management und anderen Stakeholdern reibungslos ist. - Ein ScrumMaster treibt Team-interne Prozessverbesserung voran, sowie, wenn nötig, Zusammenarbeit mit anderen Teams.
Ein COO muss unternehmensweite Prozesse am Laufen halt und verbessern, idealerweise über dem Niveau des Industriestandards, um der Firma einen Wettbewerbsvorteil zu verschaffen. - Ein ScrumMaster kümmert sich um die Stimmung innerhalb des Teams, um Selbstverbesserung und Weiterbildung und eskaliert, wenn benötigte Fertigkeiten nicht vorhanden sind und nicht selbst erlangt werden können.
Einem COO obliegt “Personalplanung, Wissensmanagement, Fähigkeiten und Fertigkeiten der Belegschaft und somit des Gesamtunternehmens […] und Motivation”. (Wikipedia)
Führungsverantwortung von C-level Rollen
Die Verantwortlichkeiten einer Rolle bleiben gleich. Dabei ist unerheblich, wie (und wie gut) eine Rolle auf unterschiedlichen Hierarchieebenen ausgefüllt wird. Dieser Artikel deckt die Führungsverantwortung von C-level Rollen bewusst nicht ab. Das Thema wie Rollen die in einer Hierarchie größere Verantwortung haben, sich selbst skalieren sollten, indem sie lehren, coachen und die Mitarbeiter ihres Verantwortungsbereichs unterstützen ist eine andere Domäne, eine völlig unterschiedliche Dimension von Verantwortlichkeit.
Verantwortlichkeiten skalieren
Alles vorangegangene führt uns zu folgendem vereinfachten Überblick über die Verantwortlichkeiten im Ganzen:
- Effektivität: CPO → … → Product Owner
- Qualität: CTO → … → Team
- Effizienz: COO → … → ScrumMaster
Dieses Bild zeigt, wie ich diesen Sachverhalt ursprünglich visualisieren wollte: “Silos” von Verantwortlichkeiten über alle Ebenen der Hierarchie einer Organisation:
Diese erste vereinfachte Version vernachlässigt den Aspekt von Zusammenarbeit und steht daher in gewisser Weiser in krassem Konflikt zu den Scrum-Werten. Wie sieht die Übersicht aus, wenn wir die notwendigen Überschneidungen zwischen den Rollen hinzufügen? Eine Draufsicht der sich überlappenden “Silos” sähe folgendermaßen aus:
Schauen wir mal genau auf die Überschneidungen: Wobei genau arbeiten diese Rollen zusammen, weil ihr jeweils eigener Verantwortungsbereich davon abhängt?
Product Owner arbeiten mit Teams an Produktvision und Roadmap/Meilensteinplan. ScrumMaster arbeiten mit Product Ownern, betreiben vielerlei Sparring rund um die Themenbereiche Produktentwicklung und Teamarbeit. Teams arbeiten mit ScrumMastern an kontinuierlicher Selbstverbesserung.
Die gleichen Überschneidungen existieren auf der obersten Ebene des Unternehmens: Es gibt gemeinsame Interessen zwischen C-level-Rollen. Natürlich existieren noch mehr, als ich im Folgenden aufzählen werde. Es folgen diejenigen gemeinsamen Interessen, die sich von Verantwortlichkeiten auf Teamebene extrapolieren lassen:
Langfristige Produktplanung ist essenzielle Verantwortung des CPO. Eine langfristige technische Planung (des CTO) kann aber nicht abgeleitet werden, ohne die Produktplanung zu kennen.
Die Überschneidung zwischen COO und CTO ist ähnlich der zwischen ScrumMaster und Dev-team: Man kümmert sich um Releaseprozesse (auf Firmen- bzw. Teamebene), um Automatisierung und/oder Lieferketten. Viele Dinge, die bei Firmengründung eher manuell gemacht wurden, beinhalten potenzielle Wertschöpfung durch Automatisierung. Zeit, die hier verbracht wird, ist Zeit (oder eben Geld) das auf andere Dinge verwendet werden könnte.
CPO und COO haben die gleichen gemeinsamen Interessen, wie Product Owner und ScrumMaster: Wertschöpfung messen, Planbarkeit verbessern (bei gleichzeitigem Beibehalten von Agilität), Berichtswesen und die schrittweise Automatisierung ebendieser.
Euer Unternehmen ist größer, mit mehr Rollen zwischen Führungsebene und Teamebene?
Alle Rollen entlang der Linie zwischen der gewichtigsten Rolle und den Teams auf Arbeitsebene, beinhalten, ja, erben dieselben Verantwortlichkeiten. Was sich ändert sind einzig und allein die Verantwortungsbereiche und deren Größe. Wofür die Menschen in diesen Rollen verantwortlich sind, bleibt gleich.
Fazit
Scrum ist erfolgreich, weil es die Verantwortlichkeiten einer übermächtigen (und konfliktbeladenen) Rolle (der Projektmanager) nimmt und dorthin sortiert, wo sie hingehören: Verteilt auf drei Rollen, die sich auf einen Bereich konzentrieren und ihre Fähigkeiten dahingehend verbessern.
Diese Verantwortlichkeiten sind im konstanten Konflikt miteinander (allein aufgrund der Tatsache, dass es immer mehr zu tun gibt, als Zeit und Budget erlauben). Der Schlüssel zur Überwindung dieser Konflikte kann nur “mehr Zusammenarbeit” sein. Nichtsdestotrotz: Die Überschneidung im operativen Arbeitsbereich bedeutet nicht, dass diese Rollen ihre eigenen Verantwortlichkeiten zugunsten von “mehr Zusammenarbeit” vernachlässigen können. Das gilt sowohl für die Team- als auch die Führungsebene.
Abhängig von der Situation des Unternehmens können sich die Überschneidungen oder ihre Gewichtung verändern. Außerordentliche Situationen erfordern nun mal außerordentliche Maßnahmen. Trotzdem ist es wichtig, die Balance zwischen den Rollen und ihren Verantwortlichkeiten zu wahren. Auch hier: Auf Team- und auf Führungsebene.
* Der Scrum Guide ist absichtlich kurz gehalten. Scrum schreibt über die Teamebene hinaus aus mehreren Gründen nichts vor: Der Hauptgrund ist, dass was auch immer auf Teamebene funktioniert, eben darum funktioniert, weil es auf Scrum-Werten basiert. Wenn man skaliert, sollte man sich auf diese Werte stützen und erhöht damit die Erfolgschancen immens. Der zweite Grund ist, dass ein komplexeres Framework (eher regel- als wertebasiert) plötzlich viel weniger flexibel ist und daher nicht mehr von so vielen Teams angewandt werden kann.
Weiterführende Links:
- Putting a cost on (technical) debt by John Cutler
- Technical debt and product success by Roman Pichler
- How to tackle technical debt by James Stanier