Entwicklung & Code
Teamkultur und Fortbildung: Wie kompetent ist dein Team?
Moin.
(Bild: Stefan Mintert )
Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potenzial sieht er in der Leadership; unabhängig von einer Hierarchieebene.
Die Aufgabe, dieses Potenzial zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind.
Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können.
Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.
Ich vermute, dass es in der Softwareentwicklung unvermeidlich ist, sich kontinuierlich weiterzuentwickeln. Als Developer arbeitet man in komplexen Aufgabenstellungen. Das erfordert neue Ansätze und Vorgehensweisen. Gleichzeitig besteht bei jedem Menschen die Gefahr, dass er eine Aufgabe auf die altbekannte Weise löst, die für neue Probleme vielleicht nicht die richtige ist. Das Gegenmittel ist klar: Fortbildung. In vielen Unternehmen, mit denen ich mit meinen Kolleginnen und Kollegen arbeite, gibt es interne Fortbildungsmöglichkeiten und gelegentlich eine externe Schulung. Das ist für den oder die Einzelne eine gute Sache. Eine Frage fehlt mir dabei ziemlich oft: Wie ist es um die Kompetenz des Teams bestellt?
Die Frage gehört für mich zur Teamführung, aber Vorgesetzte braucht das Team für den wesentlichen Schritt nicht: Wie stellen wir fest, ob das Team die richtigen Kompetenzen besitzt und an welchen Stellen eine Verbesserung erforderlich ist?
Im ersten Schritt erstellt das Team eine Liste derjenigen Kompetenzen, die erforderlich sind, um die Aufgaben des Teams zu erfüllen oder die Ziele des Teams zu erreichen. Meist ist die Liste so lang, dass eine Betrachtung aller Kompetenzen den zeitlichen Rahmen eines Meetings sprengen kann. Deshalb stimmt das Team im zweiten Schritt ab, welche Kompetenzen es näher betrachten möchte.
Für den weiteren Verlauf kann man gut mit einer Tabelle arbeiten. Die kurze Kompetenzliste steht in der ersten Spalte – in jeder Zeile eine Kompetenz. Als Beispiel für eine Liste: Java-Programmierung, git-Bedienung, Kommunikation mit Stakeholdern.
Im dritten Schritt spricht das Team darüber, wie viele Teammitglieder die jeweilige Kompetenz auf welchem Niveau (Grundkenntnisse, fortgeschrittene Kenntnisse, Expertenkenntnisse) beherrschen sollen. Auf einem Flipchart oder Whiteboard bietet es sich an, das Niveau durch Farben zu kennzeichnen (etwa Rot, Gelb, Grün). Bei einem Team, das in Java entwickelt, dürften Grundkenntnisse in der Sprache auf Dauer nicht ausreichen. Bei einem Fünfpersonenteam darf man hier das Votum „fünfmal Expertenkenntnisse“ als Zielvorstellung erwarten. Bei der git-Bedienung sind möglicherweise zweimal Experten- und dreimal fortgeschrittene Kenntnisse ausreichend. Und die Kommunikation mit Stakeholdern übernimmt vielleicht regelmäßig eine Person im Team, sodass für die vier anderen die Grundkenntnisse ausreichend sind. Diese Aufstellung der erforderlichen Kompetenzen gehört in die zweite Spalte der Tabelle.
Die restlichen Spalten sind jeweils einem Teammitglied vorbehalten. Hier trägt jede Person in einer Selbsteinschätzung ihr Kompetenzniveau ein. Die fertige Tabelle zeigt dann unmittelbar, wo das Team Defizite besitzt. Im Beispiel: Haben nur drei Personen Expertenkenntnisse in Java und nur ein Teammitglied sieht sich als git-Experte, gibt es Nachholbedarf.
Wie die Kompetenzsteigerung zu erreichen ist, kann das Team in vielen Fällen autonom besprechen und umsetzen. Für eine Weiterbildung in Java braucht es keine externe Schulung, wenn drei Experten im Team vorhanden sind. Hier können teaminterne Schulungen, aber auch Pair Programming weiterhelfen. Erst wenn ein Bedarf auftritt, den niemand im Team abdecken kann, braucht es Unterstützung von außen.
Diese strukturierte Erfassung vorhandener und erforderlicher Kompetenz führe ich mit Teams in größeren Abständen von beispielsweise einem Jahr durch. Die Tabelle ist auch als Teamkompetenzmatrix bekannt. Wenn ein Team eine solche Matrix erstellt hat, lasse ich das Team in Retrospektiven im Laufe des Jahres immer wieder mal prüfen, ob es sich in die (selbst-)gewünschte Richtung entwickelt.
Für mich ist ein wesentlicher Aspekt, dass es sich hier um Teamführung handelt und keine Vorgesetzten beteiligt sind. Das Beispiel zeigt, dass Führung nicht an eine bestimmte Position oder Funktion gekoppelt ist.
Erst Lesen, dann Hören
Im Podcast Escape the Feature Factory greife ich ausgewählte Themen des Blogs auf und diskutiere sie mit einem Gast. Durch den Austausch lerne ich eine zweite Perspektive kennen. Wenn du auch daran interessiert bist, findest du den Podcast bei Spotify, Deezer, Amazon Music, und Apple Podcasts. Wenn du die Themen, die ich im Blog anspreche, in deiner Firma verbessern möchtest, komm’ in unsere Leadership-Community für Softwareentwicklung.
(rme)