Stellen wir uns folgende Situation vor: Ein Product Owner hat sich mit einigen App-Usern getroffen und hilfreiches Feedback eingesammelt, das er gerne umsetzen möchte. Allerdings ist die Designerin des Teams im Urlaub und die Designerin eines anderen Teams, die er zur Unterstützung heranziehen könnte, krank. Der Product Owner hat derzeit einigen Druck, da er die App schon längst releasen wollte, aber weiß, dass die Integration des Feedbacks Voraussetzung ist, damit die User die App mögen werden.
Soweit die Ausgangssituation. Spinnen wir das Szenario weiter und spielen zwei Varianten durch.
Variante 1: Der Product Owner kommt zu seinem Team und beschwert sich, dass er soviel Druck hat und "in dem Laden" die Designer immer "das bottleneck" wären. Das Team stimmt mit ein und es sind sich schnell alle einig: Man müsse abwarten, bis die Designerin aus dem Urlaub zurück ist, um das Feedback umzusetzen. Der Product Owner priorisiert das Product Backlog um und zieht Aufgaben nach oben, die aktuell nicht so wichtig sind, aber "die man sowieso früher oder später erledigen muss". In der Retrospektive beschwert sich das Team bei der Designerin. Die Designerin kontert, dass sie das iterative Vorgehen bei Scrum nicht gut findet und wenn sie mehr Vorlaufzeit hätte, die Designs zu Beginn des Projekts ausarbeiten hätte können. Das Team wirft daraufhin der Designerin vor, dass sie zu unflexibel wäre.
Variante 2: Der Product Owner schildert dem Entwicklerteam die Situation, dass er gerne User-Feedback einarbeiten möchte, aber dafür ein Design braucht. Gemeinsam mit dem Team überlegt er sich, was aktuell das vernünftigste Vorgehen wäre. Da kommt einem Entwickler die Idee, dass sie zusammen einen groben Designvorschlag ausarbeiten könnten. Gemeinsam stellt sich das Team vor das White-Board und überlegt, wie sie das User-Feedback sinnvoll einarbeiten könnten. Auf Grundlage des ausgearbeiteten Designentwurfs kann der Product-Owner bereits einige User-Stories in den nächsten Sprint ziehen, die das User-Feedback betreffen. Als die Designerin aus dem Urlaub zurück kommt, wird ihr der Grobentwurf gezeigt, den sie "aufnimmt" und weiter spinnt. Im Refinement präsentiert sie ihre Ideen. Es wird hitzig diskutiert, ob die Änderungen der Designerin im Sinne des Users sind. Auf Grundlage des Feedbacks aus dem Team, ändert die Designerin ihren Vorschlag an ein paar Stellen ab. In der Retrospektive wird das Vorgehen gemeinsam reflektiert. Das Team ist sich einig: Die Herausforderung hat man gemeinsam gut gemeistert. Gleichzeitig wird reflektiert, dass ein schmaler Grat zwischen sachlicher und persönlicher Kritik besteht und dass man hier zukünftig achtsamer vorgehen wolle. Außerdem bietet die Designerin an, einen Workshop zu halten, damit ihre Designkompetenzen besser auf das Team verteilt werden.
5 Bedingungen gelingender Selbstorganisation
Wenn wir die beiden Varianten durchgehen, merken wir, dass die zweite einer Reaktionsweise entspricht, die wir als "gelingende Selbstorganisation" bezeichnen. Doch was sind die Bedingungen, die das Gelingen ermöglichen?
1. Lösungsorientierung: Wenn Probleme auftreten, ist eine Haltung gefordert, die primär an der Lösung orientiert ist. Klar kann man sich auch mal beschweren und das Verständnis der Problemlage ist nicht weniger wichtig (siehe: 5 whys). Aber gelingende Selbstorganisation zeichnet sich vor allem dadurch aus, dass das Team sich bei aufkommenden Problemen fragt, was es zur Lösung beitragen kann. Und wenn es zur Erkenntnis kommt, dass es nicht in der Lage ist, das Problem zu lösen, dann geht es entweder darum, die Situation zu akzeptieren oder das Problem an eine andere Stelle zu eskalieren, wo eine Lösung eher erreicht werden kann. In beiden Fällen wird das Team entlastet und kann den Fokus wieder auf die Arbeit lenken.
2. Teamwork: Wie wir an der zweiten Variante gesehen haben, gibt der Product Owner das Problem ans Team weiter und dieses überlegt sich eine Lösung. Schließlich hat ein Entwickler die Idee, ein Grobkonzept ohne der Designerin zu erstellen. Und ähnlich wie in einem Ping-Pong-Spiel, zirkuliert die Lösungsfindung zwischen verschiedenen Teammitgliedern (Product Owner, Entwickler, Designer), bis das finale Designkonzept erstellt wurde (siehe: The Hot Potato Process). Gelingende Selbstorganisation zeichnet sich somit durch eine Praxis des gemeinsamen Nachdenkens und Feedbackgebens aus.
3. Rollenübergreifend handeln und Kompetenzen verteilen: Rollen sind wichtig, da sie Orientierung geben und zur effizienten Arbeitsteilung beitragen. Allerdings ist es in bestimmten Fällen erforderlich, dass rollenübergreifend gehandelt wird. In unserem Beispiel entwickelt das Team ohne der Designerin einen Grobentwurf für das Design. Das ist in diesem Fall die richtige Reaktion, da so der höchste Nutzen für den User erzielt und Verzögerungen verhindert werden. Teamwork bedeutet somit auch, teaminterne Silos abzubauen, um handlungsfähig zu bleiben (siehe: T-Shaped skills). Das hat die Designerin auch erkannt und gibt einen Workshop, damit bei ihrem nächsten Fehlen, das Team die Designs noch besser erstellen kann.
4. Nutzerzentrierung: Wir haben es bereits angeschnitten: Das Team muss so zusammenarbeiten, dass der Nutzen für den Nutzer an erster Stelle steht. Diese Aufgabe übernimmt in einem Scrum-Team üblicherweise der Product Owner. Aber auch bottlenecks in der "Umsetzung" können eine Hürde darstellen. Bei Variante 1 unseres Beispiels priorisiert der Product Owner sein Backlog um, da die Designerin im Urlaub ist. Das kann fatal sein, da sich so der Release verzögert und am Ende des Tages Geld verloren geht (ein Entwicklerteam ist nicht günstig!). Das Team sollte sich also stets fragen: Was können wir dazu beitragen, damit der Nutzer das Feature möglichst schnell bekommt, das er wirklich, wirklich benötigt? (siehe die Prinzipien des Manifests für agile Softwareentwicklung: "Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen" und "Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell").
5. Gemeinsam offen reflektieren: Wenn ein Problem auftritt und vielleicht auch gemeinsam gelöst wird, geht es darum, die Vorgehensweise des Teams retrospektiv zu reflektieren. Dazu gehört auch, sich selbst zu loben, wenn ein Vorgehen erfolgreich war. Ebenso wichtig ist die Frage, wie das Team beim nächsten Mal anders oder besser reagieren hätte können und Maßnahmen dahingehend auszuarbeiten (siehe: inspect & adapt). Um gemeinsam offen zu kommunizieren, ist ein wechselseitiges Vertrauen Voraussetzung (siehe: psychological safety). Nur dann trauen sich die Teammitglieder auch kritische Stimmen offen zu äußern, die zu besseren Lösungen beitragen.