Connect with us

Entwicklung & Code

Teamkultur und Fortbildung: Wie kompetent ist dein Team?


Moin.


Escape the Feature Factory: Stefan Mintert

Escape the Feature Factory: Stefan Mintert

(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)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Software Testing: Qualität ist kein Zufall


In dieser Episode sprechen Richard Seidl und Florian Fieber über den besonderen Anlass, dass Seidl mit dem Deutschen Preis für Softwarequalität ausgezeichnet wurde. Diese Auszeichnung bietet den Rahmen, um über die Rolle des Menschen in der Technologieentwicklung nachzudenken. Richard Seidl teilt seine Sichtweise, dass Qualität weit über Testdaten und Skripte hinausgeht und dass es darum geht, ein Umfeld zu schaffen, in dem Teams Qualität aktiv leben.

Seidl und Fieber diskutieren auch die zukünftigen Herausforderungen und Möglichkeiten, die sich durch die Integration von KI im Bereich Testing ergeben.

„Wenn ein Team wirklich Qualität lebt und nicht nur Testfälle schrubbt, dann ist das ganze Thema auf einem völlig anderen Level angekommen.“ – Richard Seidl

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Qualität ist kein Zufall – Richard Seidl“ und steht auf YouTube bereit.


(mai)



Source link

Weiterlesen

Entwicklung & Code

Apple übernimmt Entwickler des Open Policy Agents


Open Policy Agent (OPA) ist eine Software, die Regeln (formuliert in der Sprache Rego) und Datenobjekte entgegennimmt und auf dieser Grundlage Entscheidungen trifft – Haupteinsatzgebiet sind Autorisierungsregeln, die die Frage beantworten, ob ein Nutzer eine Aktion ausführen darf. Weil OPA Open-Source-Software ist (Apache License 2.0) und vergleichsweise leicht in andere Anwendungen integriert werden kann, erfreut er sich großer Beliebtheit in der Cloud-Native-Community: OPA wird unter anderem genutzt, um über Anfragen ans Kubernetes-API zu entscheiden, trifft in Banken aber auch Entscheidungen, wer welche Anfragen an interne Systeme stellen darf.

Erfunden wurde OPA vom Unternehmen Styra, das mit Zusatzprodukten und Dienstleistungen rund um OPA Geld verdient hat. Auf der Homepage findet man die Logos von Zalando, CapitalOne und dem Europäischen Patentamt. Auch Goldman Sachs und Netflix gehört zu den OPA-Nutzern. Der Code von OPA selbst liegt aber nicht mehr in der Hand von Styra: 2018 wurde OPA als Incubating-Projekt von der CNCF (Cloud Native Computing Foundation) akzeptiert, seit 2021 hat es den höchsten Status „Graduated“ erreicht und hat insgesamt 485 Contributors.

Jetzt steht der nächste Umbruch an: Die Erfinder von Open Policy Agent sowie weitere Mitarbeiter des Unternehmens Styra wechseln den Arbeitgeber: Apple, ebenfalls OPA-Nutzer, übernimmt Styra-CTO Tim Hinrichs und weitere Entwickler. Das hat Hinrichs im OPA-Blog verkündet. „Apple ist ein enthusiastischer OPA-Nutzer, der es als zentrale Komponente seiner Autorisationsinfrastruktur nutzt, um ein großes Portfolio globaler Clouddienste zu verwalten.“

Weil der Code bereits in der Hand der CNCF liegt, ändert sich das Open-Source-Projekt nichts. Der Code bleibt Open Source und wird wie zuvor von der CNCF verwaltet. Auch die Liste der Maintainer soll sich nicht ändern. Neu ist vielmehr, dass Zusatzprodukte aus dem Styra-Portfolio ebenfalls Open Source werden und ins öffentliche Repository umziehen: die kommerzielle OPA-Distribution EOPA, die Verwaltungsoberfläche „OPA Control Plane“, mehrere SDKs sowie der Rego-Linter namens Regal.

Website und Rego-Playground (eine Website, um Rego-Regeln zu testen) sollen wie gewohnt weiterlaufen und auch die Entwicklung soll weitergehen. Unklar hingegen ist, in welcher Form das Unternehmen Styra weiterarbeiten wird. Dazu macht der Blogpost keine Angaben. Große Organisationen, die gehofft haben, bei Styra die Autorisierungsexpertise und Beratung von Tim Hinrichs und den anderen OPA-Kernentwicklern einkaufen zu können, gehen leer aus: Diese Expertise nutzt jetzt Apple.


(jam)



Source link

Weiterlesen

Entwicklung & Code

software-architektur.tv: Netflix ohne Bounded Contexts


In der Softwarearchitektur gilt: Systeme lassen sich besser warten und flexibler gestalten, wenn man sie in mehrere Bounded Contexts aufteilt – und das ist gerade bei Microservices-Systemen entscheidend. Doch nun hat ausgerechnet Netflix, ein Pionier der Microservices-Bewegung, einen Blogpost veröffentlicht, der einen ganz anderen Weg propagiert: „Model Once, Represent Everywhere: UDA (Unified Data Architecture)„.

In dieser Episode nimmt Eberhard Wolff den Ansatz von Netflix genauer unter die Lupe und diskutiert, ob die Zeit gekommen ist, die Idee klar getrennter Bounded Contexts infrage zu stellen – und stattdessen auf ein zentrales Modell zu setzen.

Lisa Maria Schäfer malt dieses Mal keine Sketchnotes.

Livestream am 22. August

Die Ausstrahlung findet live am Freitag, 22. August 2025, 13 bis 14 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat, Bluesky, Mastodon, Slack-Workspace oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zur Folge finden sich auf der Videocast-Seite.


(mdo)



Source link

Weiterlesen

Beliebt