Der Auftrag an uns alle lautet, die Performance unserer Teams zu steigern. Immer. Das Wird nicht immer klar ausgesprochen, aber die Erwartung ist immer da. Dass dies nur bedingt und nicht unendlich möglich ist, ist eine Sache, aber eine andere ist, dass Mitarbeiterbefähigung tatsächlich einer unserer wenigen zuverlässigen Wege ist, den Output einer Organisationseinheit positiv zu beeinflussen. Eine einmalige Aktion reicht da jedoch nicht – wie schaffen wir also eine kontinuierliche Teamentwicklung?
Wir wissen alle, dass Teamentwicklung wichtig ist, wir wissen jedoch auch alle, dass diese sehr oft im Daily Busy Business untergeht, was nur dazu führt, dass wir ab und an einzelne Maßnahmen umsetzen, aber eine Kontinuität bekommen wir so nicht.
Ein weiteres Problem ist oft, dass die Verantwortung für diese Weiterentwicklung geteilt ist. Wir haben Scrum Master, Coaches, Teamleads oder wer auch immer bei Euch für die Performance eines Teams geradestehen muss, und auf der anderen Seite die disziplinarischen Führungskräfte unserer Kollegen und Kolleginnen. Die einen sind verantwortlich für die Teamentwicklung, die anderen für die Entwicklung einzelner Mitarbeiter.
Damit stoßen wir auf eines unserer hässlichen Kernprobleme: das Eine kann ohne das Andere nicht besonders gut funktionieren – wir müssen also irgendwie einen Weg finden, diese beiden Dinge miteinander zu verbinden. Ich stelle mir die Frage, warum das so selten gemacht wird.
Und ich wünsche mir für Eure Kolleg*innen eine Person als Führungskraft, die diesen Auftrag ernst nimmt, ansonsten wird das ganz ganz schwer, und wir müssen alles selber machen, aber gehen wir der Einfachheit halber mal davon aus, dass wir zur Abwechslung einmal in unserem Leben Glück haben.
Schritt 1: die Führungskraft und alle anderen Beteiligten mit einbeziehen, was Ihr eigentlich wollt und warum
Alle anderen Beteiligten sind natürlich die Teammitglieder selbst. Mit denen sprechen wir zuerst. Was wollen wir tun, warum wollen wir das tun, und wie gehen wir dabei vor – diese Dinge sollten wir zunächst in aller Ruhe besprechen. Wir wollen eine stetige Weiterentwicklung und nicht nur eine einmalige Maßnahme. Wir wollen das aber auch nicht übermäßig invasiv tun. Das soll nicht jetzt und bis in alle Ewigkeit unser ständiges Gesprächsthema sein. Wir wollen es verstetigen, aber es darf nicht alles überschatten, schließlich müssen wir ja auch noch Dinge liefern.
Sag Euren Teams auch, dass Ihr die Führungskräfte mit einbeziehen wollt, weil das sonst nicht geht. Ein Beispiel, warum das so ist? Individuelle kostenpflichtige Schulungen müssen im Allgemeinen über die Führungskraft freigegeben werden. Die Führungskraft führt die Mitarbeiterentwicklungsgespräche.
Diese Führungskraft holen wir im nächsten Schritt mit an Bord. Das wird vielleicht ein nicht ganz so einfaches Gespräch werden, weil diese Form der Zusammenarbeit zwischen Linie und Leistungserbringung – für mich noch immer unerklärlich – sehr selten ist. Ist unser Gegenüber zur Zusammenarbeit bereit, haben wir eigentlich schon gewonnen, weil uns dann nur noch unsere eigene Disziplin im Wege steht (neben dem Mitmachwillen unseres Teams, aber das setzen wir einfach voraus).
Schritt 2: herausfinden, was wir brauchen und was wir wollen – und das immer wieder
Das können wir auf allen möglichen Wegen tun, aber ich bin faul und simpel und bevorzuge eine einfache Lösung. Eine Kompetenzmatrix kann eine Seite mit einer Tabelle in Confluence sein, oder meinetwegen auch ein Excel File. Die Spalten sind unsere Teammitglieder, die Zeilen eine lange Liste aller für uns wichtigen Kompetenzen. Hier erfassen wir alles: Rein technische Skills wie der Umgang mit für unser Team wichtige Bibliotheken und Frameworks, rein fachliche Themen, damit wir alles über den Umgang mit unserem Produkt wissen, Themen zu Architektur, dem Aufbau der Schnittstellen usw. – wir wollen alles aufschreiben, und wir wollen nicht nur wissen, was wir im Moment benötigen. Wir wollen auch wissen, was wir in Zukunft brauchen werden. Das können wir zwar nicht immer genau sagen, aber wir werden eine Idee haben, was an Weiterentwicklung unseres Produkts auf uns zu kommt.
Ihr könnt die zukünftigen Dinge auch als gesondertes Segment der Tabelle listen. Das macht Euch im Zweifel die Priorisierung leichter.
Und ja, er hat »Priorisierung« gesagt. In gewisser Weise schaffen wir uns ein Backlog. Das können wir sogar in unser Produktbacklog integrieren, damit wir nicht ständig mit mehreren Medien spielen müssen.
In unserer Skillmatrix erfassen wir – das müssen wir nicht in der Gruppe gemeinsam machen – unsere Einschätzung, wo wir jeweils stehen. Wer hat Expertenwissen, wer hat Basiswissen, wer hat überhaupt kein Wissen.
Eine kleine Randbemerkung: beschränkt den Zugriff auf diese Skillmatrix. Wir sind hier sehr tief in sehr vertraulichen Bereichen, weil wir sehr detailliert über einzelne Personen Daten erfassen. Diese Daten gehen niemanden etwas an. Wir bewegen uns auch in einem Bereich, in dem wir unsere Kolleg*innen nicht dazu zwingen können, diese Dinge im Teamkontext zu besprechen. All dies MUSS auf Freiwilligkeit basieren und darf keine Form von Druck beinhalten. Wenn Ihr Euch nicht sicher seid, was Ihr tun dürft, fragt eine Person aus dem Betriebsrat. Die können Euch im Zweifel bei den Fragen helfen, was überhaupt zulässig ist.
Aber zurück zum Inhalt.
Dann müssen wir wissen, welche dieser Skills für uns wie wichtig sind. Was brauchen wir ständig, was nur selten? Wo gehen wir ein Risiko ein, wenn das Wissen auf zu wenige Köpfe verteilt ist?
Aus der Arbeit mit der Skillmatrix ergibt sich für uns eine priorisierte Aufgabenliste – zumindest ist das unser Ziel. Wir erarbeiten gemeinsam – gern auch zusammen mit der Führungskraft – unsere dringendsten Themen. Was tut aktuell schon weh, weil wir da nicht gut aufgestellt sind? Was kommt bald auf uns zu, wobei uns noch wichtige Kenntnisse fehlen? Wo haben wir ein großes Risiko, wenn eine einzelne Person ausfällt?
Das bringen wir in eine Reihenfolge. Ein Backlog wird normalerweise priorisiert, indem wir Kosten und Nutzen zueinander in Beziehung setzen. In diesem Fall konzentrieren wir uns stark auf den Risikofaktor. Wie hoch sind die Kosten der Nichtumsetzung? Wie wahrscheinlich ist es, dass dieses Risiko eintritt, und wie schlimm ist es, wenn wir nichts dagegen tun?
Wir erhalten damit zunächst eine priorisierte Liste unserer Baustellen, haben jedoch noch keine Lösungen. Das kommt jetzt. Ich möchte vermeiden, dass wir über alle Themen jetzt schon in epischer Breite sprechen. Ich möchte, dass wir nur über die dringendsten Themen sprechen, weil die Wahrscheinlichkeit recht hoch ist, dass dies nicht wenige sind. Wenn wir quasi im Vorbeigehen über eine Lösung zu einem unser ganz niedrig einpriorisierten Themen stolpern – geschenkt, nehmen wir mit, investieren aber nicht viel Zeit.
Die Maßnahmen für unsere Liste können sehr unterschiedlich ausfallen. Das können individuelle technische Schulungen sein. Das kann Pair Programming sein, um Themen im Team besser zu verteilen. Das kann eine stärkere Einbeziehung einzelner Personen in fachliche Diskussionen sein.
Lasst die Führungskraft ruhig teilhaben. Diese Person soll verstehen, was wir wollen, was wir brauchen, warum wir das brauchen. Oft genug wird die FK sagen, dass das Ergebnis dieser Runden ihr genügt, auch das ist in Ordnung, wenn wir die volle Unterstützung von dieser Seite haben und wir nicht jede einzelne Maßnahme, die freigegeben werden muss, erneut diskutieren müssen.
Zumindest haben wir nach diesem initialen Kraftakt (und ja, das ist aufwändig) ein Backlog von Maßnahmen, das wir zum einen irgendwo verorten und abarbeiten müssen, das wir zum anderen aber auch stetig pflegen müssen.
Ich würde Euch dazu raten, mit diesen Topics genau so zu verfahren, wie ihr es mit den Maßnahmen aus Euren Retros macht. Ich will schwer hoffen, dass ihr die nachvollziehbar vorhaltet. Vielleicht gehen die bei Euch ins Produktbacklog. Vielleicht habt Ihr ein eigenes Backlog. Vielleicht ist das eine einfache Confluence Seite mit einer Liste, auf der Punkte abgehakt werden. Ist mir vollkommen schnurz. Hauptsache, ihr haltet das alles vor und habt irgendeine Methode zur Nachverfolgung etabliert.
Eine Kollegin geht auf eine Schulung – abgehakt. Ein Kollege lernt im Pair Programming eine unserer Schnittstellen in- und auswendig – abgehakt. Eine andere Person hat sich mit dem PO zusammengesetzt und weiß endlich, wozu unser Produkt überhaupt benutzt wird – abgehakt.
Wir haben die Lücken und Risiken in unserem Team identifiziert. Wir haben Maßnahmen erarbeitet, diese in eine Reihenfolge gebracht und umgesetzt. Alles ist wunderbar, jetzt müssen wir nur noch dafür sorgen, dass wir das regelmäßig tun.
Die von mir bevorzugte Variante ist, einfach zweimal im Jahr über die Matrix zu gehen. Häufiger müssen wir das nicht tun So viel ändert sich nicht. Zweimal im Jahr bereinigen und ergänzen wir die Liste der im Team benötigten Kenntnisse und Fähigkeiten, lassen unsere Kolleg*innen ihre Selbsteinschätzung updaten, identifizieren gemeinsam die wichtigsten und dringendsten Themen, überlegen uns Maßnahmen und priorisieren diese ein.
Wenn wir einmal über den initialen Aufwand hinaus sind, ist die weitere Pflege nicht schwer und nicht viel Aufwand, wir müssen uns nur regelmäßig daran erinnern.
Wenn Ihr mehr erfahren wollt, oder Unterstützung braucht, sprecht mich einfach an.
