Warum ist der P.O. in Scrum nur eine Person? Ein Erklärungsversuch …

Ein von mir sehr geschätzter Berufskollege, Heiko Bartlog, hat vor einiger Zeit auf Twitter eine Frage gestellt, die zunächst banal klingt: Warum ist der P.O. in Scrum nur eine Person?

Den Tweet und die vielen Reaktionen darauf hat Heiko in einem Blog-Artikel zusammengefasst. Die Frage ist aus meiner Sicht keineswegs banal. Ich war zunächst versucht, spontan zu antworten aber jede Antwort, die ich finden konnte, erschien mir zu oberflächlich. Nachdem die Frage einige Wochen in mir „gearbeitet“ hat, hatte ich einen Einfall und da musste ich Heiko mal eine Mail schreiben. Darin stand sinngemäß folgendes:

Klar, die naheliegendste Antwort ist: Weil es im Scrum Guide steht. Aber das wissen wir natürlich. Es geht um die Frage, warum das da steht. Spontan würde ich antworten: Aus meiner Erfahrung heraus sehe ich auch erst mal keinen Grund, warum es nicht auch mit einem P.O.-Team funktionieren sollte. Ich habe das auch bereits erlebt. Häufiger habe ich es allerdings schon schief gehen sehen und man kann unterstellen: Weil man häufig diese Beobachtung machen kann, haben sich Jeff Sutherland und Ken Schwaber im Scrum Framework dafür entschieden, dass es nur einen P.O. geben darf. Ein Einfaches „Das ist halt so!“ reicht mir aber irgendwie nicht aus. Deshalb will ich hier mal einen Erklärungsversuch machen.

Ich bin bekennender Fan der Luhmann’schen Systemtheorie. Trotz meines sicherlich nur laienhaften Verständnisses von Soziologie halte ich sie für äußerst hilfreich, die alltäglichen Vorgänge in großen Unternehmen zu verstehen. Als ich neulich mal wieder ein Buch über Organisationskultur des Soziologen Stefan Kühl las, und über die Wirkung von formeller Macht in Unternehmen nachdachte, kam mir da so ein Gedanke: Formelle Macht hat auch einen ganz bestimmten Zweck und praktischen Nutzen. Darauf beruht mein Erklärungsversuch:

In sozialen Systemen finden immer auch Machtkämpfe statt. Sie sind wichtig, um natürliche Hierarchien zu bilden. Sie sind ein Mittel zur Komplexitätsreduktion und vereinfachen unser Zusammenleben. In Organisationen wie Vereinen, Firmen oder Verbänden wird meist durch Rollen, Posten, Ämter formelle Macht verliehen. Formelle macht ist sozusagen eine Vereinbarung, dass Entscheidungen des entsprechenden Rolleninhabers Folge zu leisten ist.

Natürliche Hierarchien basieren auf freiwilliger Gefolgschaft. Sie sind sozial legitimiert und meist viel belastbarer als formelle Hierarchien, weil Vertrauen ein wesentlicher Baustein dabei ist. Im Unterschied zu formellen Hierarchien können natürliche Hierarchien aber jederzeit verändert werden (z.B. durch neue Machtkämpfe oder durch simples Beenden der Gefolgschaft). Das dient auch dazu, immer wieder heraus zu finden, wer für welche Problemstellung der/die Geeignetste ist. Das ist eher ineffizient aber effektiv. Machtkämpfe und Diskussionen kosten halt einfach Zeit, sie bringen aber auch oft gute, passfähige Lösungen hervor.

Scrum verzichtet bewusst an vielen Stellen auf formelle Macht, um genau das zu ermöglichen.  Man will herausfinden, wer was am besten kann und das kollektive Potenzial optimal nutzen. In Abwesenheit formeller Macht können frei alle Argumente vorgebracht, ausgetauscht, und auch wieder verworfen werden. Um die anspruchsvollen Aufgaben von Entwicklungsteams zu bewältigen ist dies ideal. Tendenziell setzen sich so die besten Lösungen auf Basis ihrer Qualität durch. Unter dem Einfluss von formeller Macht ist das seltener der Fall. Den Zeitaufwand nimmt man zugunsten der Qualität und Nachhaltigkeit in Kauf. 

Bei der Rolle des P.O. hingegen nutzt man bewusst formelle Macht. Man nimmt zugunsten der Agilität (zu Agilität gehört es auch, schnelle Entscheidungen treffen zu können) in Kauf, dass vielleicht nicht immer die “beste” Entscheidung getroffen wird. Es wird dadurch aber sichergestellt, dass das Team handlungsfähig bleibt und keine Blockaden durch Kompetenzgerangel entstehen. Zumindest wird so irgendeine Entscheidung getroffen, aus der man dann wieder Lehren ziehen kann. Denn: Formelle Macht ermöglicht es, auch bei Dissens eine schnelle Entscheidung zu treffen, die dann von allen akzeptiert wird, denn das ist die Vereinbarung.

Dem P.O. wird in Scrum genau diese formelle Macht zugestanden. Wenn man dann noch unterstellt, dass der P.O. ja sehr nah am Markt agiert, wo ein hohes Maß an Komplexität herrscht und es oft nicht die “eine richtige Lösung” gibt, macht das aus meiner Sicht Sinn. An dieser Stelle ist die Ambivalenz komplexer Umgebungen allgegenwärtig. Darum ist es primär wichtig, in Abwesenheit des Wissens um die Optimale Lösung eine Entscheidung zu treffen. Man könnte das nötige Wissen auch durch noch so viele Diskussionen und Argumente nicht erzeugen. Das ist im komplexen Umfeld schlicht nicht möglich. Hier zählt oft das berühmte Bauchgefühl. Wenn dann ein Team aus Product Ownern über ihre Bauchgefühle diskutiert, kann das sehr schwierig werden.

Da Sutherland und Schwaber Scrum für die Software-Entwicklung entwickelt haben, ist es weiterhin auch legitim zu unterstellen, dass die Probleme, die Entwicklungsteams zu lösen haben, eher mit hohem Anteil an Kompliziertheit (also Determinierbarkeit) daherkommen. Das bedeutet, dass sie tendenziell mit Wissen beherrschbar, und auf Basis des Austauschs von Sachargumenten diskutierbar sind. Das funktioniert im Team besser als über Bauchgefühle zu sprechen.

Aus soziologischer Sicht macht das Scrum Framework im Kontext der Software-Produktentwicklung also generell Sinn. Was nicht heißt, dass es nicht auch anders ginge. Teams sind immer komplexe, soziale Systeme. Modelle, Rezepte, Frameworks (alles was nach regelbasierten Methoden riecht) hat im Komplexen immer Grenzen. Letztlich ist der Trick, zu spüren, wann man die Regeln brechen sollte.

Ich freue mich über weitere Sichtweisen, Impulse und Gedanken.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.