Dennis Gugel Haben Sie sich jemals darüber Gedanken gemacht, wie Sie in Ihrem Team Entscheidungen treffen? Sind Sie ein Pro- und Contra-Listenführer? Oder hören alle Teammitglieder einfach auf ihr Bauchgefühl? Agile Teams müssen in hoher Frequenz eigenverantwortlich Entscheidungen treffen. Gelingt dies nicht, ist die Folge Stillstand. In unserem Scrum Team habe ich genau diese Erfahrung gemacht und einen Ausweg gefunden, der für uns gut funktioniert hat.
Ausgangslage
Die agile und die klassische Softwareentwicklung unterscheiden sich deutlich in der Methode und der Herangehensweise in Projekten. Mein Kollege Bastian Wunderskirchner hat in seinem Blogbeitrag „Agil oder alles nach Plan? Welche Projektmanagementmethode ist die Richtige?“ die markantesten Unterschiede beschrieben.
Während in der klassischen Softwareentwicklung zentrale Entscheidungen zu Anforderungen, Technologien und Architekturen vor Projektstart gefällt werden, geschieht dies in der agilen Softwareentwicklung iterativ während der Projektlaufzeit. Im Scrum Framework werden z. B. sogenannte User Stories formuliert, die zu Beginn wenig detailliert sind und im Laufe des Projekts in periodischen Product Backlog Refinements mit Informationen angereichert werden.
In der klassischen Softwareentwicklung treffen Requirements Engineers, Architekten oder Team Leads grundlegende Entscheidungen. Im Gegensatz dazu entscheidet im agilen Kontext das gesamte Development Team – das Team ist schließlich selbstorganisiert und gemeinsam verantwortlich (Agiles Manifest, Prinzip 11).
Dabei habe ich beobachten können, dass solche Teams es nicht gewohnt sind, selbstständig Entscheidungen zu treffen. Oft pendeln Diskussionen dann zwischen zwei Extremen hin und her: Entweder es sind ewig lange, nicht zufriedenstellende Diskussionen, die sich schon nach einiger Zeit nicht mehr ums Wesentliche drehen bis hin zum anderen Extrem – keiner möchte mehr irgendetwas sagen. Das Resultat: die Motivation, Entscheidungen zu treffen, und damit auch die Produktivität des Teams sinken. Aber wie bringt man ein Team dazu, Entscheidungen zu treffen, obwohl es das nicht gewohnt ist?
Ein Ausflug in die Welt der Entscheidungsprozesse
Es gibt viele Wege, Entscheidungen zu treffen und dabei nicht den „einzig Wahren“. Jeder von uns nutzt – meist unbewusst – eine Vielzahl an Entscheidungsprozessen im täglichen Leben. Bei der Entscheidungsfindung im Team kann es hilfreich sein, sich bewusst zu machen, welche Entscheidungsprozesse es gibt und welche Vor- und Nachteile diese mit sich bringen. Die Entscheidungsprozesse, die wir im Team genutzt haben, sind im Folgenden aufgelistet:
Konsens
– Jeder muss zustimmen –
Die klassische Entscheidungsfindung. Jeder äußert solange seine Meinung, argumentiert positive und negative Punkte, bis ein gemeinsamer Nenner („Konsens“) gefunden wurde.
Methode: 100$ – Game
Vermeidung
– Mal sehen was passiert –
Bei unklaren, sich ständig ändernden Bedingungen wie Stakeholdern, die ständig ihre Meinung ändern, ist die Vermeidung einer Entscheidung auch eine Entscheidung. Es handelt sich also um ein bewusstes nicht-entscheiden.
Methode: Bewusstes Vermeiden
Autokratie
– Ich entscheide –
Eine Person entscheidet ohne die Meinung der Teammitglieder einzuholen. Das kann sinnvoll sein, wenn schnelle Entscheidungen gefragt sind und das Team damit leben kann (bspw. durch „Charismatic Leadership„).
Methode: Entscheiden
Stochastisch
– der Zufall entscheidet –
Gleichwertige Entscheidungsmöglichkeiten werden durch eine Methode gefällt, die auf einem normalverteilten Zufallsprinzip beruht. Beispiele hierfür sind Roulette, Bernoulli Experiment, Laplace Experiment, usw.
Methode: Würfeln, Glücksrad, Münzwurf
Demokratie
– Die Mehrheit gewinnt –
„Herrschaft des Volkes“, ein System, bei dem Entscheidungen durch das Mehrheitsprinzip gefällt werden.
Methode: offene Abstimmung per Handzeichen, geheime Abstimmung durch Stimmzettel
Delegieren
– Ein Auserwählter entscheidet –
Einer aus der Gruppe bekommt die Entscheidungshoheit und wird damit legitimiert, eine Entscheidung zum Wohle der Gruppe / des Ziels zu treffen. Oft wird der mit dem meisten Know-How bezüglich des Problems gewählt. Er berät sich mit der Gruppe, entscheidet aber selbst.
Methode: delegieren einer Entscheidung
Beratungsansatz
– Der Experte berät, die Gruppe entscheidet –
Im Unterschied zum Delegieren, setzt der Beratungsansatz mehr auf Informationen von internen oder externen Experten. Dass die Entscheidung vom Team gefällt wird, ist dabei meist nur eine Formalie, da sie sehr stark auf Informationen des Experten beruht. Der Beratungsansatz ist ebenfalls für die Erarbeitung von Entscheidungsoptionen nutzbar.
Methode: Entscheidung nach Fachberatung
Konsent
– Kein Einwand –
Kein Tippfehler, es heißt Konsent. Zur Konsentfindung braucht es eine Entscheidungsoption. Solange kein vehementer Einwand der Teammitglieder gegen diese erfolgt, ist diese Entscheidungsoption verabschiedet. Oft wird die Konsentfindung in Kombination mit der Kreismoderation verwendet. Die Entscheidungsoption ist „Good enough for now“.
Methode: systemisches Konsensieren
Das Scrum-Team, das keine Entscheidungen treffen konnte…
In meinem Scrum Team wurde in Entscheidungssituationen zunächst tagelang diskutiert, was dazu führte, dass schließlich niemand mehr Lust hatte irgendetwas festzulegen. Oft wurden User Storys dadurch nicht weiter ausgearbeitet, die Entscheidung vertagt und der Druck durch den Product Owner immer größer. Dieser wollte schließlich möglichst alle User Storys im nächsten Sprint umgesetzt sehen. Das Vertagen der Entscheidung führte dazu, dass User Storys in den Sprint geplant wurden, für die nicht entschieden war, wie das Team technologisch damit umgehen soll. Selbstverständlich führte das wiederum dazu, dass das Sprintziel nicht eingehalten werden konnte und die Stimmung mit jedem Sprint schlechter wurde. Eine Abwärtsspirale par excellence …
… konnte sich auf etwas einigen
Um dieses Muster zu unterbrechen haben wir uns auf zwei Schritte bei der Entscheidungsfindung geeinigt:
Schritt 1 // Konsequentes Trennen zwischen der Erarbeitung von Entscheidungsoptionen und dem eigentlichen Entscheidungsprozess:
Zu Beginn des Sprints wurden User Storys zunächst auf ihre Komplexität geschätzt. Dies wurde mit Hilfe von Story Points festgelegt. Die Erfahrung hat gezeigt, dass es sich ab 13 Story Points lohnt, wenn jeder Developer Entscheidungsoptionen ausarbeitete. Diese wurden dann in einem Meeting mit einer Timebox von 30 Minuten in der Mitte des Sprints vorgetragen. Das Ziel bestand darin, dass das Team ein gemeinsames Verständnis aller Entscheidungsoptionen hatte.
Schritt 2 // Auswahl eines geeigneten Entscheidungsprozesses und Durchführen der entsprechenden Methode:
Nachdem alle Entscheidungsoptionen bekannt waren, entschied ein vorher ausgewähltes Teammitglied, welcher Entscheidungsprozess genutzt wurde. Die Moderation der zugehörigen Methode übernahm zunächst der Scrum Master. Später, als das Team die Methoden beherrschte, moderierte es den Prozess selbstständig.
Welche Erfahrungen haben wir mit obigem Vorgehen gemacht?
Es dauerte etwas, bis alle dieses Vorgehen verinnerlicht hatten. Auch wenn zunächst so Mancher das Vorgehen albern fand, waren alle offen dafür. Die Atmosphäre in den Refinements, also der Zeremonie, bei der über Details einer User Story entschieden wird, änderte sich schlagartig nach dem ersten Refinement.
Nachdem die User Storys vorgestellt und verstanden wurden, gingen die ersten Diskussionen über jene mit mehr als 20 Story Points los. Jeder hatte einen Vorschlag. Und eine Meinung. Noch bevor jemand für seinen Vorschlag ausführlich Stellung beziehen konnte, wurde die Diskussion allerdings durch mich (Scrum Master) abgebrochen und auf das oben beschriebene Vorgehen verwiesen. Das war ungewohnt. Und neu. Alle waren nun aufgefordert sich in den nächsten Tagen mit dem Thema auseinanderzusetzen und Entscheidungsoptionen zu erarbeiten.
Mitte des Sprints: Es wurde zunächst der heutige Prozessentscheider ausgewählt. Jeder schrieb seine Entscheidungsoptionen auf ein Post-it, gleiche Optionen wurden übereinander gehängt. Der Scrum Master achtete darauf, dass lediglich Verständnisfragen gestellt wurden. Nach 30 Minuten Timebox fiel der Hammer: Der Prozessentscheider wählte den stochastischen Ansatz aus. Wir würfelten. Es wurde Option 5.
War das nun die richtige Entscheidung? Lag die Wahrheit in Option 5? War das jetzt der heilige Gral? Mit hoher Wahrscheinlichkeit war das nicht die perfekte Entscheidung. Aber eine optimale, hinter der das Team stand. Und genau das war es, was das Team wertschätzte. Es war selbstorganisiert und traf bewusst gemeinsam Entscheidungen!
Fazit
Die Herausforderung, Entscheidungen im Team zu treffen, muss nicht in einem Teufelskreis immer weiter sinkender Motivation enden. Für mein Scrum Team und mich war es wichtig, dieses Muster zu erkennen. Dadurch konnten wir uns gemeinsam auf einen Prozess einigen, der von allen akzeptiert wurde. Die klare Entkopplung zwischen dem Erarbeiten und Verstehen von Entscheidungsoptionen von dem eigentlichen Entscheidungsprozess war der Schlüssel unseres Erfolgs. Damit hatten wir die Herausforderung gemeistert: Wir hatten mehr Spaß am Entscheiden.
Co-Autor:
Dr. Dominik W. Pilat