In diesem Beitrag betrachte ich rückblickend die etwa einjährige Arbeit mit einem Softwareentwicklungsteam im Food-Umfeld.
Neben den positiven Punkten in der folgenden Retrospektive betrachte ich auch die schlechten Seiten, um ein realistisches Gesamtbild der Teamentwicklung zu zeigen.
Als Erstes zum besseren Verständnis eine Erklärung des Umfelds.
Das betroffene Team wurde von einem IT-Dienstleister für maßgeschneiderte Softwarelösungen gestellt. Die Kundin war ein konzerninternes Start-up. Ziel des Projekts war die Schaffung eines Ökosystems rund um anpassbare Rezepte.
Die entsprechenden Softwaresysteme entstanden ursprünglich mit einem anderen Entwicklungspartner. Die Kundin war mit diesem in Hinsicht auf Zusammenarbeit und Fortschritt unzufrieden, was schlussendlich zur Trennung führte. Somit erbte das neue Team nicht nur eine bestehende Codebasis, sondern auch ein Projekt in zeitlicher Schieflage.
Für meine Aufgabe erschwerend kam hinzu, dass das neue Team einige Monate einen Scrum Master hatte, dessen Ergebnisse nicht sichtbar genug waren. Der Wert der Rolle eines dedizierten Teamentwicklers ist im Dienstleistungsgeschäft buchstäblich schwer zu verkaufen. Gelingt es trotzdem, die Kundin nimmt die Arbeit jedoch nicht wahr und fragt sich, welche Leistung sie für ihr Geld bekommt, schafft das kein gutes Verhältnis. Dieser Scrum Master hat letztendlich sehr kurzfristig gekündigt.
Das war die Ausgangslage Ende 2020, als ich um Unterstützung gebeten wurde. Das Team bestand zu diesem Zeitpunkt aus 6 Menschen, sollte weiter wachsen und hatte das oben angerissene Potpourri an Problemen. Mein Auftrag war so vage wie einfach: "baue ein Team".
Zu Beginn ein Blick auf die positiven Aspekte.
Im Verhältnis zwischen Auftraggeber und Auftragnehmer ist die formale Rolle der Projektleitung Standard. Und es kommt nicht selten vor, dass diese Rolle in Personalunion mit der Scrum Masterei besetzt wird – mit allen Vor- und Nachteilen. Dieses Projekt war anders. Die offizielle Projektleitung hatte eine Person inne, die parallel noch Aufgaben eines Proxy Product Owners übernahm – mit allen Vor- und Nachteilen.
Diese Konstellation erlaubte mir, mich frei von den ablauftechnischen Notwendigkeiten des Dienstleistungsalltags voll auf die Arbeiten rund um das Team zu konzentrieren. Die damit gewonnene Freiheit ermöglichte Entscheidungen ohne die Schizophrenie und den Zielkonflikten bei der Vermischung von Rollen.
Die weiter oben bereits erwähnte Ungenauigkeit meines Auftrags und die entsprechend fehlende genaue Auftragsklärung im Vorfeld könnte eigentlich als Punkt für die Sektion "was lief schlecht" gelten. Bis auf das unbestimmte Gefühl meines internen Auftraggebers, dass das Team nicht funktioniert, und die generelle Projektlage hatte ich keine weiteren Informationen oder Anhaltspunkte.
Doch genau diese Unklarheit lenkte meinen Fokus auf die Schritte, die sich in meinen Augen ohnehin immer als Einstieg in ein neues Projekt empfehlen: beobachten, Fragen stellen und zuhören, um zu verstehen.
Und als Ergebnis ergab sich ein anderes Bild und eine komplexere Lage. Das Team selbst hatte einen höheren Reifegrad als gedacht und die reine Formung einer Einheit nicht mehr erste Priorität. Stattdessen verlagerte ich mein Augenmerk auf verschiedene Themen rund um den Prozess, das Produkt und die Zusammenarbeit mit den Auftraggeber:innen.
Die anfänglichen Stolpersteine wie Zuarbeit der Product Owner (ja, es waren zwei), fehlender Fokus, Probleme mit der Fertigstellung von Aufgaben und mit Abhängigkeiten von Dritten deuteten auf eine Domäne, für die Scrum noch nicht das richtige Werkzeug darstellte. Der Umstieg auf ein rein flussbasiertes Vorgehen oder eine Mischform waren Optionen, die ich dem Team vorschlug.
Nach Abwägung der Vor- und Nachteile sprach sich die Mehrheit des Teams dafür aus, bei Scrum zu bleiben. Dies schuf die sichere Auftragsgrundlage und Ausrichtung für meine weitere Arbeit. Ein Punkt, den ich trotz der Festlegung auf Scrum nicht aus den Augen ließ, war, mich nicht dogmatisch auf den perfekten Prozess zu versteifen - das Ziel ist die nachhaltige Schaffung von Produktwert und nicht eine Vorgehensweise nach Lehrbuch.
Mit der Zeit übernahm das Team immer mehr Verantwortung für das Projekt und gestaltete eigenständig Teile des Gesamtproduktes und dessen Umfeld mit. Dabei war nicht ein einzelner Punkt ausschlaggebend. Stattdessen führte eine Reihe von Maßnahmen und Veränderungen zu diesem Zustand:
All das führte Schritt für Schritt zu gemeinsamen Erfolgen und damit zum Aufbau von gegenseitigem Vertrauen. Dieses Vertrauen wiederum führte zu einer noch engeren Zusammenarbeit mit der Kundin, die über das normale Dienstleistungsgeschäft als reine Erfüllungshilfe hinausging.
Gehen wir über zu den Lektionen aus Punkten, die nicht gut liefen.
Darauf gibt es natürlich keine allgemeingültige Antwort. Einen ersten Ansatz bietet "ein guter Scrum Master hat zwei Teams, ein sehr guter eines". Und da ist im vorliegenden Fall viel Wahrheit dabei. Ich habe dieses Team nicht in Vollzeit begleitet, sondern neben einem weiteren großen Team.
Wären beide Projekte kleiner gewesen, hätte das Setup auch weiter funktionieren können. Doch am Ende hatte ich in Summe die Verantwortung für fast 30 Menschen in zwei Projekten, was eine viel zu große Führungsspanne darstellt. Dies brachte zu viele Kontextwechsel und damit Verlustleistung mit sich.
Die Betreuung von zwei Projekten bedingt die Konzentration auf das Wesentliche. Hier einige der Baustellen, die bis zu meinem Ende im Projekt offen blieben:
In Summe lief das Projekt trotzdem erfolgreich. Nur überspitzt formuliert meiner Meinung nach eben lediglich "gut genug".
Das Team wuchs im Laufe der Zeit von knapp 5 Menschen auf mehr als 10. Diese Vergrößerung plus parallel stattfindenden Wechseln sorgte für eine ständige Unruhe. Und die damit notwendige Integration der neuen Devs plus der Wiederstabilisierung des Teamgefüges bestimmte große Teile meines Alltags.
Eine weitere beispielhafte Lektion an dieser Stelle war wieder einmal, dass jedes Team anders ist. Während ich in einem anderen, fachlich relativ homogenen Team problemlos Retros mit 16 Personen und mehr abhalten konnte, klappte dies hier nicht mehr. Einige Kernthemen konnte die ganze Gruppe besprechen. Doch durch die fachlich höhere Differenzierung gab es zu viel Leerlauf bei und Unterschiede zwischen den verschiedenen "Gewerken".
Dies machte eindeutig klar, dass ein neuer Teamschnitt erfolgen musste. Die Organisation dieser Neuordnung und die anschließende Führung waren jedoch eindeutig nicht mehr nebenher machbar und bedeutenden das logische Ende meiner Arbeit mit diesem Team.
Ich habe dieses Team fast ein Jahr lang begleitet. Wobei natürlich nur wenige Monate Aushilfe geplant waren 😁
Am Ende wurde klar, dass eine "Nebenherbetreuung" nicht mehr möglich war und dem Team gegenüber auch nicht angemessen und fair. So habe ich meinem Nachfolger, der aus dem Team selbst kam, eine stabile Grundlage für die nächsten notwendigen Schritte übergeben.
In meinen Augen hat v. a. die Arbeit an der Autonomie und der Kollaboration dazu beigetragen, ein wirksames und produktives Team zu formen. Und um damit beizutragen, dass die Kundin letztendlich den Wert der Arbeit eines guten Scrum Master und Teamentwicklers spüren konnte.
Buchen Sie jetzt eine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.