Teamentwicklungs-Retrospektive - Das Konzern-Startup


prozesse teams casestudy

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.

Die Situation

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.

Was lief gut?

Endlich mal nur Scrum Master

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.

Auftrag vs. Realität

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.

To Scrum or not to Scrum

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.

Übernahme von Verantwortung, Initiative und Mitgestaltung

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:

  • Klarstellung der Zuständigkeiten. Das klingt auf den ersten Blick hart und geht eigentlich in eine sehr offene Richtung: Zuständigkeit kann eben auch bedeuten, was ein:e Dev in der Rolle machen darf und muss. Es nahm einige Zeit in Anspruch, den Devs zu vermitteln, dass in diesem Fall die Kundin nicht auf eine reine Feature Factory bestand, sondern aktive Mitarbeit wollte.
  • Aus der Notwendigkeit geboren. Man kann sich in einem Konzernumfeld zurücklehnen und warten, bis Dritte ihre Arbeit machen. Oder man kann selbst eingreifen, helfen, Workarounds finden und Zug zum Ziel zeigen. Das Team hat sich für letzteres entschieden 😊 Und es hat den Product Ownern stets klar und offen vermittelt, welche Konsequenzen diese Zusatzarbeiten hatten.
  • Neue Devs nutzen den Freiraum. Durch das stetige Wachstum des Teams entstand natürlich Unruhe - dazu später mehr. Doch ein Vorteil an den Teamänderungen war der Zugang von Charakteren, die das Angebot zur Mitgestaltung gerne annahmen und offensiv nutzten.

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.

Was lief schlecht?

Wie viele Teams kann ein Scrum Master betreuen?

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.

Viele offene Baustellen

Die Betreuung von zwei Projekten bedingt die Konzentration auf das Wesentliche. Hier einige der Baustellen, die bis zu meinem Ende im Projekt offen blieben:

  • Mangelnde Unterstützung der Product Owner bei der Suche nach Techniken zur effektiven Definition des Produktziels und zum Product-Backlog-Management. Während das Produktziel noch eine gute Orientierung gab, waren die Ergebnisse bei den davon abgeleiteten Schritten noch zu sehr getrieben von Zeitplänen. Für mehr Hilfe bei und mit Werkzeugen wie Outcome-orientierten Roadmaps, Story Mapping, fokussierten Sprintzielen, die Wirkung in die Gesamtorganisation etc. blieb nicht genug Raum.
  • Keine Stakeholder bei Reviews. Die Reviews selbst fanden zum Glück nicht als Reporting- und Abnahmetreffen statt, sondern zumindest als Demo des tatsächlich erreichten, inkl. Besprechung, wie es weitergehen soll. Nur fanden diese Diskussion ausschließlich innerhalb des Scrum Teams statt, ohne die Endanwender:innen direkt zu involvieren.
  • Zu viele Aufgaben bei den Product Owern. Trotz der weiter oben beschriebenen Übernahme von Verantwortung durch die Devs blieben in meinen Augen noch zu viele Tätigkeiten und Koordinierungsaufgaben bei den POs. Darunter fallen Punkte wie die direktere Arbeit mit dem Designer und anderen zuliefernden Parteien im Hintergrund.
  • Keine individuelle Betreuung aller Devs. Durch die gesunde Teammischung hatte das Team einen erfreulich hohen Frauenanteil und ein gutes Verhältnis zwischen Erfahrung und Anfängern. Obwohl in den Besprechungen niemand "überbügelt" wurde und Raum für alle bestand, konzentrierte sich der Sprechanteil zu sehr bei den Seniors, wohingegen die Juniors sehr ruhig blieben. Dieses Problem der psychologischen Sicherheit tiefer zu analysieren und an einer Verbesserung zu arbeiten, war mir nicht vernünftig möglich.

In Summe lief das Projekt trotzdem erfolgreich. Nur überspitzt formuliert meiner Meinung nach eben lediglich "gut genug".

Wachstumsschmerzen

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.

Fazit

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 einen unverbindlichen Termin und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.

Vorheriger Beitrag