Die Anforderungen an unsere Entwicklungsteams wachsen stetig, und in den allermeisten Unternehmen stehen wir vor der Herausforderung und der Erwartung einer kontinuierlichen Verbesserung – mit anderen Worten: Leistungssteigerung. Was können wir, die wir in irgendeiner steuernden Rolle wirken, tun, um das zu erreichen, und wann endet das eigentlich, denn eines muss uns allen klar sein: Steigerung der Teamperformance ist nicht unendlich möglich.
Wir haben damit zwei Fragen, die wir beantworten müssen: zum einen die des Erwartungsmanagements, weil Performancesteigerung eben nicht unendlich möglich ist, und auf der anderen Seite natürlich die Steigerung selbst.
Ihr merkt schon: das ist kompliziert.
Beginnen wir mit dem, was wir selbst tun können, also mit der Arbeit in den Teams bzw. Organisationseinheiten. Dazu müssen wir uns zuerst einmal bewusst machen, dass wir auch hier wieder zwei Dinge betrachten, nämlich zum einen eine Steigerung und zum anderen eine Vermeidung.
Eine tatsächliche Steigerung der Performance gelingt uns nur über den gezielten Aufbau von Skills, die in Routine münden. Dazu müssen wir sehr genau wissen, welche Fähigkeiten aktuell und in Zukunft gebraucht werden, und in welchem Maße genau diese Fähigkeiten aktuell vorhanden sind. Ob Ihr das in Form einer Skillmatrix oder wie auch immer macht, ist vollkommen schnurz. Wichtig ist nur, dass Ihr mit der Hilfe des Teams – und keinesfalls nur aus einer Beobachterrolle heraus – eine möglichst umfassende Antwort auf die Frage bekommt, was gebraucht wird, und in welchem Maße das aktuell vorhanden ist.
Der Blick in die Zukunft ist dabei das Entscheidende. Performancesteigerung über Befähigung ist langwierig. Wir müssen Coachings und Schulungen organisieren, eventuell sogar erst das Budget dafür bekommen. Dann muss der Inhalt der Trainings gefestigt werden. Wir sprechen hier über Monate, bis eine einzelne Maßnahme wirkt, und für eine sichtbare Performancesteigerung brauchen wir mehrere Maßnahmen, die sich natürlich auch teilweise parallelisieren, aber eben nicht endlos übereinander stapeln lassen.
Auch die Auswahl der möglichen Maßnahmen können wir nicht allein machen. Hier geht es oft um sehr spezielle Anforderungen, von denen wir oft genug nicht genug verstehen, um beurteilen zu können, welche Schulung von welchem Anbieter die richtige ist.
Haben Entwickler eine externe Schulung besucht, liegt es natürlich an uns, dieses neue Wissen irgendwie im Team zu verteilen. Schließlich haben wir auch weiterhin die Aufgabe, Kopfmonopole zu vermeiden und aufzulösen. Ok, also wieder mehr Pair Programming …
Kein Scherz – klappt gut.
Ich kann an dieser Stelle nicht tiefer in die Details gehen, weil die Anforderungen an die Befähigung sehr unterschiedlich sein können. Einige Dinge können wir organisationsintern lösen. Die benötigten Skills sind in anderen Teams vorhanden. Dann sieht Befähigung anders aus als wenn wir sie extern einkaufen müssten.
Wenn wir sagen, dass Performancesteigerung über Befähigung der langfristige Ansatz ist, dann ist der Weg über Vermeidung der kurzfristige. Dazu müssen wir schließlich nur unerwünschte Dinge abstellen, oder?
Unter »Vermeidung« verstehen wir natürlich, dass wir alle Tätigkeiten, die nicht wertschöpfend sind, unterlassen. Das erste, worüber dann immer alle sprechen, ist, dass wir zu viel Zeit in Meetings verbringen, und das ist natürlich richtig, da lassen sich immer ein paar Punkte finden, das sind aber nur selten die größten Ansatzpunkte. Viel teurer sind meistens unklare Anforderungen und langsame oder ebenfalls unklare Prozesse.
Unklare Anforderungen führen dazu, dass wir erhöhten Diskussions- und Klärungsbedarf haben, was natürlich Zeit kostet und uns davon abhält tatsächlich produktiv zu arbeiten, und oft genug führen unklare Anforderungen auch zu doppelter Arbeit, weil wir Dinge einfach falsch verstanden haben, etwas tun und dann feststellen müssen, dass wir eigentlich etwas Anderes hätten tun müssen.
Diese Dinge sind richtig teuer. Ganz ähnlich ist es mit den Prozessen und Abläufen. Auch dies führt zu vielen Diskussionen und dazu, dass wir Dinge doppelt tun, auch wenn das dann weniger Entwicklung und mehr Organisation betrifft.
Kurz gesagt sind damit Anforderungen und Prozesse bzw. das Zusammenarbeitsmodell unsere größten Ansatzpunkte, wenn es um die relativ kurzfristige Performancesteigerung geht. Innerhalb der Teams regeln wir das über unsere Retrospektiven – so weit so gut. Das Problem liegt hier aber eher in der Zusammenarbeit zwischen den Teams, zwischen verschiedenen Abteilungen und in der Anforderungsausarbeitung, bevor diese in die Teams gehen.
Wenn Ihr z.B. Scrum Master seid, könnt Ihr hier allein nicht wirklich viel bewegen. Euer direkter Einflussbereich ist das Team selbst. Alles, was darüber hinaus geht, können wir nur gemeinsam angehen. Unsere Aufgabe ist es also, zunächst die Beispiele zu finden, die uns in der Vergangenheit Zeit gekostet haben. Das können wir z.B. im Rahmen einer teamübergreifenden Retrospektive machen, indem wir auch genau da zum Thema machen: was hat uns in der Vergangenheit unnötig viel Zeit gekostet?
Danach ist das Vorgehen dasselbe, was wir auch aus unseren Teamretros kennen: Lösungen erarbeiten und umsetzen, nur mit dem Unterschied, dass wir für die Erarbeitung der Lösungen und die Umsetzung dieser einen anderen Personenkreis brauchen. Wir kommen also aus dieser teamübergreifenden Retro (die wir natürlich auch regelmäßig machen sollten – in SAFe gibt es dafür das Inspect & Adapt) mit einer Reihe von identifizierten Beispielen und Problemen, Vorschlägen und einer Liste von Personen und Rollen, die wir für die weitere Arbeit brauchen. Es liegt dann an uns, diese Dinge voranzutragen.
Auch hier muss ich an dieser Stelle abbrechen, weil es jetzt höchst individuell wird. Prozesse müssen geändert werden, Regeln der Zusammenarbeit überarbeitet, der Vorgang der Anforderungserarbeitung inklusive Quality Gates usw. – unsere größten Zeitfresser und deren Gegenmaßnahmen sind sehr unterschiedlich.
Das ist das, was wir selbst tun können, um aktiv an der Performance zu arbeiten, und was auch immer hilft. Klingt arrogant, is aber so. Es ist immer eine gute Idee, an der Befähigung der Teams und an der Optimierung unseres Vorgehens zu arbeiten. Das ist nichts Anderes. Dazu brauchen wir auch die Unterstützung (Stichwort Servant Leadership) der Führungskräfte und skalierten Rollen. Ohne diese können wir uns viel überlegen, aber letztlich würde uns die Legitimation und damit das Werkzeug fehlen. Bezieht diese Personen also möglichst frühzeitig mit ein. Die werden dafür dankbar sein – glaubt mir. Schließlich haben die dasselbe Interesse.
Wie weiter oben schon erwähnt, ist Performancesteigerung nicht endlos möglich. Die Kurve flacht ab. Wenn wir schon viel getan haben und richtig gut aufgestellt sind, gelingt es uns irgendwann nur noch, den Status Quo zu halten und an ganz kleinen Schrauben zu drehen, an denen wir aber kaum noch messbare Erfolge erzielen. Wenn in dieser Situation die Erwartung aus dem Management kommuniziert wird, dass wir in Zukunft x Prozent mehr liefern sollen, dann haben wir ein Problem, weil das dann eigentlich nur noch möglich ist, wenn wir das System überreizen.
Damit meine ich Überstunden, weniger Tests in der Entwicklung, Abkürzungen in der Architektur und der Aufbau von technischen Schulden. Wie Ihr Euch denken könnt, sind all diese Dinge ausgesprochen dämliche Ideen, weil sie uns kurzfristig tatsächlich einen kleinen Schub geben und deswegen sind sie manchmal auch verlockend), mittel- und langfristig aber sehr viel teurer sind.
Eines, was mir hier immer wieder begegnet: ja, es ist uns bewusst, dass wir jetzt technische Schulden aufbauen, um dem Projekt kurzfristig mehr Power zu geben. In Zukunft werden wir die Möglichkeit schaffen, diese technischen Schulden abzubauen. Ist niemals passiert. Lasst Euch darauf nicht ein, wenn Ihr es irgendwie vermeiden könnt. Auch wenn Ihr denkt, dass nach einem Zeitpunkt x die Dinge ruhiger werden, und wir dann tatsächlich mehr Zeit haben werden, ist das noch nie nie niemals so gewesen. Wenn wir einmal eine Bugwelle vor uns aufgebaut haben, ist es extrem schwer, die wieder loszuwerden. Und der Aufwand ist immer sehr viel größer, als wenn wir es von vorherein richtig gemacht hätten.
Wir haben demnach auch das Interesse, unsere Teams und Organisationseinheiten vor überhöhten Erwartungen und Anforderungen zu schützen. Bevor wir irgendwie in die falsche Richtung denken: das ist niemals ein wir gegen die, niemals ein Leistungserbringung gegen Management oder so. Das ist immer eine Zusammenarbeit, muss so sein, denn das Einzige, was uns allen hilft, ist größtmögliche Transparenz. Wenn alle Beteiligten wissen, wo wir stehen, können wir zusammenarbeiten.
Das bedeutet, dass wir offen in den Dialog gehen, was im Moment nicht ideal ist, und was unser Plan ist, wie man das verbessern kann, und alle über diese messbaren Veränderungen im Loop zu halten. Das müssen wir nicht in epischer Breite tun, aber die offene Kommunikation von unserer Seite (meinetwegen auch in aller Kürze) wie der aktuelle ungeschönte Stand unserer Entwicklung ist, wird dazu führen, dass wir auf der einen Seite die Unterstützung bekommen, die wir wollen, auf der anderen Seite auch gesehen und verstanden wird, wenn das Plateau erreicht ist.
Ein letzter Hinweis dazu: ich würde dazu raten, skalierte Rollen und Management proaktiv einzubeziehen. Wenn wir erst dann in die offene Kommunikation gehen, wenn eine Anforderung oder Erwartung an uns gerichtet wurde, ist es zu spät.
Und als Allerletztes, aber vielleicht am allerwichtigsten: Bitte achtet darauf, dass Ihr Euch mit den Personen oder Rollen, die Anforderungen an Euch stellen, auf Metriken einigt. Es ist vollkommen egal, ob das irgendetwas mit WSJF ist oder simple Storypoints, oder wie auch immer in Euren Organisationen Wert oder Output gemessen wird. Niemand möchte Diskussionen auf Basis von Gefühlen und Eindrücken führen.
Kernaussagen:
Wenn wir Teamperformance steigern wollen sind die größten Hebel meistens Befähigung, was ein langfristiger Ansatz ist, oder die Arbeit an Anforderungen und Prozessen, was kurzfristiger wirkt.
Da Steigerungen niemals endlos möglich sind, ist es wichtig, die an uns gerichteten Erwartungen zu managen. Dies ist nur möglich mit größtmöglicher Transparenz und proaktiver Einbeziehung skalierter Rollen und des Managements. Achtet dabei bitte unbedingt darauf, Klarheit zu den Metriken zu schaffen, um jede nachfolgende Diskussion zu versachlichen.
Wenn Ihr mehr erfahren wollt, oder Unterstützung braucht, sprecht mich einfach an.
