Irgendwann müssen wir uns darum kümmern, welche Projekte wir in welcher Form angehen. In Scrum lautet die Antwort, dass dies im Zweifel der Product Owner entscheidet, aber wie sieht das in einer komplexen Unternehmensstruktur aus, die nach wie vor eine klassische Hierarchie abbildet?
Wir kennen traditionelle Hierarchien. Die Geschäftsleitung formuliert eine Unternehmensvision und sich daraus ableitende Unternehmensziele. Die Programmleitung macht daraus einen schon etwas konkreten Arbeitsauftrag, woraus sich wiederum Projekte ergeben, die entlang der Unternehmensstruktur mit klaren Zuordnungen und Verantwortungen irgendwie umgesetzt werden.
Das Prinzip dabei ist, dass eine Anforderung entlang der bestehenden Hierarchie des Unternehmens weiter aufgegliedert wird, wobei immer eine Person als Führungskraft in einer Entscheidungsfunktion eingesetzt ist. Diese Person entscheidet, was die ihm zugeordneten Teams tun und welche Prioritäten wie gesetzt sind. Das ist Teil dessen, was wir allgemein unter Führung in einem Unternehmen verstehen.
Inzwischen haben wir jedoch gelernt, dass wir in der Agilen Welt über Selbstorganisation sprechen wollen. Bedeutet das nicht auch, dass die Teams selbst entscheiden? Schließlich haben wir mit Scrum die Rolle des Product Owners eingeführt, und der Scrum Guide ist da recht eindeutig in seiner Formulierung: was wir tun, liegt in der Verantwortung des Product Owners.
Wenn wir von einem Team sprechen, dann ist es häufig so, dass der Projektmanager zum Product Owner gemacht wird. Wenn das so ist, haben wir kein großes Problem. Man muss das Organigramm ein wenig anpassen, der Projektmanager rückt ins Team hinein, ändert seine Arbeitsweise, es gibt noch ein wenig Arbeit im Teambuilding, aber alles greift in der schönen neuen theoretischen Welt wunderbar ineinander. Die hässliche Praxis ist meistens ein wenig komplizierter, weil eine Persone, die es gewohnt war, Dinge allein zu entscheiden, sich jetzt im Team abstimmen sollte. Das fällt nicht jedem leicht, und für den Scrum Master bzw. das gesamte Team kann eine schwierige Zeit anbrechen, in der man sich lange und intensiv aneinander reibt (das klingt sehr falsch auf sehr vielen Ebenen).
Meistens bewegen wir uns aber in einem weit komplexeren Umfeld mit vielen Teams. Dann bin ich bei einem skalierten Scrumsystem und denke vielleicht über einen Chief Product Owner nach. Auch das kann in der Theorie relativ einfach sein (wenn wir nicht gerade mit SAFe arbeiten). Die »Scrum-Blase« an und für sich ist nicht unser Problem. Unser Problem ist die alte hierarchische Struktur, die noch immer vorhanden ist. Da gibt es noch eine ganze Batterie von Managern oder Führungskräften, oder wie ich sie auch immer nennen will, die es gewohnt sind, über die Entwicklung des Produkts zu entscheiden, dies jetzt aber nicht mehr tun sollen.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
In den letzten beiden Beiträgen haben wir über das Prinzip Servant Leadership und Transformation hin zu Agilität gesprochen. Das kann ich irgendwie (bitte verzeiht mir auch hier die grobe Vereinfachung) als Organisationsentwicklung bezeichnen. Die Fragen, die sich jetzt stellen, lauten ganz einfach, ob das ausreicht und ob das eine gute Idee ist. Eine ganze Management Ebene rückt weiter weg vom Produkt und hinein in die Organisationsentwicklung.
Übervölkern wir damit die Organisationsentwicklung?
Ich denke nicht. Einige der Kollegen werden in der Scrum Welt eine neue Rolle finden. Ein paar werden Product Owner werden, ein paar finden die Rolle des Scrum Masters sympathischer. Die Organisation muss jetzt nur ganz stark darauf achten, dass sie alle beteiligten Personen ihre eigenen Entscheidungen treffen lässt. Eine Vorgabe, dass Person X, die bisher Projektmanager war, jetzt Product Owner wird, ist grundsätzlich eine außerordentlich blöde Idee, weil ein PO zum Teil vollkommen andere Eigenschaften braucht. Beispiel gefällig? Ein Projektmanager muss nicht zwingend teamfähig sein. Auch ein eigenbrötlerischer Sack kann dabei einen ganz hervorragenden Job machen. Ein Product Owner muss jedoch ein Teamplayer sein, sonst geht die ganze Sache in die Hose.
Ich warne also dringend davor, die Fachlichkeit einer Person alles andere überstrahlen zu lassen. Es ist schon mehr als ein Team deswegen geplatzt.
Wir haben also auch personell in der Transformation eine ganze Menge Arbeit. Das ist anstrengend und auch nicht in einer Woche erledigt – keine Frage. Wenn man alle beteiligten Personen vernünftig einbezieht und sie an den Entscheidungen teilhaben lässt, kommen wir da aber relativ gut durch.
Wir stellen fest, dass wir bei der Einführung von Scrum jetzt schon weit jenseits der Grenzen der Scrum Teams angekommen sind. Die Transformation kann sich nicht ausschließlich auf die Entwicklungsteams beschränken. Wenn ich das versuche, schaffe ich eine Sollbruchstelle in der Gesamtorganisation, weil an der Grenze zu den Teams die Dinge nicht mehr zusammenpassen.
Beenden wir den kurzen Exkurs und kommen wir wieder zu den Führungskräften, die nicht ein neues Leben als Scrum Master oder Product Owner begonnen haben. Da haben wir jetzt eine Gruppe von Personen, die eine tiefe Kenntnis des Produkts haben, die wir aber – wie wir im letzten Beitrag festgestellt haben – ganz stark in die Transformation einbinden müssen. Bedeutet das jetzt, dass all diese Leute jetzt raus aus dem Produkt sind, und sich nur noch mit Organisationsentwicklung beschäftigen?
Nein. Das wäre nicht nur grob fahrlässig, sonder auch ausgesprochen bescheuert.
Ich zitiere hierzu einfach mal ein Kanban-Prinzip: Beginne dort, wo du dich gerade befindest.
Wir brauchen das Wissen dieser Kollegen. Es spricht in meinen Augen nichts dagegen, dass diese Führungskräfte in den Refinements und Plannings der Teams mitwirken, um Input zu liefern. Die Entscheidungen trifft das Scrum-Team, aber niemand verbietet diesen Führungskräften, sich einzubringen. Ich würde das sogar einfordern, weil da Wissen rumsitzt, das im schlimmsten Fall ungenutzt verschimmelt. Eine schriftliche Dokumentation ist für mich keine Alternative (auch wenn ich die zusätzlich brauche), aber ein denkendes Gehirn ist für mich ungleich wertvoller als ein paar Blatt Papier. Das Team und insbesondere der Scrum Master sind gefordert, darauf zu achten, dass die Entscheidungen doch nicht wieder Stück für Stück bei der Führungskraft landen. Wir nutzen deren Wissen, aber wir vergessen nicht, dass die Verantwortung der Product Owner trägt.
Ich bin hier in der Transformation. Das oben beschriebene ist kein ewiger Zustand. Schritt für Schritt werden sich die Führungskräfte aus den Refinements und Plannings zurückziehen. Es wird der Zeitpunkt kommen, an dem deren Wissen den Teams keinen Mehrwert mehr bringt. Dann haben wir die fachliche Transformation (nach der organisatorischen) ebenfalls hinter uns gebracht.
Das gibt den Raum für unser Zielbild: Nach der Transformation haben wir eine Reihe von Scrum Teams (vielleicht mit einem gemeinsamen Backlog und einen Chief Product Owner – wie die Scrum Skalierung aussieht, muss uns jetzt nicht zwingend interessieren) und darüber eine skalierte Ebene, die sich folgendermaßen versteht:
Meine Aufgabe ist es, alles dafür zu tun, dass die Teams das bekommen, was sie brauchen, um das bestmögliche Produkt zu erstellen (dafür liefern die Teams das bestmögliche Produkt). Meine Aufgabe ist es ebenfalls, dafür zu sorgen, dass die Gesamtorganisation den für die Leistungserbringung idealen Rahmen zur Verfügung stellt.
Das ist meine Definition von Agiler Führung im Kontext der Gesamtorganisation (im Kontext Team sieht das ganz anders aus), und wer glaubt, dass man damit nicht so schrecklich viel zu tun haben kann, der irrt sich. Vertraut mir. Organisationsentwicklung ist saukomplex und seeehr aufwändig. Dazu kommt noch Einiges an Verwaltungsaufgaben. Die wird auch die reifste Organisation der Welt nicht los.
Damit beende ich jetzt die kurze Serie zu Agiler Führung. Ich hoffe, es hat Euch ein wenig schlauer gemacht oder zumindest ein paar Denkanstöße geben können. Ich bemühe mich, jetzt wieder regelmäßiger zu schreiben. An dieser Stelle auch einen kurzen Dank für freundliche Kommentare und Kontakte. Bitte habt Verständnis, dass es ein paar Tage dauern kann, bis ich antworte. Ich bin viel unterwegs, und am Abend nach einem ganztägigen Workshop checke ich keine Mails mehr. Dann tue ich nur noch Dinge, die nichts mit meinem Job zu tun haben (was ich übrigens auch jedem empfehlen würde).
Die Kommentarfunktion ist übrigens deaktiviert, weil ich keine Lust habe, den Schrott darin aufzuräumen. Für das Google Ranking ist das zwar nicht ideal, aber für meinen Seelenfrieden sehr wohl, und der ist mir im Zweifel wichtiger.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
