Ich bin fest davon überzeugt, dass die Stärke des Agilen Vorgehens nicht in den kurzen Entwicklungszyklen und der damit schnellen Reaktionen auf Veränderungen oder in der direkten Zusammenarbeit mit dem Anwender liegt, sondern in der Stärkung der Teams. Jede Meinung zählt gleich viel. So bringen wir unser Projekt mit dem Input von vielen Personen voran, nicht nur mit den Entscheidungen von wenigen, oder etwa nicht?
Das Leben könnte so einfach sein. Eine Person entscheidet, und ein Team setzt dies dann um. Die Verantwortungen sind klar verteilt, als Entwickler muss man sich um nichts kümmern, und wenn es schief geht, kann man immer lange darüber philosophieren, was man an Stelle des Entscheiders anders gemacht hätte. Zwischendurch beschwert man sich darüber, wie wenig Mitspracherecht man so hätte.
Dann kommt jemand um die Ecke und bietet dem Team echte Beteiligung an der Entscheidungsfindung. Was dann passiert, hat der eine oder andere von Ihnen vielleicht schon selbst erlebt: plötzlich stellen wir fest, dass einige nicht wirklich beteiligt werden wollen, und dass andere mit der Situation nicht umgehen können. Die ersten Versuche, zu einem Teamentscheid zu kommen, enden nicht selten in Konfusion und endlosen Diskussionen, die sich immer wieder im Kreis drehen, weil man schwer zu dem Punkt des Commits kommt, auch wenn man sich in der Sache grundsätzlich irgendwie einig ist.
Das ist erstaunlich. Selbst bei eingespielten Scrum-Teams, die es gewohnt sind, sich zum Start jedes Sprints auf ein Sprintcommit zu verständigen, wird es plötzlich schwierig, wenn man über Inhalte spricht. Das liegt sicherlich daran, dass wir unsere Kollegen plötzlich mit einer komplett anderen Fragestellung konfrontieren. Es geht nicht mehr darum, wie viel wir tun möchten, es geht darum, was wir tun möchten. Das erfordert eine vollkommen andere Sichtweise.
Auch in Scrum können wir das Modell des Einer-entscheidet-alles leben. Nehmen Sie sich ein beliebiges Scrum Buch und schlagen Sie die Rolle des Product Owners nach. In aller Regel werden Sie dort etwas finden wie »der Product Owner entscheidet über Inhalt und Priorisierung der User Stories« oder irgendeinen ähnlichen Käse. Natürlich kann man die Rolle des PO so leben. Das steht nicht im Widerspruch zu den Scrum Regeln, aber wo liegt dann der Unterschied zum klassischen Vorgehen? In den kurzen Iterationen und der besseren und häufigeren Kommunikation mit dem Anwender. Für sich genommen ist das ein großer Vorteil, aber da geht doch noch so viel mehr. Das Potential des Teams nutzen wir so nicht aus. Die Entwickler bleiben weiterhin lediglich das ausführende Element. Was ändert sich denn für den lieben Code hackenden Kollegen von nebenan, wenn wir von Wasserfall auf das PO zentrierte Scrum-Modell umschalten? Er wird plötzlich gefragt, was er glaubt, in zwei Wochen zu schaffen – das wars.
Gelingt es mir jedoch, die Entwickler wirklich voll in die Entscheidung zu integrieren, passieren weitere Dinge, z.B. schaffe ich plötzlich eine echte Identifikation mit dem Projekt/Produkt und damit eine ganz andere Motivation. Damit gewinne ich nicht nur Codequalität und Entwicklungstempo, sondern auch ein letztendlich besseres Produkt, weil immer wieder einige weitere hochintelligente Menschen, die das Produkt sehr gut kennen, ihre Ideen einbringen oder im Zweifel bitter darum kämpfen, einzelne Entscheidungen noch einmal zu überdenken.
Jetzt könnten Sie sagen, dass in jeder Ausprägung von Scrum das Team darin bestärkt wird, sich einzubringen. Dem werde ich nicht widersprechen, gebe jedoch zu bedenken, dass das nur selten tatsächlich geschieht. Seien wir ehrlich, wenn der PO nicht aktiv auf die Kollegen zugeht, passiert meistens recht wenig.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Lassen Sie uns doch einfach einmal in folgende Richtung denken: Team und PO entwickeln gemeinsam das Produkt, füllen zusammen das Backlog und priorisieren gemeinsam. Die Folge ist ein hochmotiviertes Team (wenn wir es richtig machen – dazu später mehr) und eine gemeinsame Sicht der Dinge. Die Rolle des PO wandelt sich dabei vom Entscheider zum Visionär und Konzepter (allein für diesen Aspekt werde ich einen eigenen Artikel brauchen). Die Rolle des Entwicklers erhält plötzlich PO-Anteile. Man muss sich damit beschäftigen, wie Anwender ein Produkt sehen, und man muss die Absichten der Kollegen vom Marketing verstehen. Natürlich gibt es da noch viel mehr. Dies ist nur exemplarisch dafür zu sehen, dass sich die Sicht auf das Produkt und das Unternehmen verschiebt. Wir holen unsere Kollegen also herunter von ihrer Insel der Glückseligen und konfrontieren sie mit der harten Realität. Hier gibt es jetzt die ersten echten Probleme. Wenn man sich als reiner Entwickler versteht und nur in Code denken muss, ist die Sicht auf die Dinge ungemein einfach. Das hinter sich zu lassen, ist für viele eine große Herausforderung. Als Scrum Master sollten wir das wissen und verstehen, damit wir unsere Kollegen dabei begleiten und sie langsam an ihre neue Rolle heranführen können.
Wie geht das?
Ich habe oft beobachten können, dass es sehr schwer war, alles auf einmal erreichen zu wollen. Ich rate dazu, zunächst mit dem Team zu klären wie weit sie in die Entscheidungen eingebunden sein wollen. Oft ergibt sich hierbei ein sehr inhomogenes Bild. Der eine oder andere wünscht sich eine sehr viel aktivere Beteiligung, die anderen sind zufrieden oder haben sich schlicht noch keine Gedanken gemacht.
Sie werden nicht glauben, wie oft ich beobachten durfte, dass einzelne Personen darüber entschieden haben, wie stark ein Team eingebunden werden muss, um dies dann den Kollegen vorzugeben. Das ist auf so vielen Ebenen vollkommen falsch, dass mir fast die Worte ausgehen – fast. Über die Rolle des Teams entscheidet das Team. Daher sorgen wir zunächst dafür, dass hier vor der gemeinsamen Sicht auf die Dinge ein gegenseitiges Verstehen einsetzt. Wenn wir mit den Kollegen über das Vorgehen und die Rollenverteilung sprechen, dann werden wir die unterschiedlichen Standpunkte auf den Tisch bringen können. Wir tauschen Argumente aus und erarbeiten gemeinsam unser Zielbild. Wir fragen uns, wo die Vorteile für das Team bei einer stärkeren Einbindung liegen und wie wir in Zukunft vorgehen möchten.
Es wird eine Weile dauern, bis alle Beteiligten ihren Rhythmus gefunden haben. Als Scrum Master sind wir in dieser Phase natürlich besonders gefordert, sowohl die Entwickler als auch den PO zu unterstützen. Wichtig ist, dass wir nicht versuchen, unvorbereitet zu einer Entscheidung zu kommen. Damit meine ich, dass immer eine oder mehrere Personen etwas vorbereitet haben sollten, worüber das Team diskutieren und entscheiden kann. Das ist grundsätzlich besser als der Versuch, mit allen bei Null zu starten, gemeinsam mögliche Lösungsoptionen zu überlegen, diese zu bewerten und sich dann zu entscheiden. Ich bin immer ein großer Freund davon, einen vorangehen zu lassen, um Dinge vorzubereiten. Das macht es für alle anderen wesentlich leichter.
Die Hauptschwierigkeit haben wir bis jetzt jedoch noch gar nicht berührt: zur richtigen Zeit über die richtigen Dinge zu sprechen.
Über allem, was wir in dieser Beziehung tun, steht »Kontext«. Wir sollten uns also hüten, mit den kleinen Dingen zu beginnen (also mit der Priorisierung des Backlogs zum Beispiel), wenn wir das größere Bild noch nicht aufgespannt haben. Jede Entscheidung kann dann nur einen Teil des Gesamten berücksichtigen und ist somit unvollkommen. Wir gehen immer vom Groben ins Feine, sprechen zunächst über Epics und eine Timeline, bevor wir über einzelne Anforderungen sprechen.
So ergibt sich fast automatisch die Antwort auf die Frage, wann wir uns mit welchen Themen beschäftigen müssen.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
